Programování pro iOS - 10. Instalace aplikace do cizího iPhone - MujMAC.cz - Apple, Mac OS X, Apple iPod

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

6. října 2010, 00.00 | Pokud je vyvíjená aplikace jen trochu složitější, vyplatí se ji nechat otestovat skupinou betatesterů. Jak ji nahrát na jejich iPhony a jak umožnit používání aplikace klientovi, který chtěl privátní aplikaci na míru, se dozvíte v dnešním pokračování seriálu.

A co AppStore? Tomu se budeme věnovat v příštím dílu. Jak už asi je po přečtení minulého dílu všem zřejmé, vinou nesmyslné uzavřenosti iOS není distribuce vůbec jednoduchá, takže i dnešní téma je dost a dost komplikované samo o sobě. A jak uvidíme příště, s AppStore to není o nic snazší, spíše naopak...

Jak na betatestery

Připomeňme, co jsme potřebovali sami k tomu, aby bylo možné vyzkoušet aplikaci na našem vlastním iPhone či iPadu:

• certifikáty (WWDR a vlastní) a šifrovací klíče: ty byly zapotřebí pouze pro podepsání aplikace, a z hlediska betatesterů se jimi tedy zabývat nemusíme – těm předáme aplikaci již hotovou a podepsanou;
• provozní profil, který spojuje identifikátor aplikace s UDID zařízení, na němž aplikaci lze spustit: ten naopak betatester samozřejmě potřebuje, aby jeho zařízení aplikaci přijalo.

Betatesterům k tomu, aby mohli testovat naši aplikaci, stačí dvojice souborů: provozní profil (obsahující mj. UDID zařízení betatestera), a aplikace sama. Tester může obojí do svého zařízení instalovat pomocí iTunes, a učiní-li tak, aplikace by se měla dát bez problémů spustit.

V principu to přesně takhle můžeme i udělat – vyexportujeme-li vývojářský profil z Xcode (dá se jednoduše vytáhnout myší z okna "Organizer / Provisioning Profiles" a vhodit třeba do složky ve Finderu nebo do okna Mailu), uživatel si jej může nainstalovat prostřednictvím iTunes. Soubory .mobileprovision se totiž sice standardně otvírají v Xcode, ale lze je vhodit také přímo do okna (nebo na ikonu) iTunes (nebo je tam otevřít příkazem z menu apod.): aplikace profil rozezná a v případě potřeby instaluje na zařízení, pokud jeho UDID profilu odpovídá.

Mimochodem, seznam profilů, které jsou na tom kterém zařízení instalovány, si můžeme kdykoli prohlédnout přímo na něm – zobrazuje je aplikace Settings ve skupině General. Odkaz na seznam profilů je tam až u konce, těsně nad položkou "Reset" (a nezobrazí se, pokud v zařízení žádný profil instalován není).

Stejně jako profil je možné do iTunes vhodit také zbuildovanou aplikaci – tedy složku JménoAplikace.app; nejsme-li si jisti, kde je, podíváme se v Xcode do záložky Products a přidržíme nad aplikací chvilku myš; Xcode zobrazí tooltip s plnou cestou:

Uživatel pak bude mít možnost takovou aplikaci při synchronizaci přenést do telefonu nebo iPadu přesně týmž způsobem, jakým se to děje s aplikacemi koupenými z AppStore.

Tímto způsobem se aplikace testerům předávaly před časem a funguje to dosud; Xcode v aktuální verzi ale opět umožňuje tento postup malinko zjednodušit. Vybereme-li z nabídky "Build" příkaz "Build & Archive", aplikace se sestaví a zároveň zabalí do archivu .IPA ("IPhone/IPad Application"); to je docela obyčejný archiv ve formátu ZIP, který obsahuje vlastní aplikaci a případně některé doplňkové soubory – např. právě profil.

Archivované aplikace pak můžeme přímo z Xcode odesílat k distribuci. Pokud chceme distribuovat aplikaci s vývojářským provozním profilem (jinými slovy, pokud v něm máme uložena UDID betatesterů), stačí v nabídce "Archived Applications" okna "Organizer" zvolit požadovaný archiv, a klepnout na tlačítko "Share Application...":

V následném dialogu pak zvolíme "Identity: Don't Re-Sign" – protože máme aplikaci již podepsanou certifikátem, odpovídajícím vývojářskému profilu – a klepneme na "Save to Disk..." nebo "E-Mail...". Xcode připraví archiv IPA obsahující jak aplikaci samotnou – korektně podepsanou –, tak i odpovídající profil.

