Aktualizace mobilní aplikace po spuštění: jak řídit verze, aby vás Apple ani Google nezaskočili

01Krátká odpověď: co aplikace po spuštění potřebuje

Pro představu, jak to dělají nejúspěšnější aplikace: podle průběžné statistiky 42matters z 27. září 2026 vydá aspoň jednou týdně novou verzi 47 % z 1 000 aplikací s nejvíce hodnoceními v App Store a 39 % v Google Play. Aspoň jednou za rok aktualizuje 98 %, respektive 97 % z nich.

Menší firemní aplikace tak často vydávat nemusí. Počítejte ale s tím, že i aplikace, na které se zrovna nic nevyvíjí, potřebuje několik aktualizací ročně, aby zůstala v obchodech a fungovala na nových telefonech.

02Proč aplikace bez aktualizací přestane fungovat

Oba obchody mají pravidla, která zastaralé aplikace postupně vytlačují. Důvod je praktický: nové verze systémů lépe chrání soukromí a bezpečnost a obchody chtějí, aby to aplikace využívaly.

Google Play: každý rok 31. srpna nová cílová verze Androidu

Od 31. srpna 2026 musí nové aplikace i aktualizace pro telefony a tablety cílit na Android 16 (API úroveň 36). Kdo potřebuje víc času, může požádat o odklad do 1. listopadu 2026. Pravidlo se posouvá každý rok: v roce 2023 platila úroveň 33, v roce 2024 úroveň 34 a v roce 2025 úroveň 35 (Google Play).

Stávající aplikace mají mírnější laťku, ale i ta roste. Aplikaci, která necílí aspoň na Android 15 (API 35), v obchodě dál najdou ti, kdo ji už mají, a lidé se starším Androidem. Noví uživatelé s novějším Androidem, než na jaký aplikace cílí, ji nenajdou a Google Play jim napíše, že aplikace byla vytvořená pro starší verzi Androidu. Pro firmu to znamená méně stažení, často aniž by si toho ve firmě někdo všiml.

Cílová verze není jen číslo v nastavení. Každá nová úroveň mění, jak se aplikace chová: jaká oprávnění musí žádat, co smí dělat na pozadí nebo jak vypadají notifikace. Proto je potřeba po jejím zvýšení aplikaci znovu otestovat.

Apple: nové Xcode každé jaro a minimální iOS 13

Od 28. dubna 2026 přijímá App Store Connect jen aplikace sestavené v Xcode 26 nebo novějším se sadou SDK pro iOS 26. Předchozí požadavky platily od 25. dubna 2023 a od 29. dubna 2024, rytmus je tedy podobný jako u Googlu, jen na jaře. Od 9. září 2026 navíc musí každé sestavení nahrané do App Store Connect, i aktualizace, podporovat jako nejstarší verzi aspoň iOS 13 (tzv. deployment target) (Apple).

Apple také průběžně odstraňuje opuštěné aplikace. Týká se to aplikací, které tři roky nikdo neaktualizoval a za posledních 12 měsíců je skoro nikdo nestáhl. Vývojář dostane e-mail a 90 dní na novou verzi, jinak aplikace z App Store zmizí, dokud ji neaktualizuje. Aplikace, která padá hned po spuštění, jde pryč okamžitě. Stávajícím uživatelům ale aplikace funguje dál (Apple).

03Jaké verze iOS a Androidu mají lidé v Česku

Než se rozhodnete, které verze systémů bude aplikace podporovat, podívejte se, co lidé skutečně používají. Nejlepší veřejně dostupný zdroj pro Česko je StatCounter, který měří návštěvy webů. Neukazuje tedy počet telefonů, ale pro odhad poměrů stačí.

V srpnu 2026 připadalo v Česku 69,4 % mobilních návštěv na Android a 30,5 % na iOS (StatCounter). Zajímavější je, jak rozdílně se oba systémy aktualizují. Z iPhonů v Česku přichází 82,6 % návštěv z některé verze iOS 26. Android 16 je jen u 28,2 % návštěv z Androidu (novější Android 17 zatím pod 1 %) a skoro čtvrtina (24,8 %) přichází z Androidu 12 nebo staršího.

