Swift on Android with Marc Prud'hommeaux

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Leo Dion (host) (00:03):
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 muchfor coming on the show.

Marc Prud'hommeaux (guest): Thanks for inviting Leo. (00:13):
undefined

I'll let you go ahead and introduce yourself.

Marc Prud'hommeaux (guest) (00:18):
Yeah, my name is Marc Prud'hommeaux I am one of
the, co-founders of Skip.Tools, whichis a, development environment and tool
set that enables, iOS developers tobuild their applications for Android.

How did you get started with this idea?

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-founderAbe, in this venture, together
back in 2008, we actually.
Together wrote the first ebookreader for the iPhone called Stanza.

Oh, cool.

Marc Prud'hommeaux (guest): and that was a pretty big hit. (00:57):
undefined
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 froma really small team, it's, a really big
ask to write your app a second time.

(01:17):
For Android.
And that's always been the case.
And, Stanza wound up gettingacquired by Amazon and Abe and I
worked for Amazon for a while, andthen we sort of went our own ways.
Abe worked, at Twitter, headof platform development, iOS,
platform development there.
And I, you know, have donevarious things working on dozens
of different app projects.
Some really big, like from New York Timesand Bose and some fairly small, but.

(01:40):
Always, we've been facedwith this prospect of.
Clients who wanna build theirapplication for iOS first.
Because iOS is really, you know,captures the vast majority of
the, you know, dollars in termsof, people who spend money, you
know, on or through applications.
But Android is the otherhalf of the mobile ecosystem.

(02:00):
And you know, people always comeinto it, you know, very often saying,
okay, we'll design the iOS applicationfirst and then Android will be TBD.
And then when it comes time toactually implement that Android side,
that's when people start making harddecisions and asking tough questions.
Do we bring on a second team?
Do we rewrite the whole thing insome cross-platform framework?

(02:22):
And there has been no realsatisfactory answer up until now.
So that's kind of the longroundabout way that we got to
identify this, you know, need that.
I think all the app developers universallyhave, having experienced themselves.

How does Skip tools differ from, something like Flutter
or React Native or Zain, for instance?

Yeah, I mean, so those are, have historically
been the really big three names incross-platform app development frameworks.
In general, all three of these applicationdevelopment scenarios bring in their own
individual way of building applications.
Flutter, which is, packed by Google.

(03:06):
You develop using dart, which istheir really bespoke language that
is mostly just used for building.
Fluter applications, react native, youwrite it in JavaScript, that's Facebook's,
you know, framework and, and MicrosoftZamarin, or more recently Volved as mwe.
Yeah.
You write in c And so all, all three ofthese languages and frameworks are really

(03:29):
alien for both iOS and for Android.
They're both bringing in their entire,you know, alien development stack.
You really need to . Know thoselanguages and really want to
develop in those languages.
The big difference with Skip is thatyou write your application in Swift
and in Swift UI just using Xcode.
You build and you run your appon iOS and Skip on iOS doesn't

(03:54):
actually do anything at all.
We don't intrude into the framework.
You're writing direct Swift UI.
Using Apple's own Swift UI, wherewe really differ comes into how
we implement the other half of theplatform story, the Android half.
and that is where Skip takes your Swiftcode and it builds it for Android.

(04:18):
initially the current sort of matureversion of Swift 1.0 is that ites
all of your Swift code into Kotlin.
and translation is just theprocess by which we parse.
Your Swift code and we convert itinto Kotlin code and we output that,
and then we build that for Android.
and the end result is that on Androidwe wind up taking, you know, your

(04:42):
Swift and turning that into Kotlin.
We also wind up taking your Swift UIand turning that into Jetpack Compose.
and Jetpack composed his Androids.
You know, modern declarative userinterface language, it is the
recommended Google recommendedway of building Android apps.
and you know, they'revery, they're very similar.

(05:03):
So it's possible basically to take a SwiftUI 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'skind of mimicking the NATO platform
experience and things like that.

(05:23):
We have real, you know, honest togoodness native of apps using both of
the platforms' common recommended idioms.

Flutter is building directly to machine code, right?
It's like kind of using core imageto 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 Nativehasn't exactly been positive.

(05:52):
So I feel like if it does work,it's amazing, when it does.
but I'm not sure if that's like a. HTMLweb view or how, do you have an idea how
React native works behind the scenes?

Yeah.
Yeah.
So, so you're right with flutter.
I mean, flutter is actually just drawingevery individual pixel on the screen.
and then they have, you know, a varietyof sort of themes that you can apply.
Like they have one that's called theCupertino theme that sort of makes,
you know, sliders look like iOSnative sliders and sort of makes text
boxes kind of look like text boxes.

(06:27):
you know, enough to sortof . pass a screenshot test and
be like, ah, that looks sort ofnative and that's good enough.
react native is different.
They actually do wind up renderingonto Native controls, but they're
using the React layout, system.
They're basically using CSS flex boxes tolay out the components and get them to,

(06:48):
you know, show up on the screen in kind ofthe same way that you'd write a webpage.
But . Instead of rendering to HTMLelements, they're kind of rendering to,
you know, text fields and, you know,sliders and, and things like that.

