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

141–150 of 298 posts

Re: The Swift SDK for Android

#141

Post by timcobb »

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…

> Sharing UI in complex apps, in my experience, always ends up being a "write once - debug everywhere" nightmare

Amen!

Re: The Swift SDK for Android

#142

Post by crossroadsguy »

Sharing the “business logic” pretty wasn’t the problem — at least not of late. Writing UI on both was the pain, or the existing shared UI solutions. As a mobile dev I’d rather appreciate a common UI framework that doesn’t suck like react native.

Re: The Swift SDK for Android

#144

Post by ktoso »

flutas wrote: post #136
orliesaurus wrote: post #60

Interesting to see excitement around this release... BUT beyond cross‑platform hype there's a practical question... what developer tooling will look like... Are we getting first‑class debugging, package management, continuous integration for Android targets... ALSO adoption often comes down to licensing and governance... open SDKs thrive when the steering group is transparent and responsive... And it's worth remember…

IMO the implementation (for me at least) is ... terrible. Why reach for this when it's, at the end of the day, just the exact same as NDK work in C++ but in Swift. You have to use Kotlin / Other UI setup anyways (or their fully-native example, use OpenGL to draw the screen[0]), and on top of that statically assign the package path and class name in the Swift code, while making it an external func in the kotlin code[1…

It's worth pointing out that the example you linked with the cdecl is not showcasing the swift-java interoperability but using "raw" JNI patterns as if you would do it with C.

This example does showcase the interoperability: https://github.com/swiftlang/swift-android-examples/tree/mai... you don't have to annotate or write any "weird" cdecls or really touch JNI details yourself when using the swift-java interop support https://github.com/swiftlang/swift-java

Re: The Swift SDK for Android

#145

Post by weird-eye-issue »

hbbio wrote: post #140
weird-eye-issue wrote: post #123

Earlier quoted context omitted.

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

Has been the true core vision of the web if not mobile. If I remember correctly, that is how the original Basecamp was implemented, or Craigslist (still is?)... or this very website

Also I just realized the irony of them using GraphQL. They've really come full circle

Re: The Swift SDK for Android

#146

Post by ChrisMarshallNY »

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…

Looks like this is package compatibility, not a cross-platform UI system (although maybe that’s in the works. SwiftUI could probably port well).

Re: The Swift SDK for Android

#147

Post by tcoff91 »

giancarlostoro wrote: post #120
trevor-e wrote: post #78

Earlier quoted context omitted.

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

This is not actually true. It’s allowed as long as you don’t make significant alterations to the app as a way to get around the App Store review process. It’s confusing because there are 2 areas of the policy that seem contradictory on this matter, but it is allowed.

Re: The Swift SDK for Android

#148

Post by aatd86 »

kridsdale3 wrote: post #113
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…

Is their code available somewhere.

I need this for UIKit so that I can make my UIs in Go. I have the gist of what it would require but have yet to implement everything. (if swiftUI allowed more control over the UI tree, I would even target it but full declarative à la react with vdom diffing is no bueno for fine grained rendering control)

Re: The Swift SDK for Android

#149

Post by tcoff91 »

crossroadsguy wrote: post #142

Sharing the “business logic” pretty wasn’t the problem — at least not of late. Writing UI on both was the pain, or the existing shared UI solutions. As a mobile dev I’d rather appreciate a common UI framework that doesn’t suck like react native.

When was the last time you tried react native? It’s pretty good now that they finally completed the transition to the New Architecture. With Expo it’s pretty nice these days.

Re: The Swift SDK for Android

#150

Post by wahnfrieden »

kridsdale3 wrote: post #113
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…

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 of date. FYI parts of SwiftUI are "native" now. Notably the new Liquid Glass UI was written in "native" SwiftUI. UIKit and AppKit actually wrap SwiftUI views to render Liquid Glass now. Although SwiftUI-exclusive APIs have always existed, this was a notable step in a new direction and suggests the future of UIKit and AppKit is a unified "native" SwiftUI implementation.

They've also been ripping out UIKit/AppKit implementations of SwiftUI views... IIRC List is no longer a UITableView for instance (could be confusing with another component though).

Post reply on HN