13 ms·

The Swift SDK for Android

696 points by gok 1y ago

chrsstrm 1y ago
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 1y ago
  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 1y ago
  > 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 https://github.com/swiftlang/swift-evolution/pull/2946/files
  - thenaturalist 1y ago
    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-android-getting-started.html https://www.swift.org/documentation/articles/swift-sdk-for-a...
    - joanniso 1y ago
      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.
      - Culonavirus 1y ago
        Isn't it kinda a bad sign that people on HN have to argue in comments about what your library/framework/sdk even does?
- brookst 1y ago
  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 1y ago
  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/ 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 1y ago
  The reverse is slowly becoming a possibility. Jet Brains just announced another improvement with Swift Export. https://kotlinlang.org/docs/native-swift-export.html https://kotlinlang.org/docs/native-swift-export.html But it's not there yet
- marcprux 1y ago
  An example of an Android app that is built using the Swift SDK for Android and is available in the Google Play Store is Skip Showcase: https://github.com/skiptools/skipapp-showcase/ https://github.com/skiptools/skipapp-showcase/ (disclaimer: I work on the Skip.tools product)
colesantiago 1y ago
What does this mean for React Native? Is Swift now going to be the de facto language for Mobile (and maybe Desktop) development?
- kelvinjps10 1y ago
  Kotlin did it first with kotlin multiplatform
  - hatmanstack 1y ago
    The Simpsons did it.
- akmarinov 1y ago
  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 1y ago
    > Also React dev experience makes anything Swift related look like stone age technology How so?
    - Larrikin 1y ago
      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 1y ago
      The npm ecosystem is one of the worst and most backwards places to be, so I don't think so.
      - wiseowise 1y ago
bingobangobungo 1y ago
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 1y ago
  Same reason everyone doesn't use Xamarin. Everyone has their own multiplatform framework solution.
- wiseowise 1y ago
  JetBrains already works on Swift support within Android Studio.
TheJoeMan 1y ago
Does this project tie in to the SKIP transpiler? https://skip.tools/blog/bringing-swift-to-android/ 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 1y ago
  Yes, Skip is a major contributor to this effort!
  - tomovo 1y ago
    Are they putting work into the SDK or is there some integration going on? The way I understand it the SDK is compiled straight into Android binaries, whereas Skip transpiles? How does that work together?
- wahnfrieden 1y ago
  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 1y ago
  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/ 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/ https://skip.tools/docs/status/ and see a subset of our available modules at https://skip.tools/docs/modules/ 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 1y ago
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 1y ago
  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 1y ago
  > 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?
- morshu9001 1y ago
  idk about Android, but native iPhone dev is pure torture. Hence React Native.
  - tcoff91 1y ago
    Android is way worse. iOS has way better APIs. Android studio is way better than XCode though
    - cosmic_cheese 1y ago
      Agreed on SDKs/APIs. Compose improved the Android situation but it’s still a mess compared to UIKit. I’m more mixed on Android Studio. It’s fine I guess, but I wish its UI were more deeply customizable. Many of its design decisions irritate me.
lukko 1y ago
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 https://apps.apple.com/app/apple-store/id1545223887
- hoppp 1y ago
  Yeah I would also like to see SwiftUI but its apple ecosystem only.
  - wahnfrieden 1y ago
    https://skip.tools https://skip.tools ported SwiftUI to Android.
- joanniso 1y ago
  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 1y ago
    Thanks - I see, so swift packages for everything. What would be the equivalent shader / GPU language on Android? OpenGL?
    - rahkiin 1y ago
      Vulkan with glsl to spirv compiler would be equivalent
    - thomspoon 1y ago
      OpenGL or Vulkan, you might be able to have some luck transpiling metal shaders to spirv-cross at a cursory look
bigyabai 1y ago
> Over 25% of packages in the Swift Package Index already build for Android That's... not encouraging.
- tclancy 1y ago
  If you compare it to absolute zero I think you may be pleasantly surprised.
