Kotlin Multiplatform v praxi: čtyři projekty, čtyři různé výzvy

V prvním článku o multiplatformním vývoji jsme se věnovali tomu, kdy strategicky dává smysl a jak o tomto přístupu přemýšlet ještě před napsáním prvního řádku kódu. 

‍

Tentokrát jsme konkrétnější. Čtyři projekty. Čtyři různé kontexty. Zapojili jsme se jako architekt, technologický lídr i auditor. Situace se lišily. Důvody, proč klienti zvolili KMP, byly však hodně podobné.

Společné rysy použití KMP

• Jeden zdroj pravdy: E-commerce i automotive týmy narážely na stejný problém. Každá platforma si žila trochu jinak. Sdílená codebase to řeší přímo u zdroje. Jedna změna, jeden test, jeden release.
• Vstup na nové trhy bez duplikace: Rychlý vstup do více evropských zemí není reálný, pokud spravujete logiku pro Android a iOS odděleně.
• Dlouhodobé TCO: Konsolidace doménové a datové vrstvy do sdílené codebase snižuje dlouhodobé náklady na údržbu. Úspory nepřijdou okamžitě, kumulují se postupně.

1. Když se architektonické rozhodnutí odkládá (e-commerce)

Středně velká e-commerce platforma nás oslovila s žádostí o revizi architektury mobilního vývoje. Dvě mobilní codebase se po letech paralelního vývoje od sebe výrazně vzdálily. Byznys pravidla byla implementována odděleně na každé platformě.

‍

Při každé změně bylo potřeba aktualizovat obě verze aplikace. Chyby se objevovaly specificky na každé platformě, takže stejný problém byl diagnostikován a opravován dvakrát. Mezitím se s každým releasem rozdíl mezi platformami tiše prohluboval.

‍

Náš přístup: Analyzovali jsme architekturu a zmapovali dopady na TCO. Pro aplikaci této velikosti a v této fázi bylo zavedení sdílené KMP vrstvy pro doménovou logiku, byznys pravidla a síťovou komunikaci dobře realizovatelné. Dalo by se řešit postupně, bez kompletního přepsání, s okamžitými úsporami na údržbě.

Výsledek: Flow tým dodal strukturovanou architektonickou analýzu a navrhl konkrétní migrační roadmapu. Klient na jejím základě ví, jaké jsou dopady na TCO a kudy vede cesta k cíli. Rozhodnutí o načasování realizace je na něm. Příprava je hotová.

2. Ověření KMP před rozhodnutím o nasazení  (automotive)

Velký automobilový výrobce provozuje komplexní mobilní aplikaci, kterou využívají stovky tisíc řidičů. Otázkou bylo, zda lze KMP bezpečně a efektivně zavést do jejich specifického ekosystému a zda se vyplatí do KMP investovat.

‍

Náš přístup: Realizovali jsme Proof of Technology po dobu cca tří měsíců. Dva vývojáři přepsali část codebase do KMP s tím, že se zaměřili na nejsložitější sdílenou logiku: autentizaci, správu sessions, telemetrii vozidla a vzdálené spouštění příkazů přes MQTT. Cílem bylo ověřit proveditelnost v reálném prostředí klienta, vůči jejich CI/CD omezením a compliance požadavkům.

‍

KMP si se sdílenou logikou poradil dobře. Zároveň odkryl některé mezery: šifrované lokální úložiště nemá v této škále hotové cross-platform řešení a Gradle moduly narůstají rychleji, než většina týmů čeká. Obojí je řešitelné. Ani jedno však není triviální.

‍

Výsledek: Klient dostal technologicky a nákladově podloženou analýzu pro vedení firmy a odpovědi na otázky: dává nám KMP smysl, a pokud ano, kdy a jak? Informované rozhodnutí za tři měsíce místo zjišťování stejných věcí rok po zahájení migrace, která mohla skončit ve slepé uličce. Klient si odnesl architektonické know-how a rámec pro rozhodnutí, kdy a jak přejít na plný rollout.

3. Více trhů, pevné termíny, jedna codebase (sportovní sázky)

Merkur Bets vstupoval na německý trh s pevným termínem: spuštění před Euro 2024. Produkt potřeboval podporovat rychlý rollout do dalších evropských zemí bez nutnosti přepisovat logiku pro každý trh znovu.

‍

Udržování oddělených Android a iOS codebase by vážně ohrozilo termín a zároveň vytvořilo náklady na údržbu, kterým se klient chtěl při škálování vyhnout.

‍

Náš přístup: Mobilní aplikace jsme postavili na KMP sdílené vrstvě pokrývající byznys logiku, kterou obě platformy potřebovaly mít identickou: autentizaci, registraci a správu účtu. Tato sdílená vrstva tvořila přibližně třetinu codebase. Zbývající dvě třetiny byly nativní: Jetpack Compose na Androidu, SwiftUI na iOS.

