Mobilná aplikácia, webová aplikácia alebo PWA? Ako sa rozhodnúť bez drahej chyby

Predstavte si poradu, na ktorej zaznie „potrebujeme appku“. O niekoľko týždňov už firma porovnáva ponuky na dve natívne aplikácie, hoci sa nikto nespýtal, ako často budú ľudia produkt otvárať a či potrebujú niečo, čo prehliadač nezvládne.

Voľbu platformy určuje to, ako často a kde bude človek produkt používať, čo musí zariadenie vedieť a koľko stojí udržiavať viac verzií naraz. O tom, či zvíťazí mobilná aplikácia alebo webová aplikácia, preto nemá rozhodovať vkus dodávateľa.

„Potrebujeme appku“ je reflex, nie zadanie

Požiadavka na aplikáciu často vzniká pri pohľade na konkurenciu a pomenúva riešenie skôr, než je pomenovaný problém. Rozumné poradie je opačné: najprv pochopiť firmu a proces, odstrániť zbytočné kroky, potom navrhnúť používateľskú skúsenosť a až nakoniec vybrať technológiu. V modeli vrstiev firmy patrí voľba platformy do vrstvy Experience: určuje, kde sa človek s produktom stretne a koľko námahy ho to stojí.

Možnosti vysvetlené pre vedenie firmy

• Natívna aplikácia je softvér napísaný priamo pre jeden operačný systém, zvlášť pre iOS a zvlášť pre Android. Znamená to dve kódové bázy, teda dva samostatne udržiavané celky zdrojového kódu.
• Multiplatformová aplikácia vzniká multiplatformovým vývojom: z jednej kódovej bázy sa zostaví aplikácia pre iOS aj Android. Príkladom je Flutter od Googlu, ktorý podľa vlastného FAQ (aktualizovaného 14. 9. 2026) umožňuje spojiť vývojárov do jedného tímu a zosúladiť vydania; ide však o tvrdenie dodávateľa. Flutter volá natívny kód cez takzvané platform channels, znalosť iOS a Androidu teda z tímu úplne nezmizne.
• Webová aplikácia beží v prehliadači bez inštalácie. Google v kurze Learn PWA (aktualizovanom 20. 9. 2024) uvádza, že pri webe odpadá balenie, dodatočná kontrola obsahu aj zdržanie aktualizácií.
• PWA, progresívna webová aplikácia, je webová aplikácia, ktorú možno nainštalovať. Po inštalácii má podľa rovnakého kurzu ikonu na ploche a vlastné okno bez rozhrania prehliadača. Offline režim, teda prácu bez siete, zabezpečuje service worker: skript, ktorý prehliadač spúšťa podľa potreby a ktorý podľa dokumentácie MDN od Mozilly dokáže uložiť súbory aplikácie do lokálnej vyrovnávacej pamäte.

Kritériá, ktoré rozhodnú skôr než technológia

• Frekvencia používania. Nástroj otváraný niekoľkokrát denne si zaslúži ikonu na ploche, tú však dá aj PWA. Pri službe, ktorú zákazník použije niekoľkokrát do roka, inštalácia len pridá krok pred prvým použitím.
• Kontext. Technik v pivnici bez signálu, skladník v rukaviciach, vodič v aute. Pri offline režime treba presne určiť, čo sa má bez siete stať: čítanie, zápis, synchronizácia aj riešenie konfliktov medzi úpravami.
• Funkcie zariadenia. Kamera, poloha na pozadí, Bluetooth, NFC, notifikácie, biometria. Podporu tých, bez ktorých sa nezaobídete, overte na cieľových zariadeniach k dátumu rozhodnutia, lebo sa mení. Pozor na prácu na pozadí: MDN (13. 9. 2026) uvádza, že service worker nebeží nepretržite a Chrome ho pravdepodobne ukončí napríklad po 30 sekundách nečinnosti.
• Distribúcia. Webovú aplikáciu otvorí odkaz alebo QR kód. Natívne aplikácie sa na mobiloch podľa Googlu inštalujú najmä z obchodov, ktoré určujú, kto a čo smie publikovať.
• Aktualizácie. Natívna aktualizácia si podľa Googlu vyžaduje nové zabalenie, podpísanie, schválenie a inštaláciu. Kým si ju používateľ nenainštaluje, váš server musí zvládať aj staršiu verziu.
• Cieľová skupina. Zamestnanec nástroj dostane, zákazníka treba presvedčiť, takže pri zákazníkovi môže každý krok navyše stáť časť konverzií.

Náklady, ktoré prvá ponuka neukáže

