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

121–130 of 298 posts

Re: The Swift SDK for Android

#121

Post by ivm »

trevor-e wrote: post #112
ivm wrote: post #80

Earlier quoted context omitted.

Not at all, but it’s important not to mix up Xamarin (nowadays just .NET) which is basically native bindings for C# and Xamarin.Forms UI framework (nowadays MAUI) which is write-once approach like RN. The former is exactly what you are talking about: building native UIs twice and then sharing the common logic.

Very neat, thanks for explaining. The only drawback I've seen in the past with apps using .NET is the binaries end up pretty huge due to the runtime. I'm assuming that's still the case here? I wouldn't be surprised if this is also an issue with Swift for Android but I haven't looked yet.

It's not too bad, about 12-15 MB for the runtime on iOS. I'd say the main downside compared to other cross-platform frameworks is the lack of official hot reload (it's possible but really clunky) for building UIs.

Otherwise, I’ve been working with it since 2018, my app now has around 500k installs on both stores, and I’ve encountered very few issues related to the stack itself. Mobile .NET has been steadily improving, and LLMs have made the two-native-UI approach much easier: after building an iOS UI, I ask Claude to repeat it on Android for the same view model and get about 80% done instantly.

Re: The Swift SDK for Android

#122

Post by ryeights »

rumori wrote: post #110
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

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.

I don’t mean to say it’s a showstopper, but it is certainly noticeable to anyone accustomed to using iOS devices. I suspect the situation on Android is better where Google has access to the native platform code.

Flutter has a secondary problem which is (IMO) a dearth of well-made libraries and showcase apps. Most everything feels half-baked.

The Kagi News app, which I have just installed, doesn’t seem to fall into this category. But like most Flutter apps the fully Material design makes it feel very out of place on iOS. Flutter typography is still broken, with characters tracked out way too far. And the scrolling and touch interaction feels, well, Flutter-y. It’s inherent to the platform

Re: The Swift SDK for Android

#123

Post by weird-eye-issue »

virtue3 wrote: post #114
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…

Having worked a long time with client teams as a lead - this is always the biggest pain in the ass. At one of my last phase startups I started shifting all our business logic stuff into our graphql server and treated it like it was part of the client teams. (we had ios/android/web as independent full apps with a very small team of devs). Business logic is the real killer. Have one person suck it up and do it in types…

So your takeaway is that business logic should be done on the server. Hasn't it always been like this?

Re: The Swift SDK for Android

#125

Post by Razengan »

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?

For that, there needs to be a single definitive agreement on UI somewhere.

Like what does it mean to be a "list"? How does it behave with mouse, touch, keyboard?

How many different kinds of lists? (for example, a list for "favorites" behaves slightly differently than a list for "bookmarks", vs lists of "products/offers" and so on)

I bet any example you can give I or others can nitpick some flaws in that.

Hell, there are differences of opinion right off the bat: Should content move up when I scroll/swipe down or move down when I scroll up?

Re: The Swift SDK for Android

#126

Post by bsimpson »

marcprux wrote: post #119
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 Swift SDK for Android doesn't specify or mandate any user-interface technology, but leaves it open for other projects to build upon. For example, Skip.tools re-implements SwiftUI for Android by bridging it to Jetpack Compose, so you can use the same codebase for both your business logic as well as UI layer. We write about it at https://skip.tools/blog/fully-native-android-swift-apps/ and an example of an app on t…

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's SDK to create the interface. Or you can use a library like our partner skip.tools to write SwiftUI apps directly.")

Re: The Swift SDK for Android

#127

Post by Jcampuzano2 »

a3w wrote: post #70
trevor-e wrote: post #47

Very excited to see this as an official project! I've been toying around with multiplatform frameworks like RN and Flutter for a side project of mine but they never feel right. I'd rather use the native UI per platform and have a nice way to share business logic. KMP exists but I think for most developers wanting to build an app it's more common to build for iOS first, and then port to Android later if the app gets t…

> but I think for most developers wanting to build an app it's more common to build for iOS first, and then port to Android later if the app gets traction. Is it? There seem to be a hundred million Java developers out there, that can do an Android app, plus even release that in-house or with minimal registration fees if single dev/sideproject. For Objective-C/Swift, there seem to be ten percent as many devs. I always…

It's probably a US centric take you're replying to.

Having worked at multiple companies making apps in the US and the company I work at right now which is a company almost everyone knows the name of and the vast majority of our revenue comes from our native apps - practically every feature we build is iOS and web first and only if it performs well do we even consider adding to android most of the time. And it's primarily because product/execs know iOS users are more likely to pay for things.

It's sad as an android user myself, but android is very much a second class citizen in the US

Re: The Swift SDK for Android

#128

Post by rustystump »

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…

Very unpopular opinion but i like apps that ashew looking “native” for an original ux. Maybe it is my love for gamedev and all the crazy designs they come up with but i personally loath boring uninspired native apps esp when the native ux is terrible.

Apple wants everyone to conform because historically their ux is on point but the last update really reinforces my view.

Re: The Swift SDK for Android

#129

Post by andrekandre »

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…

  > 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 exceptions cant be caught from swift) and in the end even kotlin multi platform isn't the same as kotlin for android, so in a sense you are still introducing a 3rd language after a fashion...

if you can fix the dev issues and have a dedicated team behind the shared logic it could work out, but still then again if you also have a website your re-implementing that logic on the front-end twice...

Re: The Swift SDK for Android

#130

Post by ranie93 »

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.

guard let self = self else { return }
Post reply on HN