Apple zveřejňuje vlastní čísla za celý svět. K 7. červnu 2026 mělo iOS 26 nainstalováno 86 % iPhonů uvedených na trh za poslední čtyři roky a 79 % všech iPhonů (Apple). Google podobný přehled verzí Androidu veřejně nevydává, vývojáři ho vidí jen pro vlastní aplikaci v Google Play Console.

Co z toho plyne pro praxi: u iOS stačí obvykle podporovat aktuální a předchozí hlavní verzi. U Androidu musí aplikace počítat se čtyřmi až pěti verzemi systému a s mnoha výrobci telefonů. Pokud aplikaci stavíte v React Native a Expo, minimum za vás částečně určí nástroje: aktuální Expo SDK 57 podporuje iOS 16.4 a novější a Android 7 a novější (Expo). O rozdílech mezi nativním a multiplatformním vývojem jsme psali v článku Nativní aplikace vs. multiplatformní vývoj.

04Číslo verze: co znamená 2.4.1 a proč jsou čísla dvě

Každá verze aplikace má ve skutečnosti dvě čísla. Číslo verze vidí uživatel v obchodě, třeba 2.4.1. Číslo sestavení (build) je interní a musí s každým nahráním do obchodu růst. V iOS se jim říká CFBundleShortVersionString a CFBundleVersion, v Androidu versionName a versionCode.

U Androidu je číslo sestavení přísné: Google Play nepřijme versionCode, který už aplikace jednou použila, a systém nedovolí nainstalovat verzi s nižším číslem přes vyšší. Nejvyšší povolená hodnota je 2 100 000 000 (Android Developers). Kdo čísla generuje z data a času, musí si ohlídat, aby se do limitu vešla.

Pro číslo verze se nejčastěji používá sémantické verzování (semver) ve tvaru HLAVNÍ.VEDLEJŠÍ.OPRAVA. Pravidla na semver.org jsou napsaná pro knihovny a rozhraní, u aplikací se ale ujala ve zjednodušené podobě: poslední číslo pro opravy, prostřední pro nové funkce, první pro velké změny.

K číslu verze patří i text „Co je nového“. V App Store má limit 4 000 znaků a u první verze se nevyplňuje, v Google Play je to 500 znaků na jazyk a nesmí sloužit k propagaci. Apple navíc nabízí propagační text do 170 znaků, který jde změnit kdykoli bez nové verze (Apple, Google Play). Pište ho pro lidi: co se zlepšilo a co opravilo, ne „drobné opravy a vylepšení“ u každé verze.

05Testování před vydáním: TestFlight a testovací kanály Google Play

Každá verze by měla projít rukama skutečných lidí na skutečných telefonech dřív, než ji dostanou všichni. Oba obchody na to mají vlastní nástroje zdarma.

• TestFlight (Apple): až 100 interních testerů z vašeho týmu a až 10 000 externích, které pozvete e-mailem nebo odkazem. Sestavení je dostupné 90 dní. První sestavení pro externí testery musí schválit Apple, další už plnou kontrolou projít nemusí (Apple).
• Interní testování (Google Play): až 100 testerů, nová verze je u nich během několika minut (Google Play).
• Uzavřené a otevřené testování (Google Play): uzavřené pro vybrané lidi podle e-mailů, otevřené pro kohokoli, kdo se přihlásí. Zpětná vazba testerů neovlivní veřejné hodnocení aplikace.

Pozor na jednu past při zakládání účtu. Kdo si v Google Play založil osobní vývojářský účet po 13. listopadu 2023, musí před prvním vydáním provést uzavřený test s aspoň 12 testery, kteří jsou přihlášení nepřetržitě 14 dní. Dříve to bylo 20 testerů, takže starší návody nesedí. Účtů vedených na firmu (organizaci) se povinnost netýká (Google Play). Firemní aplikaci proto zakládejte na firemní účet, ušetříte si dva týdny i starosti s vlastnictvím.

