Programování pro iOS - 11. Jak dostat aplikaci do libovolného iPhone - MujMAC.cz - Apple, Mac OS X, Apple iPod

Navigace:  » Úvodní stránka  » Rubriky  » Software  

13. října 2010, 00.00 | Už minule jsme viděli, že distribuce aplikace na zařízení betatesterů není nic jednoduchého. To ale není pořád nic proti tomu, čím se budeme muset prokousat dnes, kdy si budeme povídat o instalaci aplikací na AppStore.

Předpokládáme, že aplikace sama je hotová a otestovaná; v podstatě nic dalšího už s ní dělat nemusíme. Je asi vhodné přidat aplikační ikonu ve dvojnásobném rozlišení pro iPhone 4: podle některých zkušeností dokonce bez ní v současnosti AppStore aplikaci nepřijme (vizte diskusi u předminulého článku). Podle dokumentace by měla být rozhodně nepovinná; pravdou ale je, že ve správě ikon má Apple nebetyčný zmatek (vizte např. zde), a mnohdy explicitní doporučení z dokumentace nefungují.

Tak či onak, ať již je ikona ve velkém rozlišení povinná nebo ne, je rozhodně vhodné ji do aplikace přidat: nestojí nás to prakticky nic navíc, a uživatelé nových iPhonů budou spíše ochotni koupit aplikaci, která na jejich hlavní obrazovce vypadá dobře.

My se podporou různých ikon (a dalších podpůrných grafických prvků, především tedy obrázků, jež iOS ukazuje uživateli po dobu spouštění aplikace) budeme zabývat podrobně až později; prozatím se spokojíme s jednoduchým a efektivním trikem, který firma Apple zavedla spolu s displejem Retina. Kdykoli (pomocí standardních služeb aplikačních knihoven) načítáme obrázek podle jména, iOS se na iPhone 4 (resp. na libovolném zařízení, které má displej s dvojnásobným rozlišením) nejprve pokusí načíst obrázek jméno@2x.přípona; teprve pokud se to nepodaří, použije ten původní.

Funguje to i pro aplikační ikony; prostě tedy sestavíme novou ikonu ve dvojnásobném rozlišení, a uložíme ji do projektu (a nezapomeneme ji přidat také do cíle) pod jménem "".

Ještě můžeme ověřit, že jako "Base SDK" je zvoleno "iOS Device N" (kde N záleží na instalované verzi SDK, v současnosti typicky 4.0 nebo 4.1) – jde o to, že rozevírací nabídka v levém horním rohu okna sice umožní kdykoli přepnout mezi SDK "Simulator" a "Device", jenže Simulator podepisuje kód poněkud odlišným způsobem. "Base SDK" se nastavuje v inspektoru projektu v záložce "General"; pro konkrétní cíl a/nebo konfiguraci je lze změnit ve skupině "Architectures" záložky "Build" odpovídajícího inspektoru, ale k tomu je jen málokdy důvod.

Když už jsme v záložce "Build", ověříme nastavení "iOS Deployment Target" na konci skupiny "Deployment": zde musí být uvedena minimální verze systému, na níž má aplikace fungovat (tj. např. pro systém 3.1 a vyšší vyvíjíme s "Base SDK" 4.x, ale "iOS Deployment Target" 3.1).

Nakonec ještě ověříme, že máme aktivní konfiguraci "Release" (Apple v dokumentaci místy doporučuje pro sestavování aplikací pro AppStore založit novou konfiguraci jako kopii "Release"; kdo chce, ten to tak dělat samozřejmě může, ale v praxi je to většinou zbytečné), a že máme zapnutou volbu "Validate Built Product" na konci skupiny "Build Options" – díky tomu Xcode odhalí některé nekonzistence, s nimiž bychom jinak mohli mít problém později na AppStore (např. špatnou velikost ikony; kompletní seznam testů nikde, pokud vím, zdokumentován není).

