Nativní aplikace vs. Capacitor

Plně nativní aplikace vs. Capacitor není akademická debata, ale rozhodnutí, které přímo ovlivní rozpočet, rychlost dodání i budoucí údržbu. V tomhle článku si rozebereme, co se v praxi liší, kde Capacitor dává smysl a kdy už je lepší jít do Swiftu a Kotlinu bez kompromisů.

Rozdíl není v obalu, ale v architektuře aplikace

Plně nativní aplikace je napsaná zvlášť pro iOS a zvlášť pro Android. Typicky to znamená Swift pro iPhone a Kotlin pro Android. UI, navigace i přístup k hardwaru běží přímo nad nativní platformou bez mezivrstvy webového runtime.

Capacitor funguje jinak. Uvnitř mobilní aplikace běží webová část, obvykle v WebView, a nativní vrstva zajišťuje přístup k funkcím telefonu jako jsou kamera, push notifikace, soubory nebo biometrie. Prakticky tedy nasazujete web do mobilního shellu a přes pluginy saháte na zařízení.

Co uvidí byznys: čas, cena a provoz po spuštění

Pro product tým bývá hlavní otázka jednoduchá: kolik to bude stát a jak rychle to bude venku. Tady má Capacitor často náskok. Pokud už máte web v Reactu nebo jiné moderní stacku, část UI i business logiky znovu použijete. Místo dvou samostatných klientů spravujete velkou část kódu na jednom místě.

To ale neznamená, že je Capacitor automaticky levný. Jakmile potřebujete složitější offline režim, hlubokou integraci s hardwarem, plynulé animace nebo specifické chování na pozadí, začne přibývat nativní práce. V tu chvíli se rozdíl mezi hybridem a nativním řešením rychle zmenšuje.

Plně nativní aplikace mají vyšší vstupní náklady, ale u některých produktů jsou ekonomičtější dlouhodobě. Typicky tam, kde je mobilní klient hlavní produkt a ne jen další distribuční kanál. Pokud má aplikace vydělávat na retenci, rychlosti a kvalitě UX, vyplatí se investovat do základu hned.

Kde Capacitor vyhrává a kde naráží na limit

Capacitor doporučujeme tam, kde aplikace stojí hlavně na formulářích, seznamových obrazovkách, uživatelském účtu, obsahu a API komunikaci. Sem patří zákaznické zóny, interní firemní nástroje, rezervační aplikace, eventové aplikace nebo MVP, které potřebuje rychle ověřit trh.

Limity přijdou ve chvíli, kdy je UX citlivé na každé zpomalení. Třeba u komplikovaných gesture-based obrazovek, editace videa, map s velkým množstvím interakcí, Bluetooth komunikace, AR funkcí nebo aplikací, které musí spolehlivě běžet i s omezenou konektivitou a více procesy na pozadí.

Důležitý detail: problém není jen výkon. Často jde o predikovatelnost. Nativní kód vám dává větší kontrolu nad životním cyklem aplikace, pamětí, přerušením procesu systémem i laděním edge casů. U komplexnějších produktů je to zásadní rozdíl.

Technická realita: WebView, pluginy a nativní most

Technicky je Capacitor velmi rozumný kompromis. Webová část běží uvnitř aplikace a s nativní vrstvou komunikuje přes bridge. To je pohodlné, ale každé volání přes hranici mezi JavaScriptem a platformou je další vrstva, kterou musíte chápat při ladění výkonu i chyb.

Pro běžné scénáře existují hotové pluginy a oficiální dokumentace je solidní: dokumentace Capacitoru. Jenže u specifických požadavků často skončíte u vlastního pluginu. A jakmile píšete vlastní bridge pro iOS i Android, jste částečně v nativním vývoji stejně.

import { Camera, CameraResultType } from '@capacitor/camera';

const photo = await Camera.getPhoto({
  resultType: CameraResultType.Uri,
  quality: 85,
  allowEditing: false,
});

console.log(photo.webPath);

Tenhle příklad vypadá jednoduše, a často i jednoduchý je. Ale v reálné aplikaci pak řešíte oprávnění, rozdíly mezi verzemi iOS a Androidu, upload, cache, chování po minimalizaci aplikace a fallbacky při zamítnutí přístupu. Právě tady se láme, jestli je hybridní vrstva ještě výhoda, nebo už brzda.

Kdy jít do nativu bez dlouhého rozmýšlení

Pokud stavíte aplikaci, kde je mobilní zážitek jádro produktu, doporučujeme plně nativní přístup. Typicky fintech, healthtech, logistika v terénu, pokročilé chaty, audio/video aplikace nebo cokoliv, kde se intenzivně pracuje s notifikacemi, background tasky a hardwarem.

Stejně tak nativ řešíme tam, kde je priorita dlouhodobá kvalita UX. Nativní komponenty lépe zapadnou do očekávání uživatelů platformy, scroll i přechody jsou přirozenější a ladění detailů je přesnější. U prémiových produktů bývá tenhle rozdíl vidět víc, než si zadavatelé na začátku myslí.

Rozhodnutí podle typu produktu, ne podle ideologie

Nejhorší varianta je vybrat technologii podle dojmu, že jedna cesta je modernější. Není. Plně nativní aplikace vs. Capacitor je hlavně otázka požadavků. U interního nástroje může být nativ zbytečný luxus. U produktu závislého na výkonu může být Capacitor drahá oklika.

V praxi proto děláme jednoduchý filtr: co musí aplikace umět první den, co bude potřeba za rok a co se stane, když bude mobilní klient úspěšnější, než se čekalo. Tím rychle odlišíte projekt vhodný pro vývoj mobilních aplikací v nativu od projektu, kde je rychlejší hybrid rozumnější start.

Pokud už zároveň provozujete webovou část produktu, vyplatí se posoudit i architekturu backendu, autentizace a design systému. Často totiž nerozhoduje samotný framework, ale to, jestli je produkt připravený sdílet logiku mezi webem a mobilem bez zbytečných kompromisů v UX.

Co si z toho odnést pro první technické rozhodnutí

Capacitor je dobrý nástroj pro produkty, které chtějí rychle vstoupit do mobilu, využít existující webový kód a nepotřebují maximální kontrolu nad platformou. Plně nativní aplikace dávají smysl tam, kde je rozhodující výkon, plynulost, stabilita a hluboké napojení na systém telefonu.

Doporučujeme neptat se, co je obecně lepší, ale co je lepší pro váš konkrétní produkt za 12 až 24 měsíců. Právě tam se ukáže, jestli hybrid urychlí cestu k trhu, nebo jen odloží nevyhnutelný přepis. Když si tím nejste jistí, rádi to s vámi projdeme od use casů až po architekturu.