If you are looking to develop for iOS (or any single environment) only, then all the points you make are great, and you should absolutely stick to native development for that environment.

However, if you are looking to target multiple platforms (and by that I don't just mean mobile, but potentially also web, desktop, and more), then some of these frameworks start looking a lot more interesting.

React Native has split the UI from the rendering, and as such now has render targets for much more than just iOS and Android.

And while you can't share 100% of your code, you can develop a shared component library that can all feed into various native shells as needed. That shell can handle your environment-specific bindings and integrations, while your shared components provide your application's UI and interactions.

Of course it all depends on what you are building, and not all apps would be a fit for this approach.

Performance is roughly the same and you have access to most of the platform features that most apps need.

I messed around with a few cross platform tools a bit and my impression is that if you want to make something that is better than a WebApp you actually have to learn a lot more tools and frameworks and everything feels like falling apart and you are depended on multiple vendors to upkeep the tooling.

The moment you say that your app is more than an UI to access a database, native on multiple platforms is actually easier.

That's a lot of extra complexity, but it's also no less than if you had built two native apps. You're now just expecting a single team to manage it.

My background is in "real" native development (both Android and iOS) so I get on fairly well with this, however, for people coming to React Native from the web side of things, it's a lot to take in.

Overall, I still recommend to 90% of my clients that React Native is a good way to go if they have limited time and budget. For larger companies, they might have the budget to build and maintain two apps.

Also, most apps really are just UIs on top of a REST API. And even if you do want to make something more custom, you can always create a native component or module yourself for each platform and wrap it to use it with the rest of your React Native app. That way the "boring bits" like the account management, data handling, etc can all still be shared.

It's a trade off, but just about works out for me.

RN, never again.

The main benefits for us come down to the fact that we have a large existing JS web application that would take a lot of energy to port to both native platforms (we know from experience, we tried it before). Using React Native, we can share a significant amount of the data and controller layers between web and native. This also means that when a feature gets written for the web, most of the work is already done on mobile (if it was written correctly).

The other key difference is the sheer numbers of each different type of devs we have. At work we have ~400 JS devs and ~30 each of iOS and Android devs. It's just not reasonable to expect the native engineers to be able to keep up. Exploring React Native lets us distribute the load of app development off of the native engineers and put it into some of the web developers. Arguably, an alternate solution would have been to just hire more native devs and I gave that suggestion to management, but that wasn't the direction they wanted to take.

React DOM is very coupled with DOM elements, so React Native Web abstracts away web-specific things, so that code is more sharable.

"...my team is pioneering React Native development..."

React Native has been around for 5 or so years.

The simple fact that there even _is_ an iOS side and an Android side is a large part of what makes cross-platform development appealing.

You asked why you would want to go cross-platform, and then listed a bunch of things you like about iOS development.

The fact that you aren't even sure what the Android tooling looks like answers your question, doesn't it?

I know very well why I would want cross platform development, it doesn't take a genius to figure it out.

The benefit is simple, write once run it everywhere. Oh wait, is that trademarked by Java? Or is their slogan Write Once, Debug Everywhere?

- if you think swiftUI is better than AppKit you can use a mature framework in the same style and could have been doing so for years

- live feedback: SwiftUI previews and fast recompiles are garbage compared to React Fast Refresh which instantly updates the running app, on device, even preserving UI state half the time

- you can update the app outside of the app store, it may be against the rules or not but people do it all the time

- there are more medium quality but ready to go UI components out there. I was pretty shocked by that the last time I did iOS dev.

- Swift is a good language but Typescript is way more chill while still being a pretty good language

- personal opinion: simple animations in react native are not exactly perfect but coding custom CoreAnimation is way harder (for me)

- going from a random design that does not take iOS UI conventions or guidelines into account to an app that looks exactly the same is faster/easier. Is that good? Idk but it‘s something agencies need to do all the time.

You would indeed imagine that, but the reality is less rosy.

1) Android is stuck on an off-brand Java stack that makes desktop Java seem pleasant by comparison. They are finally starting to make headway on replacing this with Kotlin, but most shops are still heavily invested in Java.

2) Android's UI framework is a weird hybrid of legacy and modern controls, and it only fairly recently that it has been capable of accomplishing things like a long scrolling list without memory/performance headaches. Before that everyone had to use 3rd party controls for complex or performance critical apps.

4) A lot of time spent setting up toolchains, SDKs, etc. God forbid your project incorporates C++ dependencies.

6) Google may provide Android itself, but each chip vendor then layers on their own special sauce, and finally each handset vendor layers on ever more special sauce. Add to that the historically abysmal adoption rate of new versions of android (and many vendors not providing upgraded OS versions for their older hardware), and the odds of being able to use a newly-released Google feaure/API are... not good.