Jak s podpisem

Pro podpis ovšem potřebujeme distribuční profil specializovaný pro AppStore, podepsaný pomocí distribučního certifikátu. V podstatě obojí již známe z minulého dílu: distribuční certifikát jsme si tam sestavili pro distribuci ad-hoc (a pro distribuci přes AppStore jej můžeme použít stejně dobře), a profil sice musíme udělat nový – ten ad-hoc pro tento případ použít nejde –, ale postup je dávno známý a od toho, co jsme si ukázali minule, se liší pouze tím, že v položce "Distribution Method" zvolíme "App Store" a nikoli "Ad Hoc". Pokud naše aplikace nepotřebuje žádné specifické služby (jako je podpora in-app purchase, přístup ke keychainům, podpora GameCenter apod.), lze použít univerzální profil s "hvězdičkovým" identifikátorem, stejně, jak jsme si to ukázali hned u vývoje.

Samozřejmě, toto opět musí udělat "Team Agent"; cílovou verzi aplikace pro upload podepsanou distribučním certifikátem s profilem pro AppStore pak může sestavit buď sám, nebo to může nechat na některém vývojáři, jemuž ovšem musí zaslat jak profil, tak i certifikát a odpovídající privátní klíč (i to jsme si ukázali podrobně minule pro distribuci ad-hoc, a zde je tomu naprosto stejně).

Pozor: přinejmenším v současném Xcode 3.2.4 je třeba tento profil nastavit přímo pro build, v inspektoru cíle ve skupině "Code Signing", již známe už z předminulého dílu (kde jsme ovšem volili certifikát a profil vývojářský; nyní nastavíme ten distribuční pro AppStore):

Služba "Validate" totiž nedokáže – zjevně vinou nějaké chyby – sestavenou aplikaci korektně "přepodepsat"; k tomu se ale ještě vrátíme později, až si o této službě budeme bavit (pokud bychom ji nebo dokonce "Submit Application to iTunes Connect..." zkusili hned teď, nestane se zhola nic).

Mimochodem, vypadá vaše nabídka pro volbu profilu úplně jinak nežli ta na minulém obrázku, nejsou v ní vůbec šedé profily, ale jen černé certifikáty? Vraťte se k minulému odstavci, a tentokrát doopravdy přepněte Base SDK na "Device".

Po nastavení správného profilu spustíme Build & Archive.

Jakmile tedy máme aplikaci zbuildovanou a podepsanou, můžeme ji odeslat na AppStore?

Ale kdež. To by bylo příliš snadné, logické, a tudíž nemožně zastaralé.

Nejprve se musíme důkladně seznámit s dalším webovým portálem, s aplikací "iTunesConnect".

iTunesConnect

Pod tímto poněkud neintuitivním názvem se skrývá rozsáhlý webový portál s řadou funkcí, jež všechny tak či onak souvisí s AppStore a presentací aplikací jeho prostřednictvím – včetně doplňkových služeb, jako je in-app purchase, iAd apod. Ačkoli místy se působnost této aplikace s nám již známou "iOS Provisioning Portal" mírně překrývá, obecně platí, že aplikace "iOS Provisioning Portal" slouží pro vlastní vývoj, kdežto portál iTunesConnect na adrese itunesconnect.apple.com je zaměřen na obchodní záležitosti.

Stejně jako tomu je u aplikace "iOS Provisioning Portal", i do portálu iTunesConnect se uživatelé hlásí pomocí vlastního "apple id" a hesla; práva jsou jim ale přidělována samostatně a nezávisle. Je tedy možné, aby jeden uživatel (či přesněji "jedno apple id") měl přístup pouze do jedné z obou aplikací a ne do druhé. Jen hlavní zástupce firmy – nám již známý "Team Agent" – má v obou plná práva, včetně možnosti přidělovat přístupová práva ostatním.

