Nativní, nebo cross-platformový vývoj? My máme jasno. A vy?

27. ledna 2021

Vyvíjet nativně, nebo cross-platformově?
Pro mě je (ve většině projektů) odpověď tak jasná, že vám ji klidně vyspoileruju hned:
Jsem všemi deseti pro nativní vývoj. Tedy pro vývoj pro každou platformu zvlášť.
Proč? To vám vysvětlím na příběhu našeho skutečného klienta.
Nejde mi čistě o srovnávání pro a proti obou přístupů. Zamyslel jsem se spíš nad porovnáním jejich přínosů a potenciálních rizik. U cross-platform vývoje totiž vidím riziko poměrně velkých ztrát.
Možná to ale vidíte jinak. V takovém případě budu rád, když se nám ozvete na Facebooku nebo LinkedInu a dáte vědět, jaký je váš názor.

Proč tedy tolik fandím nativnímu vývoji (respektive NEfandím cross-platform vývoji)?

Cross-platform má své výhody. Jenže…

Abych byl fér, shrnu nejdřív výhody cross-platformového vývoje. Vidím tři.

Přenositelnost mezi platformami. Vyvinete aplikaci jednou – a rovnou máte jak Android, tak iOS verzi.
Úspora času. To souvisí s prvním bodem.
Lepší udržovatelnost kódu.

Proto je cross-platform vývoj tak lákavý. Jenže tím (alespoň podle mě) výhody končí. Ne že by šlo o naprosto nevhodný přístup, ne vždy je ale ideální.
Cross-platformové frameworky jsou totiž vystavěné jako vrstva nad samotným operačním systémem. Tudíž musí mít už z podstaty věci omezení, ať už jde o výkon nebo možnosti přístupu k periferiím zařízení.

Případ Flutter

Loni za námi přišel potenciální klient. Měl už několik vyvinutých nativních aplikací a chtěl vyvinout novou, která by stávající aplikace sjednotila. Tu chtěl stavět na Flutteru, googláckém nástroji pro cross-platform vývoj aplikací. Tady jsme zpozorněli – podle nás to pro klienta nebyla dobrá volba.
Oficiální release první stabilní verze Flutteru byl v květnu 2019, tedy 2 měsíce před situací, o které se tu bavíme. To znamená, že byl pořád ve vývojové fázi a pravděpodobně obsahoval množství chyb.

Riziko nového frameworku

Cílem klienta bylo samozřejmě ušetřit čas. Jenže celková doba tvorby mobilní aplikace se nerovná jen vývoji hlavních funkcí. Kromě jiného je tu i fáze, kdy je připravena RC (release candidate) verze mobilní aplikace, kterou musíme odladit, aby mohl vzniknout public release, který vystavíme v Google Play a AppStore.

Délka této fáze při komplexních projektech je přímo úměrná tomu, jak vyspělý a odladěný je framework, ve kterém se aplikace vyvíjí. Pokud sáhneme po cross-platform frameworku typu Flutteru, v této fázi přijdou největší problémy.
Odstranění chyb často bývá velmi komplikované, protože chyby nemusí být způsobené vývojářem, ale jsou ve frameworku samotném. Prostě není dostatečně odladěný.

Vše může dojít až do takového stavu, že se chybu vůbec nepodaří odstranit a ta v aplikaci musí zůstat.
Může se totiž stát, že vývojářský tým cross-platformového frameworku není a ani z principu nemůže být tak velký, jako je vývoj vlastního operačního systému Android a iOS. Proto nemůže reagovat tak rychle a nestíhá řešit všechny problémy, které se v jeho produktu objeví.

Komunita kolem cross-platform frameworků je zásadně menší než u nativních platforem, a tedy řešení jakékoliv specifičtější chyby je problém.

Knihovna pro Bluetooth nemá stabilní verzi

Vezměte si třeba komunikaci pomocí Bluetooth.
Na tu je do Flutteru potřeba přidat knihovnu. Nejlepší, kterou se nám podařilo najít a kterou doporučuje komunita, je Flutter_blue. Když jsme se (před rokem, kdy jsme zakázku řešili) podívali na Github této knihovny, zjistili jsme, že je ve verzi 0.6, je stále ve vývoji a nemá stabilní verzi.
Práce na ní se za několik měsíců nepohla, a co je asi nejzásadnější, viděli jsme 122 otevřených issues a 19 pull requestů, které nikdo neřeší.

Pro novou platformu neexistují zkušení vývojáři

Se stářím frameworku se pojí i dostupnost zkušených vývojářů. Není možné, aby pro framework, který měl svůj první preview release před dvěma lety, existovali seniorní vývojáři, kteří mají mají alespoň 3 až 5 let zkušeností s tímto frameworkem.
Většina současných vývojářů Flutteru se rekrutovala z nativních vývojářů pro Android a iOS s tím, že jejich zkušenosti sestávají z jednoho menšího projektu.
Je rozumné pouštět se do vývoje projektu, který je klíčový pro budoucí rozvoj firmy, s týmem juniorů? Za mě rozhodně ne.

Není cesty zpět

Výběrem Flutteru by náš klient riskoval víc, než se zdá. Jakmile se pro něj totiž jednou rozhodnete, není cesty zpět. Pokud projekt nevyjde, všechno se bude muset zahodit a začít znovu.
Existují i tzv. hybridní frameworky, které můžete zakomponovat do projektu s nativním kódem, např. React Native, ale mezi ně se Flutter neřadí.

Tušili jsme sice, že vývoj ve Flutteru by byl o něco rychlejší, ale kdyby projekt nevyšel například kvůli tomu, že Google Flutter ukončí nebo že narazíme na technické limity Flutteru, museli bychom všechen vytvořený kód zahodit.

Malá přidaná hodnota, velká rizika

Pro relativně malou přidanou hodnotu bychom tak riskovali příliš mnoho. Zároveň bychom nemohli využít už existující aplikace firmy, ze kterých jsme klientovi doporučovali vyjít. To by nám ušetřilo spoustu práce

Cross-platform vývoj jsme proto klientovi doporučili neriskovat. Vývoj dokážeme zrychlit i jinak. Můžeme stavět na už existujících aplikacích, jako to bylo v případě tohoto klienta. Nebo můžeme stanovit jasné priority, vytvořit MVP (minimum viable product), ten publikovat a další funkce dokončovat agilně. Tím by bylo možné vydat aplikaci výrazně dřív.