Hacker News Reader

Comment by imgabe | Hacker News Reader

I’ve done a couple React Native apps and never again. They’re fine at first but if you let one sit for a few months there is a combinatorial explosion of complexity among shifting incompatibilities of different versions of javascript libraries, the framework, android/iOS versions, build systems, etc. it becomes a nightmare. I’d much rather just learn Kotlin/Swift and have only one ecosystem to maintain.

View on HN

At the time I used it, it was almost worth it just to use RN for Android even if you did iOS in Swift, just because styling on Android was so hellish ("There must be some non-crazy way to set a default typeface for my app. Right?" LOL wrong; "setting this color on this Material input field must be easy" LOL nope, welcome to Java metaprogramming just to set a goddamn color), the documentation-suggested way to structure apps was so bad that you'd be reaching for other solutions anyway if you valued your sanity (I wanna say Square was at the forefront, here? It was some company like that. Like your best bet was just to find their libraries and blog posts and do exactly what they did, ignore the official docs), and in some cases the native libraries for Google APIs were less-capable than the Javascript ones anyway (Maps was one, I remember—god, what a surprise that was to find out).

But that was like 5 years ago so maybe it's gotten better.

Although I haven't used it, Jetpack Compose exists now, so that and SwiftUI are pretty similar. On a previous project I was contracting on, the CTO managed to bash out a basic Android version of the iOS app I was working on without any Kotlin experience by going through the SwiftUI views one by one and implementing them in Jetpack Compose.

I agree with you. RN still sucks on some aspects, but it's quite an amazing technology and I'm grateful it exists.

Nah, among cross-platform, RN has stagnated while Flutter has sped past.

The key issue I see these days is that it's just not worth it to build a mobile app these days unless your payment flow happens outside of the app.

I think most users would prefer an RN app over a Flutter app, especially on iOS, because the RN app will feel much more native because it renders using native views, instead of a Skia framebuffer.

> it's just not worth it to build a mobile app these days unless your payment flow happens outside of the app

not true at all, 85% of something is better than 100% of nothing. This is coming from someone who hates mobile apps and apple's grip on them

I had bad experiences with it 7 years ago, but really good experiences with it recently. If you stick to native modules managed by expo you'll be in a great place! You can run into dependency hell if you use a random react-native npm module that was last updated 5 years ago.

Maybe it got better but when I was using RN, it felt fine at the first 3 months; then we found out that it is a hell to work with JS and React Native dependency. To the point we needed to forked multiple project to make it worked. And in the end, we still need a considerable native code for our app. It might just be better to start from scratch with native iOS/Android.

People should just use Ionic & Capacitor.

You can still use your React knowledge with it.

Capcitor with solid or marko would be better, more lightweight.

I have a mobile app sitting around. Wrote it in 2020ish, Corona year. The mobile app is written in flutter and the server is in Go, you probably know by now where I'm heading with this.

I cannot even express how hellish and nightmare that whole flutter thing is: I'm worried about the engine itself (there were breaking changes in the typing system itself that I'd need to worry about), the libraries and packages to update. And not to even stop at the building (signing) stage with the whole ruby shenanigans that needs to match and work well with xcode.

Now compare that to go.

We recently threw out our React Native app and have gone all in on PWAs.

TWA as well? Because I find, the app stores are good for discovery.

This is a very weird thing to say when expo is literally one line installation and it does not require you anything to be installed (even XCode) on machine for most projects. It is literally 10x times easier than just writing in Swift.

> It is literally 10x times easier than just writing in Swift.

I feel Swift as a language is a lot more productive than TS/JS personally. I've found things like React Native and Expo etc. more of a liability than a help for businesses that are heavily reliant on mobile.

If you don't need any native plugins other than those provided by Expo Go, then yes.

If you do need other libraries, or add native code yourself, the package system becomes a nightmare. It is NPM packages on top of Cocoapods on top of a XCode/Swift/Objective-C compile process. Only slightly better on Android.

Want to make a change to a library? Good luck getting linking working on your local setup.

Cordova had exactly the same issues. I'm not sure if Ionic Capacitor is better, but this is one area where Flutter is miles ahead.

in 2023 it is a one liner to add native modules, very easy to link via normal cocoapods or gradle, then almost zero configuration.

Flutter is a joke because it reimplements literally what apple intended to perfect - rendering pipeline, a lot of things impossible to make good without using native api.

When it works it's that simple. When it doesn't - perhaps because of some incompatibility between the native model and a recent Expo update, it's hours of debugging through the different layers to figure out what's going on. That's my experience starting a React Native project in 2023.

Flutter has issues with not using native UI, but I've found the package system with native modules to be way simpler and less issues. Unfortunately you're still stuck with Coacoapods though.

If you want to submit it to the app store you'll need to install XCode anyway to build it and submit it. Might as well just start there and have it configured right from the beginning.

No, you do not, you can use a free service by expo that would build in the cloud. Literally requires zero setup. Local build is needed only if you are sensitive to security, but many banks started to use it. Also native plugins became so easy to use it is a joke how simple it is comparing to cocoapods and some cryptic libraries.

Expo's workflow is so perfect comparing to pure native, it is not even comparable. To do iOS development you need: Swift Packages, Cocoapods and XCode at least. Whils in general it is simple, but cocoapods constantly fights with apple and xcode to not crash anything. While expo also uses cocoapods, it is much more stable because you can always just delete a native project and regenerate it from scratch and it will work.

I am not even starting to discuss how complicated is development for Android - literally everything now have 5+ different APIs for a simple things like "please encrypt this string" or "take a photo". React Native and Expo has perfect packages that solves real problems and work with a few keystrokes.

I'm glad it works for you. One thing I've learned from bitter experience is "don't swim upstream". Meaning, you're likely to have problems when you're using tech outside the way it was intended. Apple intends apps to be developed in Swift with XCode, so that's what they support and when they develop new features that's what they have in mind. They don't care about Expo and if they do something that breaks Expo or Flutter or any other third-party service, that's not their problem and they aren't going to do anything about it. Expo et al are always going to be second class citizens to Apple.

Cocoapods are on their way out. I use Swift Package Manager on new projects and it's literally a couple clicks to install whatever package you want. Haven't had any problems yet.

Writing a Windows app, MacOS app, Linux app, iOS app and Android app is a nightmare because of the insanity and divergence of the SDKs.

They could all have a common API with OS-specific extensions - but instead of that, everyone is trying to make their own API. As a result, developers just write everything in electron/WebKit/WebView.

I wish there was an open standard API for writing native desktop/mobile apps that OSes could adhere to (that the EU forces them to adhere to, haha).

Yeah they did that multiple times already. One of them was Java/JVM. That was exactly how they pitched it in 1998

I suppose it's the execution that is important.

Given that GUI applications share a lot of aspects between platforms, I'd love to see an open "Vulcan"-like standard that defines a GUI API for native platforms.

OSes can interpret calls to that API such that the result looks congruent with the platform's design language - while the application code itself remains portable between platforms.

It's really not that hard to define, there's just no willingness to do so from OS vendors as it would erode their efforts to build walls around their platforms

POSIX became a standard because the US government needed software interoperability with their hardware. It wasn't enforced, but you'd miss out on the government contract lottery if you didn't adhere.

If we value competition in the OS space, it would be wise to support an initiative that would make the OS itself unimportant

I've seen Dart filling this gap for many apps lately

Really important to note, this isn’t react native, its NativeScript.

The two have some fundamental differences — React Native is complex because the React ecosystem is full of complexity. NativeScripts biggest problem is more ecosystem size.

Reply on news.ycombinator.com