Multiplatformní vývoj je strategické rozhodnutí. Nejde o nástroje nebo frameworky, ale o načasování, ambice a míru rizika. Pokud je sdílená architektura navržena správně, dokáže vývoj výrazně urychlit a produkt lépe připravit na škálování. Pokud ne, může týmy zpomalit a přidat zbytečnou komplexitu.

‍

Multiplatformní přístup sám o sobě není novinkou. Změnilo se ale to, kam až se posunul. Kotlin Multiplatform je dnes prověřený v náročných produkčních prostředích. Compose Multiplatform rychle získává na popularitě, my k němu ale přistupujeme uvážlivě a s jasným pochopením jeho současných limitů.

‍

Kdy dává multiplatformní vývoj smysl a kdy ne? Záleží na dvou velmi odlišných situacích: vývoj nové aplikace od nuly a postupný vývoj již existující nativní aplikace.

Tři způsoby, jak postavit mobilní aplikaci

Způsob, jakým aplikaci vyvíjíte, ovlivňuje všechno. Rychlost, náklady, složení týmu i to, jak snadno bude možné produkt v budoucnu měnit.

Rychlá validace díky mobilnímu webu

Nejrychlejší cestou, jak dostat produkt k uživatelům, bývá mobilní web, Progressive Web App (PWA) nebo webová aplikace zabalená do nativního obalu. Tento přístup je ideální pro rychlou validaci a první experimenty.

‍

Mobilní web má ale své limity. Přístup k funkcím zařízení je omezený, výkon slabší a uživatelský zážitek se jen zřídka vyrovná plně nativní aplikaci. I když se PWA výrazně zlepšily, u složitějších a výkonově náročných produktů stále narážejí na své hranice.

‍

Pro produkty v raných fázích, které chtějí testovat nápady s minimální investicí, může ale jít i tak o rozumný první krok.

Maximální kontrola díky nativnímu vývoji

Nativní vývoj znamená stavět zvlášť aplikaci pro Android a iOS a mít tak samostatné kódy, nástroje a často i týmy.

‍

Získáte špičkový výkon a plný přístup ke všemu, co platformy nabízí. Pro vyzrálé produkty s komplexními požadavky je to stále zlatý standard.

‍

Nevýhodou jsou ale vyšší náklady a náročnější koordinace. Vývoj trvá déle, týmy se rozrůstají a produktové změny je nutné koordinovat napříč platformami.

Multiplatformní vývoj jako vyvážený a škálovatelný přístup

Multiplatformní vývoj se snaží vzít to nejlepší z obou světů. Základní logika aplikace je sdílená, což snižuje duplicitu a urychluje vývoj. Vrstvy, které jsou vázané na konkrétní platformu, zůstávají nativní, takže aplikace odpovídá očekáváním uživatelů.

‍

Pro mnoho firem představuje tento přístup vyvážený poměr mezi rychlostí, kvalitou a dlouhodobou škálovatelností. Nejde ale o univerzální řešení, přínos multiplatformního přístupu závisí na kontextu jeho použití

Multiplatformní vývoj u nových aplikací

Při vývoji nové aplikace má multiplatformní přístup největší sílu.

‍

Od prvního dne mohou týmy pracovat paralelně na Androidu i iOS. Byznys logika, síťová komunikace, práce s daty i doménové modely se napíší jednou a znovu se využijí. Jenom tohle ušetří v průběhu životního cyklu produktu značné množství času a práce.

‍

Zároveň si týmy zachovávají plnou kontrolu nad UI a integracemi vázanými na konkrétní platformu. Výsledkem je aplikace, která působí nativně, ale je výrazně jednodušší na dlouhodobou údržbu.

‍

Pro produkty, které mají ambici růst, jde o nejlepší řešení. Obzvlášť tam, kde záleží na rychlosti, konzistenci a dlouhodobém rozvoji.

‍

Multiplatformní vývoj se obvykle hodí, pokud:

• Produkt má být na trhu několik let
• Android a iOS musí zůstat vzájemně konzistentní
• Byznys logika se často mění
• Produkt musí být snadno rozšiřitelný o nové varianty, platformy i regulatorní změny.

Právě tyto faktory vedly k rozhodnutí postavit aplikaci Merkur Bets na Kotlin Multiplatform. Produkt bylo potřeba rychle uvést na trh, udržet konzistentní napříč platformami a zároveň zachovat dostatečnou flexibilitu pro časté změny v byznysu i budoucí škálování, bez nutnosti znovu budovat core logiku.

‍

Existují ale i situace, kdy multiplatformní přístup smysl nedává:

• MVP určená pro rychlé ověření nápadu, kde je důležitější rychlost než dlouhodobá udržitelnost
• Aplikace silně navázané na uživatelské rozhraní konkrétní platformy nebo na nízkoúrovňové systémové funkce
• Týmy bez zkušeností se sdílenou architekturou a bez prostoru se ji učit
• Produkty, kde jedna platforma výrazně dominuje a druhá je pouze okrajová