• Vývoj a kódové bázy. Dve natívne aplikácie a web sú tri kódové bázy. Každá funkcia sa programuje, testuje a vydáva trikrát, verzie sa časom rozchádzajú a rastie chybovosť aj cena podpory.
• Schvaľovanie v App Store je kontrola, pri ktorej Apple posudzuje každú aplikáciu aj aktualizáciu pred zverejnením. Apple sám uvádza, že v priemere 90 % odoslaní posúdi za menej ako 24 hodín. Podstatnejšie než čakanie je, že o zverejnení nerozhodujete vy: podľa bodu 2.1 pravidiel App Review Guidelines (aktualizovaných 8. 6. 2026) Apple odmieta neúplné a padajúce aplikácie.
• Poplatky obchodov. Provízie sa týkajú predaja digitálneho obsahu a digitálnych služieb a idú priamo z marže. Bod 3.1.1 týchto pravidiel na odomknutie funkcií, obsahu či predplatného vyžaduje nákup v aplikácii (In-App Purchase), s regionálnymi výnimkami. Fyzický tovar a služby spotrebované mimo aplikácie sa naopak musia platiť inak. Pre aplikácie distribuované v EÚ uvádza Apple v podmienkach účinných od 1. 10. 2026 províziu 26 % z predaja cez In-App Purchase, pre členov App Store Small Business Program 15 %. Google uvádza, že 97 % vývojárov distribuuje aplikácie na Google Play bez poplatku, a pri transakciách v EHP od 30. 6. 2026 účtuje na prvý 1 mil. USD ročných príjmov 10 % plus 5 % poplatok za svoj platobný systém.
• Aktualizácie operačných systémov. Každá väčšia zmena iOS alebo Androidu je dôvodom aplikáciu otestovať a často znova vydať, pri dvoch natívnych aplikáciách dvakrát. Testovanie pri nových verziách systémov a prehliadačov označuje Google za povinné aj pri PWA.

PWA v realite: čo dnes vie a čo nie, najmä na iOS

• Inštalácia. Podľa MDN (7. 9. 2026) ponúkne prehliadač inštaláciu iba webu s manifestom, teda popisným súborom aplikácie, a so zabezpečeným pripojením HTTPS. Service worker podmienkou nie je, offline režim teda treba navrhnúť zámerne. Na Androide inštalujú PWA ako plnohodnotnú aplikáciu iba Chrome na zariadeniach s Google Mobile Services a Samsung Internet na zariadeniach Samsung. Ostatné prehliadače vytvoria len skratku, ktorá web otvorí v prehliadači.
• iPhone a iPad. Na iOS 16.4 a novšom sa PWA podľa MDN inštaluje z menu Zdieľať. Vlastné tlačidlo inštalácie na webe iOS nepodporuje, používateľa teda treba naviesť. V iOS 26 a iPadOS 26 sa podľa blogu WebKit (15. 9. 2025) každá stránka pridaná na plochu predvolene otvára ako webová aplikácia, aj bez manifestu.
• Push notifikácie sú správy zo servera, ktoré zariadenie zobrazí, aj keď aplikácia nebeží. Apple na blogu WebKit 16. 2. 2023 oznámil, že iOS a iPadOS 16.4 prinášajú Web Push pre webové aplikácie pridané na plochu, push je teda podľa tohto oznámenia viazaný na tento krok. O povolenie možno podľa neho žiadať iba po priamej akcii používateľa.
• Práca na pozadí. Background Sync sa po obnovení pripojenia pokúsi úlohu dokončiť, ak ho prehliadač podporuje. Podľa MDN (13. 9. 2026) ju však možno zadať iba pri otvorenej aplikácii a prehliadače obmedzujú počet aj trvanie pokusov. Tichý push bez viditeľnej notifikácie podľa rovnakého zdroja nepodporuje žiadny prehliadač.
• Obchody. PWA sa podľa MDN dá zabaliť aj pre Google Play či App Store, bod 4.2 pravidiel Apple však vyžaduje viac než prebalený web.
• Regulačné riziko. Podľa TechCrunch (1. 3. 2024) Apple v betaverzii iOS 17.4 zredukoval PWA v EÚ na obyčajné skratky s odkazom na nariadenie o digitálnych trhoch (DMA) a po kritike ustúpil. Pracovný dokument útvarov Európskej komisie z 28. 4. 2026 uvádza, že Apple v podpore webových aplikácií na ploche pokračoval.

Náš výklad: PWA je na iOS použiteľná voľba, no jej hranice určuje Apple, tak ako hranice natívnej aplikácie určujú pravidlá obchodu. Platformové riziko má každá možnosť.

Interné nástroje verzus zákaznícke aplikácie

Na rozdiel od zákazníka privedie zamestnanca k internému nástroju proces: odkaz v intranete, firemné prihlásenie, záložka v prehliadači. Argument, že aplikácia musí byť v obchode, aby ju ľudia našli, tu odpadá.

Interné nástroje často obsluhujú formuláre, schvaľovanie a prehľady bez zvláštnych nárokov na hardvér. Výnimkou sú sklad, terén či výroba, kde je zariadenie pracovným nástrojom. Zmena na webe sa pritom k ľuďom dostane bez inštalácie aktualizácie. Žiadna platforma však nezachráni nástroj, ktorý ľuďom prácu komplikuje, ako sme písali v článku Najdrahší systém je ten, ktorý vaši ľudia nepoužívajú.

Modelové situácie

