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

111–120 of 298 posts

Re: The Swift SDK for Android

#111

Post by timsneath »

wffurr wrote: post #105
timsneath wrote: post #93

Earlier quoted context omitted.

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.

This doesn't transpile. It cross-compiles to Android architectures using the NDK. You can see a very simple "hello world" example at the bottom of this article:

https://www.swift.org/documentation/articles/swift-sdk-for-a...

Re: The Swift SDK for Android

#112

Post by trevor-e »

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

Earlier quoted context omitted.

Xamarin with .NET and MvvmCross falls into the same bucket as RN and Flutter IMO, unless something changed since the last time I looked.

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.

Re: The Swift SDK for Android

#113

Post by kridsdale3 »

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 Browser Company did an amazing job of porting SwiftUI to Windows, where the element primitives in the language map to native Windows UI C++ classes under the hood.

Perhaps the future of Swift for Android is similar, where SwiftUI will map to Jetpack elements. That would be cool.

Remember on iOS and MacOS, SwiftUI is not "native". It's a description language that system frameworks interpret and create NSViews and UIViews and CGLayers etc out of.

Re: The Swift SDK for Android

#114

Post by virtue3 »

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…

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 typescript (sorry y'all) on the GQL/apollo server and all the clients can ingest it easy.

Send down viewmodels to the clients not data models. etc etc.

This helped DRAMATICALLY with complexity in the clients.

Re: The Swift SDK for Android

#115

Post by bitpush »

bpavuk wrote: post #83
bitpush wrote: post #68

Earlier quoted context omitted.

I have no love for RN and Flutter, but what makes you think Swift on Android will be even remotely close to what Flutter and RN has? If anything, Apple will launch this and quickly forget this exist.

although Apple has tremendous influence over Swift, Swift for Android is a grassroots effort, as said in the link. if community needs it, community will maintain it, and Apple won't get in the way. why would they?

I guess that goes to the larger point then. OP was saying Swift for Android will finally solve all the issues of Flutter & RN, presumably meaning Apple with its $$ and might will do it.

If it is a grassroots project, it has even bleaker outlook then? I wish them success however.

Re: The Swift SDK for Android

#116

Post by cosmic_cheese »

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 probably varies from area to area, but in the US iOS first is common.

Having developed both, it makes sense.

iOS is by far the more profitable of the two platforms and its support burden is substantially lower — far fewer versions to think about with the bulk of users running 0-2 versions behind, single form factor (only size variants), zero manufacturer skin quirks/bugs to deal with. It’s a more fertile environment for getting up and running and getting the core product shaken out.

Android can come later when you’re out of rapid iteration and have the bandwidth to deal with the idiosyncrasies of the Android world.

Re: The Swift SDK for Android

#117

Post by marcprux »

chrsstrm wrote: post #2

I'm just getting started in iOS development as a hobby, but what does this mean? Can I now build my app in Xcode with an Android target and use that binary in the Play Store? It surely can't be that easy now is it?

An example of an Android app that is built using the Swift SDK for Android and is available in the Google Play Store is Skip Showcase: https://github.com/skiptools/skipapp-showcase/

(disclaimer: I work on the Skip.tools product)

Re: The Swift SDK for Android

#119

Post by marcprux »

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 the Play Store that demonstrates this is the Skip Showcase app: https://skip.tools/docs/samples/skipapp-showcase-fuse/

[Disclaimer: I work on the Skip product, and I am also a founding member of the Swift Android Workgroup and am the release manager for the Swift SDK for Android]

Re: The Swift SDK for Android

#120

Post by giancarlostoro »

trevor-e wrote: post #78
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,…

OTA updates are definitely nice to have and I'm surprised there's not a way to do so with native iOS since RN and Flutter already support it. Technically it is possible with dynamic frameworks. In practice though it's somewhat easy to workaround the lack of OTA with dynamic server configuration for clients.

It used to be allowed, then Apple banned it outright. You're technically not supposed to do it even with RN...
Post reply on HN