And then Sam or Maui, I would assume is more like,
I don't know, kind of compilingdirectly to an app and then it has a
bunch of extensions added on top of it.

yep.
Yeah, that's right.
So, yeah, so, you know, react native, theyare 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 docompile down to, you know, machine code.
and they're shipped as, asbinaries, but they also do have

(07:37):
garbage collectors built in.
so it is kind of a Java ishscenario on both iOS and on Android.

Okay.
If that makes total sense.
So as somebody who has never developedan app for Android, I kind of wanted
to cover a few things that iOSdevelopers might not know about.
So let's start off by saying, whatare like some major differences that
you've seen with Kotlin and Swift?

Well, you know, they really come from the same
. next generation kind of language push.
You know, Kotlin is really replacing, hasreplaced Java for Android development,
just as Swift has more or less replacedObjective C development for, for iOS.
And both of these languages,you know, are very, you know,

(08:31):
heavily stress, type inference.
and, you know, declarative design,
Kotlin is, you know, I alwayssay if you squint hard enough,
Swift looks just like Kotlin.
you know, you can say, you know, var Xequals A, B, C, you know, funk do thing,

(08:52):
and then, you know, arrow return value.
There's a couple of fairly minorsyntactic differences, but, you
know, you can, you can sort of cobbletogether 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 canimagine, you know, just writing a regular

(09:12):
expression or something and taking yourSwift program and turning into Kotlin.
the more advanced things like generics,and converting value types like
structs and things like that, some ofthese don't have an exact equivalent
in Kotlin, and that's where the.
The translation of the Swift into Kotlinstarts to get really, really complex.
and that's, that's where the Skip plugindoes all the heavy lifting for you.

So is there, like, they don't have generics quite
the same way that that Swift does.

Yeah.
Simple, basic genericswork more or less the same.
You can have a collection thatdoes, you know, on a generic type,

Okay.
I could see how thatwould be kind of a pickle.

Yeah.
But, and, and generics on protocolsdo wind up getting implemented
pretty diff fairly differently oninterfaces in lin interfaces are,
are, are the equivalent there.
and then on top of all of this, the factthat Kotlin is built on top of Java and
is running in a JVM, regardless of whereyou're running it, be it on Android or
on a server or on your desktop, Java hashistorically made these very controversial

(10:17):
decision to erase your types.
So they do this thing called type erasure.
So those types don't actually exist tothe knowledge of the runtime environment.
And so that means that we have to tackon a good amount of metadata in order
to be able to accomplish some of thethings that come naturally with, Swift,
where you do always know, you know whatthe generic type is at, at runtime.

Are there any performance disadvantages with using
Swift and then having it with allthe additional metadata and such?

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 isa garbage collected environment.
and they have no native value types there.
There's no equivalent to astructure in Enum, in, in Swift.

(11:09):
you know, so, you know, what wehave to do is we have to wind up.
Translating, you know, your structsand your enums your value types
into classes in Kotlin in such a waythat it preserves the copy and write
semantics that Swift offers you.

Okay.

Marc Prud'hommeaux (guest): and so that is gonna be not as (11:25):
undefined
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 reallyencountered performance issues with it
because in general, Android is designedto accommodate this sort of . You

(11:47):
know, additional memory, overhead,you know, the higher watermark, the
garbage collection and things like that.
the statistic that I read is thaton 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 twiceas much RAM as the equivalent iPhone.

(12:10):
Version does.
and that is largely to accommodate,you know, the additional memory
overhead that you need for Java and

Right, right.
That makes total sense.
So let's move on to the UI part.
What's the big differences betweenJetpack Compose and Swift UI?

well.
As with, you know, I say Squinthard enough and Swift looks like
Kotlin squint hard enough, andSwift UI looks like Jet Pack Compose
Yeah, just went a little harder.
because, you know, the, the structureof Jetpack Compose, you know, Swift.
Sets up views in ahierarchy of these structs

Mm-hmm

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 lesshave that same sort of declarative
outline of your views, differencesthat they're done in, global functions.
And top

Oh, okay.

Marc Prud'hommeaux (guest): rather than infuse. (13:05):
undefined
Yeah.
And so those functions are the thingsthat sort of track the state access
that takes place inside of them.
and marks those, once the state getsmarked as dirty marks those, as being
needed for what they call recomposition.
and recomposition is essentially wherethe view knows that it needs to redraw.

I was gonna say a big thing is like you're losing
a lot of the power generics and dothey even have a DSL in JPAC Compose?

They not quite like as good as Swift does.
they're really working more withwhat they have in Kotlin, but
they do have a composed compiler.
you mark your functions aswhat they call composable.
and that winds up being run as aKotlin compiler plugin, once it is

So it's kinda like a macro in a way.

Yeah.

yeah.

Marc Prud'hommeaux (guest): it's a lot like a macro. (13:59):
undefined
And so these composable functions,they have additional metadata
that's tacked onto them.
Basically a context that's being passedthrough 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 orderto be able to, you know, know when you
need to recompose these, these views.