Aplikace iTunesConnect nabízí poměrně hodně samostatných služeb, a přístup k nim z různých uživatelských rolí je dost komplikovaný; nebudeme si je zde zdaleka popisovat všechny, ale soustředíme se jen na to nejhlavnější pro možnost základního prodeje aplikací v AppStore. Jen pro ilustraci, mezi službami portálu iTunesConnect, kterými se zatím zabývat nebudeme, je i přehled prodejů (mimochodem neobyčejně mizerný a nepřehledný), informace o "kontu" firmy a jeho stavu (peníze se neposílají hned po nákupu, ale teprve poté, kdy celková sumu převýší určitou hranici), možnost vyžádat si reklamní kódy pro získání aplikace zdarma (to funguje ovšem jen v AppStore USA), apod.

Kontrakty, banky, ceny...

Pokud se nechceme spokojit s šířením aplikací zdarma, musíme nejprve v portálu

• získat smlouvu s Apple a formálně ji uzavřít;

• určit bankovní spojení na vlastní firmu, kontaktní detaily apod.

Smlouvy generuje aplikace iTunesConnect v samostatné skupině služeb "Contracts, Tax, & Banking Information" – ano, na daně také dojde; taková už je doba. Nalezneme zde automaticky přijatou smlouvu stran šíření aplikací zdarma (její podmínky byly přijaty již tím, že jsme si vytvořili vývojářské konto u Apple), a možnost vyžádat si další smlouvy pro šíření placených aplikací, pro využívání systému iAd apod. Jen základní kontrakt pro šíření placených aplikací má 17 stran poměrně drobného písma...

Pro smlouvu je zapotřebí specifikovat detailní informace o firmě, bankovní spojení, a daňové informace – v našem případě to bývá poměrně jednoduché, ale jen řada odkazů typu "toto musíte řešit, sídlíte-li v Kanadě" a "tamto musíte řešit, prodáváte-li v Japonsku" je naprosto děsivá.

A aby to bylo veselejší, je platnost smluv časově omezena, a zhruba po roce bude zapotřebí je obnovit v aplikaci "iOS Provisioning Portal" (proč ausgerechnet tam? Netuším. Nutno se optat Steva.)

Příprava pro upload aplikace

Máme-li kontrakt a vše ostatní z minulého odstavce, můžeme – ale kdepak, ještě zdaleka ne odeslat aplikaci do AppStore, k tomu máme dosud daleko; můžeme se ale pustit do specifikace jejích atributů.

Obecný postup je následující:

• nejprve prostřednictvím portálu iTunesConnect nastavíme atributy budoucí aplikace – od jména přes odkaz na její webové stránky až po požadovanou cenu;

• teprve potom můžeme aplikaci na portál odeslat. To pro změnu prostřednictvím portálu iTunesConnect možné není; musíme na to použít buď speciální aplikaci "Application Loader", nebo – v poslední době – Xcode, jež funkce Application Loaderu obsahuje;

• poté čekáme, až bude mít firma Apple pokdy aplikaci zkontrolovat a případně ji publikovat v AppStore. To obvykle trvá tak týden-deset dní (ale možné je i více).

Pojďme si postupně probrat vše, co je k tomu zapotřebí (nemluvě o božské trpělivosti, již potřebujeme pro bod poslední).

Pro vkládání nových aplikací slouží samostatný blok funkcí, přístupný z hlavního okna iTunesConnect jako "Manage Your Applications"; zde si můžeme prohlédnout (a spravovat) aplikace stávající, jsou-li jaké, a pomocí odkazu "Add New Application" zde můžeme založit aplikaci novou.

Pak je třeba postupně projít a vyplnit řadu stránek, obsahujících informace o aplikaci.

Jméno firmy a výchozí jazyk

