Live data from Hacker News

The Swift SDK for Android

swift.org

251–260 of 298 posts

Re: The Swift SDK for Android

#251

Earlier quoted context omitted.

> Please kill RN and Flutter already. Just No. Nobody will kill >30% of apps on the iOS store. Flutter is simply a massively superior development experience overall compared to the horrifying disaster that is SwiftUI. SwiftUI is so utterly pathetic that more than a third of all apps are now being written in Flutter. "The compiler is unable to type-check this expression in reasonable time" -> one of the most atrocious…

Having worked with Flutter, I also have the same opinion, I don't think you could pay me enough to use xcode and care about all these half documented apple frameworks. The app build and upload process is painful enough as it is, I don't want more of it.

Xcode's upload process is painful? I think it's pretty nice. At least Android Studio doesn't have the feature, so you gotta upload the APK/AAB manually via web browser.

Disclaimer: I work on RN nowadays.

Re: The Swift SDK for Android

#252
post #226

I'd love to see a future, where I can use Swift as a bridge between Kotlin and c++ and then gradually port more and more c++ to Swift. Does anyone know/understand what's the story for using Swift's interop with c++ on Android? Should this work right now? How?

Future - Is it possible to run swift built OS to run on Android devices 100%? Is that a threat to Android as an OS?

Maybe, if someone builds this first. Same could be said about Apple running iOS (as it stands) on Android hardware. It can be done, but there are no incentives for doing this.

Re: The Swift SDK for Android

#253
post #99

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…

This isn't disagreeing

Re: The Swift SDK for Android

#254
post #99

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

Compared to the tried and true method of "write many times - debug everywhere".

there is not a world in which you won't have issues on $PLATFORM because $PLATFORM themselves have their own individual bugs / issues

Re: The Swift SDK for Android

#255

Earlier quoted context omitted.

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.

I agree it makes me very nervous. Though as I understand it, it's mostly open source (edit: not the build tool tho).

Their transpiler solution at least results in maintainable Kotlin code that one could begin working in directly without needing Skip. But the transpiler way is more limiting than the native Swift SDK on Android.

I'm considering using it just as a way to bootstrap as my main focus has been iOS/Mac. If I can use it to generate enough of a new revenue stream on Android, I could then afford to hire an Android developer to take care of doing it without Skip, too.

Re: The Swift SDK for Android

#256
post #251

Earlier quoted context omitted.

Having worked with Flutter, I also have the same opinion, I don't think you could pay me enough to use xcode and care about all these half documented apple frameworks. The app build and upload process is painful enough as it is, I don't want more of it.

Xcode's upload process is painful? I think it's pretty nice. At least Android Studio doesn't have the feature, so you gotta upload the APK/AAB manually via web browser. Disclaimer: I work on RN nowadays.

It's so bad that Apple has created a in-house third party tool to bypass it.

Re: The Swift SDK for Android

#257

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…

The issue with that approach is that the state of the art for iOS dev is about 15 years behind the state of the art for Android dev. The amount of simple things that are incredibly painful for iOS devs to do is astounding. Some of that is because xcode is horrific, some of it is that the ecosystem is starved by disinvestment from Apple. I've talked with colleagues in several companies and the story is always the same…

Exact opposite experience :)

Re: The Swift SDK for Android

#258
post #19

"You got Kotlin in my iOS." "You got Swift in my Android."

Kotlin on iOS is statically compiled and interops with Swift/ObjC natively. Don't think KMP on iOS is even running a VM like Flutter has to with Dart? https://kotlinlang.org/docs/native-overview.html

I don’t think anything runs in a vm on iOS since they don’t let you JIT compile code. Unless they’re doing pure interpretation, but I can’t imagine that being good for performance.

Re: The Swift SDK for Android

#259

Earlier quoted context omitted.

I've not had much trouble with Xcode in the past 15+ years I've been using it. Its biggest warts involve Interface Builder, which is easily avoidable by using code for UI instead of XIBs or storyboards. With Android Studio, I'd say the ways that it being an IntelliJ IDE puts it above Xcode are cancelled out by other aspects of Android development, which can be abysmal. Swift Package Manager and Clang/llvm code stripp…

Gradle is the single most confusing build system tool of all time. It’s so bad. I agree that other than JetBrains everything else about it sucks ass.

I've never seen a build system that makes sense, aside from make which is more for individual binaries. If the higher layer build system were just some Python scripts I can look at and understand, that'd be neat.

Re: The Swift SDK for Android

#260

Earlier quoted context omitted.

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

Until Static Hermes gets here it seems like a big performance loss to move to React Native.
Post reply on HN