Hacker News new | ask | show | jobs
by 4eleven7 1861 days ago
You have three options.

Optimise for user experience (go native)

Optimise for cost (whatever the cheapest developers, or a cross platform solution, like phonegap/pwa/react native)

Optimise for developer experience (use whatever your developers know, maybe native, maybe react native)

In my personal opinion, always optimise for user experience. Shared code should be in the backend, not in your mobile app. Your mobile app (ignoring camera filters & games, as they should use an engine; unity etc) should just be a JSON viewer, with a small bit of data entry. 80-90% of your efforts should be on UI and user experience, but obviously architecture requirements scales up with the team size. Anything else is over-engineering, generally.

The amount of leads I get in for mobile apps, that eventually transpire to the client not knowing the app was built in react native, because they heard “native” and assumed Swift/Kotlin, is increasing by the day. They can’t find enough good developers that know react native, and they don’t have the funds to rewrite. They’re stuck. Obviously I, as a native developer, only hear the horror stories from these experiences and not the times it works out.

But in the last 2-3 years, it has killed 2 startups that I know of, and cost 3 a lot of money to rewrite (two of them made that decision before they contacted me, one after they spoke to me, and they were shocked to find out that they didn’t have a Swift app). I am now having to rescue more clients from react native, than from clients that outsourced to the cheapest agency on Fiverr. Wild!

Side note: why has every app got to expand until it adds messaging? Let a calculator be a calculator, it doesn’t need venture capital and network effects to sell.

2 comments

There's a lot that goes on in a mobile app, please read https://developer.android.com/docs/ and https://developer.apple.com/documentation

It certainly is different to backend development, but not everything is a "JSON viewer", even if you exclude camera filters and games. Only the truly awful apps are "JSON viewers". There is a lot of complexity, and I've heard arguments from people that 'they don't want to be a front-end dev because that is just visual stuff': they're talking about pre-javascript days or talking about something they've never done to a good level.

Using a backend (adding network cost)/ sharing code should be the last on your mind for mobile apps. I've had once, where the logic for feature would take less than a day to implement (which I subsequently did), but inexperienced non-mobile developers decided it would be a good idea (and said exactly what you said) to put everything in the backend to share code between iOS and Android. The interface cost (network code) cost more time in development, and made a much worse user experience. Not to mention, I had to use the code written by the inexperienced person, which had bugs.

You might not understand mobile, but there's a lot more that goes on in a mobile app.

> n my personal opinion, always optimise for user experience

If you have unlimited money, that is. If you don't, a suboptimal UX is better than no UX.

> Shared code should be in the backend, not in your mobile app. Your mobile app (ignoring camera filters & games, as they should use an engine; unity etc) should just be a JSON viewer, with a small bit of data entry. Anything else is over-engineering, generally.

Ideally, yes, but depending on the app the frontend can still be heavy - e.g. with Coinbase, all the graphing and real-time stuff, done 3 times over, are probably a not insignificant effort.