React Native или Flutter: как да изберете и кога си струва нативна разработка

Изберете React Native, ако екипът ви вече работи с JavaScript или TypeScript и React, или ако искате приложението да използва собствените елементи на интерфейса на всяка платформа. Изберете Flutter, ако ви трябва силно индивидуален интерфейс, който изглежда еднакво на iOS и Android, и екипът ви е готов да пише на Dart. И двете технологии са достатъчно зрели за приложения в реална употреба, затова решението обикновено зависи от хората, които ще поддържат кода, и от интерфейса, който ви е нужен. Изцяло нативна разработка, със Swift за iOS и Kotlin за Android, е правилният избор, когато приложението разчита основно на хардуера на устройството, на разширения на платформата или на най-новите възможности на операционната система.

#По какво се различават React Native и Flutter

И двете позволяват по-голямата част от приложението да се напише веднъж и да се пусне за iOS и Android. Начинът, по който стигат до екрана, обаче е различен.

React Native е създаден от Meta и се развива заедно с общността. Използва JavaScript или TypeScript и подхода на React. Компонентите му се превръщат в нативни елементи на платформата, така че бутонът или текстовото поле в React Native приложение са истински елементи на iOS или Android. Много екипи работят с Expo, набор от инструменти и услуги около React Native за компилиране, обновления и достъп до често използваните функции на устройството.

Flutter се поддържа от Google, използва езика Dart и рисува собствените си елементи със собствен механизъм за изобразяване. Не използва елементите на интерфейса на платформата, което му дава пълен контрол върху всеки пиксел и еднакъв резултат на различни устройства. Идва с готови набори елементи в стила на Material Design и на iOS.

	React Native	Flutter
Език	JavaScript или TypeScript	Dart
Как се изобразява интерфейсът	С нативните елементи на платформата	Със собствени елементи, рисувани от Flutter
Изглед по подразбиране	Следва всяка платформа	Еднакъв на двете платформи
Връзка с уеб екипа	Уменията с React и част от TypeScript кода се пренасят	Почти отделно от обичайните уеб технологии
Достъп до нативен код	Нативни модули	Platform channels и плъгини

#Започнете от уменията на екипа

Технологията, която екипът ви може да поддържа, обикновено е по-добър избор от тази, която печели сравнението по функции. Едно приложение живее години след пускането си и някой трябва да се справя с всяко обновление на операционната система, всяка промяна в правилата на магазините и всяка нова функция.

• Ако уеб продуктът ви е изграден с React, React Native позволява на същите разработчици да четат и променят мобилния код, а правилата за валидация, клиентите за API и типовете на TypeScript могат да се споделят.
• Ако екипът ви вече пише на Dart или започва от нулата и предпочита един инструмент, който контролира целия интерфейс, Flutter е силен вариант.
• Ако нямате собствени разработчици и ще разчитате на външна фирма, попитайте кой ще поддържа приложението след пускането и на какъв език. Изберете технологията, която хората по поддръжката познават добре.

#Решете какво усещане трябва да дава интерфейсът

Трябва ли приложението да се държи като типично приложение за iPhone на iOS и като типично приложение за Android на Android, или навсякъде да изглежда като вашата марка?

Тъй като React Native използва елементите на платформата, стандартните контроли, въвеждането на текст, превъртането и функциите за достъпност работят така, както потребителите на всяка платформа очакват. Това е удачно за приложения, изградени около формуляри, списъци и профили, като клиентски портали, приложения за резервации и вътрешни системи.

Собственото изобразяване на Flutter е удачно за интерфейси с много графика, анимации или силна визуална идентичност, която трябва да изглежда еднакво на всяко устройство. Цената е, че навиците на всяка платформа трябва да се пресъздават съзнателно там, където ги искате. Когато Apple или Google променят вида на системните контроли, приложението на Flutter не наследява промяната автоматично.

#Проверете нативните функции, преди да решите

Повечето приложения използват камерата, push известия, местоположение, защитено съхранение на данни или плащания в приложението, а и двете технологии имат утвърдени пакети за това. Рискът е в по-редките нужди. Преди да изберете, направете списък на всички функции на устройството и външни SDK, които ще ползвате, и проверете за всяко от тях:

• дали има поддържан пакет за съответната технология и кога е обновяван за последно;
• дали доставчикът на SDK поддържа официално React Native или Flutter, или само Swift и Kotlin;
• дали функцията работи извън самото приложение, като уиджети на началния екран, приложения за часовник или разширения за споделяне, които обикновено се пишат на нативен код независимо от технологията на основното приложение;
• колко нативен код е готов да пише и поддържа екипът ви, за да запълни празнините.

И двете технологии позволяват да напишете собствени нативни модули, когато няма готов пакет. Планирайте този код: за него са нужни разработчици, които владеят Swift и Kotlin, и той трябва да се поддържа съвместим с всяка нова версия на операционната система.

#Помислете за наемането на хора и дългосрочната поддръжка

JavaScript и React се използват широко в уеб разработката, затова по правило е по-лесно да намерите разработчици, които могат да работят по React Native код. Dart се използва основно с Flutter и опитните разработчици са по-тесен кръг. Това е по-малко важно, ако работите с фирма, която остава на проекта, и по-важно, ако смятате по-късно да поемете разработката в собствен екип.

Поддръжката изисква усилия и при двете технологии. Новите версии на самата технология могат да наложат промени в кода ви и във външните пакети, а пакет, който вече не се поддържа, може да блокира обновяването. Дръжте зависимостите малко на брой, предпочитайте пакети с активни поддръжници и обновявайте по график, вместо да трупате изоставане. Магазините добавят и свой натиск: Apple и Google периодично повишават минималните версии на SDK и инструментите, с които приемат нови издания, така че приложение, което никога не се обновява, в един момент не може да получи дори поправка.

#Кога си струва изцяло нативна разработка

Мултиплатформените технологии спестяват най-много, когато приложенията за iOS и Android са почти еднакви. Нативната разработка на Swift и Kotlin има смисъл, когато:

• приложението е изградено около хардуера на устройството, например Bluetooth аксесоари, сложна обработка от камерата, сензори или продължителна работа във фонов режим;
• ви трябват новите възможности на операционната система веднага щом Apple и Google ги пуснат, преди мултиплатформените пакети да ги наваксат;
• продуктът разчита на разширения на платформата като уиджети, приложения за часовник или интеграция с автомобила;
• изискванията за производителност са строги, например обработка на аудио или видео в реално време;
• ви трябва само една платформа, с което отпада основната причина за споделен код.

Нативната разработка означава две кодови бази и обикновено два различни набора умения за всяка функция, която съществува и на двете платформи. Това е цената на най-точното съответствие с всяка платформа. Някои екипи комбинират подходите: мултиплатформено приложение с нативни модули за малкото функции, които ги изискват.

Какъвто и път да изберете, приложението е само част от продукта. Нужно му е API, което връща ясни грешки, зарежда дългите списъци на страници и поддържа по-старите версии на приложението работещи и след пускането на нови. Включете тази работа в бюджета; какво още трябва да предвидите, обясняваме в статията колко струва изработката на уеб приложение.

#Как може да помогне PN Scripts

PN Scripts разработва мобилни приложения за iOS и Android на React Native, Flutter, Swift и Kotlin, заедно с API-то зад тях и публикуването им в App Store и Google Play. Кодът и акаунтите в магазините са на ваше име от първия ден. Как протича един проект, ще видите на страницата за разработка на мобилни приложения.