3 ms·
My experience (as a senior native Android dev) has been definitely bad so far. Configuration errors and inexplicable error messages popping up on a regular basi
by V-2 8y ago
My experience (as a senior native Android dev) has been definitely bad so far. Configuration errors and inexplicable error messages popping up on a regular basis.
The amount of troubleshooting it constantly required - instead of focusing on the task at hand - started to feel cumbersome after a week or two. Simplest functionality such as breakpoints would randomly stop working. All these problems aren't exclusive to me, I would pretty much always succeed in googling them up, usually along with dozens of solutions suggested by the community (each of them different).
The documentation and tutorials leave a lot to be desired, too. A lot of this stuff is outdated, and the official documents are imprecise and feel like a draft (even when compared to what the much less mature Flutter brings to the table in this regard).
Tooling is far behind what you get if you go native. Eg. support for refactoring, whatever editor you use, will be more than rudimentary and virtually nonexistent in comparison to what Android Studio offers. The same goes for unit testing / integration testing support, it's rather iffy.
One of the more important UI Android features - Material transitions - is pretty much impossible to recreate in React Native.
I also don't find JavaScript - even with TypeScript on - nearly as good a language as Kotlin.
This isn't meant to be a rant: just an honest summary of my few weeks of experience fiddling with RN. You mention your native development was done in Swift; I heard that React Native is allegedly much more reliable for iOS than Android development. I can't really verify it either way, but potentially this might be why our mileages vary.
The upsides? React Native pretty much abstracts away the lifecycle concerns, which are still a pain in the neck for a native Android dev. Hot reloading. No obsolete APIs maintained for backwards compatibility; understandably. Asynchronous programming is simple enough (although with Kotlin's coroutines arguably on their way to become the go-to solution on Android, it's not necessarily a win over native). Nothing else has impressed very much me so far. I used Xamarin for a commercial project once, and it felt considerably better, even though it was three years ago.
- sokoloff 8y agoVery likely. We basically “don’t care” what our apps precisely look like, so long as they function and the user is not impeded in getting access to their data. (They’re simple line of business data access/overview apps.) If we cared about platform perfect compliance with standard UX, it might be more challenging. Of course, if cared about native perfection, we probably wouldn’t be trying an inherently cross-platform tool.