Začněte uživatelskými úkoly, ne jménem frameworku
Debata nativní aplikace versus společný kód často začíná tvrzením o rychlosti vývoje. To je příliš brzy. Nejprve určete, kdo aplikaci používá, které úkoly jsou kritické a jaké schopnosti zařízení opravdu potřebuje. Bankovní schválení s bezpečným přihlášením a práci v tunelech s nedostupným signálem nelze posuzovat stejně jako jednoduchý katalog. Sepište nejdůležitější obrazovky, offline scénáře, očekávanou odezvu, požadavky na přístupnost a pravidla distribuce. Teprve pak lze rozumně srovnat nativní iOS a Android, React Native nebo Flutter.
Do rozhodnutí zahrňte existující tým. Znalost Reactu může zlevnit vstup do React Native, zkušenost s Dartem může zrychlit Flutter a hotová mobilní infrastruktura může zvýhodnit nativní vývoj. Počítejte však i čas lidí, kteří rozumí samotným platformám. Sdílený kód neodstraňuje podepisování aplikací, oprávnění zařízení, systémové změny ani obchody s aplikacemi. Kdo bude řešit problém jen na jedné platformě při příští aktualizaci systému? Tato odpověď ovlivňuje dlouhodobé náklady více než počáteční ukázka.
Co získáte a za co zaplatíte u nativního vývoje
Samostatné aplikace mohou přímo používat platformní nástroje a vzory interakce. Dávají větší kontrolu nad integrací nových funkcí zařízení, jemným chováním rozhraní a diagnostikou. Cena je práce na dvou klientských implementacích a nutnost koordinovat jejich vydávání. Neznamená to však, že se vše staví dvakrát: doménové pravidlo, API, designové principy a testovací scénáře mohou být společné. Rozdíl je v klientské vrstvě a jejím přizpůsobení systému.
Nativní vývoj má smysl, když produkt stojí na náročné integraci se zařízením, výkonu, velmi specifickém systémovém chování nebo týmech, které už obě platformy dobře spravují. Není automaticky nejlepší pro každou aplikaci. U interního formuláře s několika obrazovkami může dvojí klientská práce převážit výhody. I nativní řešení musí zvládnout správu stavu, synchronizaci, analytiku a podporu starších verzí. Volte jej kvůli konkrétním požadavkům, ne kvůli nálepce nejvyšší kvality.
Co sdílí React Native a kde se rozcházejí platformy
React Native umožňuje sdílet významnou část logiky a rozhraní mezi iOS a Androidem. Jeho dokumentace ale výslovně počítá s platformními odchylkami a nabízí pro ně podmínky i samostatné soubory. To je důležité plánovat od začátku. Dobrý návrh nepředstírá, že systémový dialog, přihlášení nebo navigace musí vypadat a fungovat naprosto shodně. Společná vrstva má obsahovat sdílenou produktovou logiku a obrazovky tam, kde to dává smysl; chování specifické pro zařízení má zůstat čitelné a testované.
Při výběru knihoven kontrolujte údržbu, podporované verze obou systémů a závislost na nativních modulech. Jedna kritická knihovna bez aktivní podpory může převážit úsporu ve zbytku aplikace. Tým potřebuje postup pro aktualizace React Native a testy po změnách operačních systémů. V prototypu si ověřte nejrizikovější integraci, ne pouze jednoduchý seznam. Pokud produkt potřebuje například zvláštní práci s kamerou nebo přístupovými tokeny, vytvořte ji před definitivním rozhodnutím.
Flutter má vlastní kreslení i most k zařízení
Flutter poskytuje sdílenou implementaci rozhraní a konzistentní ovládání vzhledu. Jeho dokumentace popisuje platform channels a další cesty pro volání kódu konkrétního systému. Proto ani zde neplatí, že všechny požadavky půjdou vyřešit bez znalosti iOS a Androidu. Prověřte, zda odpovídá styl aplikace očekávání uživatelů obou platforem, jak se chovají textová pole, čtečky obrazovky a systémové dialogy a jak se bude udržovat vlastní grafická vrstva.
Přínosem může být sjednocená tvorba komplikovanějšího rozhraní na obou systémech. Nákladem jsou jiné návyky týmu, potřebné doplňky a kontrola platformních detailů. Srovnávejte skutečné obrazovky a funkce, ne ukázkovou animaci. U aplikace, která chce působit co nejvíce jako běžná součást každého operačního systému, může být míra přizpůsobování rozhodující. U produktu s výrazným vlastním vizuálním jazykem může být naopak centrálně řízený vzhled výhodou.
Offline režim je otázka datového modelu
„Funguje offline“ není jediná funkce. Rozlišujte čtení dříve načtených dat, vytváření nových záznamů bez sítě a provedení transakce, která vyžaduje serverové potvrzení. Androidí architektonické pokyny ukazují různé strategie zápisu: pouze online, frontu nebo místní zápis s pozdější synchronizací. Každá má jiné riziko konfliktu a ztráty. Například bankovní převod by neměl předstírat dokončení, pokud server transakci nepotvrdil. Interní poznámka může být vhodná pro uložení na zařízení a následné odeslání.
Ověřte, co se stane při ztrátě sítě mezi odesláním a odpovědí. Aplikace nesmí slepě opakovat operaci, která možná proběhla. Potřebuje idempotentní identifikátor a stav „ověřujeme“, případně dotaz na server. Změny z více zařízení vyžadují pravidla řešení konfliktů a jasné zobrazení výsledku uživateli. Tyto otázky jsou stejné u nativního i sdíleného vývoje. Framework je nevyřeší místo produktu. Do porovnání nákladů proto zahrňte návrh backendu a testování synchronizace.
Bezpečnost, soukromí a distribuce patří do výběru
V mobilní aplikaci rozhodují také autentizace, ochrana uložených dat, práce s tokeny a pravidla oprávnění zařízení. Pokud aplikace zpracovává citlivá data, zmapujte, co se ukládá lokálně, co se zobrazuje v notifikacích a jak se chová odhlášení. Prověřte závislosti třetích stran a analytické SDK. Výběr frameworku nemění odpovědnost za tyto věci. Apple ve svých pravidlech pro App Store stanoví požadavky na soukromí a posuzování aplikací; pravidla je nutné při vydání ověřit v aktuálním znění.
Plánujte vydání na obě platformy jako samostatnou činnost. Zahrňte podepisovací klíče, prostředí pro testování, náhledy, popisy, zásady soukromí a podporu při odmítnutí aktualizace. Dvě platformy mohou být v určitou chvíli na různých verzích aplikace. Backend musí po přechodnou dobu podporovat obě. Měřte chyby a dostupnost funkcí podle verze klienta a systému, ne jen celkovou dostupnost API. Vlastní proces vydání bývá podceněnou částí celkových nákladů.
Přístupnost a výkon ověřte na skutečných zařízeních
Neomezujte porovnání na snímky obrazovky. Otestujte ovládání jednou rukou, zvětšení písma, čtečku obrazovky, kontrast, odezvu formuláře a obnovu po přerušení aplikace. Kontrolujte slabší telefony a méně stabilní síť. Měřte spouštění, odezvu kritických akcí a spotřebu paměti v reprezentativních scénářích. Rozdíly mezi technologiemi mohou být malé u běžných obrazovek a zásadní u konkrétního náročného toku. Bez prototypu se to nedá spolehlivě poznat.
Zahrňte přerušení hovorem, návrat z ověření identity, vypršení relace a obnovení aplikace po ukončení systémem. U každého stavu má být jasné, zda lze bezpečně pokračovat a zda nebyl požadavek odeslán dvakrát. Zároveň prověřte lokalizaci, dlouhé překlady a odlišné formáty čísel či dat. Jedna společná komponenta může vyžadovat několik úprav pro oba systémy a všechny jazyky. Přístupnost a lokalizace proto patří do pilotu, ne až do závěrečného ladění.
Rozhodněte pomocí krátkého technického pilotu
Vyberte dvě až tři nejrizikovější úlohy: například přihlášení, offline změnu dat a složitější obrazovku. Pro každou variantu měřte čas vývoje, množství platformního kódu, stabilitu, přístupnost a náročnost testů. Rozhodnutí zapište s důvody a podmínkami, za nichž by se změnilo. Pokud jedna platforma zatím není potřebná, může být rozumné spustit nejprve jednu kvalitní aplikaci a druhou doplnit po ověření produktu. To není selhání sdílení kódu, ale produktová volba.
Při plánování údržby počítejte s pravidelnými aktualizacemi SDK, bezpečnostními opravami, změnami obchodů a podporou starších klientů. Stanovte vlastníka mobilního vydání a postup při kritické chybě. EXCOIN může připravit pilot, architekturu a srovnání na základě konkrétních požadavků. Žádná technologie však nevyhrává automaticky. Správná volba je ta, která umožní vašemu týmu bezpečně doručovat potřebné funkce na skutečných zařízeních i za dva roky.
Pilot ukončete společnou revizí s vývojáři, designem, podporou a vlastníkem produktu. Každá skupina uvidí jiný problém: vývojář náročnost aktualizace, designér odlišné chování ovládacích prvků, podpora obtížně vysvětlitelný chybový stav a vlastník produktu cenu další funkce. Závěr má obsahovat i nevyřešené otázky a plán, jak je ověřit v první verzi. Pokud se rozhodnutí později změní, zapište nová fakta; příští tým pak nebude opakovat stejnou debatu bez znalosti původních důvodů.