‍

Ani jedna z platforem neslevila z uživatelského zážitku. Na projektu probíhala discovery i vývojová fáze současně a koordinovalo se více mezinárodních stran najednou. Flow tým proto zavedl roli proxy product ownera pro posílení technické a produktové odpovědnosti a koordinace.

‍

Výsledek: Spuštění aplikace v Německu v termínu a následné škálování dle harmonogramu. Lokalizace a regulatorní přizpůsobení pro každou novou zemi jsou dnes otázkou konfigurace, ne dlouhého vývoje. To zásadně mění ekonomiku evropské expanze, která je rychlejší a levnější.

4. Optimalizace živé KMP aplikace bez přepsání (sportovní sázení)

Mobilní aplikace pro sportovní sázení začala mít při zátěži uživatelů výkonnostní problémy. Kurzy se aktualizují v reálném čase, uživatelé sázejí během živých zápasů. Zpoždění v těchto momentech přímo stojí konverze. Tým identifikoval, že něco není v pořádku, ale potřeboval cílenou expertízu, která pomůže najít konkrétní příčiny. Kompletní přepsání zajeté aplikace s velkým počtem uživatelů nepřipadalo v úvahu.

‍

Náš přístup: Provedli jsme strukturovaný audit frontendové vrstvy, backendových interakcí a sdílené KMP vrstvy.

‍

Architektura byla v pořádku. Problémy byly konkrétní implementační vzory, které při normální zátěži fungují, ale při vysoké zátěži aplikaci zpomalují:

• zbytečné recompositions způsobené aktualizacemi sdíleného stavu
• flows emitující víc než je třeba
• náročné výpočty spuštěné na špatném dispatcheru
• zatížení paměti z neřízených lifecycle hranic

Nic z toho není viditelné během vývoje. Vše bylo ale dohledatelné pro vývojáře, kteří vědí, co v KMP kontextu hledat.

‍

Výsledek: Dvouměsíční optimalizace přinesla snížení zatížení CPU o 70–80 % při vysoké zátěži a spokojenost zákazníků vzrostla na 74 %. Vývoj nových funkcí přitom pokračoval bez přerušení. Aplikace nepotřebovala přepsat. Potřebovala cílenou optimalizaci od vývojářů, kteří rozumí KMP kontextu. 

Co jsme se z projektů naučili

Co funguje:

• Postupná migrace vrstvy po vrstvě. Big-bang přístup k zavádění KMP do živého produktu málokdy přežije kontakt s reálnou codebase.
• Proof of Technology před plným nasazením. Tři měsíce ověřování jsou výrazně levnější než narazit na stejné problémy rok po zahájení vývoje.
• KMP pro byznys logiku, nativní UI bez výjimky. Sdílené UI je samostatné rozhodnutí s vlastními kompromisy. Tyto dvě věci by se neměly zaměňovat.
• Strukturované audity při výkonnostních problémech. Většina problémů ve zralých KMP aplikacích je lokalizovaná a opravitelná. Přepsání je zřídkakdy odpovědí.

Co způsobuje problémy:

• Odkládání architektonických rozhodnutí. Náklady na zavedení KMP do codebase, která se rozchází, rostou s každou funkcí přidanou odděleně na obou platformách.
• Implementační vzory, které ve vývoji vypadají v pořádku. Zbytečné recompositions, flows emitující víc než je třeba, výpočty na špatném dispatcheru. Nic z toho není viditelné, dokud aplikace není pod reálnou zátěží.
• Podceňování adaptace iOS vývojářů. KMP je postavený na Kotlin ekosystému. iOS vývojáři potřebují čas a cílenou podporu, aby se stali plnohodnotnými přispěvateli. Týmy, které to neplánují, skončí s dvourychlostním modelem vývoje, kde Android jde vpřed a iOS dohání.

Než se rozhodnete:

• Ověřte KMP ve svém vlastním ekosystému. Testujte ho vůči svým CI/CD omezením, compliance požadavkům a nejsložitější sdílené logice. Obecné benchmarky nejsou náhradou.
• Navrhujte sdílená API s ohledem na Swift interoperabilitu hned od začátku. Některé Kotlin vzory se za hranici platformy špatně převádí. Pokud jsou jednou zavedeny napříč celou codebase, problém se jen prohlubuje.
• Proveďte TCO analýzu před zahájením migrace. Dlouhodobé úspory díky implementaci KMP jsou reálné, ale nedostaví se okamžitě. Business case změny technologie je potřeba spočítat, ne odhadovat.

‍

Pokud vám některá z těchto situací připadá povědomá, ozvěte se. Rádi pomůžeme se zkušeným pohledem zvenku.

‍