Leo Dion (host): Hello and welcome to another episode of Empower Apps.
I'm your host, Leo Dion.
Today I'm joined by Marc Prud'hommeaux.
Marc thank you so much for coming on the show.
Marc Prud'hommeaux (guest): Thanks for inviting Leo.
Leo Dion (host): I'll let you go ahead and introduce yourself.
Marc Prud'hommeaux (guest): Yeah, my name is Marc Prud'hommeaux I am one of
the, co-founders of Skip.Tools, which is a, development environment and tool
set that enables, iOS developers to build their applications for Android.
Leo Dion (host): How did you get started with this idea?
Marc Prud'hommeaux (guest): Well, I've been building apps for, since
the very beginning of the App Store, going all the way back to 2008.
Mostly iOS, but also some Android.
Me and, both my co-founder Abe, in this venture, together
back in 2008, we actually.
Together wrote the first ebook reader for the iPhone called Stanza.
Leo Dion (host): Oh, cool.
Marc Prud'hommeaux (guest): and that was a pretty big hit.
And one of the things after we got, you know, a million users that we kept
getting questions about is, you know, when is Android gonna be available?
When are you gonna, have an Android version?
And we always wanted that.
But you know, when you're coming from a really small team, it's, a really big
ask to write your app a second time.
For Android.
And that's always been the case.
And, Stanza wound up getting acquired by Amazon and Abe and I
worked for Amazon for a while, and then we sort of went our own ways.
Abe worked, at Twitter, head of platform development, iOS,
platform development there.
And I, you know, have done various things working on dozens
of different app projects.
Some really big, like from New York Times and Bose and some fairly small, but.
Always, we've been faced with this prospect of.
Clients who wanna build their application for iOS first.
Because iOS is really, you know, captures the vast majority of
the, you know, dollars in terms of, people who spend money, you
know, on or through applications.
But Android is the other half of the mobile ecosystem.
And you know, people always come into it, you know, very often saying,
okay, we'll design the iOS application first and then Android will be TBD.
And then when it comes time to actually implement that Android side,
that's when people start making hard decisions and asking tough questions.
Do we bring on a second team?
Do we rewrite the whole thing in some cross-platform framework?
And there has been no real satisfactory answer up until now.
So that's kind of the long roundabout way that we got to
identify this, you know, need that.
I think all the app developers universally have, having experienced themselves.
Leo Dion (host): How does Skip tools differ from, something like Flutter
or React Native or Zain, for instance?
Marc Prud'hommeaux (guest): Yeah, I mean, so those are, have historically
been the really big three names in cross-platform app development frameworks.
In general, all three of these application development scenarios bring in their own
individual way of building applications.
Flutter, which is, packed by Google.
You develop using dart, which is their really bespoke language that
is mostly just used for building.
Fluter applications, react native, you write it in JavaScript, that's Facebook's,
you know, framework and, and Microsoft Zamarin, or more recently Volved as mwe.
Yeah.
You write in c And so all, all three of these languages and frameworks are really
alien for both iOS and for Android.
They're both bringing in their entire, you know, alien development stack.
You really need to . Know those languages and really want to
develop in those languages.
The big difference with Skip is that you write your application in Swift
and in Swift UI just using Xcode.
You build and you run your app on iOS and Skip on iOS doesn't
actually do anything at all.
We don't intrude into the framework.
You're writing direct Swift UI.
Using Apple's own Swift UI, where we really differ comes into how
we implement the other half of the platform story, the Android half.
and that is where Skip takes your Swift code and it builds it for Android.
initially the current sort of mature version of Swift 1.0 is that ites
all of your Swift code into Kotlin.
and translation is just the process by which we parse.
Your Swift code and we convert it into Kotlin code and we output that,
and then we build that for Android.
and the end result is that on Android we wind up taking, you know, your
Swift and turning that into Kotlin.
We also wind up taking your Swift UI and turning that into Jetpack Compose.
and Jetpack composed his Androids.
You know, modern declarative user interface language, it is the
recommended Google recommended way of building Android apps.
and you know, they're very, they're very similar.
So it's possible basically to take a Swift UI view and convert that semantic view
into the equivalent Android semantic view.
And that's what we do.
And so the end result.
Is that you don't have, you know, one of these sort of uncanny valley
flutter applications where it's kind of mimicking the NATO platform
experience and things like that.
We have real, you know, honest to goodness native of apps using both of
the platforms' common recommended idioms.
Leo Dion (host): Flutter is building directly to machine code, right?
It's like kind of using core image to kind of, or C or Objective C to
basically write directly on the screen.
I'm not sure how React native works.
and my experience with React Native hasn't exactly been positive.
So I feel like if it does work, it's amazing, when it does.
but I'm not sure if that's like a. HTML web view or how, do you have an idea how
React native works behind the scenes?
Marc Prud'hommeaux (guest): Yeah.
Yeah.
So, so you're right with flutter.
I mean, flutter is actually just drawing every individual pixel on the screen.
and then they have, you know, a variety of sort of themes that you can apply.
Like they have one that's called the Cupertino theme that sort of makes,
you know, sliders look like iOS native sliders and sort of makes text
boxes kind of look like text boxes.
you know, enough to sort of . pass a screenshot test and
be like, ah, that looks sort of native and that's good enough.
react native is different.
They actually do wind up rendering onto Native controls, but they're
using the React layout, system.
They're basically using CSS flex boxes to lay out the components and get them to,
you know, show up on the screen in kind of the same way that you'd write a webpage.
But . Instead of rendering to HTML elements, they're kind of rendering to,
you know, text fields and, you know, sliders and, and things like that.
Leo Dion (host): And then Sam or Maui, I would assume is more like,
I don't know, kind of compiling directly to an app and then it has a
bunch of extensions added on top of it.
Marc Prud'hommeaux (guest): yep.
Yeah, that's right.
So, yeah, so, you know, react native, they are all JavaScript and it winds up just
being interpreted on, on the device and, and they're . A JavaScript, interpreter.
but Flutter and Zamarin, they both do compile down to, you know, machine code.
and they're shipped as, as binaries, but they also do have
garbage collectors built in.
so it is kind of a Java ish scenario on both iOS and on Android.
Leo Dion (host): Okay.
If that makes total sense.
So as somebody who has never developed an app for Android, I kind of wanted
to cover a few things that iOS developers might not know about.
So let's start off by saying, what are like some major differences that
you've seen with Kotlin and Swift?
Marc Prud'hommeaux (guest): Well, you know, they really come from the same
. next generation kind of language push.
You know, Kotlin is really replacing, has replaced Java for Android development,
just as Swift has more or less replaced Objective C development for, for iOS.
And both of these languages, you know, are very, you know,
heavily stress, type inference.
and, you know, declarative design,
Kotlin is, you know, I always say if you squint hard enough,
Swift looks just like Kotlin.
you know, you can say, you know, var X equals A, B, C, you know, funk do thing,
and then, you know, arrow return value.
There's a couple of fairly minor syntactic differences, but, you
know, you can, you can sort of cobble together a Hello world main program
in Kotlin and it looks a lot like.
you know, Swift.
so it's, it's similar enough that you can imagine, you know, just writing a regular
expression or something and taking your Swift program and turning into Kotlin.
the more advanced things like generics, and converting value types like
structs and things like that, some of these don't have an exact equivalent
in Kotlin, and that's where the.
The translation of the Swift into Kotlin starts to get really, really complex.
and that's, that's where the Skip plugin does all the heavy lifting for you.
Leo Dion (host): So is there, like, they don't have generics quite
the same way that that Swift does.
Marc Prud'hommeaux (guest): Yeah.
Simple, basic generics work more or less the same.
You can have a collection that does, you know, on a generic type,
Leo Dion (host): Okay.
I could see how that would be kind of a pickle.
Marc Prud'hommeaux (guest): Yeah.
But, and, and generics on protocols do wind up getting implemented
pretty diff fairly differently on interfaces in lin interfaces are,
are, are the equivalent there.
and then on top of all of this, the fact that Kotlin is built on top of Java and
is running in a JVM, regardless of where you're running it, be it on Android or
on a server or on your desktop, Java has historically made these very controversial
decision to erase your types.
So they do this thing called type erasure.
So those types don't actually exist to the knowledge of the runtime environment.
And so that means that we have to tack on a good amount of metadata in order
to be able to accomplish some of the things that come naturally with, Swift,
where you do always know, you know what the generic type is at, at runtime.
Leo Dion (host): Are there any performance disadvantages with using
Swift and then having it with all the additional metadata and such?
Marc Prud'hommeaux (guest): Not really.
You know, we, we attempt to . you know, distill things down, compile things
as idiomatically as we possibly can.
you know, Kotlin in general, it is a garbage collected environment.
and they have no native value types there.
There's no equivalent to a structure in Enum, in, in Swift.
you know, so, you know, what we have to do is we have to wind up.
Translating, you know, your structs and your enums your value types
into classes in Kotlin in such a way that it preserves the copy and write
semantics that Swift offers you.
Leo Dion (host): Okay.
Marc Prud'hommeaux (guest): and so that is gonna be not as
efficient as the Swift version.
I mean, it's, it's just, it's not, it's turning into, it's running, you
know, on A JVM, it's garbage collected.
but that being said.
We don't really have never really encountered performance issues with it
because in general, Android is designed to accommodate this sort of . You
know, additional memory, overhead, you know, the higher watermark, the
garbage collection and things like that.
the statistic that I read is that on average the equivalent sort of
quality Android phone to, you know, the, the, the, their iOS version, you
know, the premier premium, you know, levels and the, and the mid levels
they want, they tend to have twice as much RAM as the equivalent iPhone.
Version does.
and that is largely to accommodate, you know, the additional memory
overhead that you need for Java and
Leo Dion (host): Right, right.
That makes total sense.
So let's move on to the UI part.
What's the big differences between Jetpack Compose and Swift UI?
Marc Prud'hommeaux (guest): well.
As with, you know, I say Squint hard enough and Swift looks like
Kotlin squint hard enough, and Swift UI looks like Jet Pack Compose
Yeah, just went a little harder.
because, you know, the, the structure of Jetpack Compose, you know, Swift.
Sets up views in a hierarchy of these structs
Leo Dion (host): Mm-hmm
Marc Prud'hommeaux (guest): have a body.
and the body might have, you know, a vs stack that contains a text
field and a slider and a button.
and Jeff had composed you more or less have that same sort of declarative
outline of your views, differences that they're done in, global functions.
And top
Leo Dion (host): Oh, okay.
Marc Prud'hommeaux (guest): rather than infuse.
Yeah.
And so those functions are the things that sort of track the state access
that takes place inside of them.
and marks those, once the state gets marked as dirty marks those, as being
needed for what they call recomposition.
and recomposition is essentially where the view knows that it needs to redraw.
Leo Dion (host): I was gonna say a big thing is like you're losing
a lot of the power generics and do they even have a DSL in JPAC Compose?
Marc Prud'hommeaux (guest): They not quite like as good as Swift does.
they're really working more with what they have in Kotlin, but
they do have a composed compiler.
you mark your functions as what they call composable.
and that winds up being run as a Kotlin compiler plugin, once it is
Leo Dion (host): So it's kinda like a macro in a way.
Marc Prud'hommeaux (guest): Yeah.
Leo Dion (host): yeah.
Marc Prud'hommeaux (guest): it's a lot like a macro.
And so these composable functions, they have additional metadata
that's tacked onto them.
Basically a context that's being passed through that has, you know, hooks that
grant access to all of your state, to, you know, all of your environment, all
the things that it needs to know in order to be able to, you know, know when you
need to recompose these, these views.
Leo Dion (host): So how, like, so I did actually build an app.
I followed through on the example.
and it was like, I, I recently ordered a pixel for a 'cause.
I wanted something cheap and like small to work with and,
built a app and it was amazing.
How does like the build process work on Android different from like Xcode build
and deploying to a simulator or device?
Marc Prud'hommeaux (guest): Right, right.
So, you know, again, . Android has all these mirrors to what we're, you
know, you know, we have in the iOS development world, you know, Swift has
Kotlin, Swift UI has Jetpack Compose.
In addition, Swift Package Manager has an equivalent in
the Kotlin world called Gradle.
and Gradle is a ancient build tool that, you know, goes back really, you know, to
to early times used to be done in Groovy.
Now it's, it's native DSL is Kotlin itself.
Similar to how Swift Package, Swift Files, yeah.
Are implemented in Swift, Gradle implements those in in Kotlin.
and so you write in whatever build logic that you need and it has its
own DSL for declaring dependencies and declaring multiple modules.
And you know, more or less everything you have in a package Swift you can
accomplish and, build gradle dot kts file.
and so what the.
You know, skip Stone plugin does automatically as every time you rebuild
your application, you know, we, we convert your Swift Kotlin, we convert
your Swift UI to JetPack compose.
We also take your Swift package manager package Swift, along with
any dependencies, and we convert that into a mirror tree of Kotlin Gradle.
project builds.
and so you wind up having this parallel structure that is automatically
derived from your Swift build every time, every time you build.
So then you have this, this, you know, forest of, of Gradle build files that,
you could run manually if you wanted to.
You just run great old build in, in the correct directory.
But what what we do is as part of the template application that you create
when you run the skip and net command, we add a build phase into Xcode such
that when you launch your application, it winds up invoking gradle, launch
debug, on the trans pile version of the Gradle project so that every time
you build and run your application on the iOS simulator, on the iOS device.
The equivalent transpiled up to date Gradle, project is compiled
and run on your attached, Android simul, emulator, or Android device.
Leo Dion (host): so ever have you ever used like tourist?
Marc Prud'hommeaux (guest): Yes.
Leo Dion (host): So I mean, it sounds like basically their stuff
is set up all in Kotlin, similar to how tourist has the whole exit
project set up in Swift, essentially, and then you could go from there.
it's, that's what I'm hearing.
I don't know, but it sounds a lot like that, which is, which is kind of cool.
Marc Prud'hommeaux (guest): Yeah.
Yeah, a little bit.
Now we don't, we don't use tourist on the side of how we
create the Xcode build file.
Leo Dion (host): Right, right.
No, I just mean like the fact that you can create an Xcode project using Swift, you
can create an Android project using Ling.
So I guess that's what I'm, I'm using the parallels there.
Marc Prud'hommeaux (guest): Yeah, exactly.
And that has the benefit too, that you know, not only do you, can you
build and run this from Xcode, which is really the common development
cycle that iOS developers will want to use, but you can also take that
same, you know, build Gradle dot kts.
And you can invoke it.
You can open it in, in Android, ID like, Android Studio or IntelliJ.
and all of these have built in support for Kotlin, Kotlin Rale files.
And so that's how you can basically take that, take that application and
open it in Android studio, and then you can have access to all of the
Android studio tools that you need.
Like, you know, analyzing the size of the generator artifact, running
the debugger, and things like that.
Leo Dion (host): so the.
I first, I think I've heard of the project, the skip tools before, but really
intrigued me was the, post I think you had on LinkedIn where you were showcasing
Biff packages that are compatible.
And I'm a big fan of Swift Package Manager is imperfect as it is, and it was cool
to see like all these libraries that were available like to use already on Android.
how does Skip,
how does it employ Swift Package Manager throughout its.
It's development and we'll talk about external LI or internal
libraries that Skip has.
But, how does it use Swift, Swift packages?
in, its, in the, the development and piling operation
Marc Prud'hommeaux (guest): So, you know, we always say this project wouldn't
have been possible a couple years ago.
It was really the advent of Swift package manager build plugins
that made all of this possible.
and build plugins are, you know, basically a, you know, plugin line that you add
to, your project dependency that is, you know, defines an action that can get run.
Whenever you perform a project build.
and that's really what unlocked the ability for us to hook right into
Swift package manager's, build process and be able to do things like, you
know, parse all of your Swift files and be able to, to convert them
into, into Kotlin on, on every build.
and so that really also makes it independent of Xcode at all.
You know, you can run.
This process, you know, the build process, just using Swift package build,
on the command line, which is great for continuous integration as well because,
you know, for all of our packages, both our core packages like the Skip UI and
Skip Foundation packages, but also for our external packages like Skip Firebase
and Skip SQL and things like that,
Leo Dion (host): Okay.
Marc Prud'hommeaux (guest): you can just build and test as part of a GitHub
action, which is, you know, has been fantastic for us for quality control.
Leo Dion (host): So, so like I build a lot of my apps using Swift Package
Manager is basically the code base and.
something like Truist to then bring that in and use that to build an app.
how would I, like, let's, how would I move forward with, with some of my
current apps to get those over to Android?
if everything is basically in Swift Package Manager, should I still employ
something like tus and then, and then run skip tools on top of that?
Or what would you recommend?
Marc Prud'hommeaux (guest): Probably what we generally recommend is that,
you create or initialize basically a blank skip project using skip a net and
what, what that winds up doing is it creates, so the core of everything is
a Swift package manager package Swift.
But when you create, an application project using.
Skipping it and passing the app Id.
it additionally creates both a, Darwin folder and an Android folder.
And the Darwin folder create, creates a, you know, app named Xcode Project.
and that's kind of an empty shell of a project.
Really all it does is it references that Swift Package manager.
Top level package.
so in some ways it's kind of an unusual Xcode project because really it's just
all it's doing is wrapping, wrapping a SPM project, and then providing additional
metadata like, you know, the application icon and you know, the entitlements and
all of the, all the extra stuff that.
Needs to go into building a real application.
but it is really sort of a hollow, kind of a hollow application, a hollow project.
It doesn't have, I think it has one source file just 'cause it needs a main method.
but you know, other than that it just really references the
Swift package manager module.
so generally, and, and that's sort of a, a very customized
xcode project that it creates.
So we generally recommend that people . Create one of these kind of empty
projects and then bring in their code, sort of piecemeal into the application.
and then it might be a iterative process, right?
Because not, maybe not everything is going to transp pile out of the box.
And so, you know, sometimes it won't be working on the very first build and run.
but we provide you with a lot of guidance and, you know, warnings
and, and things like that.
If, if it doesn't build at first.
Leo Dion (host): Where would you recommend somebody be like this, this tool is great,
but there's a few spots where you might wanna actually write some Kotlin code.
Where would that be the best fit, I guess?
Marc Prud'hommeaux (guest): Yeah, so we have, in our docs is a platform
customization guide and there's a variety of ways of doing this, of, of
basically dropping in custom Kotlin.
And there's a lot of reasons why you would need to do so.
You know, there are plenty of, you know, we trans, we translate, you know, a lot
of Swift UI into jet pack compose, and we translate a lot of your foundation.
Libraries into the equivalent Android libraries, for example,
like URL and, you know, file manager calls and things like that.
but there's always gonna be things that are very iOS specific that
aren't gonna just automatically translate into the Android world.
and in those cases, you know, the easiest solution is just to drop
The equivalent Kotlin call right into your Swift code.
and the way that we accommodate that is we have these, pre-processor blocks that
are just like pound if skip, and if you put code in there, X code will ignore
it and the iOS build will ignore it.
But we, it's part of the skip stone plugin will process that and pass
that over to the generated kotlin.
So you can actually just drop raw Kotlin right into . The middle
of your Swift code, and then be able to be able to work with it.
and it looks pretty weird at first, just sort of like you're
using Java idioms, right?
You have Java package names and you know, you have sort of
some Kotlin, you know, syntax.
but Xcode is happy to ignore it, on the, on the Swift side.
And so that's really the sort of quickest way to basically say
there's this iOS specific call.
There's no . obvious, you know, translation available for it.
So I'm gonna do this thing on the Android side and I'm gonna make,
you know, what I deemed to be the equivalent call and then work with that.
that's really the, the first level way of, of dealing with that,
of, then there's the second way, which is a little more elaborate.
You know, sometimes it's not like one or two lines.
Sometimes a whole, you know, big Kotlin file of logic that you don't
wanna . Paste into Xcode, you know, and, and sort of massage until,
you know, the, the syntax works.
You know, lines are quite right.
So you can also just drop in a Kotlin file into a skip folder in
your Swift package manager package.
and then that again, will get ignored on the Swift side, on the iOS side.
but that will just be brought straight into your Kotlin build.
and then you can reference that from code within if skip blocks.
Leo Dion (host): Oh, okay.
So you could like build a class in Kotlin and then reference
that class in your if skip.
Okay.
Very cool.
Marc Prud'hommeaux (guest): that's right.
And then, and then there's, there, there's a third, you know, the sort of next level
up is actually having a Kotlin dependency.
you know, I mentioned Skip takes your . Your sort of network of, of
Swift package manager projects and converts it into a Kotlin equivalent.
It only does that for packages that support the skip stone plugin for
basically packages where you had planned on having it work with Skip.
you can also have any dependencies you want on the iOS side, like you
can depend on projects that don't have any knowledge of Skip or anything.
but those won't . Exist on the Kotlin side.
They won't be transpired, they won't be, you know, referenced.
however, what you can do is in the skip side, you can add dependencies just like
you can on the Swift side, dependencies
Leo Dion (host): Kotlin libraries,
Marc Prud'hommeaux (guest): Exactly, yeah.
And there's a, there's sort of an
Leo Dion (host): their equivalent?
Marc Prud'hommeaux (guest): Their equivalent is called Maven dependencies.
Leo Dion (host): so it's, yeah, which is the Java one.
Marc Prud'hommeaux (guest): Yeah, exactly.
And so you basically, you, you know, basically say I depend on, you know, com,
Google Firebase, you know, colon 1.5 0.3, you put that in your skip, there's a skip
configuration file on a per Swift package manager module basis called Skip Do yaml.
you basically list those dependencies in there and then in the derived
Kotlin, Gradle . Project, it will have the dependency on those libraries.
And so then inside of, say if skip blocks or inside of, you know, your
raw Kotlin, you can just import those packages and you can use them directly.
Leo Dion (host): As of the today, the record day of recording,
Giannis had posted the, Swift on Android work group, and.
I wanted to ask about about that, but before I do, is there, I do a lot of.
Stuff with Lin like Aun or Linux as well as the Apple platforms, and I know we've
had Windows stuff for quite a while.
is there already any, like pre-processor directives or anything with available Mac?
not the available macro, but the available attribute, that are specific
to saying that a certain method is or is not available on Android.
That are either compiled time or runtime, I guess outside of Skip,
Marc Prud'hommeaux (guest): Yeah.
Yeah.
So there is, so there are.
The Android work has been going on for, you know, many years by, you know, not
just us, but a large community of people.
There are some pre-processor checks.
You can do FOS, Android, then do this and you know, else do that.
There's not currently, unfortunately, 'cause that'd be really useful for us.
There's not currently any way to annotate a, a function as being, or class as being
available or not available at Android, similar to the way that you can do it
on . Tv, VOS, this is not available.
Watch os this is available.
that'd be a great addition.
Something that not just Android people, but Linux and Windows
people would also find useful.
Leo Dion (host): Yeah.
I mean, even Linux people like I, I end up having to do like if can import,
is my work around for that sometimes.
Marc Prud'hommeaux (guest): Yeah, that's what we do as well.
Yeah, we do.
If can import, Android is the name of the module for, for Android,
you know, packages, so you can do, if, can import Android.
I, I wrote a blog post recently that's gotten some traction,
mentioning that Swift everywhere.
Package about, you know, how you can get your package working on
native, native compiled Android.
and, you know, 90% of the time is just adding in a, if can import
Android, then import Android.
Elif can import Darwin, import Darwin Elif can import
Leo Dion (host): Right, right, right.
Marc Prud'hommeaux (guest): yp, import Eucalyps and Portugal.
And
Leo Dion (host): Yeah.
Yeah, yeah, yeah.
That's, that's a really good call.
I like, the one I'll do is like, if can import 50 Y, for instance, is a
Marc Prud'hommeaux (guest): Exactly.
Yeah.
Leo Dion (host): So, yeah.
And then like on the Swift package, can you, I, I bet you can't even say what
Android version you support in the Swift
Marc Prud'hommeaux (guest): No, you can't say, but yeah, no, it's, it's
still, all that stuff is really limited to Darwin platforms right now.
But that's one of the things that we really want this android working group
to, to really get underway with, with helping push is, you know, expanding
those to, to support the other platforms.
Leo Dion (host): Well, let's, let's get into that.
What, what are you looking forward to when it comes to the Swift, and Swift
on Android work, work, reading group?
Marc Prud'hommeaux (guest): So I should prefix this by saying that
everything I've been talking about thus far has really been Swift, skip 1.0
where everything is transp compiled.
and what, you know, that takes your Swift and turns it into Kotlin, and builds it
just like a regular . You know, Android app, a hundred, you know, everything going
into it is gonna be Kotlin or Java code.
There's no native code at all.
and that has been working, you know, great so far.
But as I had mentioned, there are some limitations in transpiration.
You know, there are some limitations around, generics.
there are some, you know, there there's some sharp edges.
Like you can't have retroactive conformance to protocols for types
outside of your current module.
You know, there's kind of a list of things that are just . Just impossible
to accomplish with translation.
so that's one shortcoming of translation.
Another one is that in order to depend on another Swift package
from your . Trans pilot skip code.
That package also needs to be aware of Skip.
It needs to have the skip stone plugin being run and things like that.
and not every package is gonna want to do that.
You know, not every package is thinking about Android or, you know, really
wants to bring in that dependency.
Um, and so for the past, about the past year, we've been working on integrating
natively compiled Swift on Android side by side with the trans piloted.
Swift on Android and that that sort of complicates everything a
little bit because sometimes your Swift is turned into Kotlin and
compiled with the Kotlin compiler.
Other times your Swift is just compiled directly to Android using
the Android, Swift tool chain.
and then what Skip winds up doing is, using the skip fuse
package, it automatically and transparently builds a bridge.
between your Transpi Swift and your Compiled Swift.
so that for, you know, the, the common example is, right now if you run, skip a
Knit for a, you know, new, new application package and pass native to it, what it
will do is it'll create an application, sort of a Hello World application that's
like a little cred app, with create, read, update, delete on a little Jason file.
and without Native, that will create two modules.
A, you know, a UI module with all the Swift UI and sort of a data model, module,
with the, you know, model handling code where it, you know, is a observable view
model and it, you know, reason writes from adjacent file and things like that.
so in pure transpired mode, those are both.
done in Transpile, Swift that will turn into, into Kotlin.
When you run that in native mode, what that will do is the Swift UI is currently
still transpile into Jetpack Compose, but the view model code is actually
gonna be compiled directly to Android.
Leo Dion (host): nice.
Marc Prud'hommeaux (guest): then . They communicate back and
forth as you know, using Swift observability, using the bridge that
winds up getting automatically built.
Leo Dion (host): Okay.
Marc Prud'hommeaux (guest): So what that grants you is your view model code, your,
all of your model code that can have any dependency on Native Swift that you want.
It can use Alamo Fire, it can use, you know, the point free company,
you know, Swift snapshot testing.
It can use basically any of these packages that are already building natively for
Android and unlocks that entire huge ecosystem, you know, growing ecosystem
of, pure Swift packages that you can, you can start taking advantage of.
Leo Dion (host): That's pretty amazing.
you think that's like pretty much the future is going with
compiled as opposed toed?
Marc Prud'hommeaux (guest): Yeah, in order to give real reach to all of your
code, you know, to have it be sort of true, a hundred percent compiled Swift,
We do think that that is probably the future, for, you know, for simple
apps or apps that don't have a lot of dependencies, things like that.
you know, . People can perfectly, you know, stick with the transpile
process that has been working so far.
You know, we've shipped half a dozen apps and there are other people,
you know, many other people that are shipping apps today that, that use
that approach and that approach has a few advantages of its own right.
It, you know, not having to embed all of the Swift libraries
means it's a much smaller binary.
Shipped on Android, debugging.
That's a much easier story when it's all done in Kotlin and, and Java.
You know, if you have a crash in Swift and debugging that on Android,
there's currently some challenges that we're gonna be working with
this working group to overcome.
where, you know, you see these ma.
Leo Dion (host): I mean, are we talking Android support on Xcode?
Like I, I don't even know how you would get there.
Right?
If you're gonna step through a piece of pre transpired Swift, right.
Marc Prud'hommeaux (guest): Yeah.
Yeah, I mean, we'd love that.
You know, we've, we've, you know, communicated with Apple
that that'd be a great feature.
I don't see that happening right away.
Leo Dion (host): right,
Marc Prud'hommeaux (guest): So, so, you know, you can, you know, if you
open your project in Android studio and you run it in a debugger, you do get
some native support for that debugger.
But you know, you've probably seen mangled Swift names.
You know, in, in the past, and they're not easy to Digest or understand,
and you can't jump to the line and, you know, so, so there are
challenges with purely native code.
but overall, you know, we feel that as this technology evolves,
which is currently in still in early access tech, you know, tech
preview, release, but it's, you know, available and people are using it now.
We think the benefits really outweigh the disadvantages because it is, it is
real Swift, so you have true value types.
You're really, you know, you're running real native compiled code.
It's gonna be more memory efficient, and you have access to this entire, you know,
galaxy of, of wonderful Swift packages.
Leo Dion (host): Going back to that question I had earlier, earlier
about how does it differ, like we're talking about being a little bit more
like flutter in a way, as opposed to like the transation, which I don't
think anybody really does, right?
Marc Prud'hommeaux (guest): Yeah, no, to my knowledge, I think there have been
a couple of academic experiments with translation, but to my knowledge, you
know, we're really the only ones that are doing that level of, you know, you
can develop a full app using transation.
Leo Dion (host): one thing I wanted to come back to is, as far as the translation
is concerned, would anyone ever want to edit the Transp piled code or would they
ever want to commit it to their repo?
Or is it something that should be done way behind the scenes?
And don't touch it.
Don't look at it.
Marc Prud'hommeaux (guest): We're happy to have you look at it.
Actually, you can just open it right in X code and, you know, look at
them side by side and, and we have some map back line numbers when there
are, you know, the errors and things like that back to the original Swift.
So we're happy to give you access to it.
Leo Dion (host): But
Marc Prud'hommeaux (guest): don't, we don't read backend
changes that you make to it.
You know, we, we mark those files that read only, and if you unmark them and
make a change to it, they're gonna get lost the next time you build.
Leo Dion (host): So the intention is to just let the bill tool
use it as part of the process.
But don't, I mean, almost now that I'm thinking about it, it almost seems like,
like Babel, I guess would be a good comparison on, on an NPM or, or node
where it's like, oh, you know, this.
Used to have browsers, right, that didn't have TypeScript support, for instance,
and you'd use something like that to it.
So it can actually be used in in the browser.
Browser essentially.
It almost, this is kind of what it sounds like a bit,
Marc Prud'hommeaux (guest): a good equivalent is like TypeScript JavaScript.
You generally don't expect to be able to mess with the resulting
JavaScript, and then, you know, affect the original TypeScript.
Now all that being said though, you know, skip is a commercial tool and
you know, we sell the Transer plugin.
However, . And the output of the skip process is still your own code.
Leo Dion (host): Right.
Right.
Marc Prud'hommeaux (guest): we have a mechanism for exporting your project.
It's command, the skip export, it takes your entire project and it creates
a fully buildable runable Android.
I. Project, you know, that uses Jetpack Compose and, and everything, and it's
completely separate from needing any of the skip, you know, build tools.
And that's what we call adjustability.
That basically means like, say you decide down the road, you
don't want to use Skip anymore.
You, you know, you developed version 1.0 of your app and you know, maybe
you decided I'd rather just go my own way and have a Kotlin team and
take your app and go with that.
You're perfectly free to take that resulting exported project.
And hand it off to your Kotlin team, and they can go their own way with them.
Leo Dion (host): right.
Marc Prud'hommeaux (guest): it won't be pulled back in to your single, you
know, Swift source base, but it is your own code to do with whatever you want.
Leo Dion (host): Yeah.
Awesome.
I just, I wanna cover a couple of questions that we got from the audience.
Danny Bahar asked about, curious how Skip handles 50 Y
UI kit representable ice cream.
Skip doesn't transpose map Kit.
PDF Kit Pencil Kit.
A way to write Lin code for certain parts of your app in order to fill those apps.
Looking forward to the pot, looks amazing.
So you kind of answered some of the stuff already.
I'll just kind of paraphrase.
So UI Kit, is that supported at all?
Marc Prud'hommeaux (guest): No, not the vast, but a little bit of
it is like, you know, we have some UI color and UI font sort of the
things that are needed for support.
But the ui UI view representable, we don't have direct support for that
because we don't transp pile UI kit views.
But what we do have is an equivalent on the composed side called Composed view.
and so when you want to sort of, interface . With more legacy views.
You know, Swift UI, you have Legacy UI kit you want to interact with.
Same thing on Jetpack Compose.
They have their legacy Android views, not all of
Leo Dion (host): What is that?
Marc Prud'hommeaux (guest): it's, they just call it Android views.
. There's no, there's no other name for it.
They're the old school, sort of.
You write XML, you know, views and you build them up.
But there's a huge . Pool of these that have have, you know,
evolved over, you know, a decade.
Leo Dion (host): right.
Marc Prud'hommeaux (guest): and so there's the equivalent in Jetpack
Compose where you can, you know, insert old school, you know, legacy Android
views using what's kind of the Android version of UI view, representable.
and so what you wind up doing and, and the way that we handle things like
say, . well actually MAP Kit recently did get a UI view, but . Pretending
for a moment didn't, or say, sorry.
WK web view, that's a really common one.
what you would do is you'd use this if skip block mechanism where you'd
say, you know, if not, skip, in other words, if you're running on iOS, do the
UI view representable and you put in a web view in there, and then you do
all the stuff you need to do with sort of a, a complicated and large task.
And then on the Android side, in the else, if Skip, You would use a compose
view and you would drop in a Android web kit, web view, you would do sort
of the equivalent, you know, management shuffling around of, of state and,
and dealing with all that stuff.
and it's something that people do very commonly using Skip, because that's,
that's one of the real selling points is that, you know, unlike frameworks
like, you know, flutter or React native, we're, we're making a bridge as a
Gigantic and complex and very involved task.
You can just drop this stuff right into your Swift file and you can, you know,
start iterating from there and see it come right up on your . On your Android screen.
So even though it might be a little bit, you know, complex and daunting at first,
you know, you can get pretty far just by, just by dropping, you know, code in there.
We have a, we have an app that's actually available on the App Store, in the
Google Play Store, called Skip Showcase.
and, and that is more or less a list of, I think all of the Swift UI.
You know, views, view types, you know, there's a, a navigation list for,
you know, sliders and date pickers.
I'm actually, I'm looking at it right now, and gesture, recognizers
Leo Dion (host): this is on the, the Google App Store or the,
Marc Prud'hommeaux (guest): It, it's on,
Leo Dion (host): the Google Play Store.
Marc Prud'hommeaux (guest): Yeah, so it's on both the App Store and the Play
Leo Dion (host): Okay.
Marc Prud'hommeaux (guest): and it, it's, it is really useful when people
are evaluating Skip, because you can bring this app up, skip showcase on both,
and you can be like, okay, what does a picker look like on both of these?
And you can see exactly how the picker appears, you know, in
the user or the progress view.
Leo Dion (host): So I wanted to ask, what if you add something
that is not supported in Android?
What will end up showing up in Android?
Marc Prud'hommeaux (guest): So it is whatever you wind up
doing in the, if not skip block,
Leo Dion (host): What if you forget to?
What if you have, just like throw in a map view in Swift y and then you
transpire what's gonna end up happening?
Marc Prud'hommeaux (guest): It would, well, if you didn't guard
it inside a NIF skip block, then there would be an error once you
get
Leo Dion (host): a compilation error.
Marc Prud'hommeaux (guest): a compilation
Leo Dion (host): Okay, cool.
I was just wondering how, at what point the line would you get a
warning, so that's good to know.
Marc Prud'hommeaux (guest): so we have, we have a couple.
We have the at the Build . Processing time.
Basically when the build plugin runs, when you kind of doing the pre-build, we do
have a, a bunch of mechanisms for warning you as well when something is missing.
so for example, if there is some Swift DI view that we don't yet support, we
mark that in skip as being unavailable.
So you'll very quickly get a nice, a message that says.
This API is not available.
Maybe a suggestion for what you can do.
if you don't hit that, then you will wind up when it tries to do the gradle
build and build for Android, you'll wind up with a compilation error,
which might not be quite as friendly as the ones that we surface earlier on.
Leo Dion (host): Right.
I, as long as it's not something that you're gonna put on the
Google place or, and find out that
Marc Prud'hommeaux (guest): Right.
Oh, yeah.
No.
Yeah.
So unlike say like React native, where you know JavaScript, hope you tested
every possible runtime branch, you know, you still do have a compiler
going on here, so you're not gonna just like wind up missing something
and having a crash or a crazy error at,
Leo Dion (host): Right, right.
I did wanna, I, I, I do wanna give you a chance to mention that there are some
extra frameworks available with Skip.
so stuff like Skip web for doing specific web views and
things like that are available.
so
Marc Prud'hommeaux (guest): Yeah, we've got.
Leo Dion (host): you, you do have some stuff to kind of make that bridge.
easier.
Marc Prud'hommeaux (guest): Yeah, we have a whole, a bunch of
packages that are, you know, sort of commonly used by applications.
You mentioned skip web.
That's really common for dropping in an embedded web browser.
And actually that's a good package.
And all of these are free and open source on GitHub under the Skip tools.
Skip tools repository list.
That's actually a pretty good one to take a look at.
If you're curious about how you have these parallel implementations between
Android and iOS, because that is essentially just doing what I described
where you have a UI view Representable on the . iOS side and you have a composed
view on the, on the Android side.
but yeah, so you know, we have like, that, we have Skip sql, which runs
on top of, you know, SQL Light.
So you can, you know, write to SQL databases.
We have Skip Firebase, which is actually a pretty interesting one
because Skip Firebase, you know, we, we obviously did not reinvent . The
Firebase APIs on the Swift side, we, we just run directly against the Google
Firebase Swift SDK that they provide.
we don't actually interpose ourselves at all.
You just are calling the Google APIs directly.
and then on the,
Leo Dion (host): Is Fire bakes built into Android?
Marc Prud'hommeaux (guest): no, no, it is a separate, it's
a separate package and, and
Leo Dion (host): really?
Marc Prud'hommeaux (guest): Yeah, so, so it does interface with Google
Mobile Services, which is part of many Android distributions, but is
also a separate, somewhat separate component because for example,
Leo Dion (host): not like cloud kit where everybody gets cloud kit when
Marc Prud'hommeaux (guest): Right.
No, it's not, it's not baked in a hundred percent of the places.
so you know, also in general, like Jetpack Compose is not part of Android as well.
Like all of these things, unlike say, Swift UI, which is bundled as
part of the operating system, all of these things are really brought in
at build time and bundled as part of your app, of your application package.
And so Firebase is one of those that, that is built in, that is bun,
sorry, bundled in, not built in.
and what we wind up doing with our Skip Firebase support is that since
Google is pretty good actually about having these two APIs be very similar
in terms of just like type names and method names and things like that.
Our skip support for that.
Really all it is, is just some really simple pass through wrappers where
we have a sort of a skip side Swift type that is like firebase, you
know, connection, firebase analytics, Firebase auth, that really just passes
these calls straight through to their Kotlin equivalents, which are in many
cases named exactly the same thing.
So it actually winds up being a fairly rote exercise to enhance that package.
So, yeah, so that's, that's another good one.
we have, another good example is Skip Bluetooth, which is almost
completely user contributed.
you know, we had, we started the package a long time ago, but never actually
implemented something, but just a couple months ago, someone came along
and said, I need, you know, Bluetooth, you know, support through Skip.
And they wound up just implementing a very large swath of the, the, iOS Bluetooth.
SDK on top of the Android equivalent Bluetooth services.
Leo Dion (host): Very cool.
I wanted to get one question, one other question outta the way from Adam Hill.
he's asking, I'd like to know if there's any timeline on
trans piling arbitrary macros.
just not apple specific ones.
So I guess.
I mean, I, I could try to answer this question, but I would there is no timeline
because we're moving over to compiling.
so you do support macros, though?
It does sound like
Marc Prud'hommeaux (guest): No,
Leo Dion (host): none.
Marc Prud'hommeaux (guest): the, not on, not on the transation side.
So I think the question is maybe alluding to the fact that we do have built-in
support for some of the built-in macros
Leo Dion (host): Right?
That's what I meant.
Sorry.
Apple's macros are supported, but if you create your own macro, translation.
Marc Prud'hommeaux (guest): Yeah.
I mean it's actually, we'd love to have support for that, but
there's actually limitation on the Swift Build plugin system.
We don't get access to the, macro
Leo Dion (host): what I was gonna ask.
Right.
Marc Prud'hommeaux (guest): So there's not really any way that we can.
Support arbitrary user written macros.
however, in the Native Swift compilation and the skip fuse, you know, version
on your model side, we do support it.
So it, because it's just regular Swift.
So the answer is that in, in the trans pile world, we only support
a subset of the, you know, of the ones that we've decided, you
know, to handle like observable.
on the compiled, side of Swift, we support any macros.
Leo Dion (host): Okay.
That makes total sense.
Yeah.
I'm surprised you guys don't have, I mean, they're already doing any
transation in a, not transation, it's probably not the right term, but I
would assume you would've access to the code after the macro had been
applied, but it sounds like you don't.
Marc Prud'hommeaux (guest): Yeah, no, we only get it before, we've, we've raised
it . With Apple and we have not yet heard an answer to, to, that request.
I, I don't entirely see how they could do it, actually.
I mean, unless they're to change the entire order of how things
are, run in the build process.
but it would, it would, it has been a shortcoming so far.
one of the reasons why we are definitely pursuing the compiled angle
as well as the trans compiled angle.
Leo Dion (host): Right, right.
so if somebody wanted to use Skip,
do they need to do to get started?
How much does it run for?
And yeah.
Marc Prud'hommeaux (guest): So, yeah, so we have a very generous, free plan.
Basically we have an indie plan, where you can, use it to build, one app.
As long as you're sort of a small business, or a small group of
people, Buildship one app for free.
So you don't have to use it, you don't have to pay anything at all.
if you are a small business, then it is a annual, subscription, and it is,
2 99 a year.
and then a professional for sort of a large organization.
it's 9 99, 999 a year on a per developer basis.
Leo Dion (host): Um, before we close out, I did wanna ask you, about FOSDEM.
You spoke at this conference.
I don't think a lot of people know what FOSDEM is, especially here in the us.
but it's very popular.
I know a lot of people spoke, from the Swift community at it.
what is it, what you speak about?
Marc Prud'hommeaux (guest): so
Leo Dion (host): why were Swift people there?
Yeah.
Marc Prud'hommeaux (guest): Foss is a annual, free open source
software convention in Brussels.
this was actually my first year there.
it was a blast.
It's huge and it's totally free to attend.
it was at the campus of a, a university in, in Brussels.
and.
there's all sorts of different tracks.
There's, you know, tracks about JavaScript, there's tracks about,
you know, a lot of server side stuff.
more or less, anytime that there's free and open source software and ecosystem,
you can get one of these speaker rooms.
And these speaker rooms have various tracks.
and this was the first year there was a Swift track, that was going on.
That was, that was very cool.
There were a bunch of . Very interesting talks, only some
of which I was able to attend.
but I, I think that was really exciting for sort of Swift to make inroads into,
you know, a community where historically people have sort of looked at it as a
corporate Apple only just iOS building kind of language and opened it up to
more like, oh wow, you can build, you know, a Linux server process using Swift.
You can run around Raspberry Pi, you know, things like that.
Leo Dion (host): what did you speak on?
Marc Prud'hommeaux (guest): So I actually didn't speak on the Swift track.
I spoke on an entirely different track.
and it was actually about building App Stores, specifically about, the
alternative app, all app marketplaces in the European Union, which is a project
that I've been working on for a while.
Actually unrelated to Skip, but is using Skip technology in order
to create, a single universal app marketplace for people to be able to
distribute open source applications.
Leo Dion (host): Oh, that's awesome.
We'll have to put a link to that in the show notes as well.
Marc Prud'hommeaux (guest): Yeah, I see, I see.
App Fair Project.
and it's, It's coming along.
It's it's, we basically, that's, that's how we are currently
publishing our current example, skip applications, through the App Store.
So it's, it's very nearly ready for, you know, ingesting other people's
open source apps and being able to provide them to the entire world.
And that, and, and that's really, you know, the source of passion for
me that, you know, really caused me to wanna be able to create Skip
is that . We wanna make apps that reach the entire world, right?
So, you know, not just all the devices, which for all intents
and purposes is iOS and Android.
That's essentially a hundred percent.
but also all languages and all abilities.
So we have really good support for, localization, inter
internationalization in skip applications.
We take your XC strings translation files,
Leo Dion (host): I saw that.
It's amazing.
Marc Prud'hommeaux (guest): Yeah, we convert those over to Android.
we have really good support for the accessibility APIs and Swift UI.
so, you know, with just a single code base for the first time, really you
can take a single sort of premium . Polished iOS application, and you can
reach the entire global population, which is like 90% of all adults
have one of these two smartphones.
and that's what really makes it exciting for me is the, the possibility that a
single creator can finally reach, you know, the entire market space without
needing multiple teams and coordination between, you know, a lot of different
developing groups and things like that.
Leo Dion (host): Yeah, that's amazing.
Marc it was so cool to talk to you today about Skip.
I played around with it.
It's pretty amazing.
Pretty happy that I can build an app in Swift and post it
on the actual Android phone.
So I was super happy about that.
thank you.
Thank you for coming on.
Marc Prud'hommeaux (guest): Thanks so much for having me, Leo.
It was really, it's really been a blast.
Leo Dion (host): where could people find you online?
Marc Prud'hommeaux (guest): skip Do Tools is really the, primary way of,
of reaching me and, and the project.
and then on the about page, you can, you can see the links to my
various social media, outlets.
Leo Dion (host): I will have links to the Skip showcase, the, your
talk from fos and the alternative store that you, are working on.
And yeah, definitely take some time.
Download skip tools.
Give it a try.
It's pretty fun.
Thank you for me for today's episode and, if you are watching this on YouTube,
please subscribe and really appreciate it.
And if you're listening to this on a podcast player, please post if
you really enjoyed this episode.
Thank you so much will talk to you Bye everybody.