Napoprvé nám portál iTunesConnect otevře samostatnou stránku, v níž zadáme jméno firmy tak, jak chceme, aby se zobrazovalo v AppStore, a výchozí jazyk – v něm budeme popisovat všechny aplikace, přičemž pro kteroukoli z nich můžeme (ale nemusíme) přidat popis v dalších jazycích. V podstatě nepřipadá v úvahu, aby zde mělo smysl určit jakýkoli jiný jazyk než angličtinu.

Jméno firmy je zřejmé; musíme si ale dát pozor na překlepy, protože z nějakých záhadných implementačních důvodů Apple neumožňuje tyto informace dodatečně změnit.

Identifikátory

Následující – tedy druhá při vkládání první aplikace a kdykoli později již první – stránka, již nám při zakládání nové aplikace iTunesConnect nabídne, obsahuje tři nebo čtyři řádky, jejichž prostřednictvím určíme aplikační identifikátory. Jedná se o následující údaje:

• jméno, pod nímž bude aplikace v AppStore zobrazena. Není nutné, aby šlo o stejné jméno, které se zobrazí po instalaci na zařízení (a které je určeno v projektu), ale rozhodně by mělo být podobné; mnohdy bývá jméno v AppStore delší. Jeho součástí mohou být doplňky typu "for iPad" apod.; firma Apple ale zdůrazňuje, že jeho součástí nemá být popis funkce. Firma Apple také vyřadí jméno, které se shoduje (nebo je příliš podobné) jménu jiné existující aplikace (někdy; jindy je klidně nechá být). Ačkoli jméno může být až 255 znaků dlouhé, vhodné je udržet jeho délku menší než nějakých 35 znaků pro pohodlné zobrazení v AppStore na iPhone;

• tzv. SKU, interní identifikátor aplikace. Zde můžeme zadat prakticky cokoli; SKU je určeno pro naši vlastní orientaci, a Apple jeho obsah prakticky nijak neomezuje – jediný požadavek je, že každá naše aplikace musí mít vlastní identifikátor, odlišný od aplikací ostatních;

• bundle ID: standardní identifikátor typu "cz.mujmac.mojeaplikace", který se musí shodovat s identifikátorem, uloženým v aplikaci v souboru Info.plist. Portál iTunesConnect zde nabídne identifikátory, které byly založeny jako "app id" v aplikaci "iOS Provisioning Portal", a které připadají v úvahu; pokud vybereme identifikátor obsahující hvězdičku, objeví se další textové pole, v němž proměnnou část doplníme.

Cena apod.

V druhém kroku určíme datum, od nějž chceme aplikaci prodávat – většinou prostě použijeme nejbližší možné; pak Apple zveřejní aplikaci na AppStore automaticky ihned po úspěšném ověření – a její cenu.

Požadovanou cenu nevkládáme přímo; namísto toho můžeme zvolit jednu z řady standardních cenových vrstev, od dolaru až po tisíc dolarů za licenci (a k tomu samozřejmě možnost šířit aplikaci zdarma). Portál iTunesConnect navíc detailně pro každou vrstvu zobrazí, kolik bude odpovídající cena na různých nedolarových trzích, a také jakou část ceny dostaneme my a jakou si ponechá Apple.

Za zmínku stojí to, že zde můžeme naplánovat složitější cenový vývoj aplikace pro budoucnost, a AppStore jej pak automaticky dodrží – můžeme např. stanovit, že aplikace bude prvý měsíc zdarma, pak bude další dva týdny stát dolar, a potom její cena vzroste na pět dolarů a takovou zůstane půl roku; pak bude třeba opět zadarmo.

Vedle rozhodnutí, zda bude aplikace k dispozici školám se slevou (pikantní je, že tuto variantu iTunesConnect automaticky nabízí pro aplikace šířené zdarma), je zde také možnost specifikovat konkrétní trhy, na nichž má být aplikace nabízena: většinou ale budeme stejně chtít, aby byla k dispozici kdekoli.

Informace o aktuální verzi

