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

151–160 of 298 posts

Re: The Swift SDK for Android

#151

Post by tcoff91 »

morshu9001 wrote: post #132
VWWHFSfQ wrote: post #10

I think people will get excited about this and then quickly realize how painful it is to code in a foreign environment from the platform. How miserable it would be trying to write Java or kotlin targeting iOS apps. I think this will be the same. Just use the native tools and languages for the platform. Swift/Objc/xcode for iOS. Java/Kotlin/Android Studio for Android. You will be so much happier.

idk about Android, but native iPhone dev is pure torture. Hence React Native.

Android is way worse. iOS has way better APIs.

Android studio is way better than XCode though

Re: The Swift SDK for Android

#152

Post by wahnfrieden »

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

Re: The Swift SDK for Android

#153

Post by airspeedswift »

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…

> e.g kotlin exceptions cant be caught from swift

FWIW the approach that swift-java takes in managing interop with Java (and potentially Kotlin) function calls means it is perfectly possible to to catch exceptions thrown by the JVM using wrappers that catch and rethrow them as Swift errors. So there would be a distinction here with bringing Swift calling into JVM-based code running on Android.

Re: The Swift SDK for Android

#154

Post by beautron »

rustystump wrote: post #128
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.

I share your unpopular opinion.

While I understand that having identical UI elements across apps aids in discoverability, I just love it so much when an app has its own bespoke interface that was clearly made with love.

Like you, it might be my love of games that has given me this preference. Would StarCraft II have a better UX if its menus used the standard Windows widgets where applicable? I think certainly not. And I think the same can be true for many non-game apps.

Re: The Swift SDK for Android

#155

Post by cosmic_cheese »

tcoff91 wrote: post #151
morshu9001 wrote: post #132

Earlier quoted context omitted.

idk about Android, but native iPhone dev is pure torture. Hence React Native.

Android is way worse. iOS has way better APIs. Android studio is way better than XCode though

Agreed on SDKs/APIs. Compose improved the Android situation but it’s still a mess compared to UIKit.

I’m more mixed on Android Studio. It’s fine I guess, but I wish its UI were more deeply customizable. Many of its design decisions irritate me.

Re: The Swift SDK for Android

#156

Post by liqilin1567 »

cyberax wrote: post #95
bpavuk wrote: post #79

Earlier quoted context omitted.

yes. there is an aspect you are missing. no one in their right mind wants to bundle Chromium with every app install, and every Discord user hates mobile Discord app, which is, guess what? uses Chromium!

React.Native doesn't use Chromium.

Just curious - how does React.Native implement native UI if it doesn't use chromium

Re: The Swift SDK for Android

#157

Post by notpushkin »

liqilin1567 wrote: post #156
cyberax wrote: post #95

Earlier quoted context omitted.

React.Native doesn't use Chromium.

Just curious - how does React.Native implement native UI if it doesn't use chromium

By mapping some “low-level” components to platform primitives: https://reactnative.dev/docs/intro-react-native-components

Re: The Swift SDK for Android

#159

Post by al_be_back »

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…

i think traditional UI should be decoupled from the language - only providing CLI and web UI (w3c web standards).

Apple's ui is very nice, but you're stuck with a whole ecosystem for life. If you want to cross-platform, as you mentioned, well, all hell breaks loose: React & co, Flutter, web assembly.

a unified, all-batteries-included system is excellent for the manufacturer/provider - they can plan, invest, manage and rollout products at a desired rate. but for developers, third-party, and consumers is very costly, intense and risky.

fun-fact from Steve Jobs bio, he was interviewing a tech hopeful for a job, the guy showed him a prototype of what would become the Dock (aqua + animations), created using an Adobe product. Abobe etc had powerful, flexible platforms - unfortunately the market was driven by eager tech geeks - so it was easy to get curried away with fancy UIs. However, that was (20 years ago) an educational issue - not a tech issue.

Re: The Swift SDK for Android

#160

Post by hokumguru »

liqilin1567 wrote: post #156
cyberax wrote: post #95

Earlier quoted context omitted.

React.Native doesn't use Chromium.

Just curious - how does React.Native implement native UI if it doesn't use chromium

It’s more complex now since they shipped the new renderer, but essentially serializes the react UI tree to JSON and passes it to native which parses and renders native components
Post reply on HN