[tofuahdude]

What are your thoughts on the business end of deciding to build two separate versions of the app in two languages (not to mention the web) vs the efficiencies of one code base?

We're close to needing to make this decision and I'm real hesitant to introduce two additional languages (we're already React for the web but haven't build apps yet) vs a React Native app where our team can be immediately productive.

[pianoben]

We made this choice at Rdio back in like 2012. Our mobile apps were written almost entirely in C#, shipping on iOS, Android, and even Windows Phone 7/8. About 70% of the code was identical on all platforms, even the super-hairy audio bits. Contrary to the prevailing notions at the time, our app had native levels of quality and performance. We could roll out a new feature an all platforms in only a little more time that it would have taken to do it for one.

That agility didn't come for free, however - we gained speed, but also traded routine bugs for exotic ones. In addition to simple null-pointer errors and the like, we got to spend two weeks digging into the Mono runtime to find a locking bug that drained users' batteries. We had our own sqlite wrapper because the built-in ones on Android and iOS had too many incompatibilities. We had our own red-black tree, for some godawful reason. We had a standing weekly call with our Xamarin reps to discuss toolchain bugs.

Ultimately, the pain ended up outweighing the savings of sharing code. At the time Rdio went bankrupt, we had substantially rewritten the apps in Java and Obj-C. RIP.

[vorpalhex]

I was with a team that went the React Native route. At first it was fine until we had to go slightly off the rails.. and I was rebuilding .so files based off random gists and updating linkage assemblies.

React Native works until it doesn't and then you are getting into very detailed platform specific territory.

A lot of the cross platform promises were untrue - we quickly learned the importance of QAing both builds and frequently had platform specific patches.

Just bite the bullet and go native upfront.

[iainmerrick]

I have had the exact same experience. I’m not a big fan of React or React Native, but I can see that it does increase code reuse; but...

As you say, platform-specific glitches will always crop up so you’ll always need a bit of native work. If you’ve thinned out native development team this can make things hard. Instead of a team of 5 or 10 native developers working on bread-and-butter UI stuff, you only have enough work for 1 or 2, but it’s all grungy stuff like talking to low-level frameworks and working around platform bugs (or React Native bugs, of which there are plenty). That’s not a recipe for clean and maintainable code.

A related issue is that React and React Native aren’t 100% compatible. You can’t just move existing React code directly over as you might elect. It is possible to write code that works on both, but it isn’t trivial.

QA definitely needs to be done separately on each platform.

[The_rationalist]

Or give Ionic react a try

[vially]

I would not recommend Ionic. I've been using it in a medium sized app for about 3 years now and I get the feeling it's good for getting started, but once your app grows past a certain size it's starting to create more issues than it solves.

Some examples from the top of my head:

- various performance issues (e.g.: memory leaks which haven't been fixed for years [1])

- their push/pop router navigation seems like a really bad idea

- worse developer experience than using Angular directly (e.g.: last time I checked this, the save/compile/reload cycle of an Ionic project was an order of magnitude slower than the same project without Ionic)

[1] - https://github.com/ionic-team/ionic-framework/issues/19242

[yesimahuman]

This heavily depends on the framework you choose to use, and modern Ionic uses the stock tooling your framework does, so build times should be on par with any other project of that framework type. Earlier versions of Ionic had custom tooling and much slower build times.

[vially]

This was happening in an Ionic 4 project which was already using the stock tooling of the framework (Angular CLI). But I remember it being worse in Ionic 3 with its custom tooling, so overall things do seem to be improving with time.

My findings at that time (it was a while ago) seem to match exactly the slowdowns described in this issue [1]. Just importing the IonicModule in a new Angular project (without actually using any Ionic component) made the dev server build times jump from around 200 ms to a couple of seconds. And the situation only seemed to get worse as more Ionic features were being added to the app.

Just to make it clear, I understand that this is an open-source project and I don't expect anyone to fix my issues. And I'm also very grateful to you and the Ionic team for giving us Capacitor which is such a big improvement from Cordova.

So I don't like being all negative in here. But I did encounter a fair share of issues with Ionic and I'm only sharing my experience here as just another data-point in case it helps someone make a well-informed decision.

And I have to say, the overwhelmingly positive reaction to Ionic in general did make me question my own abilities several times. Maybe I just don't "get it". I still haven't ruled that out as a possibility.

[1] - https://github.com/ionic-team/ionic-framework/issues/17902

[yesimahuman]

Thanks for the info. I do think the choice of Angular here is significant. Angular builds have historically been very heavy. Later versions have sped things up and Ionic apps have gained from that. I haven’t seen slow builds in React, for example.

[bliteben]

-the push/pop router navigation is insane, it by default keeps all views in memory all the time for react it will reload every view with any state change by default.

[The_rationalist]

Interesting but is this still the case on recent Ionic releases?