Následující stránka je věnována aktuální verzi aplikace: prozatím ji vyplníme samozřejmě jen jednou, ale až budeme později na AppStore posílat nějaký upgrade, budeme mít možnost pro něj kterýkoli ze zde uložených údajů upravit či změnit.

Vyplníme zde

• stručný popis, v němž se zájemci dozvědí, co aplikace skutečně dělá a jak funguje (max. 4000 znaků);

• kategorii, do níž aplikace spadá – můžeme zadat dvě (jednu primární a jednu doplňkovou), a podle primární kategorie obvykle určujeme také upřesňující podkategorie;

• klíčová slova, podle nichž uživatelé mohou naši aplikaci najít;

• copyright – prostě a jednoduše text, který se zobrazí v AppStore ohledně práv k aplikaci;

• kontaktní e-mailovou adresu;

• dvě URL: jedno je povinné, a správně by na něm měl být vedle dalších informací o software i firmě (ne ale nutně o této konkrétní aplikaci) kontaktní formulář, umožňující uživatelům klást doplňkové dotazy. Druhé je nepovinné, a použijeme-li je, mělo by vést přímo na informační stránku dané aplikace. V praxi toto rozdělení nadiktované firmou Apple poměrně málokdo dodržuje, a mnohdy hned prvé URL vede na informační stránku aplikace, kdežto druhé není použito vůbec;

• poznámky pro tým Apple, který bude aplikaci ověřovat. Za běžných okolností nebývá zapotřebí sem cokoli psát, ale pokud např. aplikace obsahuje "easter eggs", je třeba je zde popsat – jinak firma Apple vyhrožuje, že jakmile se na ně přijde, aplikaci z AppStore okamžitě vyřadí. Stejně tak je zde třeba popsat případné připojení k firemnímu serveru apod., bez nějž nelze aplikaci vyzkoušet;

• řadu poněkud absurdních přepínačů, jejichž prostřednictvím firmě Apple sdělíme, zda např. aplikace náhodou neobsahuje "hrubý humor" či "zmínky o alkoholu" – nedělám si legraci! – a podle toho bude aplikaci přiděleno věkové omezení. Minimum není, jak by soudnému člověku přišlo samozřejmé, "bez omezení", nýbrž "4+";

• ikona, jež bude aplikaci representovat – mělo by jít v zásadě o aplikační ikonu, ale ve vysokém rozlišení 512×512 pixelů. Máme-li od minula připravenu ikonu "iTunesArtwork", hodí se ideálně;

• jeden až pět snímků obrazovky (zvlášť pro iPhone/iPod a pro iPad). Firma Apple zdůrazňuje, že by neměly obsahovat stavový řádek – pro aplikace, jež jej nevypínají, tedy jsou jejich správné rozměry 320*460 (iPhone), 640*920 (iPhone 4), a tak dále. Publikovat snímek celé obrazovky je samozřejmě také možné, pokud aplikace stavový řádek vypíná; stejně tak je možné publikovat snímky v režimu landscape, pokud jej aplikace podporuje. Nelze publikovat výřezy;

• konečně pak lze prostřednictvím této stránky specifikovat licenční ujednání; naštěstí aspoň zde má Apple dostatek rozumu a nabízí standardní, jež lze použít, aniž by se člověk musel špinit právničtinou.

Po uložení těchto údajů se "konto aplikace" v iTunesConnect dostane do stavu "Prepare for Upload", v němž ... ještě pořád nelze sestavenou aplikaci na AppStore odeslat. To bychom to měli moc jednoduché.

Nejprve je totiž nutné odeslání explicitně inicializovat stisknutím tlačítka "Ready to Upload Binary"; k tomu se ale vrátíme až za chvilku – předtím se ještě chvilku pozdržíme u lokalizací.

Lokalizace

