Mobilní aplikace k existujícímu webovému produktu: Co převzít a co navrhnout znovu
Provozujete webovou aplikaci nebo klientský portál a zákazníci chtějí pohodlně pracovat i z telefonu. Mobilní rozšíření může využít stejné účty, data a část pravidel. Nejdřív ale potřebujete rozhodnout, které úkoly do telefonu patří, zda je stávající systém dokáže obsloužit a jak budou web s aplikací fungovat vedle sebe.
Představte si portál, ve kterém klienti schvalují návrhy a předávají připomínky. Na počítači spravují projekty, rozpočty a uživatele. Na telefonu potřebují otevřít aktuální podklad a rozhodnout. Tento modelový příklad nás provede návrhem mobilního klienta; nejde o popis měřeného zákaznického projektu.
01Co má mobilní aplikace přidat k fungujícímu webu
Začněte jednou dokončenou úlohou: klient se dostane k aktuální verzi návrhu, zkontroluje ji a schválí nebo připomínkuje. Sepište, co mu dnes v této cestě překáží. Může jít o obtížné dohledání projektu, nepohodlné porovnání podkladů nebo ztracený rozepsaný komentář. Samotný požadavek „chceme aplikaci“ takové zadání nenahrazuje.
Pro první verzi ponechte hromadné nahrávání dokumentů, správu rozpočtu a přidělování rolí na webu. Mobilní aplikace nemusí obsahovat celou administraci, aby byla užitečná. Musí ale jasně ukázat, kterou firmu, projekt a verzi podkladu má člověk právě otevřenou.
Jestli zatím potřebujete hlavně lépe použitelný web na telefonu, nejprve zvažte, kdy může stačit PWA. Zde už řešíme dalšího klienta existující služby. Jeho přínos formulujte jako dokončený úkol zákazníka a ověřte ho na prototypu, ještě než objednáte celé mobilní rozhraní.
02Co lze převzít: data, účty a obchodní pravidla
Sdílet produkt neznamená zkopírovat všechny obrazovky. V našem portálu mají web i telefon pracovat se stejným projektem a stejným schválením. Nemají vzniknout dvě oddělené evidence, které se následně složitě srovnávají. Rozhraní API zprostředkuje mobilní aplikaci přístup k serverové části, která kontroluje oprávnění a platnost změn.
| Část produktu | Co s ní udělat | Co ověřit |
|---|---|---|
| Projekty, dokumenty a historie | Zachovat společný zdroj dat. | Oba klienti používají stejné identifikátory a aktuální verze. |
| Účty a členství ve firmách | Navázat na existující identitu. | Přihlášení, přepínání firem a odebrání přístupu. |
| Pravidla schvalování | Udržovat společně na serveru. | Kdo smí schválit kterou verzi a kdy je rozhodnutí platné. |
| API a přihlašování | Prověřit a podle výsledku upravit. | Potřebné operace, chybové stavy a mobilní přihlášení. |
| Navigace a práce s podkladem | Navrhnout pro telefon. | Čitelnost, orientace, komentování a návrat k úkolu. |
Stejný e-mail ve dvou databázích ještě neznamená společný účet. Uživatel má mít jednu identitu, k ní přiřazená členství a oprávnění. Pokud patří ke dvěma firmám, aplikace musí bezpečně rozlišit jejich projekty. Skrytí tlačítka v telefonu nenahrazuje kontrolu přístupu na serveru.
Možné je i využití části webového kódu. Dokumentace Capacitoru popisuje přidání tohoto prostředí do existujícího webového projektu při splnění jeho technických předpokladů. Sama tato možnost ale neurčuje, zda současné ovládání dobře poslouží na telefonu.
03Co prověřit v API před začátkem vývoje
Věta „API už máme“ nestačí. Nechte dodavatele předvést celou budoucí mobilní cestu přes rozhraní, se kterým bude aplikace opravdu pracovat. V portálu to znamená přihlásit klienta, načíst jeho firmy, najít projekt, otevřít podklad a uložit rozhodnutí. Jeden chybějící krok může vyžadovat zásah do stávajícího systému.
- Úplnost: lze přes API provést všechny kroky první verze včetně zobrazení výsledku a potřebné historie?
- Oprávnění: ověřuje server přístup ke konkrétní firmě, projektu i dokumentu při každé operaci?
- Objem dat: načítá telefon potřebný přehled a náhled, nebo kvůli jedné položce stahuje celý archiv?
- Nejistý výsledek: co uživatel uvidí, když odešle schválení, ale kvůli výpadku nedostane odpověď?
- Změna podkladu: co nastane, když mezitím kolega nahraje novou verzi nebo odebere schvalovateli přístup?
U nejistého výsledku navrhněte možnost ověřit stav operace a bezpečně ji zopakovat bez druhého schválení či dvojitého upozornění. U změněného podkladu musí server poznat, ke které verzi se rozhodnutí vztahovalo. Klient pak dostane srozumitelnou výzvu k načtení aktuálního návrhu, místo aby potichu schválil něco jiného.
Přihlášení potřebuje vlastní kontrolu. Používáte-li OAuth, RFC 8252 pro nativní aplikace vyžaduje přihlášení přes externí prostředí, typicky prohlížeč, a u veřejných nativních klientů ochranu autorizačního kódu PKCE. Ověřte také návrat z přihlášení, vypršení relace a odebrání přístupu.
Výsledkem prověrky má být seznam použitelných operací, potřebných úprav, vlastníků změn a otevřených otázek. S tímto podkladem lze odhadnout práci. Samotný odkaz na dokumentaci API ještě nedokládá, že všechny potřebné cesty fungují.
04Co navrhnout znovu pro telefon
Na úvodní obrazovce portálu ukažte rozhodnutí čekající na klienta. Po otevření položky musí být vidět název projektu, verze návrhu a poslední změna. Dlouhou webovou tabulku nemusíte vměstnat na úzkou obrazovku. Můžete ji nahradit přehledem úkolů, ze kterého se člověk dostane přímo k podkladu.
Schválení patří až za kontrolu potřebných informací. Pokud dokument na telefonu nejde rozumně posoudit, nabídněte pokračování na webu u stejné položky. Vhodnost úkolu pro telefon neposuzujte podle toho, zda lze vykreslit tlačítko, ale zda uživatel vidí dost podkladů pro odpovědné rozhodnutí.
Navrhněte i přerušení: zazvoní telefon, aplikace přejde do pozadí, připojení se zhorší nebo uživatel omylem odejde. U rozepsaného komentáře určete, kde se ukládá a kdy se odstraní. Návrat z upozornění má vést ke správnému projektu, po případném přihlášení znovu ověřit přístup a načíst aktuální stav.
Pro první verzi můžete vyžadovat připojení pro schválení a zachovat pouze lokální koncept komentáře. Každý koncept přiřaďte ke konkrétnímu účtu, firmě, projektu a verzi dokumentu. Takové omezení sdělte předem. Pokud potřebujete dokončovat úkoly i bez sítě, rozšiřte zadání podle pravidel offline práce a synchronizace. Samotné uložení konceptu ještě není plnohodnotný offline režim.
05Jak udržet web a starší mobilní verze v souladu
Nasazení změny na server neaktualizuje všechny telefony. Část zákazníků bude používat starší aplikaci, i když web už pracuje s novou funkcí. Proto potřebujete předem dohodnout, které verze podporujete, jak poznáte nepodporovaný požadavek a jak uživatel bezpečně dokončí rozdělanou práci.
V našem příkladu přibude na webu možnost vrátit návrh k úpravě s povinným důvodem. Stará aplikace umí pouze schválit nebo přidat komentář. Pokud server začne vyžadovat nové pole i u původních operací, může rozbít dosud funkční postup. Neznámý stav navíc nesmí telefon chybně zobrazit jako schválení.
Obecný princip kompatibility popisují pravidla Google AIP-180: změny nesmějí bez odpovídajícího řešení porušit očekávání existujících klientů. Jde o vodítko pro návrh API, nikoli automatickou záruku kompatibility vašeho produktu.
- Oddělte novou operaci od původního schvalování, pokud lze staré chování bezpečně zachovat.
- Rozhodněte, jak starší klient zobrazí položku, se kterou neumí pracovat. Nabídněte srozumitelný přechod na web, pokud je tato cesta v dané verzi dostupná.
- Ověřte skutečnou podporovanou starší aplikaci proti novému serveru. Test nejnovějšího sestavení tento souběh nepokrývá.
- Když kompatibilitu zachovat nelze, připravte oznámený konec podpory, aktualizaci a postup pro rozpracovaná data.
Tato dohoda patří do provozu produktu. Určete, kdo posuzuje dopad serverových změn na mobil, kdo schvaluje vydání a kdo řeší hlášenou chybu. Změny webu a aplikace nemusí vycházet současně, musí však respektovat společná pravidla.
06Co ovlivní cenu a termín mobilního rozšíření
Při porovnání nabídek sledujte vedle počtu obrazovek také rozsah práce kolem stávajícího systému. Jedna nabídka může počítat s hotovým přihlášením a úplným API, druhá zahrnuje jejich opravy. Bez uvedených předpokladů se jejich ceny špatně porovnávají.
Vyžádejte si oddělený odhad pro prověrku produktu, úpravy serveru, mobilní rozhraní, testování souběhu a přípravu distribuce. Přidejte provoz po spuštění: hlášení chyb, podporované verze, aktualizace a odpovědnost za společné API. U neověřených částí označte nejistotu a krok, který ji odstraní.
Až znáte mobilní úkoly a technická omezení, dává smysl řešit nativní nebo multiplatformní vývoj. Univerzální procento úspory za „využití hotového webu“ nepomůže. Sdílený server může ušetřit práci, ale nepřipravené API nebo spletitá oprávnění mohou naopak vyžadovat podstatné změny.
07Jak spustit první mobilní verzi a převzít výsledek
Pilot připravte se současnými uživateli portálu, kteří skutečně schvalují podklady. Zahrňte i člověka s členstvím ve více firmách a uživatele s omezenými právy. Pokud ještě rozhodujete o zařízeních první skupiny, navazuje výběr první mobilní platformy.
| Přejímací scénář | Očekávaný výsledek |
|---|---|
| Klient se přihlásí existujícím účtem. | Vidí správné firmy a projekty, bez zakládání duplicitního profilu. |
| Na mobilu schválí aktuální návrh. | Web po načtení ukáže stejnou verzi, autora rozhodnutí a jeho čas. |
| Během prohlížení vznikne nová verze. | Starý podklad nelze omylem schválit jako nový; klient dostane vysvětlení. |
| Odpověď serveru se po schválení ztratí. | Lze zjistit skutečný stav a opakovat pokus bez duplicitního rozhodnutí. |
| Správce odebere členství ve firmě. | Další požadavek na její data je odmítnut, i když mobil stále zobrazuje starou obrazovku. |
| Nový server obsluhuje starší aplikaci. | Dohodnuté operace fungují a nepodporovaný krok má srozumitelné řešení. |
Před pilotem určete, co budete sledovat: dokončení schválení, ztracené koncepty, nejasné výsledky odeslání a potřebu pomoci podpory. Počet instalací sám neřekne, zda se zákazníkům pracuje lépe. Neúspěšný scénář musí mít vlastníka a rozhodnutí, zda brání rozšíření pilotu.
Distribuce je další pracovní část. Apple v pravidle 4.2 požaduje užitek přesahující přebalený web. To není obecný zákaz webových technologií ani příslib schválení. Připravte skutečně použitelnou mobilní cestu a počítejte s kontrolou podmínek obchodů.
08Časté otázky k mobilní aplikaci pro existující web
Lze převést webovou aplikaci na mobilní bez přepsání celého systému?
Často lze využít serverovou část, data a některé části kódu. Rozhoduje jejich stav a zamýšlená mobilní práce. Nejdřív prověřte jednu celou uživatelskou cestu, potom určete, co zachovat, upravit a navrhnout znovu. Univerzální převod jedním klikem tento návrh nenahrazuje.
Mohou uživatelé na webu i v aplikaci používat stejný účet?
Ano, pokud oba klienti navazují na společnou identitu a stejná oprávnění. Ověřit musíte i členství ve více firmách, přihlášení po vypršení relace a odebrání přístupu. Shodný e-mail sám o sobě propojení nezajišťuje.
Projeví se každá změna webu automaticky v mobilní aplikaci?
Ne. Sdílená data se mohou projevit po načtení, změna mobilního rozhraní obvykle vyžaduje jeho aktualizaci. Záleží na architektuře. Server musí počítat také s podporovanými staršími klienty a předem stanoveným postupem pro nekompatibilní změny.
09Zdroje
Technické podklady ověřeny 6. 11. 2026: Capacitor, IETF RFC 8252, Google AIP-180 a Apple App Review Guidelines, 4.2. Rozdělení funkcí a přejímací scénáře jsou návrhem pro uvedený modelový portál.