The Swift SDK for Android • Hacker News Board

Re: The Swift SDK for Android

#191

Post by WhereIsTheTruth » Sat, Oct 25, 2025, 7:18 AM UTC

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…

Nobody cares about native UI, not even Apple, the strength of a UI toolkit is to empower creative design while retaining consistency and intuitiveness across devices

Only the UX has to feel native, the pixels are yours

Re: The Swift SDK for Android

#192

Post by wiseowise » Sat, Oct 25, 2025, 7:38 AM UTC

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!

There’s no Chromium in RN, that’s the whole idea behind Native part. It ships optimized JS runtime called Hermes.

And Discord mobile app on iOS doesn’t even use RN, it’s a native application.

Re: The Swift SDK for Android

#193

Post by serial_dev » Sat, Oct 25, 2025, 7:52 AM UTC

mojuba wrote: post #180

ranie93 wrote: post #130

Earlier quoted context omitted.

guard let self = self else { return }

There's a shorter form of it: guard let self else { return } which annoyingly the AI's don't know about.

Not much better, to be honest.

Re: The Swift SDK for Android

#194

Post by wiseowise » Sat, Oct 25, 2025, 7:52 AM UTC

akmarinov wrote: post #179

saubeidl wrote: post #85

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

Pretty much everything starts iOS first, so why bother with KMP when this exists?

What’s stopping you from developing in KMP iOS first?

Re: The Swift SDK for Android

#195

Post by isodev » Sat, Oct 25, 2025, 7:55 AM UTC

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…

Indeed, "cross-platform UI" can only be as good as the average between all the platforms it supports and it usually ends up costing a lot more than using the native UI kits of each platform. Kotlin Multiplatform has been and continues to be the "happy path" for buildings apps in our studio - native UI + shared business layer. Also, in terms of API stability and mental load, Kotlin is a lot more productive than Swift... and it doesn't come with a yearly breaking cycle.

Re: The Swift SDK for Android

#196

Post by mikelward » Sat, Oct 25, 2025, 8:13 AM UTC

marcprux wrote: post #134

bsimpson wrote: post #126

Earlier quoted context omitted.

Appreciate the response! Respectfully, the demos on your page look like impostors on Android. For apps that wouldn't bother supporting Android in the first place, maybe this is an improvement. But for apps that want all customers to feel considered, that's not a direction I would recommend. Would still like to see a call out to this in the blog post above ("For UI, you can use Swift for business logic and use Android…

> the demos on your page look like impostors on Android On the Android side, Skip apps utilize Jetpack Compose directly, which is the officially recommended toolkit for creating Android apps these days ( https://developer.android.com/compose ). It isn't mimicking native UI like other x-platform tools, but is actually using the Google-recommended API.

The three buttons dialog (ContentView.swift Showcase) in particular looks like iOS rather than Android.

Re: The Swift SDK for Android

#197

Post by palata » Sat, Oct 25, 2025, 8:18 AM UTC

andrekandre wrote: post #129

palata wrote: post #99

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…

> What KMP (and I'm hoping Swift for Android) bring is the possibility to share a Kotlin (respectively Swift) library instead of sharing code with C/C++/Rust/Go. So that an Android/iOS team can keep using Android/Swift without having to introduce a third language for sharing logic. have gone down this route before, and tbh the biggest issue is dev ux (ios devs cant debug easily, model mismatches vs kotlin e.g kotlin…

Sure. I guess my point was that maybe your devs are more comfortable doing it in Kotlin than in C/C++/Rust.

And IMO not everything should be shared; it's worth sharing complex logic because the overhead of sharing beats the overhead of writing it twice. But in many situations it is not slower to write it twice. And I am an advocate of writing the UI on each platform to have a truly native experience for the users.

Re: The Swift SDK for Android

#198

Post by WA » Sat, Oct 25, 2025, 8:19 AM UTC

WhereIsTheTruth wrote: post #191

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…

Nobody cares about native UI, not even Apple, the strength of a UI toolkit is to empower creative design while retaining consistency and intuitiveness across devices Only the UX has to feel native, the pixels are yours

I wrote this in another thread: I'm confident that with Liquid Glass, even more companies aren't interested anymore in the Apple UI look and rather want their own UI language, because Liquid Glass is just that bad.

Re: The Swift SDK for Android

#199

Post by palata » Sat, Oct 25, 2025, 8:20 AM UTC

raspasov wrote: post #161

palata wrote: post #99

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…

React Native is pretty good at cross platform but yes, it must be tested right away on all platforms. Retrofitting an iOS-only React Native app to Android later is possible but can be of a pain, at least initially.

My experience as an Android user is that React Native apps don't feel "Android native". Maybe it's because I only notice the apps that have the poorer UI, I don't know.

Re: The Swift SDK for Android

#200

Post by pta2002 » Sat, Oct 25, 2025, 8:25 AM UTC

nicce wrote: post #189

mosura wrote: post #37

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.

> 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. Yet Apple has managed to create WatchOS. I don’t know what is the portion of Swift, however.

WatchOS is hardly embedded though. An Apple Watch is basically a small iPhone tied to your wrist in terms of architecture. That’s got a whole lot more in common with a full desktop computer than it does with a microcontrollers, where they often have rather weird architectures by desktop standards, and it’s quite rare to have MMUs and things like that. Also, there is no underlying OS, and no heap allocator (unless you provide one). That’s the kind of challenge that an embedded language runtime has to provide.