Lokalizace v AppStore mají jen málo společného s lokalizací vlastní aplikace, již samozřejmě implementujeme sami při vývoji (my se v našem seriálu na lokalizace aplikací do jiných jazyků ještě podíváme podrobněji, ale nebude to hned): zde se jedná o lokalizaci popisu aplikace na AppStore, jež se zobrazí v patřičném jazyce tomu, kdo na AppStore aplikace hledá.

Pro nás je ovšem poměrně podstatné to, že AppStore existenci divokých jazyků dálněvýchodních kmenů, jako kupříkladu češtiny, nebere v potaz:

Český AppStore s uživateli komunikuje anglicky, a český popis si můžeme dát na vlastní webové stránky, chceme-li.

Přesto by se ale lokalizace mohly hodit tomu, kdo sice má z pochopitelných důvodů jako primární jazyk zvolenou angličtinu, ale s konkrétní aplikací míří primárně na velké evropské trhy: iTunesConnect umožní přidat lokalizací (s výše uvedenými jazyky) libovolně mnoho; pro každou z nich je možné samostatně specifikovat nejpodstatnější informace z minulého bloku (tedy především popis, klíčová slova, snímky obrazovky apod.)

Upload aplikace? Ještě pořád ne!

Ať už jsme nějaké lokalizace pro aplikaci připravili nebo ne, od chvíle, kdy jsme do iTunesConnect uložili informace o aktuální verzi, je tamní záznam o aplikaci ve stavu "Prepare for Upload"; v něm máme v základní stránce aplikace k dispozici tlačítko "Ready to Upload Binary".

Proč je tomu tak, a proč prostě a jednoduše nestačí zbuildovanou aplikaci odeslat?

Protože ještě zbývá jeden – a mimořádně ohavný – právní zádrhel. V současném demokratickém světě je totiž soukromí považováno za cosi krajně nemravného; jedním z projevů tohoto ukrutného idiotství je to, že prodej software, který jakkoli využívá šifrování, je v některých zemích (a přes mnohé hranice) velmi problematický.

Po stisknutí výše zmíněného tlačítka se nás proto portál iTunesConnect takto optá:

Odpovíme-li, že nikoli, "konto aplikace v iTunesConnect" přejde rovnou do režimu "Waiting for Upload", v němž už konečně sestavený kód můžeme firmě Apple poslat – tomu se budeme věnovat hned v příštím odstavci.

Co nastane, pokud odpovíme, že ano, to snad raději ani nechtějte vědět... možná se k tomu vrátíme v samostatném článku, pokud jej pan JJ, jenž má s umísťováním šifrujících aplikací na AppStore zevrubné zkušenosti, bude mít chuť napsat.

Upload aplikace

Konečně jsme se dopracovali k tomu, že portál iTunesConnect čeká v režimu "Waiting for Upload" na kód naší aplikace.

Nečekejte ovšem, že v iTunesConnect naleznete standardní tlačítko "upload", jehož prostřednictvím by bylo možné sestavenou aplikaci odeslat a server by si ji již zpracoval; to by bylo příliš jednoduché a logické. Namísto toho je nutné pro odeslání kódu použít speciální protokol; abychom mu dostáli, musíme pro odesílání použít samostatnou aplikaci.

Touto aplikací může být Xcode (od verze 3.2.3 nahoru), a v každém případě v něm začneme: Build & Archive jsme již udělali dávno, takže v záložce "Archived Applications" okna "Organizer" máme archiv obsahující aktuální build připravený. Označíme jej a stiskneme tlačítko "Validate Application..." v dolní části okna.

Xcode si vyžádá vložení přihlašovacího jména a hesla pro portál iTunesConnect, a pak otevře standardní nabídku pro volbu profilu a certifikátu, kterou již známe. Jelikož jsme aplikaci sestavili s distribučním profilem AppStore, není třeba podpis měnit, a zvolíme "Don't Re-Sign" (správně by to mělo být tak, že aplikaci sestavíme s libovolným certifikátem a profilem a ten distribuční zvolíme až zde; to ale, ehm, "just doesn't work").

