[HN Gopher] The Swift SDK for Android
___________________________________________________________________
The Swift SDK for Android
Author : gok
Score : 230 points
Date : 2025-10-24 20:06 UTC (2 hours ago)
(HTM) web link (www.swift.org)
(TXT) w3m dump (www.swift.org)
| chrsstrm wrote:
| I'm just getting started in iOS development as a hobby, but what
| does this mean? Can I now build my app in Xcode with an Android
| target and use that binary in the Play Store? It surely can't be
| that easy now is it?
| samtheprogram wrote:
| Not yet, and possibly not ever quite from Xcode. But using
| Swift CLI tools, yes.
|
| The example Activty I saw is pretty rough ergonomically, but I
| have no doubt an ergonomic, SwiftUI-like library could be built
| on top of what's currently there and/or on the roadmap.
| objclxt wrote:
| > Can I now build my app in Xcode with an Android target and
| use that binary in the Play Store?
|
| No. The vision document[1] lays out the direction of travel.
| Currently the focus is on shared business logic and libraries,
| rather than full native applications (although that's certainly
| a goal, albeit a very long term one).
|
| [1]: https://github.com/swiftlang/swift-
| evolution/pull/2946/files
| thenaturalist wrote:
| What do you mean?
|
| This doc you linked is from August.
|
| The blog post from today includes, in fact at the very top an
| XCode Swift project emulating a Pixel 9.
|
| The docs include a detailed Getting Started for Android and
| they even have an Android examples repo.
|
| Hence the SDK.
|
| By all means, it very much is possible to build Android Swift
| apps in XCode.
|
| https://www.swift.org/documentation/articles/swift-sdk-
| for-a...
| joanniso wrote:
| The post doesn't display Xcode but Android Studio. While
| with Skip you can build & run through Xcode, that's not
| something we support right now.
|
| You can build the Swift part in Xcode, VSCode or your
| favorite editor. But the Android builds don't work with
| Xcode today.
| brookst wrote:
| No, it's just an Android compiler and standard libraries.
|
| Same way there are C compilers for Windows and Linux, but that
| does not mean binary compatibility.
| joanniso wrote:
| The SDK doesn't quite work that way, your iOS-specific
| dependencies like SwiftUI and UIKit aren't available. For
| SwiftUI development, [Skip](https://skip.tools/) has a
| transpiler that translates your SwiftUI code into Jetpack
| Compose.
|
| Without Skip, you can still share other code through JNI -
| similar to Kotlin Multiplatform.
| Larrikin wrote:
| The reverse is slowly becoming a possibility. Jet Brains just
| announced another improvement with Swift Export.
| https://kotlinlang.org/docs/native-swift-export.html
|
| But it's not there yet
| colesantiago wrote:
| What does this mean for React Native?
|
| Is Swift now going to be the de facto language for Mobile (and
| maybe Desktop) development?
| akmarinov wrote:
| Not a chance
|
| React Native is popular because there's a thousand times more
| React devs than native devs.
|
| And people like to use what they know.
|
| Also React dev experience makes anything Swift related look
| like stone age technology
| Austin_Conlon wrote:
| > Also React dev experience makes anything Swift related look
| like stone age technology
|
| How so?
| Larrikin wrote:
| I assume all the extra work you have to do to make it work
| instead of using the native language.
|
| If the project is simple to port over then it should have
| just been a website.
| hoppp wrote:
| The npm ecosystem is one of the worst and most backwards
| places to be, so I don't think so.
| wiseowise wrote:
| You're either delusional mobile dev who doesn't know what
| they're talking about, or a jaded frontend dev who has no
| idea about native development. Development for i
| platforms is a fucking chore, even worse than Android
| dev.
| jshier wrote:
| Presumably hot reload and IDE integrations that actually
| work. Xcode is really crappy compared to other IDEs, so
| platforms that can avoid it for most of your work tend to
| be an advantage. Xcode 26 generally broke anything that
| relies on indexing, like autocomplete, edit in scope, or
| refactoring, among others.
| GZGavinZhao wrote:
| Flutter still exists, so as a competitor you need to beat both
| React Native and Flutter.
| p2detar wrote:
| I last used RN half a decade ago, but from what I see around me
| - our frontend developer, who is proficient in React, actually
| chose to use Flutter for our iOS and Android mobile apps -- and
| he's quite satisfied with it.
| kelvinjps10 wrote:
| Kotlin did it first with kotlin multiplatform
| hatmanstack wrote:
| The Simpsons did it.
| wiseowise wrote:
| Why would a marginal platform language become de facto language
| for mobile? If anything, Kotlin is much better positioned to
| fill the niche. It is already far, far ahead of anything Swift
| has to offer and is backed by a company actually making money
| out of the tools. What incentive does Apple have? My bet is
| expanding Apple services (Apple TV, Music, etc.), but is that
| enough for Apple to create a proper dev ecosystem? Highly
| unlikely.
| bingobangobungo wrote:
| Why cant everyone just get along and allow for KMP to work all
| within Android Studio instead of XCode. I'm working with this
| stuff everyday and that is by far my biggest headache.
| jajuuka wrote:
| Same reason everyone doesn't use Xamarin. Everyone has their
| own multiplatform framework solution.
| wiseowise wrote:
| JetBrains already works on Swift support within Android Studio.
| TheJoeMan wrote:
| Does this project tie in to the SKIP transpiler?
| https://skip.tools/blog/bringing-swift-to-android/
|
| I have an existing Swift / SwiftUI app that I am looking to port
| to Android, and have been not wanting to move to React Native.
| joanniso wrote:
| Yes, Skip is a major contributor to this effort!
| wahnfrieden wrote:
| You don't need to use the transpiler anymore. Skip added native
| Swift execution on Android recently. It has much greater
| compatibility than the transpiler (though they maintain both).
| marcprux wrote:
| Yes, Skip has been using our preview release of the Swift SDK
| for Android in our Fuse mode for over a year, and it has proven
| to be very popular! You can see our blog post about using it to
| build a completely native SwiftUI app for Android at
| https://skip.tools/blog/fully-native-android-swift-apps/
|
| To clarify a couple of other comments about transpilation vs.
| compilation, Skip has two modes: Skip Lite, whereby your Swift
| code is transpiled into Kotlin, and Skip Fuse, whereby Swift is
| compiled natively for Android using the Swift SDK. Skip Fuse
| and Skip Lite work side-by-side, where Skip Lite is used to
| provide bridged integration to many popular Kotlin frameworks
| on Android (Lottie, Firebase, Stripe, etc.). You can read about
| the comparison between the two modes at
| https://skip.tools/docs/status/ and see a subset of our
| available modules at https://skip.tools/docs/modules/
|
| We are very excited that the Swift SDK for Android is now
| official and we can switch over from using our own preview
| build of the SDK to the officially supported one.
| VWWHFSfQ wrote:
| I think people will get excited about this and then quickly
| realize how painful it is to code in a foreign environment from
| the platform.
|
| How miserable it would be trying to write Java or kotlin
| targeting iOS apps. I think this will be the same.
|
| Just use the native tools and languages for the platform.
| Swift/Objc/xcode for iOS. Java/Kotlin/Android Studio for Android.
|
| You will be so much happier.
| AnthonyMouse wrote:
| This depends entirely on how well the thing you're using
| bothered to support multiple platforms.
|
| Browsers are pretty much the gold standard here, ironically.
| You might have to care if it's Firefox or Chrome but it's
| _very_ rare for you to have to care if it 's Firefox on Windows
| or Mac or Linux. It's exactly why React is simultaneously
| horrible and everywhere.
|
| So it can be done, it's just a question of whether that
| framework has done it well, ideally while also doing other
| things well (unlike React).
| oblio wrote:
| > How miserable it would be trying to write Java or kotlin
| targeting iOS apps. I think this will be the same.
|
| What happens in the Java/Kotlin case?
| lukko wrote:
| I would love if I don't have to port my whole iOS app to Android
| manually. How exactly would this integration work if say business
| logic is handled by Swift - I'm guessing UI and SwiftUI would not
| be supported initially?
|
| My app [0] uses a lot of metal shader code - I'm guessing there's
| no easy way to bring that across?
|
| [0] https://apps.apple.com/app/apple-store/id1545223887
| hoppp wrote:
| Yeah I would also like to see SwiftUI but its apple ecosystem
| only.
| wahnfrieden wrote:
| https://skip.tools ported SwiftUI to Android.
| joanniso wrote:
| Metal cannot be used on Android. Your business logic can be
| ported - if it's separated as a library. If you don't want to
| separate it, Skip can handle bridging a lot of Apple libraries
| including SwiftUI.
| lukko wrote:
| Thanks - I see, so swift packages for everything.
|
| What would be the equivalent shader / GPU language on
| Android? OpenGL?
| rahkiin wrote:
| Vulkan with glsl to spirv compiler would be equivalent
| thomspoon wrote:
| OpenGL or Vulkan, you might be able to have some luck
| transpiling metal shaders to spirv-cross at a cursory look
| wahnfrieden wrote:
| Sometimes it is easiest to have an agent like Codex
| rewrite the shader instead...
| fooker wrote:
| It'll take you thirty minutes to port the shaders with a modern
| LLM.
|
| I am not joking. I have done this. Shaders are pretty simple.
| You'll have some weird artifacts but thats more because of
| platform differences than translation errors.
| bigyabai wrote:
| > Over 25% of packages in the Swift Package Index already build
| for Android
|
| That's... not encouraging.
| joanniso wrote:
| I'm pretty happy with that number, considering this ecosystem
| is _brand new_. This is the lowest it'll be.
| tomovo wrote:
| Yes and any package dealing with UI is automatically
| disqualified, so 25% really is pretty good.
| tclancy wrote:
| If you compare it to absolute zero I think you may be
| pleasantly surprised.
| jajuuka wrote:
| "You got Kotlin in my iOS."
|
| "You got Swift in my Android."
| ignoramous wrote:
| Kotlin on iOS is statically compiled and interops with
| Swift/ObjC natively. Don't think KMP on iOS is even running a
| VM like Flutter has to with Dart?
|
| https://kotlinlang.org/docs/native-overview.html
| oblio wrote:
| How solid is Kotlin on iOS?
| tomovo wrote:
| If you mean Kotlin Multiplatform, it works pretty well. Not
| easy to debug, the GC is a bit weaker than the Android
| implementation and optimized builds can get crazy slow as
| the app grows. The interface uses auto-generated ObjC
| headers which are very verbose. Native Swift API is in
| beta. Overall still worth it for a commercial app, I think.
| mr7uca wrote:
| incremental native builds are getting better at least
| bradleyy wrote:
| Perfectly delivered, the Reese's commercial that keeps on
| giving. Although to fully match the analogy, there'd need to be
| some form of Kotlin+swift hybrid with a crinkly wrapper.
| mosura wrote:
| I hope they actually stick with this. Swift embedded, for
| example, is a sort of proof of concept more than viable platform,
| and you end up battling that more than the problem you are trying
| to solve.
|
| It is a shame because aesthetically Swift is easily the nicest of
| the modern safe languages, but there have been really odd noises
| in the community about project leadership that sour things.
| outadoc wrote:
| I'm a big lover of Kotlin Multiplatform, but I think this is
| pretty cool anyway. I could imagine making a native Swift library
| shared between the platforms for memory-sensitive work. I'm not
| sure about using it to write an app's entire business logic, KMP
| is going to be more mature for a while for this.
| oblio wrote:
| Do you build desktop apps, too, with Kotlin Multiplatform? How
| mature is it overall?
| icar wrote:
| I want to know this as well. My only interaction with a
| Kotlin Multiplatform app is Jetbrains Toolbox, and it's slow
| to start, has a lot of input lag and overall feels sluggish.
| mr7uca wrote:
| Jvm desktop is honestly the target with the best support. I
| always build on desktop during mobile dev first because I
| don't need to deal with connecting a phone or emulator.
| Second resizable windows by default is so helpful when
| building for many screen sizes. Also it has hot-reload now
| danielfalbo wrote:
| Why can't everything just be a progressive web app
| kylecazar wrote:
| Because Google/Apple don't want us to circumvent their
| respective app stores, so they make certain features/API's a
| PITA (if not impossible) to use unless you are building
| natively.
| timeon wrote:
| Meanwhile I considered PWAs necessary evil on iOS. I would
| gladly use native tools but paying developer subscription
| just to install private/personal apps is no-go.
| throw_m239339 wrote:
| Most people don't even know they exist (I do not count webapps
| in a native shell as PWA). that's the biggest issue with PWA in
| my experience. People aren't using them.
| ls-a wrote:
| Thank you. Please kill RN and Flutter already. I'm done with
| square UI apps that handle touches after two days
| turtlebro wrote:
| You can set the corner radius to whatever you like in Flutter,
| also the framework is quite fast, if an app doesn't respond to
| touches it's likely a poorly made app
| ryeights wrote:
| Flutter has a long-standing issue where every interaction is
| subject to a 1-frame delay on iOS (P2 since 2022)...
|
| https://github.com/flutter/flutter/issues/110431
|
| Not to mention the stuff with shader compilation lag
| turtlebro wrote:
| Sure you can find some issues if you look at it hard
| enough. In the real world scenario, it's very possible to
| ship a performant, functional app in Flutter and has been
| for some time now. It also brings some of the best
| development experiences with Dart, consistent declarative
| paradigm & hot reload. Like all things, it's a trade off,
| for me it's very hard to merit maintaining 2x native apps.
|
| There are many, many people out there shipping Flutter
| apps, and many, many users using those apps. So please stop
| the hate maybe?
| ryeights wrote:
| I'm not hating, I'm actually working on a Flutter project
| currently. I don't understand why we need to pretend like
| the platform is perfect
| rumori wrote:
| I'm curious to hear where you think this is a showstopper.
| I've been testing some Flutter apps lately and other than
| some mismatches in platform UI elements they have been
| smooth. I wonder what you would think of apps like Kagi
| News.
| bitpush wrote:
| I have no love for RN and Flutter, but what makes you think
| Swift on Android will be even remotely close to what Flutter
| and RN has?
|
| If anything, Apple will launch this and quickly forget this
| exist.
| bpavuk wrote:
| although Apple has tremendous influence over Swift, Swift for
| Android is a grassroots effort, as said in the link. if
| community needs it, community will maintain it, and Apple
| won't get in the way. why would they?
| bitpush wrote:
| I guess that goes to the larger point then. OP was saying
| Swift for Android will _finally_ solve all the issues of
| Flutter & RN, presumably meaning Apple with its $$ and
| might will do it.
|
| If it is a grassroots project, it has even bleaker outlook
| then? I wish them success however.
| wahnfrieden wrote:
| Related: https://skip.tools <-- SwiftUI for Android
| trevor-e wrote:
| Very excited to see this as an official project!
|
| I've been toying around with multiplatform frameworks like RN and
| Flutter for a side project of mine but they never feel right. I'd
| rather use the native UI per platform and have a nice way to
| share business logic. KMP exists but I think for most developers
| wanting to build an app it's more common to build for iOS first,
| and then port to Android later if the app gets traction. With a
| little foresight of keeping shared code in a Swift Package, it
| seems like that's getting more and more possible which is great
| to see.
| ivm wrote:
| This is already possible with .NET and MvvmCross: a shared core
| library plus native UI projects for each platform. UIKit feels
| great in C# and it's all been working quite well since Xamarin
| times, with access to the Nuget ecosystem.
| trevor-e wrote:
| Xamarin with .NET and MvvmCross falls into the same bucket as
| RN and Flutter IMO, unless something changed since the last
| time I looked.
| ivm wrote:
| Not at all, but it's important not to mix up Xamarin
| (nowadays just .NET) which is basically native bindings for
| C# and Xamarin.Forms UI framework (nowadays MAUI) which is
| write-once approach like RN.
|
| The former is exactly what you are talking about: building
| native UIs twice and then sharing the common logic.
| trevor-e wrote:
| Very neat, thanks for explaining. The only drawback I've
| seen in the past with apps using .NET is the binaries end
| up pretty huge due to the runtime. I'm assuming that's
| still the case here? I wouldn't be surprised if this is
| also an issue with Swift for Android but I haven't looked
| yet.
| frankus wrote:
| I think business-logic-in-JavaScript is something cross-
| platform folks shouldn't snooze on either, with the usual
| caveats of not doing anything performance-critical or where an
| asynchronous API would be awkward (to be clear, using
| JavaScriptCore or QuickJS or the like, not just running in a
| WebView)
|
| But it'll run on iOS (v7.0+), Android (I think more recently)
| and of course web and server-side. And most importantly, it's
| hot-reloadable, as long as you don't run afoul of platform
| gatekeepers (i.e. use it for bug fixes and minor behavior
| changes, not like whole new features).
|
| One of the frustrating things about mobile development is that
| once you ship a version, that version will almost certainly be
| running on at least _someone 's_ device indefinitely without
| being upgraded. My day job is even on step further back in that
| we have to get our customers to update the version of our SDK
| that they're integrating (which for many of them means
| contracting out because they don't have an in-house mobile dev
| team), before they ship an app update, which then needs to be
| installed by end-users, whose device might not even support the
| new deployment target...
|
| (I've been trying to sell this to the bosses for the last 9
| years or so, and never gotten the go-ahead, so there could be
| aspects I'm missing, but it always seemed like a huge missed
| opportunity).
| trevor-e wrote:
| OTA updates are definitely nice to have and I'm surprised
| there's not a way to do so with native iOS since RN and
| Flutter already support it. Technically it is possible with
| dynamic frameworks.
|
| In practice though it's somewhat easy to workaround the lack
| of OTA with dynamic server configuration for clients.
| bpavuk wrote:
| yes. there _is_ an aspect you are missing.
|
| no one in their right mind wants to bundle Chromium with
| every app install, and every Discord user hates mobile
| Discord app, which is, guess what? uses Chromium!
| cyberax wrote:
| React.Native doesn't use Chromium.
| iknowstuff wrote:
| Your profile is full of incorrect assertions about
| software. What do you do for a living
| NSUserDefaults wrote:
| For JS driving the business logic you do not need a browser
| to run it. On iOS there is JavaScriptCore and there are
| other Javascript runtimes out there that are quite small.
|
| That said, it is true that Javascript may not be the right
| choice for every app and some developers may be used to
| better language features and performance than that.
| a3w wrote:
| > but I think for most developers wanting to build an app it's
| more common to build for iOS first, and then port to Android
| later if the app gets traction.
|
| Is it? There seem to be a hundred million Java developers out
| there, that can do an Android app, plus even release that in-
| house or with minimal registration fees if single
| dev/sideproject.
|
| For Objective-C/Swift, there seem to be ten percent as many
| devs.
|
| I always only tinkered with Android apps in my spare time, but
| never managed to deploy anything to iOS.
|
| Also, outside the US, iPhones are a 10 % niche product in
| private hands, but companies might use a lot of iPads or
| provide iPhones as work phones, so perhaps companies do think
| of both platforms as second class citizens (behind
| windows/browser as two other "OS-like" primary platforms)
| twof wrote:
| It's not really about the number of developers. If you're
| running a company in the US at least, most of your revenue is
| going to come from iOS users.
| makeitdouble wrote:
| The US still has a strong iOS market share, shipments just
| never go below 50%
|
| https://counterpointresearch.com/en/insights/us-
| smartphone-m...
| giobox wrote:
| Even ignoring global OS marketshare, iOS app store
| customers just simply spend a lot more money per user on
| the App Store vs Google Play (Google's Android app
| store). You gotta go where the money is to some extent to
| get paid.
|
| Global revenues on the iOS app store have always been
| significantly larger than Google play, even with only
| ~30% of the global smartphone market.
|
| > https://sqmagazine.co.uk/iphone-vs-android-statistics/
| disiplus wrote:
| for us its pixel phones, you can choose iphone if you want
| but most of us want pixel. so for me its macbook + pixel. I
| think the iphone only is unique to US.
| cosmic_cheese wrote:
| It probably varies from area to area, but in the US iOS first
| is common.
|
| Having developed both, it makes sense.
|
| iOS is by far the more profitable of the two platforms and
| its support burden is substantially lower -- far fewer
| versions to think about with the bulk of users running 0-2
| versions behind, single form factor (only size variants),
| zero manufacturer skin quirks/bugs to deal with. It's a more
| fertile environment for getting up and running and getting
| the core product shaken out.
|
| Android can come later when you're out of rapid iteration and
| have the bandwidth to deal with the idiosyncrasies of the
| Android world.
| pzo wrote:
| react native _do_ uses native UI per platform in contrast to
| flutter or compose multiplatform. React Native improved a lot -
| it 's not the same technology that has been 5 years ago.
| Especially this year there were plenty of improvements also
| regarding speed but in react native and community plugins (new
| architecture rolled in, react compiler, hermes v1, nitro
| modules, flash list v2, legend list, react native skia, react
| native webgpu, expo use dom) Tooling in JS/TS ecosystem also
| improved a lot.
| trevor-e wrote:
| Yes it uses native UI by _wrapping_ the underlying
| frameworks, but that still means there is a layer in between
| that has to be updated with fixes and new features. Every RN
| project I 've tried in the past turned into a dependency mess
| since you find edge cases that are not supported by the
| framework.
|
| It's definitely gotten better like you said but I just prefer
| to work with the native platform code even if it's a bit of
| extra effort.
| palata wrote:
| > KMP exists but I think for most developers wanting to build
| an app it's more common to build for iOS first
|
| This sounds US-centric to me.
|
| The advantage of KMP is that it is pretty mature and it is used
| in _big_ apps like Google workspace (Google Docs etc), so it
| feels like it may be in a really good position.
|
| I used to be exited about Flutter when it started, but the
| speed of major releases (by the time I had rewritten my app for
| Flutter 2, Flutter 3 was out, or something like that) and it
| did not seem to get so much traction (Dart is fun, but well).
|
| KMP builds on top of Kotlin, with big investment from JetBrains
| and Google. That looks extremely promising to me.
| icar wrote:
| At Proton they use Rust for shared logic (their claim is more
| than 80% of the codebase iirc), and platform specifics for the
| rest.
| bbkane wrote:
| https://proton.me/blog/authenticator-rust - I think this is
| what you're referring to? Looks really nice
| flakiness wrote:
| This looks like a Fluttter competitor where the UI is rendered by
| the Swift SDK side (vs Android-provided library).
| afavour wrote:
| This is really interesting. I've made cross platform mobile
| libraries before and ended up using Rust... which was fine. But
| there's a huge built in advantage to using a language one half of
| the problem is already fluent in. Curious to see how well it
| combines with Swift/Webassembly.
| guelo wrote:
| Less necessary to be fluent nowadays with LLMs.
| featherless wrote:
| Does this result in the Swift code being compiled or transpiled?
| orliesaurus wrote:
| Interesting to see excitement around this release...
|
| BUT beyond cross-platform hype there's a practical question...
| what developer tooling will look like... Are we getting first-
| class debugging, package management, continuous integration for
| Android targets...
|
| ALSO adoption often comes down to licensing and governance...
| open SDKs thrive when the steering group is transparent and
| responsive...
|
| And it's worth remembering that bridging two ecosystems isn't
| just about code... it's about aligning design idioms, APIs and
| expectations... Without that you end up with uncanny valley
| apps...
| user3939382 wrote:
| Whole modern stack is upside down this is a waste of talent
| pzo wrote:
| Happy to have it but I worry it's too little too late. I see more
| and more new projects choosing React Native, Flutter or Jetpack
| Compose Multiplatform. It's gonna take multiple years for apple
| or community to catch up to those. Also they should open (source)
| up xcode tooling for other IDE to get any better cross-platform
| adoption.
| a3w wrote:
| The example shows non-GUI code written in Swift, with Kotlin for
| frontend. So, still no UI in Swift?
|
| What does it add to the linked "swift-java project" then at all,
| perhaps some lifetime events and a sort of batteries-included
| standard library?
| saubeidl wrote:
| This looks not bad, but why would anyone use this in a world
| where Kotlin Multiplatform exists?
| bsimpson wrote:
| The most important question for every cross platform framework is
| what happens to the UI?
|
| Adobe products (both the Creative Suite, and their Flex Builder
| environment for Flash app) had their own design system that felt
| foreign on every platform it shipped on. If you wanted something
| that felt native, you had to reimplement e.g. Apple Aqua in Flash
| yourself.
|
| Flutter goes out of its way to do that work for you, aiming for a
| "Cupertino" theme that looks-and-feels pixel-perfect on iOS.
|
| React Native tries to delegate to platform primitives for complex
| widgets, so scroll views still feel like Apple's when on Apple's
| platform.
|
| Just about every top-level comment here is talking about that in
| one way or another; yet the blog post doesn't mention it at all.
|
| It's possible that Apple/Swift's mindshare among developers will
| lead to a significant number of apps shipping the Swift version
| for Android even if it means using Apple's UI, simply because
| they can't be bothered to make something bespoke for Android.
| Then again, Apple takes so much pride in its design language that
| it might not be willing to implement anything that feels good on
| a platform they don't own. If they were to ship an API-compatible
| widget toolkit, it might e.g. use intentionally bad spring
| physics to remind you you aren't on an iPhone.
|
| I wonder how big the community part of this is. Is this an open
| source project of non-Apple people who are trying to break
| Apple's platform out of its walled garden? Is a lot of it funded
| by Apple? Ultimately, that's going to shape a lot of how this
| plays out.
| timsneath wrote:
| It's worth noting that this doesn't add any expectations for
| how your UI is built. The example shown in the screenshot
| continues to use Jetpack Compose (Android's native UI) with
| Kotlin invoking Swift business logic. You can also use other UI
| frameworks on Android, of course, including some that are
| written in Swift.
|
| One nice thing about this implementation is that it shares many
| of the same characteristics as Swift on other platforms: unlike
| some common alternatives, it's not garbage collected but uses
| reference counting; it uses the same underlying libraries,
| concurrency primitives and memory model.
|
| Excited to see how folk use it... it's technology that will
| hopefully springboard some other interesting innovations.
|
| [Disclosure: I work on developer tools and frameworks at
| Apple.]
| wffurr wrote:
| How does transpiration work without GC? I would think all the
| Kotlin equivalents would be GC heap allocated objects.
| timsneath wrote:
| This doesn't transpile. It cross-compiles to Android
| architectures using the NDK. You can see a very simple
| "hello world" example at the bottom of this article:
|
| https://www.swift.org/documentation/articles/swift-sdk-
| for-a...
| mikeocool wrote:
| > It's possible that Apple/Swift's mindshare among developers
| will lead to a significant number of apps shipping the Swift
| version for Android even if it means using Apple's UI
|
| It doesn't sound like this release includes bringing SwiftUI or
| UIKit to android, so unless you did a ton of work to replicate
| it (ala flutter) using Apple's UI on android probably still
| isn't really possible.
| palata wrote:
| > The most important question for every cross platform
| framework is what happens to the UI?
|
| I kindly disagree. The first feature I want from a cross-
| platform framework is that it lets me write a native UI. That's
| why I like KMP: I can just share a framework with an iOS app
| built with SwiftUI.
|
| Sharing business logic makes a lot of sense in a ton of cases
| and has been done forever (C/C++/Rust/Go libraries, etc).
| Sharing UI in complex apps, in my experience, always ends up
| being a "write once - debug everywhere" nightmare.
|
| What KMP (and I'm hoping Swift for Android) bring is the
| possibility to share a Kotlin (respectively Swift) library
| instead of sharing code with C/C++/Rust/Go. So that an
| Android/iOS team can keep using Android/Swift without having to
| introduce a third language for sharing logic.
| virtue3 wrote:
| Having worked a long time with client teams as a lead - this
| is always the biggest pain in the ass.
|
| At one of my last phase startups I started shifting all our
| business logic stuff into our graphql server and treated it
| like it was part of the client teams. (we had ios/android/web
| as independent full apps with a very small team of devs).
|
| Business logic is the real killer. Have one person suck it up
| and do it in typescript (sorry y'all) on the GQL/apollo
| server and all the clients can ingest it easy.
|
| Send down viewmodels to the clients not data models. etc etc.
|
| This helped DRAMATICALLY with complexity in the clients.
| kridsdale3 wrote:
| The Browser Company did an amazing job of porting SwiftUI to
| Windows, where the element primitives in the language map to
| native Windows UI C++ classes under the hood.
|
| Perhaps the future of Swift for Android is similar, where
| SwiftUI will map to Jetpack elements. That would be cool.
|
| Remember on iOS and MacOS, SwiftUI is not "native". It's a
| description language that system frameworks interpret and
| create NSViews and UIViews and CGLayers etc out of.
| mr7uca wrote:
| Sweet, now I can make a cursed android app with views written in
| switft that use kotlin viewmodels
| palata wrote:
| I have been sharing code between Android and iOS for a long time.
| Sharing the UI has always been a nightmare for non-trivial apps.
|
| What makes sense to share is complex libraries, and usually I
| have been doing that with C/C++/Rust libraries. But it means that
| the team now deals with Kotlin, Swift _and_ one (or more) of
| those "sharing" languages.
|
| What I believe KMP and Swift for Android bring is that teams will
| be able to share libraries in Kotlin/Swift, so that they can keep
| writing in their preferred language without having to introduce
| C/C++/Rust.
|
| I believe this approach is vastly superior to any kind of
| framework that tries to share the UI. Mobile devs, in my
| experience, want to use the native tools: Kotlin for Android and
| Swift for iOS.
| w10-1 wrote:
| I read this announcement mainly as proving the success of the new
| support for SDK's. Previously, supporting another platform
| required invasive hodge-podge of CMake tangles at best.
|
| Swift SDK's are a way for anyone to support any platform, as
| proven by the Android guys doing it on their own. There are also
| SDK's for Linux, wasm, and embedded (and soon, windows?). So long
| as you play by SDK rules, Apple won't stop you from porting Swift
| to a new platform, even on competitive platforms like Android.
|
| (The inter-op story with the JVM languages is still being
| written; it reduces to either the C/C++ FFI or the two incomplete
| duals of Java's legacy JNI and newer FFI/Memory interfaces.
| Prototypes work fine when the semantics are the same, but beyond
| that, there be dragons. Cross-platform UI frameworks are
| similarly (and likely eternally) afflicted with bright and dark
| spots.)
___________________________________________________________________
(page generated 2025-10-24 23:00 UTC)