Tester, jemuž aplikaci pošleme e-mailem (nebo jiným způsobem z disku, kam jsme ji uložili příkazem "Save to Disk"), teoreticky jen otevře archiv IPA; tento typ souboru je automaticky přiřazen aplikaci iTunes, která přijatý program přidá mezi aplikace, jež uživatel může synchronizovat na zařízení.

"Teoreticky" proto, že ačkoli by to skutečně mělo fungovat bez jakýchkoli dalších problémů; podle dosavadních zkušeností je ale přece jen někdy zapotřebí poslat testerovi samostatně profil, aby jej do zařízení instaloval přímo přes iTunes (jak jsme si popsali výše): teprve po jeho samostatné instalaci to začne chodit i v praxi. Zřejmě je stále někde v iTunes či v iOS drobná chybka, která se projeví jen někdy a jen v některých kombinacích...

Distribuční profil ad-hoc

Výše popsané využití vývojářského provozního profilu pro testování je velmi pohodlné, ale má přinejmenším dvě nevýhody:

• je poněkud nepraktické udržovat aktuální seznam všech zařízení všech betatesterů ve vývojářském profilu;
• provozní profil má nepříjemně omezenou dobu trvání – vyprší po třech měsících od zadání; pak je třeba jej obnovit (tento problém není ani tak vážný pro testování, ale je zcela zásadní při distribuci aplikací na míru, k níž se podrobně vrátíme za chvilku).

Apple nabízí alternativní možnost podepisování kódu pro tyto účely; tou jsou specializované distribuční profily.

Jak za chvilinku uvidíme, vlastní vygenerování archivované aplikace s distribučním profilem není v Xcode o nic těžší, než tomu bylo s profilem provozním; podstatně problematičtější však je samotné získání distribučního profilu.

Zde se nejprve musíme malinko zdržet u uživatelských rolí, jež nabízí webová aplikace "iOS Provisioning Portal" (ano, pamatujete si dobře: když jsem psal minulý článek, táž aplikace se ještě jmenovala "iPhone Provisioning Portal" – je doba velkých změn): ty jsou čtyři, a vypadají takto:

• No Access: nemůže nic, a pro účely, o nichž se zde nyní bavíme, nemá smysl (používá se v případech, kde je třeba někoho zařadit do týmu kvůli právu ke zcela odlišným činnostem, než je vývoj aplikací pro iOS);
• Member: má možnost získávat vývojářské certifikáty a provozní profily; nemůže je ale vytvářet a také nemůže upravovat seznam zařízení, aplikačních identifikátorů apod. V praxi má jen málokdy smysl, leda v hodně velkých vývojářských firmách, kde je složité vertikální členění týmu (nebo v případech, kdy na nějakém konkrétním projektu spolupracuje externista);
• Admin: až dosud jsme tiše předpokládali, že máme v aplikaci "iOS Provisioning Portal" (minimálně) tato přístupová práva; na jejich základě můžeme dělat vše, co jsme si ukázali v minulém dílu;
• Team Agent: má neomezená práva a může toho dělat ještě více; speciálně může – na rozdíl od všech ostatních rolí – sestavovat (a načítat) distribuční certifikáty.

První problém spočívá v tom, že "Agent" je v týmu pouze jeden: je to prvotní správce, jemuž firma Apple přidělila konto v aplikaci "iOS Provisioning Portal". Nikdo jiný práva Agenta dostat nemůže; pokud tedy Agent nechce s jinými členy týmu sdílet vlastní přihlašovací jméno a heslo, je on jediný, kdo může distribuční ad-hoc profil sestavit.

Navíc si jej musí stáhnout "ručně": distribuční ad-hoc profily totiž nejsou automaticky synchronizovány do Xcode při použití služby "Refresh" v okně "Organizer / Provisioning Profiles", jak jsme si to ukázali minule. Agent tedy musí nejen profil pro testování připravit; měl by pode představy Apple zřejmě také sám přebuildovat (resp. "přepodepsat") každou aplikaci, kterou má dostat do ruky některý z betatesterů. Jistě, pro některé týmy je tento přístup vhodný; ty ostatní – a troufám si odhadnout, že takových bude většina – však mají smůlu.

