HN Explorer

Ask HN: How do you manage your front-ends on multiple platforms?

5 points by samvher ↗ HN
Most of the software engineering in my organization has been back-end work so far. However, there is a push to start providing front-ends on many platforms (on- and offline Android & iOS, and web, likely including features such as image and location capture). I am worried about the need for many different technologies in a small team.

How do you manage this in your team? Do you hire people with a variety of skills? Do you use toolkits like Flutter/React Native? Are you happy with the decisions you've made on this?

4 comments

[ 5.8 ms ] story [ 21.1 ms ] thread
dave_sid
In my opinion a catch-all framework such as React native (and even before that, Appcelerator) costs you more in the long run than just jumping in and developing natively for each platform. On the surface these frameworks look great, write once deploy anywhere etc etc. The trouble is that deliberately choosing to put a barrier like this between you and every platform means you are tied to the development progress of the intermediate platform. Its like sticking a plastic toy steering wheel on top of the steering wheel in your car. Also, I don’t think the promise of ‘write once’ is ever fulfilled. I think you will always find yourself with different edge cases for IOS, Android and Web that take up more time than its worth. You’ll spend more time dealing with edge cases than you saved by not just going native.

My opinion is to forget React native or any other framework that promises the world, and just get your team to build native IOS and Android apps. You have clever people that can handle both. Also, most mobile developers are proficient in Android and IOS.

Lastly, I think your team would likely enjoy the chance to learn Swift for IOS and continue using Java/Kotlin for Android. Give them a week and I bet they could build you two great looking demo apps in both platforms with no need for React native weighing them down. Try it. One or two weeks. See what your team can do. I bet it’s a lot.

Go for long term speed, efficiency, simplicity and core platform knowledge and drop the quick win, promise laden ball-and-chain frameworks such as react native. You don’t need it.

Just my opinion :-D

przeor
If u follow history of RN , you will find that main advantage is that your JS devs can ship to mobile ios/android so it helps smaller team to ship.

Of course if u want to build in native tech than the app will be higher quality, but the disadvantage is that your devs probably wont be efficient in catching kotlin or swift so fast as RN.

In the long term i do agree but 90% ideas for a product fail anyway, iif you know it will succeed then go native

dave_sid
I think there is always an assumption that the JS devs will thank you for not making them learn Swift and Java Kotlin, and that time will be saved by doing so. In both cases I think the assumption is wrong however. Devs love to learn and this will speed up development overall and produce a better product.
photonios
I feel that this depends on the kind of app you're building. If you have a development team already familiar with React and related technology and your app is simple in nature, then you'll get there quicker with React Native. It'll be good enough. It'll be smooth enough, it'll feel native enough and you'll be able to iterate quickly.

If you're in the business of building something super smooth, or some complex interactions and the user experience counts above all else, then yeah, you should go fully native.