There were many people who claimed they have achieved all three, but at the close examination all of them, 100% without exception, were missing many little things like standard shortcuts, respecting color preference in user settings, or just couldn't see the difference between 11pt and 13pt fonts while looking directly at them.
10 years ago I worked on rewriting Qt interface of a desktop app back to native for a similar reason, and now I am reading all the same story except it's about React Native in mobile apps.
But wouldn't knowing that require that you investigated the tech choices of all the apps you are using? If not, there's a slight fallacy in that you only _know_ that the app is cross platform when you can see that it is. So then obviously all the apps you know is cross platform will look out of place, because that's how you know they are cross platform. Not sure I'm making the argument very well.
For instance, I'm don't think that the Discord app for iOS and Android looks out of place [0].
> Switching to React Native for the Android app means an experience that is ever-improving at a more rapid pace across every platform Discord is available on, while still retaining Android and iOS specific patterns in the UI.
[0]: https://discord.com/blog/android-react-native-framework-upda...
It has a good rating in app store today. Better than Slack, even. And although there are probably many reasons for that, atleast RN hasn't killed the ratings.
Seems like the bigger problem is their QA department than their engineering decisions
I did investigate every app I ran, because I was programming UIs and was interested in all tech that was there. To the point of being able to tell whether the app was written with Delphi or Qt or MFC/ATL by just playing with it.
Qt apps on Mac always stand out, being "OK" is the top they achieve.
Windows is less offended because it has never had a stable style, but still, there are always tiny details like context menus or not responding to Ctrl+Arrows that give non-native away.
Mac OS X looked a little off, especially the spacing.
A few years ago I worked on Java application using SWT. It looked very OK on Linux/Mac/Windows. Even original AWT in Java was cross-platform an native. The problem with Java was GC pauses, but this is a solved problem now.
Java actually succeeded quite well at being cross-platform, it just wasn't a design worth being cross-platform in the first place.
Hopefully they fixed some of this in 20 years.
I wonder if those tight timelines seem justified in retrospect. The stress. Missed social events.
Engineer stress is manager success. You get burnout, they get payout.
I want to put this on a t-shirt
That's interesting. In our experience, we're having a difficult time hiring folks that want to write native (including UI) in antiquated languages and frameworks - but it's much easier to hire JavaScript folks that just hack at RN.
Of course, someone still needs to stand up the actual platform, as well as write shared (and sometimes platform specific) pieces of functionality mostly in C++ so for now I guess us oldtimers still have some job security :)
No iOS developer considers Swift antiquated (because it isn't). I'd argue no one even considers UIKit antiquated (middle aged, maybe). Maybe with the exception of brand new iOS developers who has jumped on the SwiftUI-only bandwagon. SwiftUI itself is so new that it barely is production ready.
Sounds to me like you are actually looking for web developers who doesn't want to start learning native, but are OK to do the work in JS.
Ended up using react-native-web in an Electron container to make a desktop version of an RN app, which worked surprisingly well.
These people probably have never worked on a production RN app or done upgrades and maintenance for one.
It just suffers because everybody "knows React" so how hard could it really be and people get hired into roles working on RN with very little understanding of how it's different from a web based React project.
I’m which land is Kotlin and Swift antiquated? Both a modern and cutting edge technologies with stellar toolchain and 1st class IDE and platform support.
I really dislike this argument, and it comes up every time React Native is discussed. I think it's a holdover from Ionic style mobile applications that simply emulated native UI in a webview. It was awful - especially when the native UI changed and the Ionic apps didn't. It's likely you use RN apps every day and don't even notice because they're indistinguishable from native apps.
React Native is designed to compile down to native code and it uses native UI frameworks. The documentation on how it does this is very thorough. The problem is not React Native in my opinion. It's the native UI frameworks for iOS and Android. These frameworks have a lot of issues and taming them often requires developers with a lot of time and experience in that specific domain. Which is stupid and wasteful.
Here's a story from yesterday of how Apple's SwiftUI (their much vaunted successor to UIKit, a very flawed framework itself) is struggling to construct basic settings views in the new version of MacOS: https://daringfireball.net/linked/2022/08/15/ventura-system-...
Not to mention the criticism of Swift as a language and how it has evolved, including the original creator leaving. And how complicated doing a fucking substring is: https://stackoverflow.com/questions/39677330/how-does-string...
In my opinion, Flexbox is a perfect way of laying out elements on a 2D screen. It's way less confusing than the complex constraints system that UIKit used. React Native's implementation of it works well. Kotlin and Swift as DSLs do not need to exist. They are solutions in search of a problem. Designed by big tech to moat their platforms.
Unless you're building an app that has a very non standard UI or a game, it doesn't make sense not to use React Native in my opinion.
One somewhat direct comparison is Discord (RN) vs Telegram (Swift) on iOS. Discord has put a massive engineering effort into their app but switching channels still often feels glitchy and sluggish whereas Telegram’s layouts snap into place instantly. Telegram feels more solid, and it also properly wires up all the little iOS features like haptic feedback, pull to refresh, etc. whereas Discord mutes all of that and feels less lively.
Regarding constraint-based layouts, they can actually be much simpler in many cases because they help you avoid deep layers of nesting. They also ensure consistency (leading and trailing margins, safe areas, etc.) Again, trade-offs that deal in performance and uniformity with the platform.
For CRUD type apps, it probably doesn’t matter. But like I said those probably aren’t the types of apps native developers would be most interested in building.
React native works maybe fine if your target device is the highest end iPhone, but if your users are on Android One devices, it's not going to work nearly as well.
That's aside from the layouting being obviously off compared to the native layout engines.
I can say from comparing pre-RN and post-RN apps side-by-side on a Nokia 6.2 it's definitely much slower (scrolling immediately drops frames, opening/closing the keyboard and other reflows e.g. multiwindow cause the app to hang for seconds).
A journalist who is not an iOS developer saying something 'feels wrong' doesn't mean much in terms of quantitative evaluation of SwiftUI.
Others have already commented elsewhere on the source material (a list of UX nits) was based on a one month old beta release, and many had already been fixed at the time the list was published - something the author of that list neglected to point out at first.
> Not to mention the criticism of Swift as a language and how it has evolved, including the original creator leaving.
People leave. Rob Pike has mostly stopped working on Go. Graydon Hoare left Mozilla - and worked on Swift for a time.
> And how complicated doing a fucking substring is:
I don't understand your reference. String manipulation on Swift has gotten markedly easier since Swift 3 (when that page was created), but it is still meant to be correct/safe unicode grapheme manipulations at its core. Swift's character type is essentially a variable length, special-case of string.
Most Swift string criticisms come down to - if you want to treat text as offsets into a (mutable) binary buffer, work with binary buffers and not unicode strings.
> In my opinion, Flexbox is a perfect way of laying out elements on a 2D screen. It's way less confusing than the complex constraints system that UIKit used. React Native's implementation of it works well. Kotlin and Swift as DSLs do not need to exist. They are solutions in search of a problem. Designed by big tech to moat their platforms.
AppKit and UIKit's original constraint system was simple, even simplistic.
The constraint system that was built on top was sophisticated, but is generally too fiddly. You pretty much need training in the interface builder to understand how to get constraints to apply and stick.
This was quite simply because it was a bolt-on constraint solver over a layout engine with multiple decades of legacy. No layout options went away when constraints were added - instead, the system had to adapt to having (workarounds) for all the different approaches to operate concurrently.
I don't quite understand what technical complaints if any you have of Kotlin DSL or of SwiftUI's layout systems, so I can't speak to that.
> Unless you're building an app that has a very non standard UI or a game, it doesn't make sense not to use React Native in my opinion.
I'm curious what makes something a 'standard UI' when doing native cross-platform development.
Calling John Gruber a "journalist" is reductive. He is the inventor of markdown and has a history as a software engineer himself. He is also one of the most notable people who tracks things that many would consider obscure like Apple UI frameworks.
>I don't understand your reference https://news.ycombinator.com/item?id=32325511
The standard library and API surface of Swift has changed dramatically every release. They don't have a real problem to solve, and they know they have a guaranteed userbase of their language, so it's gotten progressively weirder and shittier over the years.
>I'm curious what makes something a 'standard UI' when doing native cross-platform development.
Not that curious, because it's pretty easy to look up what React Native offers: https://reactnative.dev/docs/components-and-apis. Things like text inputs, buttons but also bigger conceptual stuff like list views and app navigation: https://reactnative.dev/docs/navigation. Those UI elements render differently in different mobile operating systems and React Native handles both gracefully.
He has plenty of people in his network who are professional developers with SwiftUI experience. However, he was talking about his gut feel from a core system service having so many UI nits from Apple, likely associating that with issues he has heard of from developers who have tried to adopt SwiftUI in their existing and/or new projects.
So thats the basis of my opinion - a quote or two from those full-time developers would added greatly to the article, significantly more his personal reaction.
As a developer with some client-side experience, I'd say the nits speak far more to Apple's MacOS development process these days than to the quality of SwiftUI. A decision was made to add it to the 13 beta and commit to shipping it, rather than hold it back for macOS 14.
Yikes, I hope you're not calling Kotlin or Swift antiquated. That's utterly false.
The same Xamarin app i built in 2014, still runs, on .net7. MS nailed crossplatform in a way that an ad company is never going to invest in. They needed to nail cross-platform to keep themselves as a company relevant; they lost the platform war, then redefined it.
Just launched more apps on the platform this year, love it to death. SAme skills i learnt in silverlight, still relevant 10yrs later. Share 90% of code across every platform; and that 10% is built on native wrapped libraries which are generated off every release. MS has the infrastructure and investment like no ad or book store would ever.
As others have linked, Airbnb actually did write a summary about this.
Basically what went down: For years Airbnb had actually pretty strong native mobile engineering both on iOS and Android (some of the best engineers I’ve worked with) there was no issue investing more in to it. The had the resources, platforms were working well.
The main challenge however was that anything the company needed to launch, needed to be built on 3 platforms at the same time (4 if you count tablet). Timelines were often tight which made the overall coordination between the platforms tough.
One the main examples of this was when 2015-2016 team I was part of basically redesigned and rebuilt the mobile apps, and created a design system/component/layout library at the same time for each platform. It was a huge effort.
At the same time, there was one guy basically hacking on React Native and ended he built the whole component system by himself in few weeks, compared to the months it took in native platforms. This was obviously impressive and company decided to experiment if we could use RN more to speed up development. I think the idea was never to fully replace the native platforms or even core flows, but there were lot of random flows and screens in guest and host apps which only minority of the users see.
So 2016-2019 there was a core team working on a RN adoption, and different people and teams used it in different projects. There were some technical issues at times with performance and navigation that got eventually solved.
However where it all came down was there wasn’t that much adoption and there wasn’t clear group who would actually use RN. Mobile engineers didn’t want to write RN code and web engineers didn’t want to build on mobile. RN also requires understanding of the native platforms, and if the point is build both for iOS and Android, then you need to understand both platforms which is a rare skill set.
So in the end it was just more complicated than it was worth.
I think new company/product can build the team and culture around RN will have better success.
I’d still think if it’s the right choice given what you are building. No matter how good you are I think the RN/Flutter apps can be ok it’s really hard to make them feel fully native.