So how, like, so I did actually build an app.
I followed through on the example.
and it was like, I, I recentlyordered a pixel for a 'cause.
I wanted something cheap andlike small to work with and,
built a app and it was amazing.
How does like the build process work onAndroid different from like Xcode build

(14:44):
and deploying to a simulator or device?

Right, right.
So, you know, again, . Android hasall these mirrors to what we're, you
know, you know, we have in the iOSdevelopment world, you know, Swift has
Kotlin, Swift UI has Jetpack Compose.
In addition, Swift PackageManager 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

(15:11):
to early times used to be done in Groovy.
Now it's, it's nativeDSL is Kotlin itself.
Similar to how SwiftPackage, Swift Files, yeah.
Are implemented in Swift, Gradleimplements those in in Kotlin.
and so you write in whatever buildlogic that you need and it has its
own DSL for declaring dependenciesand declaring multiple modules.

(15:32):
And you know, more or less everythingyou have in a package Swift you can
accomplish and, build gradle dot kts file.
and so what the.
You know, skip Stone plugin doesautomatically as every time you rebuild
your application, you know, we, weconvert your Swift Kotlin, we convert
your Swift UI to JetPack compose.

(15:53):
We also take your Swift packagemanager package Swift, along with
any dependencies, and we convert thatinto a mirror tree of Kotlin Gradle.
project builds.
and so you wind up having this parallelstructure that is automatically
derived from your Swift buildevery time, every time you build.

(16:15):
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 buildin, in the correct directory.
But what what we do is as part of thetemplate application that you create
when you run the skip and net command,we add a build phase into Xcode such

(16:36):
that when you launch your application,it winds up invoking gradle, launch
debug, on the trans pile version ofthe Gradle project so that every time
you build and run your application onthe iOS simulator, on the iOS device.
The equivalent transpiled up todate Gradle, project is compiled

(17:00):
and run on your attached, Androidsimul, emulator, or Android device.

so ever have you ever used like tourist?

Yes.

So I mean, it sounds like basically their stuff
is set up all in Kotlin, similarto 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 likethat, which is, which is kind of cool.

Yeah.
Yeah, a little bit.
Now we don't, we don't usetourist on the side of how we
create the Xcode build file.

Right, right.
No, I just mean like the fact that you cancreate 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.

Yeah, exactly.
And that has the benefit too, thatyou know, not only do you, can you
build and run this from Xcode, whichis really the common development
cycle that iOS developers will wantto 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, IDlike, Android Studio or IntelliJ.

(18:13):
and all of these have built insupport for Kotlin, Kotlin Rale files.
And so that's how you can basicallytake that, take that application and
open it in Android studio, and thenyou can have access to all of the
Android studio tools that you need.
Like, you know, analyzing the sizeof the generator artifact, running
the debugger, and things like that.

so the.
I first, I think I've heard of theproject, the skip tools before, but really
intrigued me was the, post I think youhad on LinkedIn where you were showcasing
Biff packages that are compatible.
And I'm a big fan of Swift Package Manageris imperfect as it is, and it was cool
to see like all these libraries that wereavailable like to use already on Android.

(19:00):
how does Skip,
how does it employ SwiftPackage Manager throughout its.
It's development and we'll talkabout external LI or internal
libraries that Skip has.
But, how does it useSwift, Swift packages?
in, its, in the, thedevelopment and piling operation

So, you know, we always say this project wouldn't
have been possible a couple years ago.
It was really the advent of Swiftpackage manager build plugins
that made all of this possible.
and build plugins are, you know, basicallya, you know, plugin line that you add
to, your project dependency that is, youknow, defines an action that can get run.

(19:42):
Whenever you perform a project build.
and that's really what unlocked theability for us to hook right into
Swift package manager's, build processand be able to do things like, you
know, parse all of your Swift filesand be able to, to convert them
into, into Kotlin on, on every build.
and so that really also makesit independent of Xcode at all.

(20:04):
You know, you can run.
This process, you know, the buildprocess, just using Swift package build,
on the command line, which is great forcontinuous integration as well because,
you know, for all of our packages, bothour core packages like the Skip UI and
Skip Foundation packages, but also forour external packages like Skip Firebase
and Skip SQL and things like that,

Okay.

you can just build and test as part of a GitHub
action, which is, you know, has beenfantastic for us for quality control.

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 bringthat in and use that to build an app.
how would I, like, let's, how wouldI move forward with, with some of my
current apps to get those over to Android?

(20:57):
if everything is basically in SwiftPackage Manager, should I still employ
something like tus and then, andthen run skip tools on top of that?
Or what would you recommend?

Probably what we generally recommend is that,
you create or initialize basically ablank skip project using skip a net and
what, what that winds up doing is itcreates, so the core of everything is
a Swift package manager package Swift.
But when you create, anapplication project using.

(21:27):
Skipping it and passing the app Id.
it additionally creates both a,Darwin folder and an Android folder.
And the Darwin folder create, createsa, you know, app named Xcode Project.
and that's kind of anempty shell of a project.
Really all it does is it referencesthat Swift Package manager.

