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

201–210 of 298 posts

Re: The Swift SDK for Android

#201

Post by Culonavirus »

joanniso wrote: post #18
thenaturalist wrote: post #12

Earlier quoted context omitted.

What do you mean? This doc you linked is from August. The blog post from today includes, in fact at the very top an XCode Swift project emulating a Pixel 9. The docs include a detailed Getting Started for Android and they even have an Android examples repo. Hence the SDK. By all means, it very much is possible to build Android Swift apps in XCode. https://www.swift.org/documentation/articles/swift-sdk-for-a...

The post doesn't display Xcode but Android Studio. While with Skip you can build & run through Xcode, that's not something we support right now. You can build the Swift part in Xcode, VSCode or your favorite editor. But the Android builds don't work with Xcode today.

Isn't it kinda a bad sign that people on HN have to argue in comments about what your library/framework/sdk even does?

Re: The Swift SDK for Android

#203

Post by forgotusername6 »

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…

What if you want your app to work offline?

Re: The Swift SDK for Android

#204

Post by OJFord »

realusername wrote: post #188
rustystump wrote: post #128

Earlier quoted context omitted.

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.

The debate has been settled anyways, none of the top apps (Facebook, Whatsapp, Youtube, Tiktok..) uses the native design, users simply do not care.

For the big ones the consistent familiar design language of the app becomes more important, or at least they can argue/get away with that, for the random crap companion app to a £5 drop-shipped FYGUIO-'brand' gizmo, it's much nicer and better-working app if it just follows the platform.

Re: The Swift SDK for Android

#205

Post by hulitu »

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?

They don't give a fsck. Compare Windows, Adobe, Apple, Google products from 10 years ago with the present ones.

Re: The Swift SDK for Android

#206

Post by fragmede »

forgotusername6 wrote: post #203
virtue3 wrote: post #114

Earlier quoted context omitted.

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…

What if you want your app to work offline?

And not just off-line, but as we learned last week, if us–east-1 is down you have spotty connectivity, not hard down, and your device needs to not cook your users; literally in the case of Sleep8.

Re: The Swift SDK for Android

#207

Post by fragmede »

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…

> if you also have a website your re-implementing that logic on the front-end twice...

Which argues for react-native, warts and all.

Re: The Swift SDK for Android

#208

Post by hamburglar »

mkhalil wrote: post #168
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…

Huh? Did you read the link? Did you notice the ONE screenshot clearly shows the app has a material-ui look. I'm going to say this because I think you might not know this, but also because I think many others might not have thought about this: Almost always, a programming language is UI agnostic. Swift SDK for Android means: You can now write Android Apps in Swift. This doesn't magically include Apple's components / S…

> Almost always … a new "Window" means whatever a the OS thinks is a Window. A Button is what is defined (or exposed/binded to) as a Button in Android.

But not always, and when it’s not true, it sticks out like a sore thumb. It’s convenient for developers, but produces apps that have this uncanny valley “this isn’t quite right” quality to them. Adobe used to do this when I worked there 20 years ago (honestly don’t look at modern Adobe software if I can help it so I don’t know if they still do) with an internal component called Adobe Dialog Manager that was built expressly so developers didn’t need to worry about native widgets. The result was this “adobeness” to all the ui elments on both platforms (at this point we are talking windows vs macOS). There was no os-level button. There was an ADMButton on both platforms and it was hand-rolled behavior for rollovers and drawing styles and general interaction rules and it was this pleasantly uniform experience that sucked equally everywhere.

Re: The Swift SDK for Android

#209

Post by dvtkrlbs »

wahnfrieden wrote: post #150
kridsdale3 wrote: post #113

Earlier quoted context omitted.

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…

It exists already. SwiftUI to Jetpack Compose: https://skip.tools And a less mature but very interesting project with a SwiftUI-like API for UI across macOS/Linux/Windows plus some emerging support for Android and even a TUI target contributed by Miguel de Icaza: https://swiftcrossui.dev > It's a description language that system frameworks interpret and create NSViews and UIViews and CGLayers etc out of. This is out…

I think using a closed source solution (except the platform native solution) for such a core part of an application is a big no.

Re: The Swift SDK for Android

#210

Post by dvtkrlbs »

icar wrote: post #88
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…

At Proton they use Rust for shared logic (their claim is more than 80% of the codebase iirc), and platform specifics for the rest.

afaik 1password also does something similar
Post reply on HN