Earlier quoted context omitted.
> 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). Sharin…
> > 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. I don’t understand – aren’t you agreeing?
The Swift SDK for Android
291–298 of 298 posts
Re: The Swift SDK for Android
#292Earlier quoted context omitted.
> 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). Sharin…
This isn't disagreeing
Re: The Swift SDK for Android
#293Earlier quoted context omitted.
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.
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.
> looking forward to native swift export to go stable - it's currently experimental
What are the timelines given for a stable release?
And when it does, what else would you say are the next big things annoying/missing in terms of devex?
Re: The Swift SDK for Android
#294Re: The Swift SDK for Android
#295Earlier quoted context omitted.
How does transpiration work without GC? I would think all the Kotlin equivalents would be GC heap allocated objects.
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...
Re: The Swift SDK for Android
#296Earlier quoted context omitted.
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.
Thanks. > looking forward to native swift export to go stable - it's currently experimental What are the timelines given for a stable release? And when it does, what else would you say are the next big things annoying/missing in terms of devex?
The other big problem is debugging. It's impossible to breakpoint kotlin when debugging from swift, so some bugs that are realised only from the swift client side can be tricky and time consuming to fix.
Re: The Swift SDK for Android
#297Earlier quoted context omitted.
I think using a closed source solution (except the platform native solution) for such a core part of an application is a big no.
I agree it makes me very nervous. Though as I understand it, it's mostly open source (edit: not the build tool tho). Their transpiler solution at least results in maintainable Kotlin code that one could begin working in directly without needing Skip. But the transpiler way is more limiting than the native Swift SDK on Android. I'm considering using it just as a way to bootstrap as my main focus has been iOS/Mac. If I…
Re: The Swift SDK for Android
#298Earlier quoted context omitted.
The issue with that approach is that the state of the art for iOS dev is about 15 years behind the state of the art for Android dev. The amount of simple things that are incredibly painful for iOS devs to do is astounding. Some of that is because xcode is horrific, some of it is that the ecosystem is starved by disinvestment from Apple. I've talked with colleagues in several companies and the story is always the same…
Exact opposite experience :)