(21:48):
Top level package.
so in some ways it's kind of an unusualXcode project because really it's just
all it's doing is wrapping, wrapping aSPM project, and then providing additional
metadata like, you know, the applicationicon and you know, the entitlements and
all of the, all the extra stuff that.
Needs to go into buildinga real application.

(22:11):
but it is really sort of a hollow, kindof a hollow application, a hollow project.
It doesn't have, I think it has one sourcefile just 'cause it needs a main method.
but you know, other than thatit just really references the
Swift package manager module.
so generally, and, and that'ssort of a, a very customized
xcode project that it creates.
So we generally recommend that people. Create one of these kind of empty

(22:35):
projects and then bring in their code,sort of piecemeal into the application.
and then it might be aiterative process, right?
Because not, maybe not everything isgoing to transp pile out of the box.
And so, you know, sometimes it won't beworking on the very first build and run.
but we provide you with a lot ofguidance and, you know, warnings

(22:55):
and, and things like that.
If, if it doesn't build at first.

Where would you recommend somebody be like this, this tool is great,
but there's a few spots where you mightwanna actually write some Kotlin code.
Where would that be the best fit, I guess?

Yeah, so we have, in our docs is a platform
customization guide and there's avariety of ways of doing this, of, of
basically dropping in custom Kotlin.
And there's a lot of reasonswhy 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, andwe translate a lot of your foundation.

(23:31):
Libraries into the equivalentAndroid libraries, for example,
like URL and, you know, filemanager calls and things like that.
but there's always gonna be thingsthat are very iOS specific that
aren't gonna just automaticallytranslate into the Android world.
and in those cases, you know, theeasiest solution is just to drop

(23:55):
The equivalent Kotlin callright into your Swift code.
and the way that we accommodate that iswe have these, pre-processor blocks that
are just like pound if skip, and if youput code in there, X code will ignore
it and the iOS build will ignore it.
But we, it's part of the skip stoneplugin will process that and pass

(24:18):
that over to the generated kotlin.
So you can actually just drop rawKotlin right into . The middle
of your Swift code, and then beable to be able to work with it.
and it looks pretty weird atfirst, just sort of like you're
using Java idioms, right?
You have Java package namesand you know, you have sort of
some Kotlin, you know, syntax.
but Xcode is happy to ignoreit, on the, on the Swift side.

(24:42):
And so that's really the sortof 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 theAndroid side and I'm gonna make,
you know, what I deemed to be theequivalent call and then work with that.
that's really the, the first levelway of, of dealing with that,

(25:06):
of, then there's the second way,which is a little more elaborate.
You know, sometimes it'snot like one or two lines.
Sometimes a whole, you know, bigKotlin 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 aKotlin file into a skip folder in

(25:29):
your Swift package manager package.
and then that again, will get ignoredon the Swift side, on the iOS side.
but that will just be broughtstraight into your Kotlin build.
and then you can reference thatfrom code within if skip blocks.

Oh, okay.
So you could like build a classin Kotlin and then reference
that class in your if skip.
Okay.
Very cool.

that's right.
And then, and then there's, there, there'sa third, you know, the sort of next level
up is actually having a Kotlin dependency.
you know, I mentioned Skip takesyour . Your sort of network of, of
Swift package manager projects andconverts it into a Kotlin equivalent.
It only does that for packages thatsupport the skip stone plugin for

(26:18):
basically packages where you hadplanned on having it work with Skip.
you can also have any dependenciesyou want on the iOS side, like you
can depend on projects that don't haveany knowledge of Skip or anything.
but those won't . Existon the Kotlin side.
They won't be transpired, theywon't be, you know, referenced.
however, what you can do is in the skipside, you can add dependencies just like

(26:42):
you can on the Swift side, dependencies

Kotlin libraries,

Exactly, yeah.
And there's a, there's sort of an

their equivalent?

Their equivalent is called Maven dependencies.

so it's, yeah, which is the Java one.

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 packagemanager module basis called Skip Do yaml.
you basically list those dependenciesin there and then in the derived

(27:16):
Kotlin, Gradle . Project, it will havethe dependency on those libraries.
And so then inside of, say if skipblocks or inside of, you know, your
raw Kotlin, you can just import thosepackages and you can use them directly.

As of the today, the record day of recording,
Giannis had posted the, Swifton Android work group, and.
I wanted to ask about about that, butbefore I do, is there, I do a lot of.
Stuff with Lin like Aun or Linux as wellas the Apple platforms, and I know we've

(27:54):
had Windows stuff for quite a while.
is there already any, like pre-processordirectives or anything with available Mac?
not the available macro, but theavailable attribute, that are specific
to saying that a certain methodis or is not available on Android.
That are either compiled time orruntime, I guess outside of Skip,

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 dothis 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 annotatea, a function as being, or class as being

(28:41):
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 Androidpeople, but Linux and Windows
people would also find useful.

