#Wondering about Android builds

1 messages · Page 1 of 1 (latest)

bright temple
#

I sometimes see people and merge requests mentioning Android build, and wondering what it’s about.
Why would Vapor be built on a mobile device ? Can Swift be used to create Android apps ?
I don’t know much about Android apps these past years, but didn’t find much about it, so I’m being curious.

sharp plaza
#

@scarlet birch one for you?

#

I mean Vapor wise we just want to support all possible platforms

#

Android support is still in the works IIRC. Recently we have a Android working group too (and @scarlet birch is there as well).

scarlet birch
#

Good timing, just got out of the Android meeting

sharp plaza
#

lol

scarlet birch
#

Like 1 minute ago

#

Swift can be used for Android. It's a bit of an adventure right now, because the whole process isn't standardised yet. So you have a few decisions to make along the way.

First of all, you need to be able to compile your code for Android.

  • https://skip.tools offers tools to do so. Their old proposition was based on transpiling, which is not really using Swift. Just the Swift syntax.
  • Then there are two opensource cross-compilation SDKs. One by the browser company, and one by Finagolfin (this is what I use).
  • Skip also offers Native Swift development, which is what I'd always recommend over transpiling.

Native Swift already gets you access to about 75% of the Swift for Linux libraries, and Skip has some tools for interfacing between your Swift and Kotlin codebases. And the other 25% are almost all very simple one-liner PRs.

Once you have the SDK tools set up - which is not very difficult luckily - you'll have two paths. This is basically just preference:

  • You can either make the whole project in Swift, which is easier to build. This is all using the NDK though, so you wouldn't get access to the Android UI libraries like jetpack compose. Some people do this, and have bindings to Java UI classes, it's not my preference but the build setup is super clean and uses SwiftPM.
  • Or you can go the "Swift as a Library" approach, which is what I like more. In this case you build the UI with Kotlin, and call into Swift for any business logic. The business logic then notifies the UI of new data. Works really well if you're planning to use TCA (swift-composable-architecture) or similar patterns.
Skip
Skip

Skip brings SwiftUI app development to Android

#

If you want to do this today, go for Skip. I haven't used it, but it's the only real way you'll make an app today. We're putting good tools in place, but those need time to develop and then more time to bake.

stiff bough
#

What's your take on Kotlin Multiplatform?

scarlet birch
#

I don't want a drop of Objective C in my codebase. KMM doesn't have Swift interop, it has Objective C interop.

#

And Kotlin Native's ecosystem is very poor compared to the java ecosystem anyways

#

If I wanted to hate myself I'd go that route

#

I don't know why it exists, because it really is the worst of native and kotlin combined. But Kotlin is a not a bad language, I'm sure there could've been a better version of this.

#

A much better version

#

The main thing I care about with Swift on Android is not repeat what KMM does. Hence why I think that JNI is a stop gap. A proper version needs to focus on Kotlin, not Java.

lofty needle
#

KMP is working on native Swift interop, but given the build times, complete lack of debugging and host of other issues I'm not holding my breath

bright temple
quasi anvilBOT
scarlet birch
#

Happy they're taking it on though