8 ms·

Tangent but I'm holding out from learning Swift until I see how the "Cross platform UI" wars shake out. We've got at least Kotlin, Dart, and JavaScript all batt

by zengid 3y ago

Tangent but I'm holding out from learning Swift until I see how the "Cross platform UI" wars shake out. We've got at least Kotlin, Dart, and JavaScript all battling it out (via Kotlin Multiplatform, Flutter, React Native) to be the king of UI languages across all platforms. I really like Swift though (from the little I've learned), so it's too bad it doesn't really have a cross platform UI story yet. (I could learn all four but I have kids, so it'll probably just be React Native for me.)

dlivingston 3y ago
I wouldn't hold your breath. It's very explicitly tied to Apple APIs and OS conventions; I doubt it will ever be cross-platform. If you want a cross-platform SwiftUI, QtQuick/QML is probably your best bet.
MobileVet 3y ago
I've worked in mobile since 2004 (not a typo, '04). The 'one platform to rule them all' has been just around the corner the entire time. As was already said, don't hold your breath. All of that said, if you are time constrained and really want to look at a single thing, I would go with Flutter. It impressed me when I cranked out a side project with it a year or so ago. Hopefully they continue to put effort towards it.
- zengid 3y ago
  [flagged]
- rapsey 3y ago
  From our experience Flutter apps are easy to start with but quite hard to maintain. The core system keeps changing so much you are constantly having to fix things and dealing with broken dependencies. Would never use it for anything important.
  - dan1234 3y ago
    I have the same problem with react native.
    - com2kid 3y ago
      I stopped supporting an open source React Native library because keeping the sample code working in Expo was taking too much of my time. This was years ago, maybe things have calmed down since then, but Expo always felt like hanging onto the horns of a bull, so long as you didn't fall off it was a fun ride!
      - timmeta 3y ago
        That's similar to my experience. Not just React but across JS in general. Was super hard to keep everything at pace when it was and is moving so fast. I slightly envy the old COBOL people sometimes...
  - CrimsonRain 3y ago
    Our experience is opposite. We started with GetX because we were new. Then moved to Riverpod/Go-Router as we gained experience. We have a set-up of four modules (shared lib; shared ui; app1 and app2) for two apps targeting web+ios+android; about 50k LoC @ 160 line length. Obviously there were a lot of friction when moving out of GetX, but upgrading things have always been easy. Usually at most one day worth of work (worst case). We don't upgrade as soon as a new flutter version is released. We give it a month at least and then upgrade. During upgrade, most of the problems usually come from 3P dependencies which interact with native such as package info plus. Also, we don't add dependencies unless we really need to. I think we are at ~30 total between all modules. On the other hand, our react projects are forever in dependency hell. Much larger project, yes but way too many dependencies and too many things break during upgrade.
    - bartvk 3y ago
      > Also, we don't add dependencies unless we really need to I think this is the trick. I've worked for a client whose coding standards basically forbade 3rd party clients. Turns out, it often is not needed at all. Do you need to include a library for a bar chart? No, a bar chart is often just a bunch of rectangles and labels. When you have stupid-simple project setups, you can have huge projects but they'll compile fast and upgrade quickly.
- lockhouse 3y ago
  The biggest problem with Flutter is Dart. Not the language specifically (it’s a nice enough flavor of C-family language), but the ecosystem. Even Swift is better in this regard. Flutter ported to TypeScript and sufficiently distanced from Google would actually be very compelling.
  - deleted 3y ago
    [deleted]
  - danielvaughn 3y ago
    Yep, I just commented the same thing before I read this. I'd say it's both Dart and Material Design. Dart doesn't seem bad (I've only glanced), it's just not very compelling or interesting.
- Vt71fcAqt7 3y ago
  I have to agree. Also I feel like those complaining about dart just have a bad taste in their mouth from dart 1.0. Dart has named parameters (so better than java) and null saftey. It's a pretty standard GCed OOP language. I also don't understand when people complain about the dart ecosystem. Seems fine to me.