- joanniso 1y ago
  I'm pretty happy with that number, considering this ecosystem is _brand new_. This is the lowest it'll be.
  - tomovo 1y ago
    Yes and any package dealing with UI is automatically disqualified, so 25% really is pretty good.
jajuuka 1y ago
"You got Kotlin in my iOS." "You got Swift in my Android."
- ignoramous 1y ago
  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 https://kotlinlang.org/docs/native-overview.html
  - deleted 1y ago
    [deleted]
  - oblio 1y ago
    How solid is Kotlin on iOS?
    - tomovo 1y ago
      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 1y ago
        incremental native builds are getting better at least
      - afro88 1y ago
        We use it in my team and it works well enough, but iOS is a bit second class citizen. Everything translates to Obj-C (NSObject at the root), so even something as simple as a data class becomes NSObjects with a cumbersome dev experience rather than a native swift enum. We're looking forward to native swift export to go stable - it's currently experimental / beta.
deleted 1y ago
[deleted]
mosura 1y ago
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.
- deleted 1y ago
  [deleted]
- ranie93 1y ago
  guard let self = self else { return }
  - timsneath 1y ago
    Ha! But that's not semantically meaningful Swift code in any normal context, nor is it idiomatic. `self` is equivalent to `this` in C++, and is never normally null. You use this construct for unwrapping nullable fields, for example something like this: guard let httpResult else { return } Note that you don't need to assign the value to itself in modern Swift. This line takes an optional (httpResult?) and returns early if null. If not, you can use it with strong guarantees that it's not nullable, so no need for ? or ! to unwrap it later in the scope.
    - CBMPET2001 1y ago
      I've seen that exact pattern used to safely unwrap a weakly captured 'self' within a closure (to avoid retain cycles)
    - saagarjha 1y ago
      It’s nil in Swift, and what the other comment said ;)
    - viktorcode 1y ago
      > But that's not semantically meaningful Swift code in any normal context, nor is it idiomatic. `self` is equivalent to `this` in C++, and is never normally null. It is, when `self` is captured weakly in a closure, and that closure is outliving the instance.
outadoc 1y ago
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 1y ago
  Do you build desktop apps, too, with Kotlin Multiplatform? How mature is it overall?
  - icar 1y ago
    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 1y ago
    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 1y ago
Why can’t everything just be a progressive web app
- kylecazar 1y ago
  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 1y ago
    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 1y ago
  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.
- ripped_britches 1y ago
  Apple and Google couldn’t take 15-30% that way
- dagmx 1y ago
  Because hardware capabilities exist outside the realm of web technologies.
ls-a 1y ago
Thank you. Please kill RN and Flutter already. I'm done with square UI apps that handle touches after two days
- turtlebro 1y ago
  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 1y ago
    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 https://github.com/flutter/flutter/issues/110431 Not to mention the stuff with shader compilation lag
    - turtlebro 1y ago
      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 1y ago
        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
        deleted 1y ago
        [deleted]
      - 1y ago
wahnfrieden 1y ago
Related: https://skip.tools https://skip.tools <-- SwiftUI for Android
trevor-e 1y ago
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 1y ago
  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 1y ago
    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 1y ago
      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 1y ago
        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.
flakiness 1y ago
This looks like a Fluttter competitor where the UI is rendered by the Swift SDK side (vs Android-provided library).
afavour 1y ago
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 1y ago
  Less necessary to be fluent nowadays with LLMs.
featherless 1y ago
Does this result in the Swift code being compiled or transpiled?
- mk89 1y ago
  It's compiled. From what I see in other threads, skip.tools offers the possibility to transpile SwiftUi to Compose, so you build one UI and port it to android too. Here we're talking about sharing the code logic (written in swift) and write android UI that uses it.