But _also_ (and that's no small deal), these cross platform framework often benefit from a huge skill transferability from web development, eg React Native or Vue Native. This is a massive deal, it means you can get a web dev to be productive on a mobile app pretty much immediately (and potentially you use the same technology as for your web app, which itself is also a big deal)

That said, browser based apps make a lot of sense when your app is client-server application and don't need a lot of device-level functionality. This is especially true if your app needs to be a web app, mobile app and desktop app.

I can build stuff the same way on a Thursday for mobile that I do on a Tuesday for web.

This seems like you have very low standards for what is good.

I'm no stranger to Web tech, including JS on the browser and on the server side. It's hell compared to native App development using the native technologies.

I mean, it's so bad that the tutorials explaining the project setup phase can be hours long to follow. Scripts running in the background just to keep you in check and let you write more readable code that is no where as good as Swift(linter, transcompilers, packers oh god >:( ).

When Xcode misbehaves, I would clean the build folder or restart it and everything is back to normal.

It has been a few years since I did something for the web but please let me know if you have a magical IDE or a script or something that lets you do work on you actual code with no janitorial work. Did JS world become considerably better in the last years? Did npm swamp dried out?

As a front-end developer, it's clear to me that you only think that because you are familiar with it, same for me with js - all you need to start developing is npx create-react-app appname or npx create-next-app appname. I toyed around with react native too, and expo is godsend. On the other hand when I tried to use swift/xcode I quickly discovered that official docs are just trash for people unfamiliar with it and community is so much smaller (I was only looking at swiftui FWIW). You have to configure things like dependencies with xcode ui while in js it's all code. Needless to say I didn't go through with it and will go react native next time without a second thought.

For me, it's that you're talking about the flaws which means they're considerable.

You literally considered it while writing your list. Therefore literally considerable.

I use Xamarin for some projects and it's serviceable. Xamarin Forms is a decent toolkit for cross platform internal business apps. Personally I enjoy native iOS dev quite a bit more than cross-platform Xamarin dev, but depending on your use-case, Xamarin might be a better idea than writing separate native iOS and Android apps. Again, I believe for internal business apps that needs to be multi-platform and don't have to look very beautiful, in those cases Xamarin is an excellent choice.

So with that out of the way I want to compare each of your points with the Xamarin situation, from my point of view.

> 1) Swift is very pleasant to use and it is fast.

C# is very pleasant to use as well. It's quite modern and feature wise is pretty close with Swift. On iOS it's probably a little bit slower, but still good enough for most use-cases. I prefer Swift over C#, but C# is almost as nice to use in my opinion.

>2) The UI libraries that I need to learn: UIKit and SwiftUI. SwiftUI is also very pleasant to use and it is getting there.

UIKit and SwiftUI are available for Xamarin, however when developing with Xamarin Forms you will likely try to avoid using these libraries, since Xamarin Forms is meant to cover both iOS and Android UIs.

>3) No hoops to jump for integrating API that makes an App do things that WebApp cannot do.

Again, pretty much all native APIs are available from C# in Xamarin.

>4) Work environment setup is very easy, no scripts to run no tooling that breaks down. It's as simple as creating an new Word document and start doing actual work, not janitorial tasks.

Generally the same for Xamarin, though I guess there's some extra layer of tooling (from what I understand Xamarin translates the C# code to native code, probably Objective-C, maybe Swift).

>5) Despite its bugs, Xcode is a good IDE that natively understand all the tooling I use. Autocomplete might break down sometimes but it can handle project creation, asset management, project configurations and the distribution.

Xcode is leagues above Xamarin Studio. My main issue with Xamarin Studio is that the app just becomes dog-slow after some time. Interaction between Xamarin Studio and iOS Simulator is sometimes also a bit finicky.

>6) The only vendor that I rely on is Apple, as soon as they make something interesting it is available to me. The latest API is there right away.

In Xamarin usually new APIs are available pretty much as soon as Apple releases a new SDK. From what I understand Xamarin uses some automated tooling to generate the C# SDK based on Apple's header. Same stuff you can use to wrap third party libraries in a C# project (Objective Sharpie [0]). Objective Sharpie isn't trivial to use, but quite powerful.

>7) The apps look in place by default, you actually have to work to make UI unconventional and weird.

Xamarin uses the native UI components, regardless if you use Xamarin iOS, Xamarin Android or Xamarin Forms. However, Xamarin Forms is meant to encompass both iOS and Android and therefore is a bit less flexible.

---

[0]: https://docs.microsoft.com/en-us/xamarin/cross-platform/maci...