Na vlastnictví účtů myslete od začátku. Pokud vývojářské účty a přístupy drží jen dodavatel, jakákoli aktualizace záleží na něm. Jak to napravit, když už se to stalo, popisujeme v článku Jak převzít web od dodavatele, postup platí obdobně i pro aplikace.

06Postupné vydání: jak nepokazit aplikaci všem najednou

Ani důkladné testování neodhalí všechno. Proto se nové verze nevydávají všem uživatelům naráz, ale postupně. Když se objeví problém, zasáhne jen malou část lidí a vydávání se dá zastavit.

App Store: sedm dní, od 1 % po všechny

Apple nabízí fázované vydání (phased release), které rozloží aktualizaci do sedmi dní. První den ji dostane 1 % uživatelů s automatickými aktualizacemi, sedmý den všichni. Vydávání můžete pozastavit, dohromady nejvýš na 30 dní, nebo naopak kdykoli pustit aktualizaci všem (Apple).

Jedna věc se často přehlíží: fázování se týká jen automatických aktualizací. Kdo v App Store klepne na „Aktualizovat“ ručně, dostane novou verzi hned. Fázované vydání tedy snižuje riziko, ale nezaručuje, že chybnou verzi uvidí jen 1 % lidí.

Google Play: procenta volíte sami

V Google Play určujete podíl uživatelů sami a sami ho musíte zvyšovat, automaticky neroste. Začít můžete i jen v několika zemích. Když se objeví chyba, vydávání zastavíte, ale vrátit se ke starší verzi nejde: kdo novou verzi dostal, zůstane na ní. Oprava znamená vydat další verzi s vyšším číslem sestavení (Google Play).

Jak to vypadá ve velkém, ukazuje Spotify. Novou verzi aplikace vydává každý týden, nejdřív malé části uživatelů a druhý den všem. Při vážné chybě vydávání zastaví a připraví opravu. Tímto postupem se ke všem uživatelům dostane přes 95 % verzí, zbytek Spotify zruší a změny počkají na další týden (Spotify Engineering).

Jak dlouho trvá schválení

Apple uvádí, že v průměru 90 % žádostí posoudí do 24 hodin. Při kritické chybě můžete požádat o urychlené posouzení (Apple). Google zpracovává aktualizace co nejdříve, u některých účtů a aplikací ale kontrola trvá až 7 dní, výjimečně i déle. Užitečná je funkce řízeného publikování, kdy si po schválení sami určíte, kdy se změny zveřejní (Google Play). S rezervou počítejte hlavně u verzí navázaných na termín, třeba na kampaň nebo změnu ceníku.

07Pády a stabilita: co sledovat po vydání

Po vydání verze začíná nejdůležitější část: měřit, jestli se aplikace u lidí chová tak, jak má. Nástroje jako Sentry nebo Firebase Crashlytics zachytí každý pád i s informací o telefonu, verzi systému a kroku, při kterém nastal.

Google sleduje stabilitu aplikací sám a má pevně dané hranice. Pokud pád zaznamená víc než 1,09 % uživatelů denně v průměru přes všechna zařízení, nebo víc než 8 % uživatelů na jednom modelu telefonu, může Google aplikaci v obchodě méně ukazovat a na její stránce zobrazit varování. U zamrznutí aplikace (ANR) je hranice 0,47 %. Google hodnotí posledních 28 dní a od února 2027 může viditelnost ovlivnit i spotřeba paměti (Android Developers).

Pro srovnání: podle dat firmy Instabug (dnes Luciq) za rok 2024 měl medián aplikací, které používají její nástroj, 99,95 % relací bez pádu. Horší čtvrtina aplikací měla 99,77 % nebo méně, lepší čtvrtina 99,99 % nebo víc (Luciq). Rozdíl několika desetin procentního bodu vypadá nevinně, v počtu pádů je ale velký: zhruba 23 proti 1 pádu na 10 000 relací.

Stabilita se promítá do hodnocení. Google už v roce 2019 uvedl, že 42 % lidí, kteří dají aplikaci jednu hvězdičku, zmiňuje nestabilitu nebo chyby. Ve stejném článku Google uvedl, že když vývojář na recenzi odpoví, uživatel hodnocení v průměru zvýší o 0,7 hvězdičky (Android Developers Blog). Odpovídat na recenze po každé verzi se tedy vyplatí.

