Za poslední roky se iOS vývoj velmi posunul, za hlavní zmínku stojí postupné nahrazování Objective-C Swiftem, což znamená nemalé zásahy do vývojového prostředí. Když jsem s vývojem začínal (v dobách kdy o Swiftu nemohla být ani řeč), patřil Xcode určitě k těm vůbec nejlepším prostředím vůbec. Vynikal předevšim obrovskou svižností, spuštění bývalo okamžité, stabilita byla slušná. Nicméně postupem času se toto začalo měnit.
Jistě, některé přednosti Xcodu zůstaly, ale objevila se spousta neduhů, které nám stále více znepříjemňují život. Podívejme se na ty nejzásadnější.
Zvyšující se čas kompilace
Doba, za kterou se zkompiluje totožná aplikace napsaná v Objective-C je rapidně nižší než doba kompilace aplikace napsané ve Swiftu. Swift je programátorsky o mnoho přívětivější než Objective-C, což znamená, že větší čast odpovědnosti je přesunuta na kompilátor, což zvyšuje na něj zvyšuje nároky.
Zároveň Swift kompilátor stále obsahuje některé chyby, které čas kompilace prodlužují. Ve chvílích, kdy kompilátor tipuje jakého typu bude konkrétní proměnná, čas kompilace se může zvyšovat až exponenciálně. Více zde.
V těchto případech je možné kompilátoru pomoci a doplnit očekávaný typ proměnné, což čas kompilace rapidně sníží. Ale jak zjistíme, které kusy kódu se v naší aplikaci kompilují nejdéle? K těmto účelům využíváme aplikaci BuildTimeAnalyzer, která je po přidání pár flagů schopna analyzovat časy kompilace jednotlivých funkcí a poté je přehledně zobrazit.
Bezdůvodné rekompilace projektu
S předchozím bodem souvisí i tento. Čas kompilace se značně prodlužuje neobvyklými rekompilacemi celého projektu. Velice často stačí v jediném souboru změnit konstantu, přepsat název proměnné, odmazat nebo zakomentovat kus kódu, který nikde není využíván a výsledkem je rekompilace.
O tomto problému se také intenzivně diskutovalo na fóru Applu a alespoň částečná řešení z této diskuze vzešla. Do build setting projektu stačí doplnit uživatelskou proměnnou HEADER_MAP_USES_VFS = YES. Další z řešení je zrušení možnosti Find implicit dependencies v kompilačním schématu.
Nicméně ani jeden z těchto workaroundů nám 100% nezafungoval a občasné rekompilaci se na některých projektech nevyhneme. Zatím se nám ani nepodařilo vysledovat, jaké kusy kódu tyto rekompilace vyvolávají.
Pády kompilátoru i Xcode
Jak bylo zmíněno výše, v dřívějších dobách byla stabilita Xcodu velmi slušná, nicméně s posledními verzemi jsou dny kdy Xcode nespadne ani jednou spíše výjimkou než pravidlem, přičemž v některých případech není výjimkou, že úspěšnému spuštění Xcodu předchází několik pádů.
S vývojem Swiftu se množí také pády samotného kompilátoru. Velmi často stačí se v pár řádcích kódu splést v typech a místo všeříkající chyby o nesouladu typů získáme segmentation fault kompilátoru. Dohledat poté původ takového pádu kompilátoru velmi často nebývá snadné, přestože se z výpisu kompilátoru dá vyčíst který blok kódu pád způsobil.
Syntax highlight, code completion a formátování
Hlavními výhodami kvalitních vývojových prostředí by mělo být kvalitní zvýrazňování syntaxe, doplňování kódu a formátování. Ale každý vývojář, který využívá Xcode se jistě setkal se situací, kdy syntax highlight vypověděl službu, celý soubor popř. projekt zčernal, přičemž zároveň vypoví službu automatické odsazování kódu.
Tyto nepříjemnosti by nebyly tak závažné, kdyby Xcode nabízel možnost zformátovat soubor/projekt podle předem určeného stylu, jako to umožňují jiná vývojová prostředí. Bohužel taková základní věc v Xcodu doteď nebyla implementována, tak je potřeba se spoléhat na řešení třetích stran, která nejsou úplně spolehlivá.
Migrace kódu
Jelikož je Swift stále ve vývoji, tak se s jeho jednotlivými verzemi mění i jeho syntaxe a zpětná podpora napříč jednotlivými verzemi Xcode není nic moc, je potřeba kód postupně mezi jednotlivými verzemi migrovat. V závislosti na velikosti projektu migrace samozřejmě zabírá více a více času, který se na aplikaci z uživatelského pohledu nijak neprojevuje.
Provisioning a code signing
Jelikož nevyužíváme možnosti, aby nám Xcode vyřešil code signing aplikace automaticky, tak je pro nás nový způsob vyplňování provisioning profilů značnou komplikací. Jelikož na každém projektu využíváme continous integration včetně automatické distribuce buildů, jsou tyto problémy zásadní, jelikož velmi často se stává, že kompilace aplikace skončí s chybou právě kvůli provisioningu.
Náhodně fungující debugger
Ve složitějších aplikacích je rozhodně velmi důležitá role debuggeru. Velice často při vývoji je důležité zjistit jaké hodnoty se nachází v proměnných a jak na ně aplikace reaguje. Nicméně debugger v Xcode nahodile funguje a nefunguje, nezřídka odmítá zobrazit aktuální hodnoty a při pokusu vypsat hodnoty do konzole velmi často končí s chybou. Vývojář je poté často odkázán na starý dobrý print v kódu aplikace, aby zjistil jaké hodnoty jsou v proměnných uloženy.
Refaktoring ve Swiftu
Naprosto jednoduchá operace přejmenování třídy, nebo proměnné napříč projektem je v Xcodu implementována pouze pro Objective-C, pokud je aplikace napsána ve Swiftu, můžeme se spolehnout akorát na Find and replace, nicméně toto je pouze slabá náhrada.
Závěrem
Závěrem můžeme doufat, že s postupnou stabilizací syntaxe Swiftu se Apple zaměří na nedostatky Xcodu, které jsou určitě způsobeny stálými změnami ve Swiftu, které musí vývojové prostředí reflektovat.
