Flutter, React Native vagy natív? Így döntünk a gyakorlatban

Indulj a termékből, ne a keretrendszerből

A platformkérdés általában rossz irányból érkezik: „Fluttert használjunk?” Pedig a hasznos kérdés az, hogy mit vár el ez a termék a platformtól. Néhány alapvető tény a termékről a legtöbb esetet eldönti, még mielőtt bármilyen keretrendszer-összehasonlításba belekezdenénk:

• —Milyen mélyen nyúl bele az app a platformba – háttérfolyamatok, Bluetooth, widgetek, óraappok, kamera-pipeline-ok?
• —A termék sikere a natív megjelenésen és viselkedésen múlik, vagy egy erős, saját márkaarculaton?
• —Ki tartja karban két év múlva – a te csapatod, a miénk, vagy egy olyan, amelyet még csak ezután veszel fel?
• —Mennyi büdzsé és idő jut az első verzióra – és tényleg van üzleti indoka annak, hogy a termék már az indulásnál mindkét platformon jelen legyen?

Mikor nyer a cross-platform

A legtöbb termékfejlesztő startupnak és üzleti appnak az az anyagilag helyes döntés, ha egyetlen kódbázis megy mindkét store-ba: nagyjából feleannyi fejlesztési munka, egy csapat, és minden funkció egyszerre érkezik iOS-re és Androidra. Az Invoice Guru tipikus példa erre – egy kétkezi szakembereknek szóló számlázóappnál nincs olyan követelmény, ami két párhuzamos natív kódbázis árát indokolná.

A cross-platform világon belül nálunk a Flutter az alapértelmezett: egyetlen renderelőmotor rajzolja ugyanazt a felületet mindkét platformon, erős a tooling, és JavaScript-bridge nélkül egyenletes a teljesítmény. A React Native akkor kerül elő, ha az ügyfél helyzete amellett szól: van egy React/TypeScript-alapú webes csapata, amely közösen viszi majd az appot, vagy a kódbázis és a toborzás már eleve a React-ökoszisztémára épül. Mindkettő bevált technológia; a mérleg nyelve szinte mindig a projekt körüli emberek, nem a benchmarkok.

Mikor éri meg a natív a dupla kódbázist

A natív Swift és Kotlin továbbra is jó választás néhány jól felismerhető helyzetben: ha az app mélyen a platform API-jaira épül, ha a terméknek fontos, hogy az új OS-funkciókat azonnal átvegye, ha teljesítménykritikus média-pipeline-ról van szó, és – ezt gyakran elfelejtik – ha a szervezet meglévő csapatai és kódbázisai már eleve natívak. A Crew Call két natív appként futott, Swiftben és Kotlinban, és az ügyfél csapatába integrált fejlesztőink is ebben a világban dolgoztak, mert a terméknek ez volt a kialakult valósága.

Az ár nem titok: két kódbázis, kétféle szakértelem, és minden funkciót kétszer kell megépíteni. Ha a terméknek tényleg kell az, amit a natív ad, ez az ár megéri. Ha nem, akkor csak drágán vesszük meg az alaposság érzését.

A tanács, amit valóban adunk

A GYIK-ünkben is kimondjuk: mind a négy stackkel dolgozunk, ezért azt ajánljuk, ami a termékhez illik – nem azt, amit épp el akarunk adni. A gyakorlatban ebből egy egyszerű minta rajzolódik ki: új termékeknél a cross-platform (többnyire Flutter) az alapértelmezés, React Native akkor, ha az ügyfél csapata eleve arra húz, natív pedig akkor, ha a termék platformigényei vagy a szervezet korábbi befektetései miatt valóban ez az indokolt választás.

A legdrágább hiba nem az, ha a „rossz” keretrendszert választod – mindegyikkel kiváló appokat lehet szállítani. Hanem az, ha olyan okból választasz, aminek semmi köze a termékedhez: a hype miatt, egyetlen fejlesztő ízlése alapján, vagy egy régi döntésre hivatkozva, amelyet senki nem vizsgált felül, amikor a termék igényei megváltoztak.