- kitsunesoba 3y ago
  In my experience the issue with Flutter apps is though they aren't too bad on Android, they have an odd off-putting feel to them on iOS, more than is typically visible with competing cross-platform UI frameworks.
  - martinald 3y ago
    It's because unlike a lot of frameworks like React Native and Xamarin, it doesn't use native UI components under the hood (unless this has changed recently). It's a bit like using a canvas element in HTML and drawing your own toolkit, or old Java GUI apps.
  - __m 3y ago
    Especially when you need a date picker that doesn't scream Android
- mikhael28 3y ago
  Dart and Flutter are totally fine, and great in production. I really don't understand the hate.
  - M4v3R 3y ago
    Flutter is mostly fine. Until you need to implement text input in your app. And it turns out that autocomplete doesn’t work properly on iOS for non-English phones and you discover there’s a bug filled on their tracker for 5 years already and it’s still open [1]. Or you encounter another similar issue that is niche enough that the developers ignore it completely but is frustrating for your users and there’s nothing you can do. Don’t get me wrong, I would really love Flutter to be THE solution to the cross platform mobile app problem, but sadly it only gets you 95% there and if you really care about the last 5% you’re out of luck. [1] https://github.com/flutter/flutter/issues/12920 https://github.com/flutter/flutter/issues/12920
    - jononomo 3y ago
      Isn't getting 95% of the way there better than getting 0% of the way there? What are you going to do instead?
      - waboremo 3y ago
        Your equation isn't complete. You can't only care about getting 95% of the way there if the final 5% takes substantially more time than it normally would or worse halts development entirely.
      - M4v3R 3y ago
        It depends. For some use cases it’s definitely enough and if you’re on tight budget it might get you far enough. But eventually it might fall short and you’ll have to either fight the framework or switch to a native solution. I believe it’s good for knocking out an MVP if the mobile app is not critical to your business. I would not choose it otherwise though.
      - 1123581321 3y ago
- cush 3y ago
  I'm still holding out for Xamarin
- madeofpalk 3y ago
  More specifically, there are a bunch of efforts, but the Swift ecosystem doesn't seem too interested in this. Even Apple can barely get it with SwiftUI being a dumpster fire on macOS.
lobstrosity420 3y ago
Swift had no horse in that race whatsoever. It was made to interface with Cocoa and it excels at pretty much exclusively that.
Mertax 3y ago
Why not include C#/MAUI on this list to make it 5?
- sirwhinesalot 3y ago
  The moment it went with Catalyst on macOS and forgot Linux exists entirely it was dead on arrival. It's Xamarin Forms but worse. Well done Microsoft slow clap.
  - criddell 3y ago
    > it was dead on arrival I understand holding out hope for year of the Linux desktop, but ignoring Linux has never really hurt anybody, has it?
    - sirwhinesalot 3y ago
      Well, depends. If I'm evaluating cross-platform UI libraries, Linux support is a must have, even if the market might be small. Electron, Qt, Anything Java, Avalonia, wxWidgets, all the native webview wrappers, etc. All have Linux support.
      - dangerboysteve 3y ago
        Tauri looks great (Rust, webkit & js)
        sirwhinesalot 3y ago
        Oh yes, it is my preferred solution these days. Web crap is annoying as heck to work with though...
  - pjmlp 3y ago
    Ignoring Linux I can even understand, given the Year of Linux Desktop meme, but the Catalyst shortcut, what were they thinking. Not even the new VS4MAC UI uses MAUI, they used their own bindings.