orliesaurus 1y ago
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...
- andrekandre 1y ago
  > Are we getting first‑class debugging, package management, continuous integration for Android targets... the most important part imo. i'd love it if you could pull/push and build/debug changes to the shared code from android studio and build it all together there, that would reduce a huge amount of friction...
- flutas 1y ago
  IMO the implementation (for me at least) is ... terrible. Why reach for this when it's, at the end of the day, just the exact same as NDK work in C++ but in Swift. You have to use Kotlin / Other UI setup anyways (or their fully-native example, use OpenGL to draw the screen[0]), and on top of that statically assign the package path and class name in the Swift code, while making it an external func in the kotlin code[1]. You then also get to deal with the annoyances that come up with native libs. kotlin side: /* * A native method that is implemented by the 'helloswift' native library, * which is packaged with this application. */ external fun stringFromSwift(): String swift side: @_cdecl("Java_org_example_helloswift_MainActivity_stringFromSwift") [0]: https://github.com/swiftlang/swift-android-examples/blob/main/native-activity/src/main/swift/Sources/native-activity/native-activity.swift https://github.com/swiftlang/swift-android-examples/blob/mai... [1]: https://github.com/swiftlang/swift-android-examples/tree/main/hello-swift/src/main https://github.com/swiftlang/swift-android-examples/tree/mai...
  - ktoso 1y ago
user3939382 1y ago
Whole modern stack is upside down this is a waste of talent
pzo 1y ago
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 1y ago
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 1y ago
This looks not bad, but why would anyone use this in a world where Kotlin Multiplatform exists?
- cosmic_cheese 1y ago
  Because some of us prefer writing Swift over writing Kotlin.
- akmarinov 1y ago
  Pretty much everything starts iOS first, so why bother with KMP when this exists?
  - wiseowise 1y ago
    What’s stopping you from developing in KMP iOS first?
    - hn-acct 1y ago
      The developer experience is worse for an iOS developer.
bsimpson 1y ago
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 1y ago
  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 1y ago
mr7uca 1y ago
Sweet, now I can make a cursed android app with views written in switft that use kotlin viewmodels
palata 1y ago
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.
- viktorcode 1y ago
  Cannot agree more. The UI concepts and capabilities differ too much. Any cross platform UI solution will always be missing some hard to implement things and many recently introduced UI features. And so far I haven't seen a single non trivial app from RN / Flutter world which would feel native on iOS.
w10-1 1y ago
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.)
crossroadsguy 1y ago
Sharing the “business logic” pretty wasn’t the problem — at least not of late. Writing UI on both was the pain, or the existing shared UI solutions. As a mobile dev I’d rather appreciate a common UI framework that doesn’t suck like react native.
- tcoff91 1y ago
  When was the last time you tried react native? It’s pretty good now that they finally completed the transition to the New Architecture. With Expo it’s pretty nice these days.
nhumrich 1y ago
Does this mean there is no longer any excuse to not put iMessage on the iPhone?
- prirai 1y ago
  You mean android?
danielcspaiva 1y ago
Rip flutter
poolnoodle 1y ago
Can somebody explain what goes into making a new language compatible with Android?
- viktorcode 1y ago
  Interop with Android SDK / NDK, plus a simple way to get started with development.
tomburgs 1y ago
I've worked with Flutter, React Native, and now I'm building an app in SwiftUI. I've found a few things in the process: 1.) Neither RN nor Flutter seems to be able to create truly native applications on iOS. I've never once seen an application made in either of them and thought it was a native iOS application. 2.) Unless your application must support both platforms, android (in an economic sense) is dead weight. I was shocked to see how bafflingly little android users contributed to our revenue. I've heard this from people in other companies as well. 3.) SwiftUI (and I assume UIKit) makes it really simple to create apps according to HiG. You can feel yourself fighting the framework whenever you deviate from what Apple wants you to do. I actually think this is a good thing. I think Apple is doing something really smart here. They're not making SwiftUI cross platform, they're making it possible for you to re-use your business logic from your SwiftUI apps in Android apps. The way see I see it they're saying — if you want to spend the least amount of time possible building a cross platform app use Flutter or RN. If you want to create a truly native experience on both platforms, but still re-use your core business logic, Swift is your friend.
- saretup 1y ago
  > android (in an economic sense) is dead weight Well it depends on your business model. Android has much smaller user LTV in most cases (especially in apps with no ads and only IAPs/Subscriptions), but the CPI is also smaller, so the economies of scale are different. In certain situations it happens that iOS is not profitable but android is.