Ale zase ne úplnou smůlu; jen se jim to trochu zkomplikuje. Agentovi totiž samozřejmě nikdo a nic nebrání v tom, aby distribuční profil a jemu odpovídající certifikát rozeslal e-mailem (nebo jakkoli jinak) všem vývojářům, již mají sami mít právo a možnost sestavovat a rozesílat buildy testerům.

Podívejme se na celý postup podrobněji. Abychom mohli sestavovat a distribuovat aplikace pro testování pomocí ad-hoc profilu, je třeba zajistit následující:

Nejprve musí Agent sestavit distribuční certifikát – ten se od osobního vývojářského certifikátu liší pouze tím, že se jeho vytvoření zadá v záložce "Certificates / Distribution" a nikoli "Certificates / Development". Tato záložka se v aplikaci "iOS Provisioning Portal" automaticky zobrazí Agentům, ale nikomu jinému:

Certifikát si samozřejmě standardním způsobem stáhne a uloží do keychainu – stačí klepnutí na tlačítko "Download" a otevření přijatého souboru CER poklepáním ve Finderu.

Potom musí Agent vygenerovat distribuční profil – opět jde o prakticky totožnou akci, jakou bylo sestavení vývojářského profilu; jen zase probíhá v "agentské" záložce "Provisioning / Distribution" (namísto "Provisioning / Development"), a je zde možnost zvolit typ certifikátu. Zvolíme samozřejmě "Ad Hoc" (typ "App Store" budeme potřebovat příště pro odeslání aplikace do AppStore):

Hotový distribuční certifikát si Agent stáhne do svého počítače pomocí tlačítka "Download".

Nyní záleží na struktuře týmu: pokud odpovídá představám Apple, a Agent je skutečně jediný, kdo může sestavovat distribuce pro betatestery, jsme v podstatě hotovi – Agent si stažený profil uloží do Xcode (stejně jako tomu je se všemi ostatními soubory typu .mobileprovision, stačí jej otevřít, a Xcode jej automaticky načte).

Pak Agent v Xcode použije výše popsanou službu pro distribuci archivovaných aplikací, ale před sestavením archivu namísto volby "Don't Re-Sign" vybere právě distribuční profil, který se mu zde – poté, co byl uložen do Xcode – automaticky zobrazí:

Pokud ovšem mají tuto možnost mít i ostatní členové týmu, je to poněkud složitější: v takovém případě musí Agent vyexportovat certifikát z keychainu – v aplikaci Keychain Access na to je k dispozici služba "Export Items", jež dokáže vybraný certifikát včetně odpovídajících klíčů uložit do standardního formátu .p12:

Vzhledem k tomu, že se spolu s certifikátem (ten sám o sobě je samozřejmě veřejný) ukládá i privátní klíč, je výsledný soubor zašifrován (a měli bychom v takovýchto případech vždy používat kvalitní hesla).

Certifikát ve formátu P12, heslo a distribuční profil pak musí Agent předat (např. e-mailem, ovšem heslo je samozřejmě v takovém případě lepší sdělit jiným kanálem) těm vývojářům, kteří mají mít možnost sestavovat aplikace pro betatestery. Vývojáři si certifikát uloží do keychainu (stačí otevřít soubor P12 a zadat heslo), profil do Xcode (stačí jej jen otevřít), a teprve pak budou mít možnost podepisovat aplikace pro distribuci výše popsaným způsobem.

Entitlements

Firma Apple v dokumentaci zdůrazňuje, že distribuce ad-hoc nebude fungovat, pokud nebudou při sestavování aplikace použity tzv. "entitlements" k tomu, aby bylo zakázané ladění aplikace. Podle našeho testování tomu tak ve skutečnosti není – aplikace distribuovaná výše popsaným způsobem bez "entitlements" běží na zařízení bez jakýchkoli problémů –, nicméně je samozřejmě možné, že např. v některé z budoucích verzích iOS (nebo vývojového systému) se to změní, případně že tomu je jinak v některé odlišné konfiguraci (máte-li s tím vlastní zkušenost, ať již kladnou nebo zápornou, dejte prosím vědět v diskusi).

V každém případě je dobře vědět, co to "entitlements" jsou, a jak je do aplikace zahrnout; proto si to popíšeme podrobněji.