afavour 3y ago
I’ve been dabbling in this space for a long time and I’ve become convinced there will be no good cross-platform mobile UI story. The UIs are too different for there to be a one size fits all solution. (as an aside I really like Swift too and have been enjoying noodling around with it as a server language. Probably rarely a wise choice given that it isn’t their focus but there is some attention given: https://swift.org/server/ https://swift.org/server/)
- danielvaughn 3y ago
  Yep. The only real option is that each platform agrees to abide by a common protocol for describing GUIs. I don't see that happening.
- criddell 3y ago
  > there will be no good cross-platform mobile UI story Generally (IMHO) there are no good cross-platform stories, mobile or otherwise with the notable exception of some game engines. The closest you can get is choosing the web browser as your platform and writing a web app (Electron). If you want to make the best app you can, use the native toolkit directly or via a framework for your UI.
  - koito17 3y ago
    For web apps on desktop you're not even restricted to Electron anymore. Thanks to Tauri, I feel a lot more comfortable shipping web apps beyond the browser (and React Native) since I don't have to pay the cost of bundling Chromium and Node.js. The Rust ecosystem is large enough that any backend-related task I would use Node.js for has an equivalent in Rust.
    - pjmlp 3y ago
      We were never restricted to Electron. There are browsers already installed, and MSHTML apps and XUL predate it for a decade.
- waboremo 3y ago
  Seconding this. The cross platform experience has been so abysmal for so long, that I question whether the benefits of "easier to support" are even real considering the generally worse experience, longstanding bugs that are harder to nail down, and the added time of having to switch mental models between cross platform and the native code you're going to have to eventually write. I'm at the point now where native apps are still back in heavy consideration, as it's far more straight forward to cascade launch your products on different platforms than it is to half-ass everywhere.
danielvaughn 3y ago
I really like Flutter's approach, I just wish they weren't so wedded to (a) Dart and (b) Material Design.
imachine1980_ 3y ago
for what understand (im not a mobile developer) the best of all of this is react native, works well most time the ux of expo is great and you can "port it to web" like twitter, all the people who use xamarin cry, all the comments who hear about kotlin multi platform is the ecosystem isn't there, and flutter is lots harder when thing make more complicate and google is unreliable they already kind kill flutter desktop or at leas the cut most funding, i feel react native is the only really companies beat real money in it, you have multiple app in your phone using it discord, instagram,pinterest, microsoft teams, they aren’t perfect but they aren't bad, also the comunity is huge, also i hear lots of bad things about swift so there too, the lack of docs and that.
jb1991 3y ago
No, it won't be Reactive Native or any other. There are no cross-platform UI wars any more. There are efforts at this, all with huge compromises, but working with a native UI toolkit on any platform will always offer a superior developer experience and a superior user experience; that's just the way it has always been, still is, and I'd predict always will be.
- jeremy_wiebe 3y ago
  The problem is that developer experience (and often user experience) aren’t always the highest priority. For many businesses that want to ship a mobile app, cost is by far the biggest constraint. And “writing once, shipping everywhere” pushes out native development. We at Khan Academy have moved much of our app to React Native and overall it’s a great experience and much easier to maintain than two native apps. Of course, the constraints and requirements vary by business and so what’s right for us may not be right for you.
  - no_butterscotch 3y ago
    How much of KA's web react code (I'm assuming?) can be re-used in RN land? Or vice versa, do you use RN-Web or plan to?
    - jeremy_wiebe 3y ago
      Currently we only share Perseus (our exercise and article npm library). We do hope to begin work to share more code at some point but it hasn’t risen up in the priority list just yet.
tarkin2 3y ago
I was put off my React Native and Flutter since they don't give a native experience and some native features. Good and fast at the start, but after a while they'll be lacking. Kotlin multiplatform--with the business logic shared but UI native--seemed like the best bet, backed by an impressive stack and company. And KM has gained traction in quite a few companies, slowly moving shared logic to Kotlin, while keeping separate iOS, Android and web teams. Yet I feel more companies value Flutter, or even React Native, because it allows companies to reduce the number of employees they need, and many companies will value that over than having a perfect native experience. I can't see there being a winner anytime soon. Web-savvy companies will favour React Native, companies with native developers will move some things to Kotlin Multiplatform, companies looking to reduce head counts more than improve user experience will favour Flutter or React Native.
037 3y ago
While we were waiting for the perfect cross-platform solution, we underestimated the web standards that we've always had in front of us, and are slowly becoming the perfect, powerful common denominator.
- dwaite 3y ago
  sort of. From a user perspective, the app security model is brokered (by a store) while the web security model is a direct ad-hoc relationship to whoever [you _think_] owns the domain you are on. Apps tend to need reviews for republication, while a website could change owners (through acquisition, domain expiry or other exploit) at any given time. Modern systems sandbox both application access for security exploit reasons as well as user privacy reasons. The web lets apps talk to one another arbitrarily, embed one another in frames, and so on. Because of this, hardware access will always be significantly more constrained than store-reviewed apps.
