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

161–170 of 298 posts

Re: The Swift SDK for Android

#161

Post by raspasov »

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…

React Native is pretty good at cross platform but yes, it must be tested right away on all platforms.

Retrofitting an iOS-only React Native app to Android later is possible but can be of a pain, at least initially.

Re: The Swift SDK for Android

#162

Post by makeitdouble »

giobox wrote: post #109
makeitdouble wrote: post #90

Earlier quoted context omitted.

The US still has a strong iOS market share, shipments just never go below 50% https://counterpointresearch.com/en/insights/us-smartphone-m...

Even ignoring global OS marketshare, iOS app store customers just simply spend a lot more money per user on the App Store vs Google Play (Google's Android app store). You gotta go where the money is to some extent to get paid. Global revenues on the iOS app store have always been significantly larger than Google play, even with only ~30% of the global smartphone market. > https://sqmagazine.co.uk/iphone-vs-android-st…

Average amount of money spent means little in the context of parent's comment (revenue for a US company).

For instance, if you're Netflix, do iOS user bring you more revenue in the US ? What if you're Hertz ? What about Walmart or Costco ? The only factor will be how many of your users are on iOS vs android. It's a different story if you're a gaming company and target whales of course.

Re: The Swift SDK for Android

#163

Post by rkapsoro »

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…

They didn't port SwiftUI to windows; they wrote a Swift wrapper for WinUI. Impressive in its own right, but not SwiftUI.

Re: The Swift SDK for Android

#164

Post by seivan »

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…

[dead]

Re: The Swift SDK for Android

#165

Post by afro88 »

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…

Think of this more like Kotlin Multi Platform. Shared logic, not UI.

Re: The Swift SDK for Android

#166

Post by afro88 »

tomovo wrote: post #63
oblio wrote: post #59

Earlier quoted context omitted.

How solid is Kotlin on iOS?

If you mean Kotlin Multiplatform, it works pretty well. Not easy to debug, the GC is a bit weaker than the Android implementation and optimized builds can get crazy slow as the app grows. The interface uses auto-generated ObjC headers which are very verbose. Native Swift API is in beta. Overall still worth it for a commercial app, I think.

We use it in my team and it works well enough, but iOS is a bit second class citizen. Everything translates to Obj-C (NSObject at the root), so even something as simple as a data class becomes NSObjects with a cumbersome dev experience rather than a native swift enum.

We're looking forward to native swift export to go stable - it's currently experimental / beta.

Re: The Swift SDK for Android

#167

Post by xethos »

makeitdouble wrote: post #162
giobox wrote: post #109

Earlier quoted context omitted.

Even ignoring global OS marketshare, iOS app store customers just simply spend a lot more money per user on the App Store vs Google Play (Google's Android app store). You gotta go where the money is to some extent to get paid. Global revenues on the iOS app store have always been significantly larger than Google play, even with only ~30% of the global smartphone market. > https://sqmagazine.co.uk/iphone-vs-android-st…

Average amount of money spent means little in the context of parent's comment (revenue for a US company). For instance, if you're Netflix, do iOS user bring you more revenue in the US ? What if you're Hertz ? What about Walmart or Costco ? The only factor will be how many of your users are on iOS vs android. It's a different story if you're a gaming company and target whales of course.

Even if you're a social media company, where network effect is everything and getting into everyone's pocket matters, you can still go iOS first. Snap ran with that strategy at first, and it hardly killed the company.

Notably, that's a situation that actually matters for cross-compatibility. There's no web client for SnapChat. Hertz & Costco could point Android users to the web with few repurcussions, IMO

Re: The Swift SDK for Android

#168

Post by mkhalil »

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 / SwiftUI. When you write code for a platform, specifically an SDK for an OS, all you do is expose that platform to that language.

So, as long the SDK/bindings are there, 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.

Swift was sorta released for Windows: a new Window looks like a generic Win32 Window. The same one you would get if you used C, C++, Rust, etc..

All your examples are GREAT examples to explain how this works: - Flutter has "Cupertino" to allow people to use Flutter to make Apple apps, and not have to learn names/methods/interface of the native Apple UI. - React Native: A LOT of work was put in to make/bind Apple native objects to a React component. And the same for Android.

So again:

The Swift SDK for Android means you can write your Android apps in Swift. The same apps you might of wrote in Java or Kotlin, you can now use Swift. Meaning whatever it looked like in Java/Kotlin (using native api's), it would look like in Swift.

The SwiftUI, Apple's component library written/exposed to Swift, is something completely different.

Re: The Swift SDK for Android

#170

Post by noduerme »

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…

I guess I'm not clear on what you mean about putting business logic in the client. It can't only be on the client side. If you do so, then obviously you have to replicate it on the server to check that the client was sending the right results, no? Not to mention avoiding thread races and double inserts and whatever else may have gone stale on the server before you allow a client to validate something? Even if your code isn't public-facing, the server still needs to check everything. As a solo dev it seems insane to me to ever put business logic in the client, unless the client and server literally share the same typescript codebase for crosschecking ops, and even then the server needs the same code plus additional safeguards. It baffles me that anyone would write a platform from the ground up with primary business logic on the client side, if the server isn't written in the same language. Maybe some simple initial validations and checks to avoid bombarding the server, but the server has to be the central source of truth.
Post reply on HN