iOS vs. Android: Souboj vývojářů
Je to odvěký souboj: Která platforma je lepší? Kdo však po kliknutí na titulek očekával jednoznačnou odpověď, bude zklamán. V Ackee totiž táhneme za jeden provaz a respektujeme jiné přístupy, nástroje i platformy. O to zajímavější však bylo poslechnout si, jak se na oba operační systémy dívají naši team leadeři. V pomyslném duelu o nejlepší platformu se utkal Jan Mísař za iOS a David Bilík za Android.
Proč jste se rozhodli být vývojářem právě té vaší platformy?
🍏 Honza: Myslím si, že to bude podobné jako u většiny mobilních vývojářů. Koupil jsem si tenkrát iPhone, už ani nevím proč, a chtěl jsem si na něj prostě zkusit něco naprogramovat.
🤖 David: Já to měl podobně. Původně jsem chtěl začít programovat pro iOS, ale vůbec jsem nevěděl, co to obnáší. Pak jsem zjistil, že k tomu potřebuji mít Mac a iPhone. :D Což zpětně dává smysl, jenže žádnou z těch věcí jsem neměl. Měl jsem ale tou dobou telefon s Androidem, tak jsem si řekl, že zkusím začít tím. Přišlo mi zajímavé vytvářet si aplikace na zařízení, které každý den používám. Na FITu se tou dobou otevřel předmět, který se programování pro Android věnoval, tak jsem si ho zapsal. V rámci předmětu mě to začalo bavit a skrze kontakty z předmětu jsem si našel první práci.
Kdybyste se mohli vrátit v čase, vybrali byste si stejně?
🤖 David: Já asi jo, protože i když ten vývoj není dokonalý, tak jsme si za těch 8 let vytvořili s Androidem vztah plný lásky a nenávisti. Neznám vývoj na druhé platformě, takže se mi to těžko porovnává, ale dá se říct, že s vývojem na Android jsem spokojený.
🍏 Honza: Já bych určitě neměnil. Ani ne tolik z těch programátorských důvodu, protože tam jsem na tom stejně jako David, vývoj na Android tolik neznám a nedokážu to porovnat, ale věřím, že bych se to taky dokázal naučit. Nicméně z toho uživatelského pohledu bych rozhodně neměnil a to především kvůli celému Apple ekosystému, protože to do sebe parádně zapadá, narozdíl od Androidu, který tohle ze své podstaty nabídnout nemůže.
Takže oba stále používáte telefon se stejným operačním systémem?
🍏 Honza: Je to tak. Ale přiznej se, Davide.
🤖 David: No neboj se, chystal jsem se na to. 😬 Tak čtyři roky zpátky jsem si pořídil iPhone SE. Moje strategie byla, že jsem si vždy kupoval telefony od Googlu, nejdřív Nexusy a pak Pixely, jenže Google to – aspoň tehdy – s těmi telefony neuměl. I když měly čistý operační systém, tak kvalita těch zařízení neodpovídala konkurenci jako třeba Samsung (který bych si ale nikdy nepořídil 😃). Rozhodl jsem se tedy, že zkusím iPhone a uvidím, jestli je to opravdu o tolik lepší, jak všichni říkají. Po roce a půl jsem ale přešel zpět na Android (Pixel 2), protože problémy se začaly objevovat i na iPhone a já dal Androidu druhou šanci. 🙂 Od té doby jsem zase na Androidu a teď mám Google Pixel 4.
Jak probíhá vaše spolupráce co se týče projektů, kdy se aplikace vyvíjí pro obě platformy?
🤖 David: Tohle je složitá otázka, protože se to liší projekt od projektu. Dělali jsme aplikace, kdy jedna platforma byla napřed, a to se nám osvědčilo jako výhoda. Typicky je to u projektů, kdy nedodáváme všechny části – jako třeba API. Tam to vývojáři jedné platformy “prokopnou” a na druhé platformě se těží z těchto nabytých znalostí a nemusí s tím “bojovat” oba vývojové týmy.
Ve většině projektů ale oba týmy vyvíjí paralelně stejné funkce a snaží se spolupracovat tak, aby dosáhly stejného výsledku v chování aplikací a odpovídalo to zadání. I sebelepší zadání se dá interpretovat více způsoby a my chceme, aby obě aplikace fungovaly stejně. Nechceme, aby se při testování přišlo na to, že tam jsou rozdíly a muselo se to opravovat. K takové vzájemné komunikaci se snažíme povzbuzovat všechny členy týmu.
🍏 Honza: K tomu už asi nemám co dodat.
V čem vidíte výhody a nevýhody obou platforem z pohledu vývojáře?
🍏 Honza: Jasná výhoda vývoje na iOS je omezená množina zařízení, na které vyvíjíme. Ta zařízení si vyrábí jenom Apple, iOS běží jenom na nich a i když je jich už dneska hodně, tak je to pořád limitovaný počet. Zatímco na Androidu je těch zařízení spousta od různých bizarních výrobců, od úplného low costu po high-end. V tom je to problematičtější.
Další skvělá věc u iOS je, že jeho uživatelé jsou zvyklí updatovat na nejnovější systémy poměrně brzy a ve velké míře. To znamená, že my vyvíjíme v podstatě na ty nejposlednější verze a můžeme si dovolit docela rychle zahazovat ty staré. Ten vývoj je pak o dost pohodlnější, než když musíme podporovat právě i nějaké starší verze.
Nevýhodou je rozhodně uzavřenost toho Apple ekosystému a to, že Apple čím dám tím víc utahuje šrouby. iOS je už dnes hodně přísně omezený a dá se čekat, že s příchodem nových počítačů s procesory Apple Silicon bude tímto směrem směřovat i macOS.
🤖 David: Jako jednu z největších výhod vidím v tom, že pro Android můžu vyvíjet na běžném počítači, který není Mac. Ceny počítačů s macOS jsou stále vyšší než dostupnější varianty s Windows či Linux a může to být tedy omezující faktor.
S fragmentací, kterou zmiňoval Honza, je to složitější. Pro uživatele je určitě výhodné, že si může koupit telefon v různých cenových kategoriích a velikostech displeje, pro vývojáře to ale znamená, že musí všechny tyto zařízení podporovat. Zároveň Google nedokázal zajistit tak vysokou adopci nových verzích systémů, jako má iOS, takže musíme podporovat i verze systému, které jsou třeba 6 let staré.
Naštěstí si Google tenhle problém (který sám v počátcích Androidu způsobil) uvědomuje, a zpětnou kompatibilitu se snaží řešit. Typicky nové věci, které se do systému přidávají, nejsou přímo součástí systému, ale formou knihovny, která se dá použít i na starších systémech. Tohle ale samozřejmě nejde říct o všem, každopádně se snaží co to jde.
A plusy a mínusy z pohledu uživatele?
🍏 Honza: Dá se říct, že iOS je bezpečnější, konzistentní apod. právě z důvodu přísných Apple guidelines, ale jinak už se dnes ty rozdíly z uživatelského hlediska smazávají. Když si někdo koupí telefon s Androidem za peníze srovnatelné s cenou iPhonu, tak dostane stejně rychlé a funkční zařízení. Ten rozdíl už je pryč. Nicméně řekl bych, že iPhone má oproti Androidu stále takový ten cool faktor. A myslím si, že mít iPhone třeba mezi mladší generací je takový sociální status a Apple si tím udržuje tu svou “exkluzivitu”, ale jinak tam žádný větší rozdíl není.
🤖 David: Myslím, že největší výhoda je ta, co už byla zmíněna – že si uživatel může vybrat přesně ten telefon, který mu vyhovuje. Pokud chce mít DualSIM, fyzickou klávesnici nebo “foldable” displej, existuje telefon s Androidem, který to nabízí.
S tou exkluzivitou souhlasím s Honzou, ale myslím, že to vzniklo historicky, kdy cena iPhonů je +- stejná dodnes, kdežto dřív vlajkové lodě jako třeba Samsung Galaxy S2 stály o deset tisíc míň než iPhone. Dnes jsou ty ceny srovnatelné a někdy i vyšší za Android než iPhone.
Jak je to s rychlostí vývoje?
🤖 David: Tady hodně záleží na zkušenostech vývojáře. U zkušených vývojářů nebude v rychlosti vývoje na danou platformu rozdíl. Já když například píšu aplikaci, tak myslím na to, aby dobře fungovala na telefonu, který bude mít malý displej, nižší výkon procesoru a třeba operační systém starý 5 let. Prostě tak, aby všude běžela obdobně dobře. Pro nezkušené lidi tohle ale může být velké zdržení při vývoji, protože na to nemyslí a tyto problémy se odhalí při testování na různých zařízeních.
🍏 Honza: Tohle my u Applu právě nemusíme řešit.
A co rychlost z toho uživatelského hlediska?
🍏 Honza: U těch srovnatelných modelů se nedá říct, že by jedna platforma byla rychlejší. U těch levnějších se to může projevit.
🤖 David: Přesně tak, tam uživatel dostane přesně to, za co si zaplatí.
Kolik času zabere odladit aplikaci na většinu zařízení na trhu?
🍏 Honza: Tady fakt záleží, o jakou aplikaci se jedná. Pokud je to nějaká jednoduchá tabulka a obrázky, tak v podstatě skoro žádný čas, protože to prostě funguje. Ale pokud tam člověk řeší třeba nějaké 3D modely, openGL a podobné technologie, tak to dá samozřejmě víc práce. Nicméně na to není univerzální odpověď.
🤖 David: Přesně tak, záleží na tom, co ta aplikace má za nestandardní fíčury. Na Androidu typicky bývá problém s foťákem, každý telefon totiž fotí trochu jinak. U jedné aplikace jsme řešili, že na jednom konkrétním telefonu je po vyfocení fotka vzhůru nohama a ještě zrcadlově. 🤯 Museli jsme do kódu dát podmínky, že pokud aplikace běží na tomto zařízení, ať se fotka otočí. Podobné srandy se dějí s GPS polohou, senzory (např. akcelerometr) a podobně. V podstatě pokaždé, když záleží na hardware, který se liší mezi výrobci i jednotlivými modely, tak narůstá čas na testování. Pokud pouze zobrazujeme data, které nám přijdou z API, tak tam takové problémy nevznikají. Nicméně žádné absolutní či relativní číslo nemůžu dát, protože to fakt závisí projekt od projektu.
Jak je to s rychlostí v kontextu vydávání aplikací?
🍏 Honza: Tady to má iOS trochu horší. Což souvisí s tím, jak už jsem zmiňoval, že Apple čím dál více utahuje šrouby. I v kontrole aplikací je důkladnější. Review proces je poměrně přísný a kvůli tomu dlouho trvá. Ta situace se o dost zlepšila, protože teď schvalování zabere nízké jednotky dnů – většinou maximálně 2 dny. Ale je to pár let zpátky, co ten proces zabral 7 dní a nešlo to rychleji. To bylo velmi nekomfortní. V tomhle ohledu je na tom Android lépe.
🤖 David: Tady bych jen doplnil Honzu, že Android na tom býval lépe. Teda je otázka, co je vlastně to lepší, protože dřív neexistoval žádný review proces. 😃 Jakákoliv aplikace, která se do Google Play Store nahrála, byla uživatelům dostupná. Tím pádem i potenciálně nebezpečné aplikace s malwarem. Ale Google v posledních letech po vzoru Apple začal zavádět právě ten review proces. Akorát je vidět, že Apple je v tom o dost napřed. Pokud při schvalování nastane nějaký zádrhel, vývojář obdrží email, že appka porušuje nějaké pravidlo z dvaceti různých. Neřeknou, o které konkrétně se jedná. Komunikovat s nějakým člověkem z Googlu je skoro nemožné, většinou odepíše nějaký robot. Je to pak spíš takový pokus – omyl, jestli update, který vydám, má opravené právě to, co mu bylo vyčteno. S tímhle v posledních letech svět vývojářů Androidu bojuje. U nás naštěstí tolik problémů nemáme, ale své zkušenosti už také máme.
Vydávání máte na starosti vy jako team leadeři?
🤖 David: Aplikaci do storu většinou nahráváme my vývojáři a ten release samotný si řeší klient nebo projekťák. Nebo aspoň tak je to u nás na Androidu.
🍏 Honza: Stejně tak je to i na iOS.
Platí stále to, že by Android mohl být v ohledu bezpečnosti při stahování aplikací méně bezpečný?
🤖 David: Tím, že Google zavedl ten Review proces, je tam velká snaha minimalizovat potenciální hrozby. Google má striktní guidelines, jak se aplikace mohou chovat po nainstalování – například aplikace nemůže zobrazovat reklamy v notifikacích. Z tohohle pohledu ty aplikace tedy nejsou nebezpečnější oproti iOS. Google zároveň do operačního systému přidává nové možnosti, jak uživatel může chránit svůj obsah, čímž uživatelům opět pomáhá kontrolovat svá data. Například jedna z posledních novinek je to, že aplikace již nemůže číst GPS polohu bez uživatelova vědomí. Díky těmto krokům si myslím, že iOS i Android jsou na tom z hlediska bezpečnosti velmi podobně.
Nicméně na Androidu stále platí to, že uživatel si může aplikaci nainstalovat “bokem”, tedy pouze přes soubor APK a nenainstaluje si ji z Google Play Store. Musí pro to povolit několik nastavení v systému, ale jakmile to udělá, může si takto nainstalovat aplikaci, která by normálně review procesem vůbec neprošla. Je tu tedy stále vyšší bezpečností riziko než u iOS, ale uživatel musí vyvinout značnou snahu, aby toho docílil.
Zůstaňme u toho bezpečí – jak je to se zabezpečením dat, když chci v aplikaci uložit citlivá osobní data?
🍏 Honza: Na iOS to zabezpečení zas tolik neřešíme, ale to ne proto, že bychom na to kašlali, ale spíš z toho důvodu, že iOS je sám o sobě velmi dobře zabezpečený. Ukrást nějaká data z iOS aplikace je samo o sobě složité, takže my tam nemusíme přidávat moc dalších vrstev zabezpečení.
🤖 David: Android to má dost podobně, protože aplikace nemají přístup k privátním datům jiných aplikací. Je to stejné, jako když si telefon připojím k počítači – data si také nemohu přečíst a zkopírovat. Jsou chráněna přímo systémem. Pokud se nejedná o aplikaci, kde je bezpečnost kritická (například bankovní aplikace), není třeba dodávat žádné další vrstvy zabezpečení. U těchto citlivých aplikací můžeme například detekovat, zda má uživatel “rootnutý” telefon, a znemožnit mu naši aplikaci používat či další bezpečnostní kontroly. Obecně ale uživatele nechceme omezovat v používání naší aplikace a tedy záleží appka od appky, jakou úroveň zabezpečení zvolíme.
Jakou používáte architekturu? Je to MVVM?
🤖 David: Ano, používáme MVVM, což je architektura, kterou Google v posledních letech doporučuje jako architekturu pro vývoj Androidích aplikací a poskytuje k ní podpůrné knihovny, tutoriály atp. Tahle architektura ale určuje pouze rozdělení vrstev na tzv. prezenční, tedy zobrazovací vrstvě. Za písmenkem M z MVVM se skrývá celá další architektura, kterou je třeba nějak řešit. My na Androidu používáme tzv. clean architecture, kterou před pár lety představil Uncle Bob Martin, což je v programátorském světě docela známá postavička. Tahle architektura nám umožňuje aplikace psát “čistě” a škálovatelně.
🍏 Honza: My na iOS taky používáme MVVM jako základní návrhový vzor té aplikace, na kterém stojí její hlavní logika. Ale je to samozřejmě ještě podpořené dalšími design patterny, které jsou hlavně právě v tom “eMku”, jak už říkal David.
Kromě toho, že aktuálně používáme MVVM, tak dost pokukujeme po reduxové architektuře a snažíme se ji nějak implementovat. A mám pocit, že i Android kouká tímhle směrem, ale je to pořád ještě dost otázka budoucnosti.
🤖 David: Jojo, u nás se té reduxové architektuře říká MVI (Model View Intent), a myslím si, že jakmile u nás bude stabilní Jetpack Compose, což je obdoba iOSího Swift UI, tak se ta naše architektura taky posune spíš tímhle směrem.
Jak programujete vzhled obrazovek?
🍏 Honza: My děláme UI výhradně v kódu. Nepoužíváme storyboardy ani interface builder, a to z mnoha důvodů, ale to je na dlouhý povídání. Každopádně Apple nedávno přišel s úplně novým systémem tvorby UI – SwiftUI – který nahrává právě těm reduxovým architekturám, takže až se víc rozšíří, tak nám ani nezbyde nic jiného, než nějakou tu reduxovou architekturu začít používat.
🤖 David: Tady mají na iOS velkou výhodu, že jim Apple SwiftUI představil v jakž takž stabilní podobě a dal se rovnou používat. Google nám ve stejný čas představil také nový UI framework po vzoru Reactu či Flutteru zvaný Jetpack Compose, ale jen ve formě developer preview, release verze bude možná v průběhu tohoto roku. V současné chvíli tedy nemůžeme tenhle framework využívat v produkčních aplikacích, protože není stabilní. Což ale neznamená, že bychom ho mezitím nezkoumali, protože samozřejmě chcem být připravení, jakmile to půjde. ????
Nicméně s definicí UI v kódu oproti tradičnímu způsobu skrz XML máme v posledních letech bohaté zkušenosti. Potom, co jsme v roce 2017 adoptovali Kotlin, jsme zavedli knihovnu Anko od JetBrains, která UI definuje přímo v Kotlinu. Usnadnilo nám to dost věcí, protože jsme mohli využívat všechny výhody Kotlinu a nebyli jsme omezení XMLkem. Bohužel JetBrains přestali kvůli blížícímu se releasu Jetpack Compose Anko podporovat a v současné době je deprecated. Vracíme se tedy zpět k XML, dokud nebude Compose stable. Nicméně tím, že máme zkušenosti s definicí UI v kódu, pro nás přechod na Compose nebude takový skok.
Využíváte i reaktivní programování?
🍏 Honza: Používáme ho, a to už opravdu dlouho. V poslední době je to hodně trendy, ale my jsme to v podstatě používali už v Objective-C. Tenkrát jsme používali Reactive Cocoa, které se už dnes jmenuje ReactiveObjective-C a jehož další verze je ReactiveSwift. Z historických důvodů nepoužíváme RxSwift, který je rozhodně rozšířenější, ale už zmíněný ReactiveSwift, který vychází právě z ReactiveObjective-C.
🤖 David: My ho používáme taky už několik let, tak čtyři, možná i víc. Začali jsme v té době s nejrozšířenější knihovnou RxJava, tenkrát ve verzi 1. Poté jsme přešli na RxJava 2, která je součástí většiny našich aplikací. Během posledních let JetBrains představili svůj koncept reaktivního programování jako součást Coroutines, což je nativní framework pro paralelní programování v Kotlinu. Nám dává smysl používat přímo něco, co je součástí jazyka, ve kterém vyvíjíme, než knihovnu třetí strany, takže poslední rok už v aplikacích používáme Coroutines.
Ruční správa paměti už se neřeší, nebo je to ještě téma? Kdy se to změnilo?
🍏 Honza: Situace na iOS je, řekl bych, už dost vyřešená. K tomu došlo už ve verzi iOS 4 nebo 5, což je opravdu spoustu let zpátky, kdy tam Apple přidal ARC. Díky tomu je ta práce s pamětí mnohem pohodlnější, vyloženě ručně už se to neřeší. Nicméně i tak je potřeba vědět, jak ARC funguje a jak se k tomu chovat, aby tam nevznikly nějaké memory leaky. Rozhodně to není bez práce, že by se to neřešilo vůbec.
🤖 David: Android z Javy převzal koncept Garbage collection, takže manuální uvolňování paměti řešit nemusíme. Ale jak říká Honza, i když to za nás řeší framework, vývojář musí vědět, jak tenhle systém funguje, protože když s pamětí zachází nešikovně, může vzniknout takzvaný “memory leak”, který garbage collector nedokáže uvolnit. V paměti pak tedy zůstávají viset části aplikace, která se nikdy neuvolní a systém po čase takovou aplikaci shodí pro nedostatek paměti. Ale na to, jak memory leaky hledat a eliminovat, máme naštěstí několik dobrých nástrojů, ať už od komunity nebo od Googlu, takže jsme na tom teď nejlíp, co jsme kdy byli.
V čem na vaší platformě spočívá výhoda nativního vývoje?
🍏 Honza: Tak Davide, tuhle otázku nechám asi tobě, protože ty jsi expert na multiplatformní vývoj.
🤖 David: Já myslím, že nutně nezáleží na dané platformě, tak odpovím obecně za obě. O tom, kdy se vyplácí psát aplikaci nativně a kdy ne, máme i blog, takže to jen rychle shrnu. Multiplatformní vývoj se vyplácí tehdy, kdy aplikace nedělá žádné “speciální” věci jako např. přístup k fotoaparátu, senzorům nebo práce s rozšířenou realitou. V podstatě jen zobrazuje data, které se pošlou ze serveru, a maximálně je lehce zpracovává. V tu chvíli se může zdát, že bude lepší sáhnout po nějakém multiplatformním řešení, jako je React Native či Flutter. Já osobně mám zkušenosti s React Native, vyvinul jsem v něm několik aplikací, které jsou ve storech. Bohužel to, co se na začátku jeví jako největší výhoda – tedy že vám stačí jeden vývojář, abyste vyvinuli appku na dvě platformy – úplně neplatí. Často jsem musel otravovat třeba tady Honzu, aby mi pomohl s problémem, který jsem řešil na iOS. Anebo někoho z našeho frontend týmu, protože jsem nevěděl, jak něco udělat v Javascriptu, ve kterém se React Native píše. Pak je tam ještě celá další oblast problémů, které přináší samotný React Native a které jsem musel řešit sám. Takže v podstatě to nevyžaduje jen jednoho člověka, ale potřebujete Androiďáka, iOSáka a Frontenďáka. 😃 Rozhodně se tedy strávený čas na vývoji aplikace nedělí dvěma.
Další možností je využít framework od Google Flutter. S tím máme zatím zkušenosti pouze ve formě crowd learningu, kde se společně snažíme framework naučit a zjistit, na jaké use casy by se nám hodil a zda ho lze na některé aplikace využít. Ale máme za sebou teprve pár týdnů lekcí, tak uvidíme, co nám naše bádání přinese.
A kde čerpáte inspiraci? Kromě lidí v týmu – to vždycky říká každý! :D (Ne že by to teda nebyla pravda).
🤖 David: Teď jsi mi sebrala odpověď. 😃
🍏 Honza: Já bych to rozdělil na dvě části. První je technická inspirace, kterou už čím dál víc čerpám právě z týmu. Hodně členů už je na tom technicky o dost líp než já, protože já už se tomu programování věnuji čím dál míň. A pak samozřejmě z Twitteru, různých blogů a podcastů, co poslouchám, asi jako všichni. Druhá část je teamleaderovská – u té nejvíc čerpám z toho, co nás naučila Irena. A také hodně sleduju síť Red Button.
🤖 David: No, já vlastně nevím, co bych k tomu doplnil. V té technické části jsou to newslettery, podcasty, blogy, videa a lidi z týmu, kteří sami přicházejí s novými věcmi, to jsem na tom stejně jako Honza. Poslouchám i podcasty a čtu knížky, které jsou zaměřené na vývoj lidí a týmu. Tam také nejvíc čerpám ze setkání s Irčou.
Tak i tak musím říct, že největší inspirací mi jsou ostatní teamleadeři v Ackee. Když čtu knížky nebo poslouchám zahraniční podcasty, často se jedná o jinou kulturu, která se na české prostředí anebo na Ackee nedá úplně namapovat. Pokud mi ale kolega řekne, co mu funguje v jeho týmu, tak to pravděpodobně bude podobné i v našem, a takové rady jsou nejcennější.