johnthuss 3y ago
The only cross-platform UI that is likely to be feasible to use long term is HTML/CSS/JS. That comes with significant downsides in terms of display fidelity. But that is going to be the case (to some degree) with any cross-platform toolkit.
- mch82 3y ago
  This seems right, at least for the next decade. Recently, I really enjoy running containerized apps locally and accessing the GUI as a website on localhost. It feels like there’s a lot of room to build on that model.
cush 3y ago
The Browser Company is currently working on a Swift on Windows
snyp 3y ago
I’ve been writing mobile apps since 2013. Cross Platform UI is a myth. Just use a framework and language you are familiar or comfortable with. I prefer native so I just stick to that. You are sure to be most productive in languages you are familiar with rather than any new/old cross platform UI framework. Just be cognizant of the fact that all of them have trade offs.
- krembanan 3y ago
  > Cross Platform UI is a myth How can you say this when many of the worlds most used apps are written in React Native? Same with Electron and desktop apps. I find it hard to believe you can be more productive writing native code when you need two entirely different codebases, compared to a single one, no matter how good of an iOS and Android developer you are.
  - brailsafe 3y ago
    It's just reps no matter how you do it.
  - waboremo 3y ago
    You do realize you still have to write a lot of native code in cross platform apps, right? It's what all the most used apps do. This idea that individually you can be more productive on a cross platform app has no basis in reality. You're still having to concern yourself with platform specific aspects, except now you're also throwing in another layer into the mix for your shared aspects. These shared aspects tend to also not be up to user expectation most of the time, so you're having to rewrite things that comes easy for native apps, to ensure consistency and accessibility. Such moves makes sense for Facebook. Given who they hire, what they work on. Same for Microsoft, but not sure using them is a good example considering their app experiences are universally terrible. For a lot of other places though? There has been a grand total of zero proven demonstration of increased productivity or dramatic savings. You still have to hire android/ios/windows/mac/linux devs respectfully whenever you eventually want to expand to those platforms.
    - 3y ago
nicoburns 3y ago
Add Rust to your list. The Rust UI ecosystem is still very immature, but it has a tendency to implement things very well once they are implemented and the potential is huge.
- zengid 3y ago
  That's another one I'm watching for sure!
- zengid 3y ago
  Speaking of Rust UI, do you have any favorites? I've been casually watching for a long time but haven't seen a clear winner there besides Iced or egui.
  - nicoburns 3y ago
    Iced is still the most capable atm, but Vizia and Freya are also worth looking at. The great thing is that the ecosystem is mostly made up of modular composable libraries, so to a large extent once one framework gains a functionality they all do.
chasing 3y ago
Learning one will make learning the others easier. They have conceptual differences, of course, but there's also a lot of overlap. Regardless, the "cross platform UI wars shaking out" will mean there are three or four options with high market share that each have plusses and minuses depending on the specifics of your project. There won't be a single winner.
egberts1 3y ago
Let us not ignore Electron GUi kit.
redsaber 3y ago
I'm still hoping that Kotlin Multiplatform succeeds. Since kotlin is now the language recommended by Google so should be able to natively write for Android while also being able to deploy to other OS.
inopinatus 3y ago
I’ve written a few command-line utilities in Swift lately and really enjoyed working with it. The type system I find especially appealing, being an enabler far more than an impediment, and coming from writing tons of C and Ruby there’s a lot that is familiar. Thus making the current multi-platform story a real shame, it’s a massive barrier to ever choosing Swift for a significant project. It feels like Apple’s reflexive parochialism is limiting their influence, and that is something only leadership could overturn. I doubt they feel any financial incentive to do so.

