Představte si poradu, na které zazní „potřebujeme appku“. O několik týdnů později už firma porovnává nabídky na dvě nativní aplikace, přestože se nikdo nezeptal, jak často budou lidé produkt otevírat a zda potřebují něco, co prohlížeč nezvládne.
Volbu platformy určuje to, jak často a kde bude člověk produkt používat, co musí zařízení umět a kolik stojí udržovat více verzí najednou. O tom, zda zvítězí mobilní aplikace nebo webová aplikace, proto nemá rozhodovat vkus dodavatele.
„Potřebujeme appku“ je reflex, ne zadání
Požadavek na aplikaci často vzniká při pohledu na konkurenci a pojmenovává řešení dřív, než je pojmenován problém. Rozumné pořadí je opačné: nejprve pochopit firmu a proces, odstranit zbytečné kroky, potom navrhnout uživatelský zážitek a teprve nakonec vybrat technologii. V modelu vrstev firmy patří volba platformy do vrstvy Experience: určuje, kde se člověk s produktem setká a kolik úsilí ho to stojí.
Možnosti vysvětlené pro vedení firmy
- Nativní aplikace je software napsaný přímo pro jeden operační systém, zvlášť pro iOS a zvlášť pro Android. Znamená to dvě kódové základny, tedy dva samostatně udržované celky zdrojového kódu.
- Multiplatformní aplikace vzniká multiplatformním vývojem: z jedné kódové základny se sestaví aplikace pro iOS i Android. Příkladem je Flutter od Googlu, který podle vlastní stránky FAQ (aktualizované 14. 9. 2026) umožňuje spojit vývojáře do jednoho týmu a sladit vydávání nových verzí; jde však o tvrzení dodavatele. Flutter volá nativní kód přes takzvané platform channels, znalost iOS a Androidu tedy z týmu úplně nezmizí.
- Webová aplikace běží v prohlížeči bez instalace. Google v kurzu Learn PWA (aktualizovaném 20. 9. 2024) uvádí, že u webu odpadá balení aplikace, dodatečná kontrola obsahu i zdržení aktualizací.
- PWA, progresivní webová aplikace, je webová aplikace, kterou lze nainstalovat. Po instalaci má podle stejného kurzu ikonu na ploše a vlastní okno bez rozhraní prohlížeče. Offline režim, tedy práci bez připojení k síti, zajišťuje service worker: skript, který prohlížeč spouští podle potřeby a který podle dokumentace MDN od Mozilly dokáže uložit soubory aplikace do lokální mezipaměti.
Kritéria, která rozhodnou dřív než technologie
- Frekvence používání. Nástroj, který se otevírá několikrát denně, si zaslouží ikonu na ploše, tu však nabídne i PWA. U služby, kterou zákazník využije několikrát do roka, přidá instalace jen další krok před prvním použitím.
- Kontext. Technik ve sklepě bez signálu, skladník v rukavicích, řidič v autě. U offline režimu je třeba přesně určit, jak se má aplikace bez sítě chovat: čtení, zápis, synchronizace i řešení konfliktů mezi úpravami.
- Funkce zařízení. Kamera, poloha na pozadí, Bluetooth, NFC, notifikace, biometrie. Podporu těch, bez kterých se neobejdete, ověřte na cílových zařízeních k datu rozhodnutí, protože se mění. Pozor na práci na pozadí: MDN (13. 9. 2026) uvádí, že service worker neběží nepřetržitě a Chrome ho pravděpodobně ukončí například po 30 sekundách nečinnosti.
- Distribuce. Webovou aplikaci otevře odkaz nebo QR kód. Nativní aplikace se na mobilech podle Googlu instalují hlavně z obchodů s aplikacemi, které určují, kdo a co smí publikovat.
- Aktualizace. U nativní aplikace vyžaduje aktualizace podle Googlu nové zabalení, podepsání, schválení a instalaci. Dokud si ji uživatel nenainstaluje, musí váš server zvládat i starší verzi.
- Cílová skupina. Zaměstnanec nástroj dostane, zákazníka je třeba přesvědčit, takže u zákazníka může každý krok navíc stát část konverzí.
Náklady, které v první nabídce neuvidíte
- Vývoj a kódové základny. Dvě nativní aplikace a web jsou tři kódové základny. Každá funkce se programuje, testuje a vydává třikrát, verze se časem rozcházejí a roste chybovost i cena podpory.
- Schvalování v App Store je kontrola, při které Apple posuzuje každou aplikaci i aktualizaci před zveřejněním. Apple sám uvádí, že v průměru 90 % aplikací odeslaných ke schválení posoudí za méně než 24 hodin. Podstatnější než čekání je to, že o zveřejnění nerozhodujete vy: podle bodu 2.1 pravidel App Review Guidelines (aktualizovaných 8. 6. 2026) Apple odmítá neúplné a padající aplikace.
- Poplatky obchodů s aplikacemi. Provize se týkají prodeje digitálního obsahu a digitálních služeb a jdou přímo na úkor marže. Bod 3.1.1 těchto pravidel vyžaduje pro odemčení funkcí, obsahu či předplatného nákup v aplikaci (In-App Purchase), s regionálními výjimkami. Fyzické zboží a služby spotřebované mimo aplikaci se naopak musí platit jiným způsobem. Pro aplikace distribuované v EU uvádí Apple v podmínkách účinných od 1. 10. 2026 provizi 26 % z prodejů přes In-App Purchase, pro členy App Store Small Business Program 15 %. Google uvádí, že 97 % vývojářů distribuuje aplikace na Google Play bez poplatku, a u transakcí v EHP od 30. 6. 2026 účtuje z prvního 1 mil. USD ročních příjmů 10 % a navíc poplatek 5 % za svůj platební systém.
- Aktualizace operačních systémů. Každá větší změna iOS nebo Androidu je důvodem aplikaci otestovat a často znovu vydat, u dvou nativních aplikací dvakrát. Testování s novými verzemi systémů a prohlížečů označuje Google za povinné i u PWA.
PWA v praxi: co dnes umí a co ne, hlavně na iOS
- Instalace. Podle MDN (7. 9. 2026) nabídne prohlížeč instalaci jen u webu s manifestem, tedy popisným souborem aplikace, a se zabezpečeným připojením HTTPS. Service worker podmínkou není, offline režim je tedy nutné navrhnout vědomě. Na Androidu instalují PWA jako plnohodnotnou aplikaci pouze Chrome na zařízeních s Google Mobile Services a Samsung Internet na zařízeních Samsung. Ostatní prohlížeče vytvoří jen zástupce, který web otevře v prohlížeči.
- iPhone a iPad. V iOS 16.4 a novějších verzích se PWA podle MDN instaluje z nabídky Sdílet. Vlastní instalační tlačítko na webu iOS nepodporuje, uživatele je proto potřeba navést. V iOS 26 a iPadOS 26 se podle blogu WebKit (15. 9. 2025) každá stránka přidaná na plochu ve výchozím nastavení otevírá jako webová aplikace, i bez manifestu.
- Push notifikace jsou zprávy ze serveru, které zařízení zobrazí, i když aplikace neběží. Apple na blogu WebKit 16. 2. 2023 oznámil, že iOS a iPadOS 16.4 přinášejí Web Push pro webové aplikace přidané na plochu, push je tedy podle tohoto oznámení vázán na tento krok. O povolení lze podle něj žádat pouze v reakci na přímou akci uživatele.
- Práce na pozadí. Background Sync se po obnovení připojení pokusí úlohu dokončit, pokud ho prohlížeč podporuje. Podle MDN (13. 9. 2026) ji však lze zadat jen tehdy, když je aplikace otevřená, a prohlížeče omezují počet i délku pokusů. Tichý push bez viditelné notifikace podle stejného zdroje nepodporuje žádný prohlížeč.
- Obchody s aplikacemi. PWA lze podle MDN zabalit i pro Google Play či App Store, bod 4.2 pravidel Applu však vyžaduje víc než přebalený web.
- Regulatorní riziko. Podle serveru TechCrunch (1. 3. 2024) Apple v betaverzi iOS 17.4 zredukoval PWA v EU na pouhé zástupce s odkazem na akt o digitálních trzích (DMA) a po kritice ustoupil. Pracovní dokument útvarů Evropské komise z 28. 4. 2026 uvádí, že Apple v podpoře webových aplikací na ploše pokračoval.
Naše interpretace: PWA je na iOS použitelná volba, její hranice ale určuje Apple, stejně jako hranice nativní aplikace určují pravidla obchodu s aplikacemi. Riziko spojené s platformou nese každá z možností.
Interní nástroje versus zákaznické aplikace
Na rozdíl od zákazníka přivede zaměstnance k internímu nástroji proces: odkaz na intranetu, firemní přihlášení, záložka v prohlížeči. Argument, že aplikace musí být v obchodě s aplikacemi, aby ji lidé našli, tu odpadá.
Interní nástroje se často točí kolem formulářů, schvalování a přehledů a nemají zvláštní nároky na hardware. Výjimkou jsou sklad, terén či výroba, kde je zařízení pracovním nástrojem. Změna na webu se přitom k lidem dostane bez instalace aktualizace. Žádná platforma ale nezachrání nástroj, který lidem práci komplikuje, jak jsme psali v článku Nejdražší systém je ten, který vaši lidé nepoužívají.
Modelové situace
Následující situace jsou hypotetické a slouží jen k ilustraci způsobu uvažování.
Terénní technik
Technici servisní firmy zapisují zakázky i bez signálu. Pokud stačí offline zápis a synchronizace po obnovení připojení, je PWA rozumnou volbou pro pilotní provoz a testy na telefonech techniků ukážou, zda je synchronizace spolehlivá. Jestliže firma potřebuje průběžné sledování polohy během celé směny nebo propojení s měřicím přístrojem přes Bluetooth, je bezpečnější multiplatformní nebo nativní aplikace.
E-shop
Zákazník nakupuje několikrát do roka a přichází přes vyhledávač nebo newsletter. Aplikace by před nákup přidala ještě instalaci a přihlášení. Víc přinese investice do srozumitelnosti webu, protože nejasnou nabídku aplikace nevyřeší, jak rozebíráme v článku Když zákazník nerozumí vašemu webu, platíte za návštěvnost, kterou nevyužijete.
B2B objednávání
Odběratelé velkoobchodu opakovaně objednávají dlouhé seznamy položek. Rozhodující je rychlé zopakování objednávky, import z tabulky a napojení na ERP, tedy podnikový informační systém. To zvládne webová aplikace, nejprve ale ověřte, zda nestačí B2B modul e-shopu nebo ERP, které firma už má.
Věrnostní program
Síť kaváren by si měla nejprve ověřit, zda věrnostní funkci nenabízí její pokladní systém. Střední cestou je PWA s push notifikacemi, na iPhonu až po přidání na plochu. Nativní aplikace dává smysl, když pilotní provoz ukáže, že hosté program používají často a brzdí je právě tento krok.
Interní schvalovací nástroj
Firma schvaluje faktury a žádosti o dovolenou e-mailem. Nejprve je třeba zrušit schvalovací kroky, které nic nekontrolují, a ověřit, zda proces nepokryje účetní nebo personální systém, za který firma už platí. Pokud ne, stačí webová aplikace s firemním přihlášením, případně PWA. Dvě nativní aplikace by tu přidaly náklady na vývoj a vydávání bez přínosu, který by je vyvážil.
Postupná cesta: web, měření, teprve potom nativní aplikace
U produktu, který nemá jasný požadavek na nativní aplikaci, doporučujeme postupovat po krocích:
- První verze jako web nebo PWA: jedna kódová základna, okamžité aktualizace a rychlá odpověď na otázku, zda lidé produkt chtějí.
- Měření: jak často se lidé vracejí, z jakých zařízení, kolik z nich si PWA nainstalovalo a která omezení se opakují.
- Předem stanovený práh: vedení určí, jaký výsledek odůvodní nativní aplikaci. Bez něj rozhodnutí opět sklouzne k reflexu.
- Nativní aplikace tam, kde ji data odůvodní, často jen pro nejaktivnější skupinu uživatelů.
Běžnou praxí je oddělit serverovou část s daty a logikou a zpřístupnit ji přes API, tedy dohodnuté rozhraní pro výměnu dat mezi programy. Nativní aplikace se pak napojí na stejná data a pravidla a web zůstane plnohodnotným kanálem, jak rozvádíme v článku Prémiový web není estetika. Je to obchodní infrastruktura. Pokud ale od začátku víte, že produkt stojí na funkci, kterou web nepokryje, je postupná cesta zbytečnou oklikou.
Kdy je nativní aplikace správnou volbou
- Produkt stojí na nepřetržité práci na pozadí, například na sledování polohy během celé směny. Service worker podle MDN neběží neustále, proto na to web podle nás nestačí.
- Aplikace do hloubky pracuje s Bluetooth, USB, soubory či kontakty, tedy s oblastmi, které Google uvádí mezi silnými stránkami nativních aplikací.
- Aplikace je sama produktem, který lidé používají denně, a výkon je součástí její hodnoty.
I tehdy nejprve zvažte multiplatformní vývoj s jednou kódovou základnou. Samotnou otázku „mobilní aplikace nebo webová aplikace“ otevírejte až poté, co přesně pojmenujete problém, uživatele a prostředí.
Co si z toho vzít
- Otázku „potřebujeme appku“ nahraďte otázkami: kdo produkt používá, jak často, kde a co musí zařízení umět.
- Náklady počítejte za celý životní cyklus: každá nativní platforma přidává kódovou základnu, schvalování a testování, při prodeji digitálního obsahu i provizi obchodu s aplikacemi.
- Tvrzení o schopnostech PWA si nechte doložit zdrojem s uvedeným datem, hlavně u iOS, kde se podmínky od roku 2023 několikrát změnily.
- U interních nástrojů začněte webem, nativní aplikaci zvažujte až pro terén, sklad nebo práci s hardwarem.
- Před první verzí si dohodněte měřitelný práh, který odůvodní nativní aplikaci.
← Všechny články