Program, který v Mac OS X podepisování kódu zajišťuje (jmenuje se "codesign"), toho dokáže mnohem více, než jen sestavit signaturu a opatřit ji digitálním podpisem. Mezi řadu jeho schopností patří také to, že do podpisu může zakódovat obecný soubor; ten se právě nazývá "entitlements". Kód, který podpis verifikuje, si pak může tento soubor v rámci ověřování podpisu zase "vytáhnout" a na základě jeho obsahu s podepsanou aplikací zacházet speciálním způsobem.

Pro aplikace, jež mají běžet v operačním systému iOS, obecně "entitlements" povinné nejsou; pokud ale jsou použity, mohou mít formu slovníku ve formátu "property list" – podobně jako nám již dávno známý "Info.plist". V současnosti jediný klíč podporovaný editorem v Xcode je právě "get-task-allow", který povoluje/zakazuje ladění. (Souborové vzory v aktuální verzi Xcode obsahují kromě toho také klíče "application-identifier" a "keychain-access-groups"; ty se týkají přístupu aplikací do potenciálně sdíleného keychainu a my se jimi prozatím zabývat nemusíme.)

Chceme-li do projektu "entitlements" přidat, nejjednodušší je použít zmíněný standardní souborový vzor Xcode: zvolíme standardní službu "Add / New File", a odpovídající vzor vyhledáme ve skupině "iOS / Code Signing":

Jméno souboru můžeme zvolit libovolné; standardní nabídka "Entitlements.plist" je stejně dobrá, jako každá jiná.

Dáme si pozor na to, abychom jej nechali přidat i do odpovídajícího cíle. V aktuální verzi je Xcode dostatečně "chytré" na to, aby soubor přidalo do cíle speciálním způsobem – nestane se tedy zdrojem, prostě překopírovaným do aplikační složky "Resources", ale namísto toho bude použit právě při podepisování kódu.

Můžeme si pro jistotu ověřit, zda je to správně: podíváme-li se do seznamu "Copy Bundle Resources" cíle, s nímž pracujeme, nově přidaný soubor tam nebude. Když ale otevřeme informace o cíli a podíváme se do jeho záložky "Build" a tam vyhledáme skupinu "Code Signing", bude v ní jméno nově přidaného souboru automaticky zapsáno v řádku "Code Signing Entitlements":

Kdyby tomu tak nebylo (některé ze starších verzí Xcode to, paměť-li mne nešálí, automaticky neřešily; může se to stát také po změnách projektu), prostě je tam uložíme sami.

Pro úpravy obsahu tohoto souboru nejprve musíme Xcode říci, o jaký typ "property listu" jde – editor to kupodivu sám nepozná (alespoň ne v aktuální verzi 3.2.4). Entitlements prostě otevřeme v editoru, a pak z hlavní nabídky vybereme "View / Property List Type / iPhone Entitlements plist" (ano, zde je ještě pořád iPhone a nikoli iOS – je doba velkých změn, a zdaleka ne všechny jsou už za námi). Standardním způsobem, tedy klepnutím na "ucho" vpravo od řádku "iPhone Entitlements", přidáme novou položku; Xcode nám nabídne jedinou možnost – "Can be debugged" – což je jen jeho krycí název pro klíč "get-task-allow". Postaráme se, aby byla tato možnost pro distribuci vypnuta:

A to je vše; po příštím buildu by měly být "entitlements" korektně zakódovány v podpisu.

Samozřejmě, že tak nějak z definice, pokud v "entitlements" zakážeme ladění, nemůžeme ladit – přidáme-li tedy výše popsané "entitlements" do nastavení projektu, a pak jej zkusíme spustit prostřednictvím debuggeru, zobrazí nám Xcode (v současné verzi pro jistotu dvakrát, jednou v okně "Organizer" a jednou v konsoli) toto:

Řešení je jednoduché: uložíme "entitlements" jen do nastavení pro konfiguraci "release" a nikoli pro konfiguraci "debug". Nebo, pokud z nějakého důvodu chceme distribuovat konfiguraci "debug", pro ladění přepínač "Can be debugged" zapneme a vypneme jej až před vlastní distribucí.

Zakázkové a in-house aplikace

Jestliže nám aplikaci betatesteři dostatečně důkladně vyzkoušeli a jsou-li s ní přiměřeně spokojeni, můžeme ji prohlásit za hotovou a předat zákazníkům. Ti, kdo míří na zákazníky na celém světě prostřednictvím AppStore, se potřebné detaily dozvědí v příštím dílu našeho seriálu; dnes si nejprve popíšeme možnosti, které máme v případě, že je zakázková aplikace určena pro konkrétního klienta, jemuž je psána na míru.