by zengid 3y ago

dlivingston 3y ago

I wouldn't hold your breath. It's very explicitly tied to Apple APIs and OS conventions; I doubt it will ever be cross-platform. If you want a cross-platform SwiftUI, QtQuick/QML is probably your best bet.

MobileVet 3y ago

I've worked in mobile since 2004 (not a typo, '04). The 'one platform to rule them all' has been just around the corner the entire time. As was already said, don't hold your breath. All of that said, if you are time constrained and really want to look at a single thing, I would go with Flutter. It impressed me when I cranked out a side project with it a year or so ago. Hopefully they continue to put effort towards it.

zengid 3y ago
[flagged]
rapsey 3y ago
From our experience Flutter apps are easy to start with but quite hard to maintain. The core system keeps changing so much you are constantly having to fix things and dealing with broken dependencies. Would never use it for anything important.
- dan1234 3y ago
  I have the same problem with react native.
  - com2kid 3y ago
    I stopped supporting an open source React Native library because keeping the sample code working in Expo was taking too much of my time. This was years ago, maybe things have calmed down since then, but Expo always felt like hanging onto the horns of a bull, so long as you didn't fall off it was a fun ride!
    - timmeta 3y ago
      That's similar to my experience. Not just React but across JS in general. Was super hard to keep everything at pace when it was and is moving so fast. I slightly envy the old COBOL people sometimes...
- CrimsonRain 3y ago
  Our experience is opposite. We started with GetX because we were new. Then moved to Riverpod/Go-Router as we gained experience. We have a set-up of four modules (shared lib; shared ui; app1 and app2) for two apps targeting web+ios+android; about 50k LoC @ 160 line length. Obviously there were a lot of friction when moving out of GetX, but upgrading things have always been easy. Usually at most one day worth of work (worst case). We don't upgrade as soon as a new flutter version is released. We give it a month at least and then upgrade. During upgrade, most of the problems usually come from 3P dependencies which interact with native such as package info plus. Also, we don't add dependencies unless we really need to. I think we are at ~30 total between all modules. On the other hand, our react projects are forever in dependency hell. Much larger project, yes but way too many dependencies and too many things break during upgrade.
  - bartvk 3y ago
    > Also, we don't add dependencies unless we really need to I think this is the trick. I've worked for a client whose coding standards basically forbade 3rd party clients. Turns out, it often is not needed at all. Do you need to include a library for a bar chart? No, a bar chart is often just a bunch of rectangles and labels. When you have stupid-simple project setups, you can have huge projects but they'll compile fast and upgrade quickly.
lockhouse 3y ago
The biggest problem with Flutter is Dart. Not the language specifically (it’s a nice enough flavor of C-family language), but the ecosystem. Even Swift is better in this regard. Flutter ported to TypeScript and sufficiently distanced from Google would actually be very compelling.
- deleted 3y ago
  [deleted]
- danielvaughn 3y ago
  Yep, I just commented the same thing before I read this. I'd say it's both Dart and Material Design. Dart doesn't seem bad (I've only glanced), it's just not very compelling or interesting.
Vt71fcAqt7 3y ago
I have to agree. Also I feel like those complaining about dart just have a bad taste in their mouth from dart 1.0. Dart has named parameters (so better than java) and null saftey. It's a pretty standard GCed OOP language. I also don't understand when people complain about the dart ecosystem. Seems fine to me.
kitsunesoba 3y ago
In my experience the issue with Flutter apps is though they aren't too bad on Android, they have an odd off-putting feel to them on iOS, more than is typically visible with competing cross-platform UI frameworks.
- martinald 3y ago
  It's because unlike a lot of frameworks like React Native and Xamarin, it doesn't use native UI components under the hood (unless this has changed recently). It's a bit like using a canvas element in HTML and drawing your own toolkit, or old Java GUI apps.