Yeah.
I mean, even Linux people like I, Iend 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. (29:03):
undefined
Yeah, we do.
If can import, Android is the nameof the module for, for Android,
you know, packages, so you cando, if, can import Android.
I, I wrote a blog post recentlythat's gotten some traction,
mentioning that Swift everywhere.
Package about, you know, how youcan get your package working on
native, native compiled Android.

(29:25):
and, you know, 90% of the time isjust adding in a, if can import
Android, then import Android.
Elif can import Darwin,import Darwin Elif can import

Right, right, right.

yp, import Eucalyps and Portugal.
And

Yeah.
Yeah, yeah, yeah.
That's, that's a really good call.
I like, the one I'll do is like, ifcan import 50 Y, for instance, is a

Exactly.
Yeah.
Yeah.
Yeah.

So, yeah.
And then like on the Swift package, canyou, I, I bet you can't even say what
Android version you support in the Swift

No, you can't say, but yeah, no, it's, it's
still, all that stuff is reallylimited to Darwin platforms right now.
But that's one of the things that wereally want this android working group
to, to really get underway with, withhelping push is, you know, expanding
those to, to support the other platforms.

Well, let's, let's get into that.
What, what are you looking forward towhen it comes to the Swift, and Swift
on Android work, work, reading group?

So I should prefix this by saying that
everything I've been talking about thusfar has really been Swift, skip 1.0
where everything is transp compiled.
and what, you know, that takes your Swiftand turns it into Kotlin, and builds it
just like a regular . You know, Androidapp, a hundred, you know, everything going

(30:47):
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 aresome limitations in transpiration.
You know, there are somelimitations around, generics.
there are some, you know,there there's some sharp edges.
Like you can't have retroactiveconformance to protocols for types

(31:07):
outside of your current module.
You know, there's kind of a list ofthings that are just . Just impossible
to accomplish with translation.
so that's one shortcoming of translation.
Another one is that in order todepend on another Swift package
from your . Trans pilot skip code.
That package also needsto be aware of Skip.
It needs to have the skip stoneplugin being run and things like that.

(31:30):
and not every package isgonna want to do that.
You know, not every package is thinkingabout Android or, you know, really
wants to bring in that dependency.
Um, and so for the past, about the pastyear, we've been working on integrating
natively compiled Swift on Androidside by side with the trans piloted.

(31:50):
Swift on Android and that thatsort of complicates everything a
little bit because sometimes yourSwift is turned into Kotlin and
compiled with the Kotlin compiler.
Other times your Swift is justcompiled directly to Android using
the Android, Swift tool chain.
and then what Skip winds updoing is, using the skip fuse

(32:15):
package, it automatically andtransparently builds a bridge.
between your Transpi Swiftand your Compiled Swift.
so that for, you know, the, the commonexample is, right now if you run, skip a
Knit for a, you know, new, new applicationpackage and pass native to it, what it
will do is it'll create an application,sort of a Hello World application that's

(32:37):
like a little cred app, with create, read,update, delete on a little Jason file.
and without Native, thatwill create two modules.
A, you know, a UI module with all theSwift UI and sort of a data model, module,
with the, you know, model handling codewhere it, you know, is a observable view

(33:00):
model and it, you know, reason writesfrom adjacent file and things like that.
so in pure transpiredmode, those are both.
done in Transpile, Swift thatwill turn into, into Kotlin.
When you run that in native mode, whatthat will do is the Swift UI is currently
still transpile into Jetpack Compose,but the view model code is actually

(33:24):
gonna be compiled directly to Android.

nice.

Marc Prud'hommeaux (guest): then . They communicate back and (33:28):
undefined
forth as you know, using Swiftobservability, using the bridge that
winds up getting automatically built.

Okay.

So what that grants you is your view model code, your,
all of your model code that can have anydependency 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 packagesthat are already building natively for
Android and unlocks that entire hugeecosystem, you know, growing ecosystem

(34:01):
of, pure Swift packages that you can,you can start taking advantage of.

That's pretty amazing.
you think that's like prettymuch the future is going with
compiled as opposed toed?

Yeah, in order to give real reach to all of your
code, you know, to have it be sort oftrue, a hundred percent compiled Swift,
We do think that that is probablythe future, for, you know, for simple
apps or apps that don't have a lotof dependencies, things like that.
you know, . People can perfectly,you know, stick with the transpile

(34:37):
process that has been working so far.
You know, we've shipped half a dozenapps and there are other people,
you know, many other people that areshipping apps today that, that use
that approach and that approach hasa few advantages of its own right.
It, you know, not having toembed all of the Swift libraries
means it's a much smaller binary.
Shipped on Android, debugging.

(34:57):
That's a much easier story when it'sall done in Kotlin and, and Java.
You know, if you have a crash inSwift and debugging that on Android,
there's currently some challengesthat we're gonna be working with
this working group to overcome.
where, you know, you see these ma.

I mean, are we talking Android support on Xcode?
Like I, I don't even knowhow you would get there.
Right?
If you're gonna step through a pieceof pre transpired Swift, right.

Yeah.
Yeah, I mean, we'd love that.
You know, we've, we've, youknow, communicated with Apple
that that'd be a great feature.
I don't see that happening right away.

right,