Jak hned uvidíme, nejsou kdovíjak skvělé.

Firma Apple pro tyto případy podporuje tzv. "Enterprise" konta: zde se ovšem u firmy Apple neregistruje vývojář za stovku (dolarů) ročně, nýbrž sám zákazník za tři stovky (týchž); navíc má firma Apple na tyto potenciální zákazníky další požadavky (ještě nedávno byla mezi nimi např. velmi nezanedbatelná velikost firmy – nutností bylo minimálně 300 zaměstnanců). V současnosti je jediný veřejně uváděný požadavek to, že klientova firma musí mít číslo DUNS od firmy D&B – toto číslo lze získat zcela jistě zdarma v USA, patrně i u nás (wiki a český portál firmy). Ze stránek Apple nicméně nepřímo vyplývá, že číslo DUNS je podmínkou nutnou, nikoli postačující – to se ukáže až při jednání...

Musím se upřímně přiznat, že s distribucí Enterprise dosud nemám naprosto žádnou zkušenost. Předpokládám jen, že patrně v takovémto případě firma Apple sestaví certifikát a profil, který umožní instalaci konkrétní aplikace do libovolného zařízení s iOS (tedy bez seznamu UDID povolených cílových zařízení), ale zároveň bude hrozit vysokými smluvními pokutami v případě, že by se takováto aplikace dostala na zařízení patřící někomu, kdo není zaměstnancem nebo spolupracovníkem dané firmy. Skutečně to ale nevím, jde jen o mírně kvalifikovaný odhad na základě dlouholetých zkušeností s firmou Apple. Neznám prozatím žádný podnik u nás, jenž by licencí Enterprise disponoval; všichni moji současní klienti, jimž píši aplikace na míru, využívají distribuce ad-hoc. Pokud má někdo s distribucí Enterprise konkrétní zkušenosti, jistě čtenáři uvítají, podělí-li se o ně v diskusi k článku.

Pokud distribuce Enterprise nepřipadá v úvahu – třeba proto, že klient se nechce s Apple dohadovat o nějakých licencích; on prostě chce software na iPhone či iPad, a jak to uděláme, to je na nás jako na vývojářích –, nezbývá, než využít výše popsanou "betatesterskou" distribuci ad-hoc. Klient nám v takovém případě musí dát UDID všech zařízení, na kterých chce software provozovat (nemůže jich ovšem být více než 100), my pro ně sestavíme odpovídající ad-hoc distribuční profil, a ten klientovi předáme spolu s hotovou aplikací. Zároveň si zapíšeme do kalendáře, že za necelý rok bude zapotřebí profil obnovit, aby aplikace nepřestala fungovat.

Poslední zbývající alternativou je jailbreak; tím se ale prozatím zabývat nebudeme, ačkoli někteří klienti jej preferují i pro další výhody, jež přináší.

Ikona pro iTunes

Předáváme-li klientovi aplikaci jako archiv IPA podepsaný ad-hoc distribučním certifikátem, otevře se mu tento archiv v iTunes přesně stejně, jako aplikace, koupené z AppStore: uvidí jej tam tedy jako ikonu aplikace, kterou bude moci synchronizovat do svých zařízení (jejichž UDID jsou uloženy v daném profilu).

V tomto případě ovšem asi budeme také chtít, aby se naše aplikace v iTunes presentovala hezkou specifickou ikonou. To je poměrně snadné: připravíme ikonu aplikace v rozlišení 512 × 512 pixelů a ve formátu PNG (nebo JPEG, a tu a tam Apple psává, že je přípustný i formát TIFF bez vnitřní komprese, ale skutečně jen tu a tam: nestojí to za experimentování, nejjednodušší je prostě použít PNG), a uložíme ji do aplikace (týmž způsobem, jako jakýkoli jiný zdrojový soubor) pod jménem "iTunesArtwork" – pozor, bez přípony, ne tedy "iTunesArtwork.png"!

Aplikace iTunes pak dokáže tuto ikonu z archivu IPA načíst a korektně zobrazit.

Chceme-li, můžeme samozřejmě této možnosti využít i v případě, kdy aplikaci distribuujeme betatesterům: uvidí-li hezké obrázky, budou určitě vstřícnější. Stejnou ikonu ostatně budeme potřebovat i pro AppStore, jak si ukážeme příště.