- __m 3y ago
  Especially when you need a date picker that doesn't scream Android
mikhael28 3y ago
Dart and Flutter are totally fine, and great in production. I really don't understand the hate.
- M4v3R 3y ago
  Flutter is mostly fine. Until you need to implement text input in your app. And it turns out that autocomplete doesn’t work properly on iOS for non-English phones and you discover there’s a bug filled on their tracker for 5 years already and it’s still open [1]. Or you encounter another similar issue that is niche enough that the developers ignore it completely but is frustrating for your users and there’s nothing you can do. Don’t get me wrong, I would really love Flutter to be THE solution to the cross platform mobile app problem, but sadly it only gets you 95% there and if you really care about the last 5% you’re out of luck. [1] https://github.com/flutter/flutter/issues/12920 https://github.com/flutter/flutter/issues/12920
  - jononomo 3y ago
    Isn't getting 95% of the way there better than getting 0% of the way there? What are you going to do instead?
    - waboremo 3y ago
      Your equation isn't complete. You can't only care about getting 95% of the way there if the final 5% takes substantially more time than it normally would or worse halts development entirely.
    - M4v3R 3y ago
      It depends. For some use cases it’s definitely enough and if you’re on tight budget it might get you far enough. But eventually it might fall short and you’ll have to either fight the framework or switch to a native solution. I believe it’s good for knocking out an MVP if the mobile app is not critical to your business. I would not choose it otherwise though.
    - 1123581321 3y ago
cush 3y ago
I'm still holding out for Xamarin
madeofpalk 3y ago
More specifically, there are a bunch of efforts, but the Swift ecosystem doesn't seem too interested in this. Even Apple can barely get it with SwiftUI being a dumpster fire on macOS.

lobstrosity420 3y ago

Swift had no horse in that race whatsoever. It was made to interface with Cocoa and it excels at pretty much exclusively that.

Mertax 3y ago

Why not include C#/MAUI on this list to make it 5?

sirwhinesalot 3y ago
The moment it went with Catalyst on macOS and forgot Linux exists entirely it was dead on arrival. It's Xamarin Forms but worse. Well done Microsoft slow clap.
- criddell 3y ago
  > it was dead on arrival I understand holding out hope for year of the Linux desktop, but ignoring Linux has never really hurt anybody, has it?
  - sirwhinesalot 3y ago
    Well, depends. If I'm evaluating cross-platform UI libraries, Linux support is a must have, even if the market might be small. Electron, Qt, Anything Java, Avalonia, wxWidgets, all the native webview wrappers, etc. All have Linux support.
    - dangerboysteve 3y ago
      Tauri looks great (Rust, webkit & js)
      - sirwhinesalot 3y ago
        Oh yes, it is my preferred solution these days. Web crap is annoying as heck to work with though...
- pjmlp 3y ago
  Ignoring Linux I can even understand, given the Year of Linux Desktop meme, but the Catalyst shortcut, what were they thinking. Not even the new VS4MAC UI uses MAUI, they used their own bindings.

afavour 3y ago