So, so, you know, you can, you know, if you
open your project in Android studio andyou run it in a debugger, you do get
some native support for that debugger.
But you know, you've probablyseen mangled Swift names.
You know, in, in the past, and they'renot easy to Digest or understand,
and you can't jump to the lineand, you know, so, so there are

(35:55):
challenges with purely native code.
but overall, you know, we feelthat as this technology evolves,
which is currently in still inearly access tech, you know, tech
preview, release, but it's, you know,available and people are using it now.
We think the benefits really outweighthe disadvantages because it is, it is
real Swift, so you have true value types.

(36:17):
You're really, you know, you'rerunning real native compiled code.
It's gonna be more memory efficient, andyou have access to this entire, you know,
galaxy of, of wonderful Swift packages.

Going back to that question I had earlier, earlier
about how does it differ, like we'retalking about being a little bit more
like flutter in a way, as opposed tolike the transation, which I don't
think anybody really does, right?

Yeah, no, to my knowledge, I think there have been
a couple of academic experiments withtranslation, but to my knowledge, you
know, we're really the only ones thatare doing that level of, you know, you
can develop a full app using transation.

one thing I wanted to come back to is, as far as the translation
is concerned, would anyone ever want toedit the Transp piled code or would they
ever want to commit it to their repo?
Or is it something that shouldbe done way behind the scenes?
And don't touch it.
Don't look at it.

We're happy to have you look at it.
Actually, you can just open it rightin X code and, you know, look at
them side by side and, and we havesome map back line numbers when there
are, you know, the errors and thingslike that back to the original Swift.
So we're happy to give you access to it.

But

Marc Prud'hommeaux (guest): don't, we don't read backend (37:32):
undefined
changes that you make to it.
You know, we, we mark those files thatread only, and if you unmark them and
make a change to it, they're gonnaget lost the next time you build.

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'mthinking about it, it almost seems like,
like Babel, I guess would be a goodcomparison on, on an NPM or, or node
where it's like, oh, you know, this.
Used to have browsers, right, that didn'thave TypeScript support, for instance,

(38:04):
and you'd use something like that to it.
So it can actually beused in in the browser.
Browser essentially.
It almost, this is kind ofwhat it sounds like a bit,

a good equivalent is like TypeScript JavaScript.
You generally don't expect to beable to mess with the resulting
JavaScript, and then, you know,affect the original TypeScript.
Now all that being said though, youknow, skip is a commercial tool and
you know, we sell the Transer plugin.
However, . And the output of theskip process is still your own code.

Right.
Right.

we have a mechanism for exporting your project.
It's command, the skip export, it takesyour entire project and it creates
a fully buildable runable Android.
I. Project, you know, that uses JetpackCompose and, and everything, and it's
completely separate from needing anyof the skip, you know, build tools.
And that's what we call adjustability.
That basically means like, sayyou decide down the road, you

(39:00):
don't want to use Skip anymore.
You, you know, you developed version1.0 of your app and you know, maybe
you decided I'd rather just go myown way and have a Kotlin team and
take your app and go with that.
You're perfectly free to takethat resulting exported project.
And hand it off to your Kotlin team,and they can go their own way with them.

right.

it won't be pulled back in to your single, you
know, Swift source base, but it is yourown code to do with whatever you want.

Yeah.
Awesome.
I just, I wanna cover a couple ofquestions 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.

(39:47):
A way to write Lin code for certain partsof your app in order to fill those apps.
Looking forward to the pot, looks amazing.
So you kind of answeredsome of the stuff already.
I'll just kind of paraphrase.
So UI Kit, is that supported at all?

No, not the vast, but a little bit of
it is like, you know, we have someUI color and UI font sort of the
things that are needed for support.
But the ui UI view representable, wedon't have direct support for that
because we don't transp pile UI kit views.
But what we do have is an equivalent onthe composed side called Composed view.
and so when you want to sort of,interface . With more legacy views.

(40:30):
You know, Swift UI, you have LegacyUI kit you want to interact with.
Same thing on Jetpack Compose.
They have their legacyAndroid views, not all of

What is that?

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 ofthese that have have, you know,
evolved over, you know, a decade.

right.

and so there's the equivalent in Jetpack
Compose where you can, you know, insertold school, you know, legacy Android
views using what's kind of the Androidversion 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 recentlydid get a UI view, but . Pretending

(41:17):
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 thisif skip block mechanism where you'd
say, you know, if not, skip, in otherwords, if you're running on iOS, do the
UI view representable and you put ina web view in there, and then you do
all the stuff you need to do with sortof a, a complicated and large task.

(41:39):
And then on the Android side, in theelse, if Skip, You would use a compose
view and you would drop in a Androidweb kit, web view, you would do sort
of the equivalent, you know, managementshuffling around of, of state and,
and dealing with all that stuff.
and it's something that people do verycommonly using Skip, because that's,

(42:02):
that's one of the real selling pointsis that, you know, unlike frameworks
like, you know, flutter or React native,we're, we're making a bridge as a
Gigantic and complexand very involved task.
You can just drop this stuff right intoyour Swift file and you can, you know,
start iterating from there and see it comeright up on your . On your Android screen.