Pozor, pád nemusí způsobit jen vaše nová verze. V květnu a v červenci 2020 shodila změna na serverech Facebooku aplikace pro iPhone, které používaly jeho vývojářskou knihovnu (Facebook SDK), mezi nimi Spotify nebo Pinterest (GitHub). Proto je dobré sledovat pády i mezi vydáními, ne jen pár dní po nich.

08Jak přimět uživatele k aktualizaci a kdy ji vynutit

Novou verzi mít v obchodě nestačí, musí se dostat k lidem. Podle průzkumu ESET a Ipsos z prosince 2024 aktualizují Češi aplikace nejčastěji, když je k tomu vyzve systém (35 %). Automaticky se aktualizace stahují 31 % uživatelů a 25 % si je kontroluje samo (ESET). Na iPhonech jsou automatické aktualizace aplikací ve výchozím stavu zapnuté, uživatel je ale může vypnout (Apple).

Vždy tedy zůstane skupina lidí na staré verzi. Aplikace i server s tím musí počítat: když změníte rozhraní serveru, staré verze aplikace musí fungovat dál, dokud je lidé používají. Teprve když stará verze fungovat nemůže, přichází na řadu vynucená aktualizace.

• Android: Google nabízí funkci aktualizací v aplikaci (In-App Updates) ve dvou podobách. Flexibilní stáhne aktualizaci na pozadí a uživatel pokračuje v práci. Okamžitá zobrazí celou obrazovku a bez aktualizace dál pustit nejde. Každé verzi můžete přiřadit prioritu 0 až 5 (Android Developers).
• Google Play Console: umí navíc vyzvat uživatele staré nebo chybné verze k aktualizaci i bez zásahu do kódu, pokud aplikace používá Play App Signing a vychází jako Android App Bundle (Google Play).
• iOS: podobnou funkci Apple nemá. Aplikace si při spuštění zjistí ze serveru minimální podporovanou verzi, a pokud je nainstalovaná verze starší, zobrazí výzvu s odkazem do App Store.

Vynucenou aktualizaci používejte střídmě. Kdo ji uvidí po každé drobnosti, bere ji jako otravnou překážku. Google sám doporučuje u drobných změn vzhledu nevyžadovat nic, u zlepšení výkonu nabídnout flexibilní aktualizaci a okamžitou si nechat pro kritické bezpečnostní opravy.

09Aktualizace bez schvalování: OTA a vzdálené přepínače

U aplikací v React Native lze část změn doručit přímo do telefonu bez nového schvalování v obchodě. Říká se tomu aktualizace OTA (z anglického over the air), v ekosystému Expo ji zajišťuje služba EAS Update. Umí vyměnit JavaScript, styly a obrázky. Nové nativní knihovny, změny oprávnění ani přechod na novější Expo SDK tak doručit nejde, na ty je potřeba nové sestavení (Expo).

Apple to připouští jen s podmínkami. Licenční smlouva pro vývojáře v článku 3.3.1(B) povoluje stahovat interpretovaný kód, pokud nemění hlavní účel aplikace, neobchází zabezpečení systému a nevytváří obchod s dalšími aplikacemi. Pravidla App Store v bodě 2.5.2 zakazují stahovat kód, který přidává nebo mění funkce (Apple). V praxi se OTA hodí na rychlé opravy chyb a textů. Nové funkce patří do běžné verze se schválením.

Pokud jste dřív používali Microsoft CodePush, služba App Center skončila 31. března 2025. Microsoft zveřejnil verzi CodePush k provozu na vlastním serveru (Microsoft Learn).

Druhým nástrojem jsou vzdálené přepínače (feature flags). Nová funkce je v aplikaci schovaná a zapnete ji na serveru, klidně jen pro část uživatelů. Když se něco pokazí, funkci vypnete bez nové verze. Takto podle svého popisu z roku 2017 pracuje třeba Meta, která funkce vydává odděleně od verzí aplikace (Engineering at Meta). Přepínače ale přidávají do kódu složitost, a proto je potřeba ty nepotřebné průběžně mazat (martinfowler.com).