I’ve been dabbling in this space for a long time and I’ve become convinced there will be no good cross-platform mobile UI story. The UIs are too different for there to be a one size fits all solution. (as an aside I really like Swift too and have been enjoying noodling around with it as a server language. Probably rarely a wise choice given that it isn’t their focus but there is some attention given: https://swift.org/server/ https://swift.org/server/)

danielvaughn 3y ago
Yep. The only real option is that each platform agrees to abide by a common protocol for describing GUIs. I don't see that happening.
criddell 3y ago
> there will be no good cross-platform mobile UI story Generally (IMHO) there are no good cross-platform stories, mobile or otherwise with the notable exception of some game engines. The closest you can get is choosing the web browser as your platform and writing a web app (Electron). If you want to make the best app you can, use the native toolkit directly or via a framework for your UI.
- koito17 3y ago
  For web apps on desktop you're not even restricted to Electron anymore. Thanks to Tauri, I feel a lot more comfortable shipping web apps beyond the browser (and React Native) since I don't have to pay the cost of bundling Chromium and Node.js. The Rust ecosystem is large enough that any backend-related task I would use Node.js for has an equivalent in Rust.
  - pjmlp 3y ago
    We were never restricted to Electron. There are browsers already installed, and MSHTML apps and XUL predate it for a decade.
waboremo 3y ago
Seconding this. The cross platform experience has been so abysmal for so long, that I question whether the benefits of "easier to support" are even real considering the generally worse experience, longstanding bugs that are harder to nail down, and the added time of having to switch mental models between cross platform and the native code you're going to have to eventually write. I'm at the point now where native apps are still back in heavy consideration, as it's far more straight forward to cascade launch your products on different platforms than it is to half-ass everywhere.

danielvaughn 3y ago

I really like Flutter's approach, I just wish they weren't so wedded to (a) Dart and (b) Material Design.

imachine1980_ 3y ago

for what understand (im not a mobile developer) the best of all of this is react native, works well most time the ux of expo is great and you can "port it to web" like twitter, all the people who use xamarin cry, all the comments who hear about kotlin multi platform is the ecosystem isn't there, and flutter is lots harder when thing make more complicate and google is unreliable they already kind kill flutter desktop or at leas the cut most funding, i feel react native is the only really companies beat real money in it, you have multiple app in your phone using it discord, instagram,pinterest, microsoft teams, they aren’t perfect but they aren't bad, also the comunity is huge, also i hear lots of bad things about swift so there too, the lack of docs and that.

jb1991 3y ago

No, it won't be Reactive Native or any other. There are no cross-platform UI wars any more. There are efforts at this, all with huge compromises, but working with a native UI toolkit on any platform will always offer a superior developer experience and a superior user experience; that's just the way it has always been, still is, and I'd predict always will be.

jeremy_wiebe 3y ago
The problem is that developer experience (and often user experience) aren’t always the highest priority. For many businesses that want to ship a mobile app, cost is by far the biggest constraint. And “writing once, shipping everywhere” pushes out native development. We at Khan Academy have moved much of our app to React Native and overall it’s a great experience and much easier to maintain than two native apps. Of course, the constraints and requirements vary by business and so what’s right for us may not be right for you.
- no_butterscotch 3y ago
  How much of KA's web react code (I'm assuming?) can be re-used in RN land? Or vice versa, do you use RN-Web or plan to?
  - jeremy_wiebe 3y ago
    Currently we only share Perseus (our exercise and article npm library). We do hope to begin work to share more code at some point but it hasn’t risen up in the priority list just yet.

tarkin2 3y ago

I was put off my React Native and Flutter since they don't give a native experience and some native features. Good and fast at the start, but after a while they'll be lacking. Kotlin multiplatform--with the business logic shared but UI native--seemed like the best bet, backed by an impressive stack and company. And KM has gained traction in quite a few companies, slowly moving shared logic to Kotlin, while keeping separate iOS, Android and web teams. Yet I feel more companies value Flutter, or even React Native, because it allows companies to reduce the number of employees they need, and many companies will value that over than having a perfect native experience. I can't see there being a winner anytime soon. Web-savvy companies will favour React Native, companies with native developers will move some things to Kotlin Multiplatform, companies looking to reduce head counts more than improve user experience will favour Flutter or React Native.

037 3y ago

While we were waiting for the perfect cross-platform solution, we underestimated the web standards that we've always had in front of us, and are slowly becoming the perfect, powerful common denominator.