- deleted 1y ago
  [deleted]
- Farbklex 1y ago
  What's your market? Android being financially irrelevant seems very US-centric.
  - tomburgs 1y ago
    Western & Northern Europe. It's not that it was a negligible share of Android users, it's that they didn't generate any meaningful revenue.
kurak 1y ago
I'd love to see a future, where I can use Swift as a bridge between Kotlin and c++ and then gradually port more and more c++ to Swift. Does anyone know/understand what's the story for using Swift's interop with c++ on Android? Should this work right now? How?
- the_arun 1y ago
  Future - Is it possible to run swift built OS to run on Android devices 100%? Is that a threat to Android as an OS?
  - kurrrrrak 1y ago
    Maybe, if someone builds this first. Same could be said about Apple running iOS (as it stands) on Android hardware. It can be done, but there are no incentives for doing this.
victor106 1y ago
> Swift has matured significantly over the past decade — extending from cloud services to Windows applications, browser apps, and microcontrollers Really!!! Would love to know more how that statement is true. I could not find any resources to support that claim
- steve1977 1y ago
  It is probably true in that you can actually do all of that with Swift. How much is actually used on a larger scale is another question.
cranx 1y ago
So this still uses the JNI for the ui? Unfortunate that is
Vipsy 1y ago
When it comes to UI, most of us know native wins for actual feel and simplicity. Cross-platform UI tends to create new headaches, not solutions. Still, having more options like this pushes the ecosystem forward. Let's just hope the platform docs stay sharp and open for devs who want to build confidently.
Kibranoz 1y ago
i am unable to try it as downloading the swift language doesn't work on fedora 42

696 points by gok 1y ago

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 1y ago
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 1y ago
> 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 https://github.com/swiftlang/swift-evolution/pull/2946/files
- thenaturalist 1y ago
  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-android-getting-started.html https://www.swift.org/documentation/articles/swift-sdk-for-a...
  - joanniso 1y ago
    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.
    - Culonavirus 1y ago
      Isn't it kinda a bad sign that people on HN have to argue in comments about what your library/framework/sdk even does?
brookst 1y ago
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 1y ago
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/ 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 1y ago
The reverse is slowly becoming a possibility. Jet Brains just announced another improvement with Swift Export. https://kotlinlang.org/docs/native-swift-export.html https://kotlinlang.org/docs/native-swift-export.html But it's not there yet
marcprux 1y ago
An example of an Android app that is built using the Swift SDK for Android and is available in the Google Play Store is Skip Showcase: https://github.com/skiptools/skipapp-showcase/ https://github.com/skiptools/skipapp-showcase/ (disclaimer: I work on the Skip.tools product)

colesantiago 1y ago

What does this mean for React Native? Is Swift now going to be the de facto language for Mobile (and maybe Desktop) development?

kelvinjps10 1y ago
Kotlin did it first with kotlin multiplatform
- hatmanstack 1y ago
  The Simpsons did it.
akmarinov 1y ago
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 1y ago
  > Also React dev experience makes anything Swift related look like stone age technology How so?
  - Larrikin 1y ago
    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 1y ago
    The npm ecosystem is one of the worst and most backwards places to be, so I don't think so.
    - wiseowise 1y ago

bingobangobungo 1y ago

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 1y ago
Same reason everyone doesn't use Xamarin. Everyone has their own multiplatform framework solution.
wiseowise 1y ago
JetBrains already works on Swift support within Android Studio.

