4 ms·
Because you'll still need UX experts for each platform. And people who know how to get through the App Store review. And expertise to handle each platform's qui
by slau 2y ago
Because you'll still need UX experts for each platform. And people who know how to get through the App Store review. And expertise to handle each platform's quirks, push notification implementation limitations, etc.
Things like ReactNative or <insert cross-platform app dev toolkit here> miss exactly the same point that CEOs firing engineers over LLMs or vibe coders do: the code was _never_ the problem. It's all the domain expertise that allowed you to produce said code.
Do you know how often I use an app that was clearly built for Android, but also happens to run on iOS? Most likely once, and then never again. Because all the conventions are wrong, and it requires more effort than what I'm willing to give it.
Granted, I haven't played around with Flutter so maybe I'm unaware of how good these cross-platform solutions have become, but still.
- giancarlostoro 2y agoYou can still have RN dev focused on Apple nuances, and another for Android? They can work together towards a common goal, what you're also missing with React Native is that the UI is platform specific, the business logic is fully shared however.
- occz 2y agoMy experience is that anyone who is sufficiently specialized in either platform will select to develop natively for that platform over using RN, since RN imposes lowest common denominator UX for both platforms, more or less.
- lenerdenator 2y ago> Things like ReactNative or <insert cross-platform app dev toolkit here> miss exactly the same point that CEOs firing engineers over LLMs or vibe coders do: the code was _never_ the problem Problems are subjective. To the people who work on the app and actually use it as a part of their work or daily lives, you're exactly right. To the CEO doing the firing, the problem is that he wants a bonus because the other guy who founded his startup around the same time is able to afford <insert ostentatious display of wealth here> and he cannot. And in that case, the engineers are the problem because they cost money. Worst case scenario, you fire the engineers, business goes down, and you have to exit for less money than you thought you would. Not like it matters; you were paying yourself insane amounts of money out of the seed money anyways so you have plenty of money to last until the next big idea that Marc Andreessen wants to flush money away on. ... as for the survival of Objective C, I'm willing to bet that there's an entire class of apps for iOS and iPadOS that most of us use every day but barely give any thought to; apps that are the COBOL banking backends of the mobile world. They've fulfilled a purpose at some business since 2012, they're mission-critical, and you gain zero value rewriting them in anything else, so Objective C keeps getting written to add things onto those apps as new features are needed.
- cosmic_cheese 2y agoFor apps with any level of complexity you’ll absolutely at some point need to get “under the hood” and have to be able to work with native Swift/Kotlin at some point, likely many times. If you can’t you’ll be at the mercy of maintainers and other contributors who may or may not encounter the same problems you do. That being the case, the value prop of cross platform UI frameworks is a lot more shaky. Usually the UI isn’t the hard part, and most apps don’t have a ton of complex logic they need to share either (though there are ways to do this, if necessary). At that point why bother with the cross platform UI framework at all? Just skip the extra layer of bugs and write native.