dwaite 3y ago
sort of. From a user perspective, the app security model is brokered (by a store) while the web security model is a direct ad-hoc relationship to whoever [you _think_] owns the domain you are on. Apps tend to need reviews for republication, while a website could change owners (through acquisition, domain expiry or other exploit) at any given time. Modern systems sandbox both application access for security exploit reasons as well as user privacy reasons. The web lets apps talk to one another arbitrarily, embed one another in frames, and so on. Because of this, hardware access will always be significantly more constrained than store-reviewed apps.

johnthuss 3y ago

The only cross-platform UI that is likely to be feasible to use long term is HTML/CSS/JS. That comes with significant downsides in terms of display fidelity. But that is going to be the case (to some degree) with any cross-platform toolkit.

mch82 3y ago
This seems right, at least for the next decade. Recently, I really enjoy running containerized apps locally and accessing the GUI as a website on localhost. It feels like there’s a lot of room to build on that model.

cush 3y ago

The Browser Company is currently working on a Swift on Windows

snyp 3y ago

I’ve been writing mobile apps since 2013. Cross Platform UI is a myth. Just use a framework and language you are familiar or comfortable with. I prefer native so I just stick to that. You are sure to be most productive in languages you are familiar with rather than any new/old cross platform UI framework. Just be cognizant of the fact that all of them have trade offs.

krembanan 3y ago
> Cross Platform UI is a myth How can you say this when many of the worlds most used apps are written in React Native? Same with Electron and desktop apps. I find it hard to believe you can be more productive writing native code when you need two entirely different codebases, compared to a single one, no matter how good of an iOS and Android developer you are.
- brailsafe 3y ago
  It's just reps no matter how you do it.
- waboremo 3y ago
  You do realize you still have to write a lot of native code in cross platform apps, right? It's what all the most used apps do. This idea that individually you can be more productive on a cross platform app has no basis in reality. You're still having to concern yourself with platform specific aspects, except now you're also throwing in another layer into the mix for your shared aspects. These shared aspects tend to also not be up to user expectation most of the time, so you're having to rewrite things that comes easy for native apps, to ensure consistency and accessibility. Such moves makes sense for Facebook. Given who they hire, what they work on. Same for Microsoft, but not sure using them is a good example considering their app experiences are universally terrible. For a lot of other places though? There has been a grand total of zero proven demonstration of increased productivity or dramatic savings. You still have to hire android/ios/windows/mac/linux devs respectfully whenever you eventually want to expand to those platforms.
  - 3y ago

nicoburns 3y ago

Add Rust to your list. The Rust UI ecosystem is still very immature, but it has a tendency to implement things very well once they are implemented and the potential is huge.

zengid 3y ago
That's another one I'm watching for sure!
zengid 3y ago
Speaking of Rust UI, do you have any favorites? I've been casually watching for a long time but haven't seen a clear winner there besides Iced or egui.
- nicoburns 3y ago
  Iced is still the most capable atm, but Vizia and Freya are also worth looking at. The great thing is that the ecosystem is mostly made up of modular composable libraries, so to a large extent once one framework gains a functionality they all do.

chasing 3y ago

Learning one will make learning the others easier. They have conceptual differences, of course, but there's also a lot of overlap. Regardless, the "cross platform UI wars shaking out" will mean there are three or four options with high market share that each have plusses and minuses depending on the specifics of your project. There won't be a single winner.

egberts1 3y ago

Let us not ignore Electron GUi kit.

redsaber 3y ago

I'm still hoping that Kotlin Multiplatform succeeds. Since kotlin is now the language recommended by Google so should be able to natively write for Android while also being able to deploy to other OS.

inopinatus 3y ago

I’ve written a few command-line utilities in Swift lately and really enjoyed working with it. The type system I find especially appealing, being an enabler far more than an impediment, and coming from writing tons of C and Ruby there’s a lot that is familiar. Thus making the current multi-platform story a real shame, it’s a massive barrier to ever choosing Swift for a significant project. It feels like Apple’s reflexive parochialism is limiting their influence, and that is something only leadership could overturn. I doubt they feel any financial incentive to do so.