TheJoeMan 1y ago

Does this project tie in to the SKIP transpiler? https://skip.tools/blog/bringing-swift-to-android/ 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 1y ago
Yes, Skip is a major contributor to this effort!
- tomovo 1y ago
  Are they putting work into the SDK or is there some integration going on? The way I understand it the SDK is compiled straight into Android binaries, whereas Skip transpiles? How does that work together?
wahnfrieden 1y ago
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 1y ago
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/ 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/ https://skip.tools/docs/status/ and see a subset of our available modules at https://skip.tools/docs/modules/ 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 1y ago

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 1y ago
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 1y ago
> 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?
morshu9001 1y ago
idk about Android, but native iPhone dev is pure torture. Hence React Native.
- tcoff91 1y ago
  Android is way worse. iOS has way better APIs. Android studio is way better than XCode though
  - cosmic_cheese 1y ago
    Agreed on SDKs/APIs. Compose improved the Android situation but it’s still a mess compared to UIKit. I’m more mixed on Android Studio. It’s fine I guess, but I wish its UI were more deeply customizable. Many of its design decisions irritate me.

lukko 1y ago

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 https://apps.apple.com/app/apple-store/id1545223887

hoppp 1y ago
Yeah I would also like to see SwiftUI but its apple ecosystem only.
- wahnfrieden 1y ago
  https://skip.tools https://skip.tools ported SwiftUI to Android.
joanniso 1y ago
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 1y ago
  Thanks - I see, so swift packages for everything. What would be the equivalent shader / GPU language on Android? OpenGL?
  - rahkiin 1y ago
    Vulkan with glsl to spirv compiler would be equivalent
  - thomspoon 1y ago
    OpenGL or Vulkan, you might be able to have some luck transpiling metal shaders to spirv-cross at a cursory look

bigyabai 1y ago

> Over 25% of packages in the Swift Package Index already build for Android That's... not encouraging.

tclancy 1y ago
If you compare it to absolute zero I think you may be pleasantly surprised.
joanniso 1y ago
I'm pretty happy with that number, considering this ecosystem is _brand new_. This is the lowest it'll be.
- tomovo 1y ago
  Yes and any package dealing with UI is automatically disqualified, so 25% really is pretty good.

jajuuka 1y ago

"You got Kotlin in my iOS." "You got Swift in my Android."

ignoramous 1y ago
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 https://kotlinlang.org/docs/native-overview.html
- deleted 1y ago
  [deleted]
- oblio 1y ago
  How solid is Kotlin on iOS?
  - tomovo 1y ago
    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 1y ago
      incremental native builds are getting better at least
    - afro88 1y ago
      We use it in my team and it works well enough, but iOS is a bit second class citizen. Everything translates to Obj-C (NSObject at the root), so even something as simple as a data class becomes NSObjects with a cumbersome dev experience rather than a native swift enum. We're looking forward to native swift export to go stable - it's currently experimental / beta.

deleted 1y ago

[deleted]

mosura 1y ago

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.

deleted 1y ago
[deleted]
ranie93 1y ago
guard let self = self else { return }
- timsneath 1y ago
  Ha! But that's not semantically meaningful Swift code in any normal context, nor is it idiomatic. `self` is equivalent to `this` in C++, and is never normally null. You use this construct for unwrapping nullable fields, for example something like this: guard let httpResult else { return } Note that you don't need to assign the value to itself in modern Swift. This line takes an optional (httpResult?) and returns early if null. If not, you can use it with strong guarantees that it's not nullable, so no need for ? or ! to unwrap it later in the scope.
  - CBMPET2001 1y ago
    I've seen that exact pattern used to safely unwrap a weakly captured 'self' within a closure (to avoid retain cycles)
  - saagarjha 1y ago
    It’s nil in Swift, and what the other comment said ;)
  - viktorcode 1y ago
    > But that's not semantically meaningful Swift code in any normal context, nor is it idiomatic. `self` is equivalent to `this` in C++, and is never normally null. It is, when `self` is captured weakly in a closure, and that closure is outliving the instance.

