Цікаво, як часто ви змінюєте стек на проєкті, коли замовник змінює вимоги? Думати, що можна передбачити все — утопія. Іноді треба бути реалістами.
На думку одразу спадає декілька ситуацій коли це може бути корисно:
1) Коли потрібно реалізувати складний функціонал «на вчора».
2) Коли ресурси команди або компанії обмежені, і немає змоги або бажання наймати окремих Android та iOS розробників для реалізації невеликої, але складної для React Native фічі.
3) Коли просто треба перевірити фічу
4) Додати офлайн режим до аплікації
Мова не про те, що це ідеальне рішення або що воно краще за всі інші. Це просто опція, альтернатива між «зробити» і «не зробити». Як кажуть: «Done is better than perfect»
Дякую за коментар, є з чим погодитись в вашому дописі, але хочу зазначити, що React Native — це дійсно еволюція. Якщо Cordova була мобільною розробкою з акцентом на веб, то React Native — це мобільна розробка з акцентом на натив. Багато бібліотек пишуться на Swift і Kotlin, тому React Native розробники — це вже давно не «самозванці» в світі мобільної розробки. Вони створюють додатки, використовуючи ті ж самі нативні мови, коли в цьому є потреба, а коли ні — вони набагато швидші :)
І ця стаття не про використання браузера як такого, вона про можливість підняття сервера за допомогою ресурсів девайсу, Це можливість розробляти веб-додатки, а потім інтегрувати їх у мобільний додаток (як якусь окрему фічу) , дозволяючи працювати з ними офлайн