Multiplatformní vývoj u existujících aplikací je jiný příběh

Jakmile už máte nativní aplikaci v produkci, situace se mění.

‍

Často slýcháme otázku, zda je možné Kotlin Multiplatform zavést postupně, bez kompletního přepisu aplikace. Krátká odpověď je ano. Důležitější otázkou ale je, zda se to vyplatí.

‍

Základním faktorem není technická proveditelnost, ale očekávaná životnost produktu. Pokud budete na aplikaci pracovat další roky, investice se zpravidla vrátí. Pokud ne, nemusí dávat smysl.

‍

V praxi týmy obvykle začínají u Androidu, který je často už napsaný v Kotlinu. Sdílené moduly se postupně vyčleňují, nejčastěji od nižších vrstev, jako je networking, ukládání dat nebo doménová logika. Někdy se podaří přesunout i izolované funkce. Konkrétní strategii obvykle doporučujeme až po revizi aplikace a jejího kódu.

‍

Dříve nebo později se musí do vývoje přidat i iOS. Pro iOS týmy bývá tento přechod náročný. Mění se mentální model, nástroje i způsob práce a refaktoring je nevyhnutelný.

‍

Je ale potřeba říct, že začátek není jednoduchý. Multiplatformní vývoj týmy zpočátku zpomalí. Vývojáři mají pocit, že by bez sdíleného kódu postupovali rychleji. Tento pocit je zcela přirozený.

‍

Postupem času se ale situace obrátí. Sdílené datové modely znamenají, že na změnách se pracuje jenom jednou, ne dvakrát. Byznys logika má jedno místo. Nové funkce se napříč platformami chovají konzistentně.

‍

V mnoha případech je postupný rozvoj stávající aplikace bezpečnější než vyvíjet novou aplikaci souběžně s tou původní. Snižuje riziko funkčních rozdílů a udržuje byznysovou funkcionalitu sladěnou.

Více než technologie: lidé, procesy a náklady

Technologie je jen část skládačky. Stejně důležitá je struktura týmu a vývojové procesy. V praxi jsou to také nejčastější důvody, proč multiplatformní iniciativy selhávají.

‍

Android a iOS týmy jsou zvyklé fungovat samostatně. Používají odlišnou terminologii i mírně rozdílné přístupy k architektuře. Sdílený kód vyžaduje užší spolupráci a změny v plánování i doručování práce.

‍

V počáteční fázi se týmy často cítí pomalejší. Právě v této fázi se multiplatformní přístup obvykle zpochybňuje nejvíce. Z našich zkušeností ale víme, že pokud jsou základy pevné, hodnota tohoto přístupu se začne postupně ukazovat.

‍

Plánování musí být přesnější a týmy se musí shodnout na tom, co patří do sdílených modulů a co zůstává vázané na konkrétní platformu. Komunikace hraje důležitou roli. Postupem času ale tření ubývá.

‍

U dlouhodobě rozvíjených produktů vidíme, jak se multiplatformní vývoj stal přirozenou součástí dodávky, nikoliv omezením.

‍

Často podceňovaným faktorem jsou dlouhodobé náklady na změny. U většiny vyzrálých produktů není největší položkou první verze aplikace, ale její neustálé úpravy.

‍

Regulační změny, úpravy API, nové byznysové požadavky nebo vstupy na další trhy vytvářejí trvalý tlak na vývojové týmy. Při dobře navrženém multiplatformním řešení se mnoho těchto změn implementuje jednou místo dvakrát. To snižuje nekonzistence, zrychluje reakce a usnadňuje další vývoj.

‍

V odvětvích jako BFSI, sportovní sázení nebo jiná regulovaná prostředí, kde se změny dějí neustále, je tato efektivita často důležitější než rychlost prvního uvedení produktu na trh.

Od kompromisu ke konkurenční výhodě

Ještě nedávno byly multiplatformní frameworky vnímány jako kompromis. Dnes jsou nástroje jako Kotlin Multiplatform, Compose Multiplatform nebo Flutter dostatečně vyspělé na to, aby podporovaly komplexní a kvalitní produkty.

‍

Ať už začínáte od nuly, nebo rozvíjíte existující aplikaci, klíčové je udělat krok zpět a podívat se na své cíle, architekturu i tým dříve, než se rozhodnete. Multiplatformní vývoj není vhodný pro každý projekt. Pokud je ale použitý s jasným záměrem a realistickými očekáváními, může se stát skutečnou konkurenční výhodou.

‍

Pokud chcete nezávislý a upřímný pohled na to, zda multiplatformní přístup dává smysl právě ve vaší situaci, rádi pomůžeme. Obvykle začínáme krátkou revizí produktu a architektury, která zabere jen několik mandayů. Výstupem je jasné doporučení, další konkrétní kroky a realistický pohled na kompromisy.

‍

Tato malá investice na začátku často dává týmům jistotu, že mohou postupovat rychle, aniž by se tím omezovali do budoucna.