Yes, initially it is easier, but it is more difficult to scale to other platforms later on. It's all dependent on how much work you want to do upfront versus in the future.
As an indie dev, I feel like the greater risk is that you aren't able to release an MVP and find PMF at all, so I'd always err on getting something working on fewer platforms first so you can move quickly. Having the option to go multi-platform later is a good problem to have, but isn't guaranteed, so don't tackle it early on.
Trying to build for multiple platforms is a lot of overhead, not to mention UI paradigms don't always map one-to-one. Even building for both Mac and iOS (versus just iOS, for instance), for me, can be challenging since there are enough to differences between the two platforms in terms of UX that I have to take extra care to nail both experiences faithfully.
Yep that's true, but it's still another reason I'd use Flutter or React Native simply because they make building for even one platform much easier than Swift, in my experience. Then you can build up afterwards because they also make building for other platforms easier too. It's just one reason why Electron for example is well used in companies.
I think it depends on what you are building and who are your competitors.
Many B2B apps are built as plain web apps that run in the web browser and connect to a backend (CRUD apps). That's because business customers care less about the presentation, and more about the value that the software might deliver. If it saves them time or money - they will buy it no matter what the UX is. And many of them even prefer a tab in the browser, since they do their work in the browser anyway.
With B2C users often expect a more polished experience. More often than not they pay for a nicer, more polished thing, rather than for something that solves a particular pain point. Of course, the app should be useful, but that's table stakes. The deciding factor often becomes the UX. Thus in B2C, the client technology plays a bigger role. Depending on how many competitors offer a native UX, the users might not even consider you if they see that the app is not lightning-fast or has some weird, custom UI that looks off.
React Native has some native UI elements, but then many other things such as the navigation stack are reimplemented from scratch which results in a UX that appears to be similar, yet may work in weird ways that differ from native behavior. Plus React Native is pretty slow in my experience, and like any cross-platform thing has a ton of other weird edge cases and annoyances.
I have not used Flutter, but from my understanding, they have reimplemented the whole UI stack from scratch, and draw everything on a low-level graphical canvas. This means that it is even less native than React Native. They emulate/copy the native UI, but it is not the same. Not to mention that they have to do a ton of work to keep up with the latest changes in Android and iOS. Feel free to correct me.
For B2B, React Native, Flutter, or even Web/Electron are perfectly fine. For some less competitive B2C categories as well. For super competitive ones native is almost always a requirement.
“Easier” depends a lot on the project in my experience. For example if you need a tableview/datagrid as performant and feature rich as NSTableView on Swift/AppKit, you’re probably going to have to build it yourself with React (of any flavor) and especially Flutter (which has a heavy mobile bent to it) or at minimum settle for a community library that’s got big holes in its functionality.
There’s also the whole third party dependency mess referenced in an earlier post, which is unavoidable with both — anything more involved than “hello world” is going to have a mile long list due to how barebones the frameworks themselves are.