Potom se Xcode spojí s portálem a ověří, zda je distribuční balík v pořádku; pokud ne, vypíše nám seznam konkrétních chyb a nedostatků, jež musíme opravit, a zkusit to znovu.

Proběhne-li validace bez chyby, můžeme kód skutečně odeslat.

Nejjednodušší je i toto udělat přímo z Xcode – postup je téměř stejný jako při validaci, jen použijeme příkaz "Submit Application to iTunes Connect". Je to dobré cvičení pro posílení trpělivosti (již budeme ostatně potřebovat i později, až budeme čekat, kdy Apple aplikaci zkontroluje a zveřejní nebo nám hodí na hlavu): Xcode totiž nezobrazuje vůbec žádnou informaci o průběhu operace, a ta trvá dlouho – i při uploadu poměrně malé aplikace řádově minuty. Nakonec, máme-li štěstí, ve chvíli, kdy už uvažujeme o tom vše restartovat a zkusit to znovu, se objeví potvrzení o úspěchu:

Podíváme-li se nyní do portálu iTunesConnect, uvidíme, že aplikace je velmi krátkou dobu – zřejmě dokud probíhá nějaké interní zpracování – ve stavu "Upload Received", z nějž brzy automaticky přejde do stavu "Waiting for Review". V tom pak zůstane několik dní nebo také týdnů, to podle toho, kolik mají v Apple zrovna volného času. Až aplikaci zkontrolují, buď ji rovnou zveřejní na AppStore – pokud jsme si ovšem nevyžádali specifické datum, od nějž chceme aplikaci prodávat –, nebo nás informují o tom, že (a proč konkrétně) nebyla aplikace do AppStore zařazena.

Po celou tuto dobu máme v iTunesConnect k dispozici tlačítko "Reject This Binary"; můžeme je použít, pokud bychom mezitím narazili na nějaký problém nebo chybu a aplikaci v podobě, v níž jsme ji naposledy odeslali, nechtěli publikovat. Stisknutím tohoto tlačítka se vrátíme do režimu "Waiting for Upload".

Pokud jsme měli smůlu, Xcode ohlásí nějaké chyby, a aplikace v portálu iTunesConnect buď není vůbec, nebo tam je ve stavu "Invalid Binary".

Pokud chyby zjevně napovídají, že máme něco v sestavené aplikaci špatně, opravíme to, a zkusíme to znovu (po úspěšné validaci výše popsaným způsobem by to spíše ale nastat nemělo).

Chyby ovšem mohou znamenat také to, že má něco špatně Apple. Z důvodů, jež se raději neodvažuji ani odhadovat, totiž je jádro uploadovacího procesu napsané v Javě, a to je vždy recept na neštěstí a problémy. Speciálně se může stát, že uvidíte chybu zhruba takovouto:

V takovém případě je zbytečné ztrácet čas snahou opravit build aplikace (nebo případě použít Application Loader, o němž si něco málo řekneme za chvilku): závada je zcela jinde. Některým z uživatelů, již na tento problém narazili, podle informací z Webu pomohl upgrade Mac OS X (a speciálně Javy); jiným nikoli. Nepomůže-li upgrade, řešení v současnosti neznám (firma Apple na můj dotaz dosud neodpověděla), a jediná možnost, o níž vím, je odeslat aplikaci z jiného počítače, na němž se Java zrovna nalézá v poněkud odlišném stavu esoterického vlnění, takže náhodou momentálně aspoň trochu funguje.

Application Loader

"Moment," zarazili jste se asi – "z jiného počítače? A to tam mám instalovat kompletní Xcode, přenést tam všechny certifikáty, ...?!?"

