6 ms·

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

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.

ivm 1y ago
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 1y ago
  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 1y ago
    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 1y ago
      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 1y ago
        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.
frankus 1y ago
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 1y ago
  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 1y ago
    It used to be allowed, then Apple banned it outright. You're technically not supposed to do it even with RN...
    - tcoff91 1y ago
      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.
a3w 1y ago
> 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)
- twof 1y ago
  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 1y ago
    The US still has a strong iOS market share, shipments just never go below 50% https://counterpointresearch.com/en/insights/us-smartphone-market-share https://counterpointresearch.com/en/insights/us-smartphone-m...
    - giobox 1y ago
      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/ https://sqmagazine.co.uk/iphone-vs-android-statistics/
      - makeitdouble 1y ago
pzo 1y ago
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 1y ago
  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.
palata 1y ago
> 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.
- deleted 1y ago
  [deleted]
icar 1y ago
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 1y ago
  https://proton.me/blog/authenticator-rust https://proton.me/blog/authenticator-rust - I think this is what you're referring to? Looks really nice
- dvtkrlbs 1y ago
  afaik 1password also does something similar
crowbahr 1y ago
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 1y ago
  Exact opposite experience :)
  - inquirerGeneral 1y ago
    [dead]
  - crowbahr 11mo ago
    You like xcode and think iOS state of the art is ahead of android?

ivm 1y ago

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 1y ago
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 1y ago
  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 1y ago
    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 1y ago
      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.

frankus 1y ago

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 1y ago
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 1y ago
  It used to be allowed, then Apple banned it outright. You're technically not supposed to do it even with RN...
  - tcoff91 1y ago
    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.

a3w 1y ago

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

twof 1y ago
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 1y ago
  The US still has a strong iOS market share, shipments just never go below 50% https://counterpointresearch.com/en/insights/us-smartphone-market-share https://counterpointresearch.com/en/insights/us-smartphone-m...
  - giobox 1y ago
    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/ https://sqmagazine.co.uk/iphone-vs-android-statistics/
    - makeitdouble 1y ago

pzo 1y ago

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 1y ago
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.

palata 1y ago

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

deleted 1y ago
[deleted]

icar 1y ago

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 1y ago
https://proton.me/blog/authenticator-rust https://proton.me/blog/authenticator-rust - I think this is what you're referring to? Looks really nice
dvtkrlbs 1y ago
afaik 1password also does something similar

crowbahr 1y ago

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 1y ago
Exact opposite experience :)
- inquirerGeneral 1y ago
  [dead]
- crowbahr 11mo ago
  You like xcode and think iOS state of the art is ahead of android?