[trevor-e]

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 traction. With a little foresight of keeping shared code in a Swift Package, it seems like that's getting more and more possible which is great to see.

[a3w]

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

Is it? There seem to be a hundred million Java developers out there, that can do an Android app, plus even release that in-house or with minimal registration fees if single dev/sideproject.

For Objective-C/Swift, there seem to be ten percent as many devs.

I always only tinkered with Android apps in my spare time, but never managed to deploy anything to iOS.

Also, outside the US, iPhones are a 10 % niche product in private hands, but companies might use a lot of iPads or provide iPhones as work phones, so perhaps companies do think of both platforms as second class citizens (behind windows/browser as two other "OS-like" primary platforms)

[cosmic_cheese]

It probably varies from area to area, but in the US iOS first is common.

Having developed both, it makes sense.

iOS is by far the more profitable of the two platforms and its support burden is substantially lower — far fewer versions to think about with the bulk of users running 0-2 versions behind, single form factor (only size variants), zero manufacturer skin quirks/bugs to deal with. It’s a more fertile environment for getting up and running and getting the core product shaken out.

Android can come later when you’re out of rapid iteration and have the bandwidth to deal with the idiosyncrasies of the Android world.

[deaux]

In large parts of the world, the iOS and Android revenue share are roughly 50/50 with the higher $/user of iOS and the higher market share of Android cancelling each other out. And that means everyone makes hybrid apps unless they're in a niche where that's impossible, which is rare. Only if they become very successful or raise massive funding (for that country), then they might switch to two native apps.

[Jcampuzano2]

It's probably a US centric take you're replying to.

Having worked at multiple companies making apps in the US and the company I work at right now which is a company almost everyone knows the name of and the vast majority of our revenue comes from our native apps - practically every feature we build is iOS and web first and only if it performs well do we even consider adding to android most of the time. And it's primarily because product/execs know iOS users are more likely to pay for things.

It's sad as an android user myself, but android is very much a second class citizen in the US

[twof]

It's not really about the number of developers. If you're running a company in the US at least, most of your revenue is going to come from iOS users.

[makeitdouble]

The US still has a strong iOS market share, shipments just never go below 50%

https://counterpointresearch.com/en/insights/us-smartphone-m...

[giobox]

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-statistics/

[makeitdouble]

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.

[xethos]

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

[disiplus]

for us its pixel phones, you can choose iphone if you want but most of us want pixel. so for me its macbook + pixel. I think the iphone only is unique to US.

[palata]

> KMP exists but I think for most developers wanting to build an app it's more common to build for iOS first

This sounds US-centric to me.

The advantage of KMP is that it is pretty mature and it is used in big apps like Google workspace (Google Docs etc), so it feels like it may be in a really good position.

I used to be exited about Flutter when it started, but the speed of major releases (by the time I had rewritten my app for Flutter 2, Flutter 3 was out, or something like that) and it did not seem to get so much traction (Dart is fun, but well).

KMP builds on top of Kotlin, with big investment from JetBrains and Google. That looks extremely promising to me.

[frankus]

I think business-logic-in-JavaScript is something cross-platform folks shouldn't snooze on either, with the usual caveats of not doing anything performance-critical or where an asynchronous API would be awkward (to be clear, using JavaScriptCore or QuickJS or the like, not just running in a WebView)

But it'll run on iOS (v7.0+), Android (I think more recently) and of course web and server-side. And most importantly, it's hot-reloadable, as long as you don't run afoul of platform gatekeepers (i.e. use it for bug fixes and minor behavior changes, not like whole new features).

