Swift LanguageAnnouncing the Swift on Android Working Group, with the goal of establishing and maintaining Android as an officially supported platform for Swift. More here: https://forums.swift.org/t/announcing-the-android-workgroup/80666 #android
Brett Walker@swiftlang Glad to see that. I’ve seen quite a few companies lately using Kotlin Multiplatform to share business logic across Android/ iOS apps and Swift really needs a competitive alternative to that.
Brandon Butler@petsound Don’t forget Flutter!
@brandonbutler True, I guess it depends how far they want to go in supporting Android frameworks with Swift.
Miha Markič@petsound @brandonbutler All these non native solutions have frictions, you have at least twice as many problems and you expand your dependency on yet another product which might evaporate in future. Thanks, I'll pass.
@mihamarkic @petsound Can you elaborate on “twice as many problems” my experience has been the opposite.
@brandonbutler @petsound You have dependency issues (you usually need wrapper libraries) and if you look at Android ecosystem - it's complex and with lot of libraries which needs to be wrapped and depend on such wrapped ones. Then you have build process which is as well two fold - one your language and then it has to be wrapped into android app/library. Also android build process changes here and there, kotlin gets more complex. And so on.
@mihamarkic These sound like the issues I experienced with Xamarin.Forms.
With Flutter we don’t experience things like this too often as we’re not using native apis that much.
@brandonbutler I guess if you don't use native libraries then you have less of this issues, but it doesn't change much with flutter. Another problem with flutter is updating native bootstrap, isn't it?
@mihamarkic Since flutter renders everything on their own canvas it seems like it’s a bit more resilient than frameworks that try to resolve to native UI.
That being said there can be an odd Xcode update that makes compiling/debugging break until they fix that. But I’m really worried about SDK changes breaking things.
The most I have to mess with native stuff is if we’re using Bluetooth or the odd setting update in a plist file, app icons, etc.
@brandonbutler Yes, that's true about resiliency, but just to since extent. And then you are hit with another set of problems. One of them is autofill which at least on Android wasn't working for years, is it working now? Then you have integration of 3rd party native UI and not libraries. Then you have webview where flutter libraries exist but they are lacking features. Then you have 60hz refresh limit. And so on. Even if it works initially, then your client comes with a feat request...
@brandonbutler in addition your app now depends on flutter and its libraries. What if Google drops it in favor of the Kotlin multiplatform? The bug fixing on their side isn't something to brag about as well.
@mihamarkic This is true. Though Flutter is open source and since a lot of Google’s apps are written with it gives me a bit more confidence it will stick around.
@brandonbutler Yeah, but one never really knows at the end of the day.