Pro menší aplikace stačí Firebase Remote Config. Od 1. září 2026 už ale není bez omezení zdarma: zdarma je do 100 000 načtení konfigurace denně na projekt, nad tento limit se platí 0,06 USD za 10 000 načtení, tedy asi 1,30 Kč (Firebase). Do vzdálené konfigurace nepatří hesla ani jiné tajné údaje.

10Co říká zákon o aktualizacích

Pokud aplikaci nabízíte spotřebitelům za peníze nebo výměnou za jejich osobní údaje, máte ze zákona povinnost dodávat aktualizace, které aplikace potřebuje, aby fungovala bez vad. Jde o povinnost firmy vůči jejím zákazníkům. Co musí dodat vývojářská agentura firmě, určuje smlouva o dílo.

Občanský zákoník, § 2389d

Poskytovatel digitálního obsahu musí zajistit ujednané aktualizace a také ty, které jsou nezbytné, aby byl obsah bez vad, a na jejich dostupnost uživatele upozornit. U předplatného to platí po celou dobu smlouvy, u jednorázového prodeje tak dlouho, jak to uživatel může rozumně očekávat (§ 2389f). Pravidla platí od 6. ledna 2023 a týkají se i aplikací „zdarma“, za které uživatel platí svými osobními údaji, pokud je firma nezpracovává jen kvůli provozu aplikace nebo zákonným povinnostem (§ 2389g). Pokud uživatel aktualizaci v přiměřené době neprovede, nemá práva z vady, která vznikla jen kvůli tomu, ovšem jen když byl na aktualizaci a důsledky upozorněn (zákony pro lidi).

Připravovaná novela zákona o ochraně spotřebitele

Evropská směrnice 2024/825 měla v členských státech platit od 27. září 2026. Mimo jiné zavádí povinnost informovat před nákupem, jak dlouho budou bezplatné aktualizace k dispozici, pokud tento údaj výrobce nebo poskytovatel obchodníkovi sdělí. V Česku k 28. září 2026 novela schválená není, sněmovní tisk 53 čeká na třetí čtení (Poslanecká sněmovna).

Nařízení o kybernetické odolnosti (CRA)

Mobilní aplikace, kterou firma nabízí v rámci podnikání, i zdarma, je produkt s digitálními prvky. Výrobcem je i firma, která si aplikaci nechala vyvinout a nabízí ji pod svým jménem. Od 11. září 2026 platí povinnost hlásit aktivně zneužívané zranitelnosti (včasné varování do 24 hodin, oznámení do 72 hodin). Od 11. prosince 2027 budou platit hlavní povinnosti: doba podpory zpravidla aspoň pět let (kratší jen u produktu, který se má používat kratší dobu), bezpečnostní aktualizace zdarma, a pokud to jde, odděleně od funkčních (Evropská komise).

Zákon o požadavcích na přístupnost (424/2023 Sb.)

Od 28. června 2025 se týká mimo jiné mobilních aplikací e-shopů a finančních služeb, mikropodniky jsou vyjmuté. Výjimka pro starý obsah platí jen tehdy, když se po tomto datu neaktualizuje. Pokud se na vaši aplikaci zákon vztahuje, musí tedy přístupnost splňovat každá nová verze (zákony pro lidi).

Konkrétní povinnosti vaší aplikace posuďte s právníkem. Z pohledu vývoje z toho ale plyne jednoduchá věc: plán aktualizací a přehled o tom, kdo za ně odpovídá, patří do smlouvy už při zadání aplikace. Víc o zabezpečení dat v aplikacích a systémech na míru najdete v článku Bezpečnost dat v systému na míru.

11Plán údržby: s čím počítat každý rok

Na internetu se často uvádí, že údržba aplikace stojí ročně 15 až 20 % ceny vývoje. Toto číslo se obvykle připisuje analytickým firmám, dohledatelný zdroj ale nemá. Spolehlivější je sestavit rozpočet z konkrétních položek:

1. Jaro: přechod na nové Xcode. Apple ho v posledních letech vyžadoval vždy koncem dubna, termín pro rok 2027 zatím neoznámil. Zároveň kontrola knihoven a aktualizace Expo SDK nebo nativních závislostí.
2. Léto: zvýšení cílové verze Androidu do 31. srpna a otestování změn chování, které nová úroveň přináší.
3. Před vydáním nových verzí iOS a Androidu: otestovat aplikaci na betaverzích systémů a opravy vydat nejpozději v den, kdy nový systém vyjde.
4. Průběžně: sledování pádů a hodnocení, odpovědi na recenze, bezpečnostní opravy knihoven a drobné opravy.
5. Podle plánu rozvoje: nové funkce, ideálně v pravidelném rytmu, třeba jednou za dva až čtyři týdny, aby se opravy a novinky nehromadily.
6. Jednou ročně: kontrola minimální podporované verze systémů podle statistik vlastní aplikace, obnovení vývojářských účtů (Apple Developer Program se platí ročně) a revize přístupů.

Připočtěte i provozní náklady mimo vývoj: server a databázi, nástroje na sledování pádů, případně placené limity služeb jako Firebase. Pokud aplikace vydělává v obchodě, zohledněte provize Applu a Googlu, které jsme rozebrali v článku Jak vydělat na mobilní aplikaci.

12Nejčastější chyby po spuštění

• Vývojářské účty na jméno dodavatele. Když spolupráce skončí, nemáte jak vydat ani opravu.
• Termín obchodu se řeší až po jeho uplynutí. Oprava kritické chyby pak čeká na přechod na novou cílovou verzi Androidu nebo nové Xcode.
• Aktualizace všem najednou. Bez postupného vydání zasáhne chyba všechny uživatele během pár hodin.
• Změna serveru bez ohledu na staré verze. Uživatelé, kteří neaktualizovali, najednou vidí chybu a píšou jednohvězdičkové recenze.
• Vynucená aktualizace kvůli drobnostem. Lidé si na výzvy zvyknou a přestanou je brát vážně, nebo aplikaci smažou.
• Žádné měření pádů. O problému se dozvíte z recenzí, tedy pozdě.
• Poznámky k verzi „drobné opravy“. Promarněná šance ukázat uživatelům, že se aplikace zlepšuje.

13Časté otázky

14Závěr: aktualizace patří do plánu od prvního dne

Aplikaci v obchodě je potřeba udržovat podobně jako web. Už v rozpočtu a ve smlouvě s vývojáři si ujasněte, kdo hlídá termíny Applu a Googlu, kdo sleduje pády, jak rychle se opravují chyby a na čí jméno jsou vývojářské účty.

Pokud aplikaci teprve chystáte, podívejte se, jak u nás vývoj probíhá a kolik stojí. Když už aplikaci máte a nevíte, v jakém je stavu, začněte kontrolou cílové verze Androidu, verze Xcode a toho, kdo má přístup k vývojářským účtům.

15Zdroje

• Google Play: požadavky na cílovou úroveň API
• Google Play: požadavky na testování u nových osobních účtů
• Google Play: testovací kanály
• Google Play: postupné vydávání
• Google Play: publikování a kontrola aplikací
• Google Play: výzva k aktualizaci
• Android Developers: číslování verzí
• Android Developers: aktualizace v aplikaci
• Android Developers: Android vitals
• Apple: nadcházející požadavky
• Apple: odstraňování zastaralých aplikací
• Apple: fázované vydání
• Apple: TestFlight
• Apple: App Review
• Apple: podíl verzí iOS
• Apple: licenční smlouva pro vývojáře
• Semantic Versioning 2.0.0
• Expo: EAS Update
• Firebase: ceník
• StatCounter: verze Androidu v Česku
• StatCounter: verze iOS v Česku
• 42matters: frekvence aktualizací v App Store
• Luciq: Mobile App Stability Outlook
• Spotify Engineering: jak vydáváme aplikaci Spotify
• ESET: průzkum o zabezpečení smartphonů
• Evropská komise: Cyber Resilience Act
• Poslanecká sněmovna: sněmovní tisk 53