Ne, to zapotřebí není: služby pro odeslání aplikace na portál iTunesConnect jsou k dispozici nejen v Xcode, ale také v samostatné aplikaci jménem "Application Loader". Máme-li instalované vývojové prostředí (dostatečně aktuální verze), nalezneme ji ve složce "/Developer/Applications/Utilities"; kromě toho je možné její instalaci stáhnout přímo z portálu iTunesConnect.

Po prvém spuštění si Application Loader vyžádá zadání přihlašovacího jména a hesla pro portál iTunesConnect. Stojí za zmínku, že na rozdíl od Xcode už to nikdy nezopakuje, a pokud bychom ji chtěli použít s odlišným kontem, strávíme asi celkem dlouhou dobu hledáním, než v naprosto nesmyslně nazvané a umístěné položce nabídky "Window / Run Setup Wizard..." nalezneme možnost změny.

Pak Application Loader načte z portálu iTunesConnect informace o všech aplikacích, jež jsou ve stavu "Waiting for Upload", a nechá nás vybrat, kterou z nich chceme odeslat; pro jistotu zobrazí základní informace a nabídne nám tlačítko "Choose" pro specifikaci aplikačního archivu, který chceme odeslat:

Archiv musí být ve formátu ZIP (nebo IPA, což, jak víme, je totéž). Můžeme jej tedy rovnou "vytáhnout" z Xcode z okna "Organizer" – buď si zabalenou aplikaci necháme přeposlat e-mailem, nebo ji uložíme na disk, přesně jak jsme si to popsali minule při sestavování instalací pro betatestery (a samozřejmě si dáme pozor, abychom zvolili "Don't Re-Sign", neboť předně samozřejmě nerezignujeme, a nadto je aplikace již podepsána správným certifikátem a obsahuje správný profil). Můžeme také vzít aplikaci rovnou z archivu, který nám Xcode ukáže např. po zvolení kontextového příkazu "Reveal Archived Application in Finder".

Alternativně můžeme, chceme-li, vzít build .app a zabalit jej do archivu ZIP sami.

To, že přitom Application Loader obtěžuje s připomínkou, zda jsme nezapomněli vyzkoušet aplikaci v iOS 4, je celkem drobnost – směšná sice, protože pokud ji ve čtyřce otestovat z libovolného důvodu nechceme, rozhodně to nepůjdeme dělat teď, a jinak už jsme to samozřejmě udělali dávno a dávno –, ale drobnost.

Z jiné vlastnosti Application Loaderu však na mne dýchl nefalšovaný duch let 80.; až jsem nostalgickou slzu zamáčkl a vzpomněl si na doby, kdy všichni používali CP/M nebo MS DOS (zatímco počítače Apple se do socialistických zemí nesměly vozit kvůli embargu COCOM na výkonné procesory Motorola):

Tehdy byly skutečně problémy s mezerami ve jménech na denním pořádku; dnes ale to působí poněkud zvláštně. Dokonce i ta nešťastná Java dokáže se jmény obsahujícími mezery pracovat bez nejmenších problémů; opravdu by mne zajímalo, které programátorské ... řekněme embryo a jak přesně tohle dokázalo (možná je součástí aplikace nějaký shellový skript s neošetřenými argumenty; v jejích Resources jsem ale nic takového nenašel a dále jsem nehledal).

Každopádně si dáme pozor, a pokud jméno archivu mezeru obsahuje, prostě ji smažeme: jméno archivu je zcela nepodstatné, pro validaci se beztak rozbalí.

A... to je vlastně vše: pak Application Loader aplikaci odešle přesně stejně, jako Xcode; na rozdíl od něj aspoň zobrazuje informace o průběhu celé akce (chceme-li je vidět detailně, můžeme otevřít okno "Window / Background Activity"):

Tím jsme se základy distribuce aplikací pro iOS hotovi, a příště se opět vrátíme k programování: ukážeme si, jak fungují dotykové události, co mají společného s událostmi Mac OS X, jež už známe, a čím se od nich naopak liší, a naučíme se s nimi správně pracovat.