One of the frustrating things about mobile development is that once you ship a version, that version will almost certainly be running on at least someone's device indefinitely without being upgraded. My day job is even on step further back in that we have to get our customers to update the version of our SDK that they're integrating (which for many of them means contracting out because they don't have an in-house mobile dev team), before they ship an app update, which then needs to be installed by end-users, whose device might not even support the new deployment target…

(I've been trying to sell this to the bosses for the last 9 years or so, and never gotten the go-ahead, so there could be aspects I'm missing, but it always seemed like a huge missed opportunity).

[trevor-e]

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.

[giancarlostoro]

It used to be allowed, then Apple banned it outright. You're technically not supposed to do it even with RN...

[tcoff91]

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.

[wahnfrieden]

This is false.

[bpavuk]

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!

[iknowstuff]

Your profile is full of incorrect assertions about software. What do you do for a living

[wiseowise]

There’s no Chromium in RN, that’s the whole idea behind Native part. It ships optimized JS runtime called Hermes.

And Discord mobile app on iOS doesn’t even use RN, it’s a native application.

[saagarjha]

No, it’s React Native.

[wiseowise]

Huh, you are right. I was thinking about Android. This one was fully native until recently.

[NSUserDefaults]

For JS driving the business logic you do not need a browser to run it. On iOS there is JavaScriptCore and there are other Javascript runtimes out there that are quite small.

That said, it is true that Javascript may not be the right choice for every app and some developers may be used to better language features and performance than that.

[cyberax]

React.Native doesn't use Chromium.

[liqilin1567]

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

[hokumguru]

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

[notpushkin]

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

[adityapurwa]

React Native asks the native layer to render the UI natively.

[crowbahr]

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: the iOS repository is a patchwork of horrible patterns that shatters when you update to the latest iOS target.

At my current employer it takes 4 iOS devs longer to implement things than it takes 1.5 Android devs (0.5 because the other .5 is spent being Team Lead and architecting, planning, endless meetings etc).

When I talked with the KMP team at Google they were mentioning that their most enthusiastic user base at Google was iOS developers, begging to be saved from their tooling nightmares.

I'm sure some defensive devs will show up here but I've been at 5 different places over my decade at work and every single one of them has had endless struggles hiring iOS devs, maintaining iOS projects etc.

[myHNAccount123]

Exact opposite experience :)

[crowbahr]

You like xcode and think iOS state of the art is ahead of android?

[icar]

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

[bbkane]

https://proton.me/blog/authenticator-rust - I think this is what you're referring to? Looks really nice

[dvtkrlbs]

afaik 1password also does something similar

[ivm]

This is already possible with .NET and MvvmCross: a shared core library plus native UI projects for each platform. UIKit feels great in C# and it’s all been working quite well since Xamarin times, with access to the Nuget ecosystem.

[trevor-e]

Xamarin with .NET and MvvmCross falls into the same bucket as RN and Flutter IMO, unless something changed since the last time I looked.

[ivm]

Not at all, but it’s important not to mix up Xamarin (nowadays just .NET) which is basically native bindings for C# and Xamarin.Forms UI framework (nowadays MAUI) which is write-once approach like RN.

The former is exactly what you are talking about: building native UIs twice and then sharing the common logic.

[trevor-e]

Very neat, thanks for explaining. The only drawback I've seen in the past with apps using .NET is the binaries end up pretty huge due to the runtime. I'm assuming that's still the case here? I wouldn't be surprised if this is also an issue with Swift for Android but I haven't looked yet.

[ivm]

It's not too bad, about 12-15 MB for the runtime on iOS. I'd say the main downside compared to other cross-platform frameworks is the lack of official hot reload (it's possible but really clunky) for building UIs.

Otherwise, I’ve been working with it since 2018, my app now has around 500k installs on both stores, and I’ve encountered very few issues related to the stack itself. Mobile .NET has been steadily improving, and LLMs have made the two-native-UI approach much easier: after building an iOS UI, I ask Claude to repeat it on Android for the same view model and get about 80% done instantly.

[pzo]

react native do uses native UI per platform in contrast to flutter or compose multiplatform. React Native improved a lot - it's not the same technology that has been 5 years ago. Especially this year there were plenty of improvements also regarding speed but in react native and community plugins (new architecture rolled in, react compiler, hermes v1, nitro modules, flash list v2, legend list, react native skia, react native webgpu, expo use dom) Tooling in JS/TS ecosystem also improved a lot.

[trevor-e]

Yes it uses native UI by wrapping the underlying frameworks, but that still means there is a layer in between that has to be updated with fixes and new features. Every RN project I've tried in the past turned into a dependency mess since you find edge cases that are not supported by the framework.

It's definitely gotten better like you said but I just prefer to work with the native platform code even if it's a bit of extra effort.