React Native made me give up a project today
React Native is great; React Native firebase is great; Firebase is great; Apple is great.
Getting an app published that depends on all these to work together is an absolute nightmare.
Just installing it is now a walk through a minefield of errors - is your mac an M1? There are dozens of different recipes to follow for a maddening mix of how to install different versions of ruby, of cocoapods, with homebrew or not, with the arm terminal or rosetta emulator.
Maybe I was naive to expect that after a couple of years things would have just gotten easier or faster.
After a day spent 99% on just setup and getting a generic app to not break, before even touching a line of code to make a feature, I have quit.
I wonder if others feel this way? I'm sad because I like app development, and the idea of building for multiple platforms. And I previously invested a lot in learning and supporting RN but the balkanization of this platform has reached the tipping point for me.
82 comments
[ 2.9 ms ] story [ 162 ms ] threadI recently started writing about going back to a Rust project (check my submissions if you're interested) after 2 years and the experience couldn't be more different (incredibly positive, can't say enough good things).
I would love to develop more for mobile platforms, but I just don't think the cost to my mental state is worth it. I actually ended up killing two mobile apps for my main solo project and replacing them with iOS shortcuts and a Discord bot which thankfully provide 99% of the same functionality that the apps previously did.
I know it's not possible for every use case, but if your mobile app is primarily used to send API requests with payloads of text/images/videos, you'd be surprised how far you can get just using iOS shortcuts these days.
simplify your approach.
Upgrading versions or dependencies isn’t a nightmare.
Dart is easy to use and a pretty good language.
Lots of community support and dependencies.
It works.
Admittedly it's more of a vibe than a hard metric, but a clean build of an empty React Native app for iOS has a triple-digit number of warnings in Xcode.
[1] Making a cross-platform app that's snappy and really nails the platform idioms tends to be at least as much work as making two equally-good native apps.
Docker example: https://docs.docker.com/desktop/troubleshoot/known-issues/ See the "Known issues for Mac with Apple silicon" tab.
Cocoapods in particular is a huge pain in the ass though, even on native iOS projects. It’s been blissful to drop it in favor of Xcode’s built in Swift Package Manager.
As an aside, I’ve found it similarly frustrating to try to get old Rails projects running again. Found one that I hadn’t worked on in at least a decade, would be neat to see it booted up again right? Haha nope forget it, isn’t happening.
It was a bit of an adventure, but it can be done. The tricky thing is making sure native compilation works.
Platform tooling only.
Because the speed of iteration in JS-framework-land is so fast that if you take more than a week or two setting up your dev environment your dependencies are already out of date and insecure, and the half of them that are using “require” instead of “import” stopped working with another library you depend on. Then, when you reported that, the maintainer replied to the GH issue, “modern browsers and Node releases have supported ESM loading for _ages_, like months and months before I started being a dev in 2018 so trust me, it’s stable now.”
(Not that I’ve had an experience like this, ever. And if so, not in a least six months. Or two. Whatever; I’m just slow, obviously.)
Try this line with D3 :-) The maintainer, Mike Bostock, has been a developer since before Node and its commonjs modules. He dropped support of commonjs since d3 version 7, about a year and a half ago.
And that was the day I decided RN was kinda bad.
If you revisit your Capacitor-wrapper a few years later, you either take the update-dependencies-route or just start a fresh project and dump your PWA bundle in there.
Depends on how many native APIs you are using, such as in app purchases.
One thing you do generally need to do with React Native is make sure that you're on a relatively recent version of dependencies. If you're revisiting an old project you likely will need to upgrade everything. That probably does make it a bad choice for infrequently maintained projects. Although if you can avoid the native build and stick with what Expo provides then it would become painless again.
Especially now is a bad time to claim that Expo makes transitioning painless - Expo is under major transition to their new EAS services (and old Expo updates are going to be dropped permanently in 2 months) and support for the new React Native Architecture is significantly changing their build process.
I would agree that before Expo's recent major changes (which I applaud), upgrades have generally been quite smooth.
Thankfully, the latest Expo versions seem to allow much more flexibility in the build process, making it much more viable for me to do my own Expo builds and stay mostly intact from Expo's support cycles.
I mean, I think this is absolutely the killer feature of Nix (even above the more accessible asdf, since Nix will also provide native libraries); it's really nice to get a development environment which will Just Work. (OP's frustration isn't unusual).
On the other hand, Nix doesn't make problems disappear; and can require having a deep understanding of what the problem encountered is. OP ran into problems trying to get a project which had worked on (presumably) x86_64 macOS, but didn't work on M1.
Forgive me for saying this, but the fact that you started with that line makes it sound like you might have some Stockholm Syndrome (or perhaps Sunk Cost Fallacy is more appropriate here). Because what you wrote afterwards makes it clear that at least some of the parts that you mentioned afterwards are in fact not great.
However, the infra surrounding getting that to work is quite the burden and one could argue that it isn't worth it, but at the end of the day that's a metric that can be measured and judged by the developers.
So it isn't a rant about any one actor being bad. But somehow, getting it all to work together is not just difficult, it seems like with time it's getting more difficult.
jesus christ so hard to code there.
It's crazy to me how `https://asdf-vm.com` is still not that well known, Should help to fix lots of dependency issue and it should be a must install for all developers.
Use asdf, language-specific package managers, various version managers (rvm, nvm, whatever), docker, vendor things in, all that kind of stuff, for dev dependencies. Same as you should do on most Linux distros (with some exceptions that are made so they play nice with dev dependencies, like Nix).
honestly, to me it sounds like you have moved over an old environment from years of upgrades, instead of starting fresh on an M1. You're just in edge case hell, and there's no way out if you weren't using segregated environments.
trust me when I'd say it would be faster to start over. when you need your special configurations or PATH variables, you'll find them that one time you need them.
Then you add Android to the mix, it does not get better. RN is just trying to solve the multi-platform mobile app development, it cannot solve how Apple chooses to dictate build / release of their applications.
Well, maybe Qt, but even if it does, C++ is much less forgiving than TS.
Offline-capable web apps are, or course, a viable alternative, as long as you can afford ignoring iOS.
Coming back after some time away is usually 5 minutes of updating things to get Android working, and then a few hours of iOS dependency hell.
It’s definitely an issue with RN, but I haven’t used a cross platform framework that’s any better in this regard.
So the problem is setting up and app either for development or deployment is annoying in general.
If you're feeling brave (I guess not today) you could also try a Kotlin Multiplatform app, which lets you share code between Android, iOS and desktop or even use Jetpack Compose on iOS (but that's a road less travelled because you don't get fully native UI that way).
I'm not certain it's the case here though.
So, i fully agree that it can be discouraging, when you hoped 98% of your time would be pure dev time.
I'm a solo developer writing a fairly complex mobile application with watch integration and while some bits of the setup might be frustrating, however I would urge you to persist for more than a day if possible.
Indeed I had a huge amount of trouble porting my project from my previous mac to a new M1 but after the frustrating setup I just returned to writing JS and swift code and things have been perfectly fine.
Desktop, CLI and Web Backend programs can be easier because they are in a much stable environment. But mobile development is very much a high-speed train.
My own tips for React Native is just use the IDE (XCode, Android Studio) for each platform whenever I have to build and use a text editor for the JS part. Always worked flawlessly.
I think there's something similar for Apple, but I can't actually remember the details right now.
Maybe it's because of your complicated setup?
[0]: https://apps.apple.com/app/id1620426799
[1]: https://twitter.com/daniel_nguyenx/status/157500684665792512...
- integration is hard
- parts don't always play nice - because that's not their job
- the better-integrated platforms (read: apple) are worse at playing nice with other parts
- open-source communities can tie things together, but any sustained effort requires some driving entity or opportunity, so they are first to fail in a downturn [ok, that's just a hypothesis]
As for how it feels: the sense of productivity/velocity is an unhelpful guide. You can end up polishing a turd, or playing infinite games, or stalling at critical point. If you instead are making something deeply valuable, the technical means are just that.
fwiw, in the complex equation of development, I pick one variable to maximize that's key for my goals, and leave the others stable/conventional -- which happens to avoid integration issues.
Why write? The devil made me do it.