(42:22):
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 actuallyavailable on the App Store, in the
Google Play Store, called Skip Showcase.
and, and that is more or less a listof, I think all of the Swift UI.

(42:45):
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 itright now, and gesture, recognizers

this is on the, the Google App Store or the,

It, it's on,

the Google Play Store.

Yeah, so it's on both the App Store and the Play

Okay.

and it, it's, it is really useful when people
are evaluating Skip, because you canbring this app up, skip showcase on both,
and you can be like, okay, what doesa picker look like on both of these?
And you can see exactly how thepicker appears, you know, in
the user or the progress view.

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 (43:24):
undefined
doing in the, if not skip block,

What if you forget to?
What if you have, just like throw ina map view in Swift y and then you
transpire what's gonna end up happening?

It would, well, if you didn't guard
it inside a NIF skip block, thenthere would be an error once you
get

a compilation error.

a compilation

Okay, cool.
I was just wondering how, at whatpoint the line would you get a
warning, so that's good to know.

Marc Prud'hommeaux (guest): so we have, we have a couple. (43:50):
undefined
We have the at theBuild . Processing time.
Basically when the build plugin runs, whenyou kind of doing the pre-build, we do
have a, a bunch of mechanisms for warningyou as well when something is missing.
so for example, if there is some SwiftDI view that we don't yet support, we
mark that in skip as being unavailable.
So you'll very quickly geta nice, a message that says.

(44:13):
This API is not available.
Maybe a suggestion for what you can do.
if you don't hit that, then you willwind up when it tries to do the gradle
build and build for Android, you'llwind up with a compilation error,
which might not be quite as friendlyas the ones that we surface earlier on.

Right.
I, as long as it's not somethingthat you're gonna put on the
Google place or, and find out that

Right.
Oh, yeah.
No.
Yeah.
So unlike say like React native, whereyou know JavaScript, hope you tested
every possible runtime branch, youknow, you still do have a compiler
going on here, so you're not gonnajust like wind up missing something
and having a crash or a crazy error at,

Right, right.
I did wanna, I, I, I do wanna give youa chance to mention that there are some
extra frameworks available with Skip.
so stuff like Skip web fordoing specific web views and
things like that are available.
so

Marc Prud'hommeaux (guest): Yeah, we've got. (45:09):
undefined

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 (45:16):
undefined
packages that are, you know, sortof commonly used by applications.
You mentioned skip web.
That's really common for droppingin an embedded web browser.
And actually that's a good package.
And all of these are free and opensource on GitHub under the Skip tools.
Skip tools repository list.
That's actually a prettygood one to take a look at.
If you're curious about how you havethese parallel implementations between

(45:38):
Android and iOS, because that isessentially just doing what I described
where you have a UI view Representableon 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 isactually a pretty interesting one

(46:01):
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 actuallyinterpose ourselves at all.
You just are calling theGoogle APIs directly.

(46:23):
and then on the,

Is Fire bakes built into Android?

Marc Prud'hommeaux (guest): no, no, it is a separate, it's (46:27):
undefined
a separate package and, and

really?

Yeah, so, so it does interface with Google
Mobile Services, which is part ofmany Android distributions, but is
also a separate, somewhat separatecomponent because for example,

not like cloud kit where everybody gets cloud kit when

Right.
No, it's not, it's not baked ina hundred percent of the places.
so you know, also in general, like JetpackCompose is not part of Android as well.
Like all of these things, unlikesay, Swift UI, which is bundled as
part of the operating system, all ofthese things are really brought in
at build time and bundled as part ofyour app, of your application package.
And so Firebase is one of thosethat, that is built in, that is bun,

(47:08):
sorry, bundled in, not built in.
and what we wind up doing with ourSkip Firebase support is that since
Google is pretty good actually abouthaving these two APIs be very similar
in terms of just like type names andmethod names and things like that.
Our skip support for that.
Really all it is, is just some reallysimple pass through wrappers where

(47:31):
we have a sort of a skip side Swifttype that is like firebase, you
know, connection, firebase analytics,Firebase auth, that really just passes
these calls straight through to theirKotlin equivalents, which are in many
cases named exactly the same thing.
So it actually winds up being a fairlyrote exercise to enhance that package.

(47:54):
So, yeah, so that's,that's another good one.
we have, another good example isSkip Bluetooth, which is almost
completely user contributed.
you know, we had, we started the packagea long time ago, but never actually
implemented something, but just acouple months ago, someone came along
and said, I need, you know, Bluetooth,you know, support through Skip.
And they wound up just implementing a verylarge swath of the, the, iOS Bluetooth.

(48:19):
SDK on top of the Androidequivalent Bluetooth services.

Very cool.
I wanted to get one question, one otherquestion outta the way from Adam Hill.
he's asking, I'd like to knowif 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 thisquestion, but I would there is no timeline

(48:46):
because we're moving over to compiling.
so you do support macros, though?
It does sound like

No,

none.

the, not on, not on the transation side.
So I think the question is maybe alludingto the fact that we do have built-in
support for some of the built-in macros

