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
marceloexc@swiftlang let's fucking go
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.
@mihamarkic Autofill works. If you absolutely need a native UI component there is a platform view you can use. But the third party UI views one would use would be written in Dart/Flutter. We view would be an example of using a native view, it can be done. Flutter apps can go to 120hz.
@brandonbutler Good that they implemented those two - it took them ages though.
Ivan Mir@brandonbutler @mihamarkic that's not quite a problem for native .NET either, but at the cost of double UI
@ivmirx @mihamarkic The one pain point I had with even just native .NET was you had to wait for Microsoft to update the binding libraries.
@brandonbutler @mihamarkic in theory, it's possible to slap together an API wrapper for something specific. Usually I just don't move to new APIs quickly anyway, but I'll see how hard will it be to accomplish with the Liquid Glass update.
@ivmirx @brandonbutler While it is possible to create one by yourself, AFAIK it's by no means easy and you most probably don't want to. Also MS doesn't provide bindings to beta libraries.
@mihamarkic @brandonbutler it's not easy but more because of the poorly documented process than the binding concept itself. I just wrote an up-to-date guide this week: https://qotoqot.com/tech/ios-bindings/
In the case of beta APIs or Swift-only APIs (Swift bindings are still far from release), you can slap together some Swift wrapper with exposed `@objc` methods, and then bind that.
I believe the biggest problem with mobile .NET is the lack of documentation and how-to's for brittle multi-step processes.
@ivmirx @brandonbutler I guess you have yet to meet kotlin :) And you are definitely correct on lack of docs point.
@mihamarkic @brandonbutler damn, I was looking at KMM with hope! Oh well, seems that existing cross-platform solutions are basically a "choose your poison" situation.
@ivmirx @brandonbutler Kotlin is great and everything, it's just that it is not easy to create bindings for C# (in my humble experience that is). And then you need bindings to kotlin stuff (ktx) as well (provided by MS).
@ivmirx @brandonbutler I had to implement emarsys libraries once (they don't give a shit about .NET). And those are huge and kotlin based. I've ended up creating an Android project that had a dependency on emarsys libraries and I've implemented just the few simple methods I needed. And then create bindings to this simplified project. Even then it was not trivial - also needed including thousands of emarsys libraries to .NET and so on.
@mihamarkic @brandonbutler uff, yes, I guess it'd be a problem with most if not all cross-platform solutions. In the end, I think that the apps just have to go native if they're are heavily dependent on some not-so-popular API sets of a specific platform or on 3rd party SDKs.
Probably the cross-platform business logic can be somewhat achieved with a portable embedded library in Rust / C++ / … but that's even less documented path!
Sven Jacobs 
@petsound @swiftlang Competition is good! KMP is a few years ahead so let's see how fast Swift can catch up. I would love to see a better interoperability between KMP/Android and Swift. Regardless of which solution you choose, I think we can all benefit from this development.
Nadiyar/13697@swiftlang lmao welcome to hell, Swift developers <3