outadoc 1y ago

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 1y ago
Do you build desktop apps, too, with Kotlin Multiplatform? How mature is it overall?
- icar 1y ago
  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 1y ago
  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 1y ago

Why can’t everything just be a progressive web app

kylecazar 1y ago
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 1y ago
  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 1y ago
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.
ripped_britches 1y ago
Apple and Google couldn’t take 15-30% that way
dagmx 1y ago
Because hardware capabilities exist outside the realm of web technologies.

ls-a 1y ago

Thank you. Please kill RN and Flutter already. I'm done with square UI apps that handle touches after two days

turtlebro 1y ago
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 1y ago
  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 https://github.com/flutter/flutter/issues/110431 Not to mention the stuff with shader compilation lag
  - turtlebro 1y ago
    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 1y ago
      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
      - deleted 1y ago
        [deleted]
    - 1y ago

wahnfrieden 1y ago

Related: https://skip.tools https://skip.tools <-- SwiftUI for Android

trevor-e 1y ago

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 1y ago
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 1y ago
  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 1y ago
    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 1y ago
      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.

flakiness 1y ago

This looks like a Fluttter competitor where the UI is rendered by the Swift SDK side (vs Android-provided library).

afavour 1y ago

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 1y ago
Less necessary to be fluent nowadays with LLMs.

featherless 1y ago

Does this result in the Swift code being compiled or transpiled?

mk89 1y ago
It's compiled. From what I see in other threads, skip.tools offers the possibility to transpile SwiftUi to Compose, so you build one UI and port it to android too. Here we're talking about sharing the code logic (written in swift) and write android UI that uses it.

orliesaurus 1y ago

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...

andrekandre 1y ago
> Are we getting first‑class debugging, package management, continuous integration for Android targets... the most important part imo. i'd love it if you could pull/push and build/debug changes to the shared code from android studio and build it all together there, that would reduce a huge amount of friction...
flutas 1y ago
IMO the implementation (for me at least) is ... terrible. Why reach for this when it's, at the end of the day, just the exact same as NDK work in C++ but in Swift. You have to use Kotlin / Other UI setup anyways (or their fully-native example, use OpenGL to draw the screen[0]), and on top of that statically assign the package path and class name in the Swift code, while making it an external func in the kotlin code[1]. You then also get to deal with the annoyances that come up with native libs. kotlin side: /* * A native method that is implemented by the 'helloswift' native library, * which is packaged with this application. */ external fun stringFromSwift(): String swift side: @_cdecl("Java_org_example_helloswift_MainActivity_stringFromSwift") [0]: https://github.com/swiftlang/swift-android-examples/blob/main/native-activity/src/main/swift/Sources/native-activity/native-activity.swift https://github.com/swiftlang/swift-android-examples/blob/mai... [1]: https://github.com/swiftlang/swift-android-examples/tree/main/hello-swift/src/main https://github.com/swiftlang/swift-android-examples/tree/mai...
- ktoso 1y ago

user3939382 1y ago

Whole modern stack is upside down this is a waste of talent

pzo 1y ago

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 1y ago

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 1y ago

This looks not bad, but why would anyone use this in a world where Kotlin Multiplatform exists?

cosmic_cheese 1y ago
Because some of us prefer writing Swift over writing Kotlin.
akmarinov 1y ago
Pretty much everything starts iOS first, so why bother with KMP when this exists?
- wiseowise 1y ago
  What’s stopping you from developing in KMP iOS first?
  - hn-acct 1y ago
    The developer experience is worse for an iOS developer.

bsimpson 1y ago

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 1y ago
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 1y ago

mr7uca 1y ago

Sweet, now I can make a cursed android app with views written in switft that use kotlin viewmodels

palata 1y ago

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.

