Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Swift SDK for Android

swift.org

Post reply on HN
Print view View original

101–110 of 298 posts

Re: The Swift SDK for Android

#101

Post by palata »

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.

Re: The Swift SDK for Android

#102

Post by NSUserDefaults »

bpavuk wrote: post #79
frankus wrote: post #67

Earlier quoted context omitted.

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,…

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!

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.

Re: The Swift SDK for Android

#103

Post by turtlebro »

ryeights wrote: post #71
turtlebro wrote: post #58

Earlier quoted context omitted.

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

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

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?

Re: The Swift SDK for Android

#104

Post by ryeights »

turtlebro wrote: post #103
ryeights wrote: post #71

Earlier quoted context omitted.

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

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 peop…

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

Re: The Swift SDK for Android

#105

Post by wffurr »

timsneath wrote: post #93
bsimpson wrote: post #86

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…

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…

How does transpiration work without GC? I would think all the Kotlin equivalents would be GC heap allocated objects.

Re: The Swift SDK for Android

#106

Post by marcprux »

TheJoeMan wrote: post #9

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.

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.

Re: The Swift SDK for Android

#107

Post by w10-1 »

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

Re: The Swift SDK for Android

#108

Post by [deleted] »

palata wrote: post #99
bsimpson wrote: post #86

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…

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

[deleted]

Re: The Swift SDK for Android

#109

Post by giobox »

makeitdouble wrote: post #90
twof wrote: post #73

Earlier quoted context omitted.

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.

The US still has a strong iOS market share, shipments just never go below 50% https://counterpointresearch.com/en/insights/us-smartphone-m...

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/

Re: The Swift SDK for Android

#110

Post by rumori »

ryeights wrote: post #71
turtlebro wrote: post #58

Earlier quoted context omitted.

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

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

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.
Post reply on HN