Situácie nižšie sú hypotetické a slúžia iba na ukážku uvažovania.

Terénny technik

Technici servisnej firmy zapisujú zákazky aj bez signálu. Ak stačí offline zápis a synchronizácia po návrate siete, PWA je rozumný pilot a testy na telefónoch technikov ukážu, či je synchronizácia spoľahlivá. Ak firma potrebuje priebežnú polohu počas celej zmeny alebo spojenie s meracím prístrojom cez Bluetooth, bezpečnejšia je multiplatformová alebo natívna aplikácia.

E-shop

Zákazník nakupuje niekoľkokrát do roka a prichádza cez vyhľadávač alebo newsletter. Aplikácia by pred nákup vložila inštaláciu a prihlásenie. Viac prinesie investícia do zrozumiteľnosti webu, lebo nejasnú ponuku aplikácia nevyrieši, ako rozoberáme v článku Keď zákazník nerozumie vášmu webu, platíte za návštevnosť, ktorú nevyužijete.

B2B objednávanie

Odberatelia veľkoobchodu opakovane objednávajú dlhé zoznamy položiek. Rozhodujú rýchle zopakovanie objednávky, import z tabuľky a napojenie na ERP, teda podnikový informačný systém. To zvládne webová aplikácia, no najprv overte, či nestačí B2B modul e-shopu alebo ERP, ktoré firma už má.

Vernostný program

Sieť kaviarní by najprv mala overiť, či vernostnú funkciu neponúka jej pokladničný systém. Strednou cestou je PWA s push notifikáciami, na iPhone až po pridaní na plochu. Natívna aplikácia má zmysel, keď pilot ukáže, že hostia program používajú často a brzdí ich práve tento krok.

Interný schvaľovací nástroj

Firma schvaľuje faktúry a dovolenky e-mailom. Najprv treba zrušiť schvaľovacie kroky, ktoré nič nekontrolujú, a overiť, či proces nepokryje už platený účtovný alebo personálny systém. Ak nie, stačí webová aplikácia s firemným prihlásením, prípadne PWA. Dve natívne aplikácie by tu pridali náklady na vývoj a vydávanie bez prínosu, ktorý by ich vyvážil.

Postupná cesta: web, meranie, až potom natívna aplikácia

Pre produkt bez jasnej natívnej požiadavky odporúčame postup v krokoch:

1. Prvá verzia ako web alebo PWA: jedna kódová báza, okamžité aktualizácie a rýchla odpoveď, či ľudia produkt chcú.
2. Meranie: ako často sa ľudia vracajú, z akých zariadení, koľkí si PWA nainštalovali a ktoré obmedzenia sa opakujú.
3. Prah stanovený vopred: vedenie určí, aký výsledok odôvodní natívnu aplikáciu. Bez neho sa rozhodnutie vráti k reflexu.
4. Natívna aplikácia tam, kde ju dáta odôvodnia, často len pre najaktívnejšiu skupinu.

Bežnou praxou je oddeliť serverovú časť s dátami a logikou a sprístupniť ju cez API, teda dohodnuté rozhranie na výmenu dát medzi programami. Natívna aplikácia sa potom napojí na rovnaké dáta a pravidlá a web ostane plnohodnotným kanálom, ako rozvádzame v článku Prémiový web nie je estetika. Je to obchodná infraštruktúra. Ak však od začiatku viete, že produkt stojí na funkcii, ktorú web nepokryje, postupná cesta je zbytočná obchádzka.

Kedy je natívna aplikácia správna voľba

• Produkt stojí na nepretržitej práci na pozadí, napríklad na sledovaní polohy počas celej zmeny. Service worker podľa MDN nebeží neustále, preto na to web podľa nás nestačí.
• Aplikácia pracuje do hĺbky s Bluetooth, USB, súbormi či kontaktmi, teda s oblasťami, ktoré Google uvádza medzi silnými stránkami natívnych aplikácií.
• Aplikácia je samotným produktom, ktorý ľudia používajú denne, a výkon je súčasťou jej hodnoty.

Aj vtedy najprv zvážte multiplatformový vývoj s jednou kódovou bázou. Samotnú otázku „mobilná aplikácia alebo webová aplikácia“ otvárajte až po presnom pomenovaní problému, používateľa a prostredia.

Čo si z toho zobrať

• Otázku „potrebujeme appku“ nahraďte otázkami: kto produkt používa, ako často, kde a čo musí zariadenie vedieť.
• Náklady počítajte za celý životný cyklus: každá natívna platforma pridáva kódovú bázu, schvaľovanie a testovanie, pri predaji digitálneho obsahu aj províziu obchodu.
• Tvrdenia o schopnostiach PWA si nechajte doložiť zdrojom s dátumom, najmä pri iOS, kde sa podmienky od roku 2023 viackrát zmenili.
• Pri interných nástrojoch začnite webom, natívnu aplikáciu zvažujte až pre terén, sklad alebo prácu s hardvérom.
• Pred prvou verziou si dohodnite merateľný prah, ktorý odôvodní natívnu aplikáciu.