viktorcode 1y ago
Cannot agree more. The UI concepts and capabilities differ too much. Any cross platform UI solution will always be missing some hard to implement things and many recently introduced UI features. And so far I haven't seen a single non trivial app from RN / Flutter world which would feel native on iOS.

w10-1 1y ago

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.)

crossroadsguy 1y ago

Sharing the “business logic” pretty wasn’t the problem — at least not of late. Writing UI on both was the pain, or the existing shared UI solutions. As a mobile dev I’d rather appreciate a common UI framework that doesn’t suck like react native.

tcoff91 1y ago
When was the last time you tried react native? It’s pretty good now that they finally completed the transition to the New Architecture. With Expo it’s pretty nice these days.

nhumrich 1y ago

Does this mean there is no longer any excuse to not put iMessage on the iPhone?

prirai 1y ago
You mean android?

danielcspaiva 1y ago

Rip flutter

poolnoodle 1y ago

Can somebody explain what goes into making a new language compatible with Android?

viktorcode 1y ago
Interop with Android SDK / NDK, plus a simple way to get started with development.

tomburgs 1y ago

I've worked with Flutter, React Native, and now I'm building an app in SwiftUI. I've found a few things in the process: 1.) Neither RN nor Flutter seems to be able to create truly native applications on iOS. I've never once seen an application made in either of them and thought it was a native iOS application. 2.) Unless your application must support both platforms, android (in an economic sense) is dead weight. I was shocked to see how bafflingly little android users contributed to our revenue. I've heard this from people in other companies as well. 3.) SwiftUI (and I assume UIKit) makes it really simple to create apps according to HiG. You can feel yourself fighting the framework whenever you deviate from what Apple wants you to do. I actually think this is a good thing. I think Apple is doing something really smart here. They're not making SwiftUI cross platform, they're making it possible for you to re-use your business logic from your SwiftUI apps in Android apps. The way see I see it they're saying — if you want to spend the least amount of time possible building a cross platform app use Flutter or RN. If you want to create a truly native experience on both platforms, but still re-use your core business logic, Swift is your friend.

saretup 1y ago
> android (in an economic sense) is dead weight Well it depends on your business model. Android has much smaller user LTV in most cases (especially in apps with no ads and only IAPs/Subscriptions), but the CPI is also smaller, so the economies of scale are different. In certain situations it happens that iOS is not profitable but android is.
deleted 1y ago
[deleted]
Farbklex 1y ago
What's your market? Android being financially irrelevant seems very US-centric.
- tomburgs 1y ago
  Western & Northern Europe. It's not that it was a negligible share of Android users, it's that they didn't generate any meaningful revenue.

kurak 1y ago

I'd love to see a future, where I can use Swift as a bridge between Kotlin and c++ and then gradually port more and more c++ to Swift. Does anyone know/understand what's the story for using Swift's interop with c++ on Android? Should this work right now? How?

the_arun 1y ago
Future - Is it possible to run swift built OS to run on Android devices 100%? Is that a threat to Android as an OS?
- kurrrrrak 1y ago
  Maybe, if someone builds this first. Same could be said about Apple running iOS (as it stands) on Android hardware. It can be done, but there are no incentives for doing this.

victor106 1y ago

> Swift has matured significantly over the past decade — extending from cloud services to Windows applications, browser apps, and microcontrollers Really!!! Would love to know more how that statement is true. I could not find any resources to support that claim

steve1977 1y ago
It is probably true in that you can actually do all of that with Swift. How much is actually used on a larger scale is another question.

cranx 1y ago

So this still uses the JNI for the ui? Unfortunate that is

Vipsy 1y ago

When it comes to UI, most of us know native wins for actual feel and simplicity. Cross-platform UI tends to create new headaches, not solutions. Still, having more options like this pushes the ecosystem forward. Let's just hope the platform docs stay sharp and open for devs who want to build confidently.

Kibranoz 1y ago

i am unable to try it as downloading the swift language doesn't work on fedora 42