Right?
That's what I meant.
Sorry.
Apple's macros are supported, but ifyou create your own macro, translation.

Yeah.
I mean it's actually, we'd loveto have support for that, but
there's actually limitation onthe Swift Build plugin system.
We don't get access to the, macro

what I was gonna ask.
Right.
Right.

So there's not really any way that we can.
Support arbitrary user written macros.
however, in the Native Swift compilationand 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 thetrans pile world, we only support

(49:46):
a subset of the, you know, ofthe ones that we've decided, you
know, to handle like observable.
on the compiled, side ofSwift, we support any macros.

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'sprobably not the right term, but I
would assume you would've access tothe code after the macro had been
applied, but it sounds like you don't.

Yeah, no, we only get it before, we've, we've raised
it . With Apple and we have not yetheard an answer to, to, that request.
I, I don't entirely see howthey could do it, actually.
I mean, unless they're to changethe entire order of how things
are, run in the build process.
but it would, it would, ithas been a shortcoming so far.

(50:35):
one of the reasons why we aredefinitely pursuing the compiled angle
as well as the trans compiled angle.

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.

So, yeah, so we have a very generous, free plan.
Basically we have an indie plan, whereyou can, use it to build, one app.
As long as you're sort of a smallbusiness, or a small group of
people, Buildship one app for free.
So you don't have to use it, youdon't have to pay anything at all.
if you are a small business, then itis a annual, subscription, and it is,

(51:21):
2 99 a year.
and then a professional forsort of a large organization.
it's 9 99, 999 a year ona per developer basis.

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 whatFOSDEM 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?

so

why were Swift people there?
Yeah.

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, auniversity in, in Brussels.
and.
there's all sorts of different tracks.
There's, you know, tracks aboutJavaScript, there's tracks about,

(52:18):
you know, a lot of server side stuff.
more or less, anytime that there's freeand open source software and ecosystem,
you can get one of these speaker rooms.
And these speaker roomshave various tracks.
and this was the first year therewas a Swift track, that was going on.
That was, that was very cool.
There were a bunch of . Veryinteresting talks, only some
of which I was able to attend.

(52:39):
but I, I think that was really excitingfor sort of Swift to make inroads into,
you know, a community where historicallypeople have sort of looked at it as a
corporate Apple only just iOS buildingkind of language and opened it up to
more like, oh wow, you can build, youknow, a Linux server process using Swift.
You can run around RaspberryPi, you know, things like that.

what did you speak on?

So I actually didn't speak on the Swift track.
I spoke on an entirely different track.
and it was actually about buildingApp Stores, specifically about, the
alternative app, all app marketplaces inthe European Union, which is a project
that I've been working on for a while.
Actually unrelated to Skip, butis using Skip technology in order

(53:27):
to create, a single universal appmarketplace for people to be able to
distribute open source applications.

Oh, that's awesome.
We'll have to put a link tothat in the show notes as well.

Marc Prud'hommeaux (guest): Yeah, I see, I see. (53:39):
undefined
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, skipapplications, 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 toprovide them to the entire world.

(53:59):
And that, and, and that's really,you know, the source of passion for
me that, you know, really causedme to wanna be able to create Skip
is that . We wanna make apps thatreach the entire world, right?
So, you know, not just all thedevices, which for all intents
and purposes is iOS and Android.
That's essentially a hundred percent.

(54:20):
but also all languages and all abilities.
So we have really good supportfor, localization, inter
internationalization in skip applications.
We take your XC strings translation files,

I saw that.
It's amazing.

Yeah, we convert those over to Android.
we have really good support for theaccessibility APIs and Swift UI.
so, you know, with just a single codebase 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

(54:55):
have one of these two smartphones.
and that's what really makes it excitingfor me is the, the possibility that a
single creator can finally reach, youknow, the entire market space without
needing multiple teams and coordinationbetween, you know, a lot of different
developing groups and things like that.

Yeah, that's amazing.
Marc it was so cool to talkto you today about Skip.
I played around with it.
It's pretty amazing.
Pretty happy that I can buildan 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. (55:29):
undefined
It was really, it's really been a blast.

where could people find you online?

skip Do Tools is really the, primary way of,
of reaching me and, and the project.
and then on the about page, youcan, you can see the links to my
various social media, outlets.

I will have links to the Skip showcase, the, your
talk from fos and the alternativestore 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 episodeand, if you are watching this on YouTube,
please subscribe and really appreciate it.

(56:07):
And if you're listening to this ona podcast player, please post if
you really enjoyed this episode.
Thank you so much willtalk to you Bye everybody.

All Episodes

Episode Transcript

Popular Podcasts

On Purpose with Jay Shetty

Crime Junkie

Ridiculous History

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Swift on Android with Marc Prud'hommeaux

Episode Transcript

Popular Podcasts

.css-r6mb8g{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:1;overflow:hidden;}On Purpose with Jay Shetty

Crime Junkie

Ridiculous History

All Episodes

Swift on Android with Marc Prud'hommeaux

On Purpose with Jay Shetty