social icon social icon social icon social icon social icon

Multiplatformowe aplikacje – o wyzwaniach podczas testów (cz.1)

Według danych opublikowanych przez serwis Statista, w trzecim kwartale 2023 roku na rynku smartfonów liczą się dwa systemy operacyjne – Android oraz iOS. Na trzecim miejscu znajduje się pozycja podpisana „Samsung”. Biorąc pod uwagę zmiany jej popularności na przestrzeni lat można wywnioskować, że w rzeczywistości chodzi o BadaOS. Warto jednak zauważyć, że najpopularniejszy mobilny system operacyjny zajmuje ponad 70% rynku, drugie miejsce oznacza niecałe 29% udziałów. Cała reszta razem to mniej niż 1% działających smartfonów.

Jeśli na wykres, z którego pochodzą powyższe dane, nałożymy filtr usuwający platformy, które utraciły wsparcie twórców i od lat nie mają realnego zastosowania innego niż hobbystyczne, okaże się, że Android i iOS to jedyne systemy operacyjne, dla których warto pisać komercyjne oprogramowanie.

Mogłoby się wydawać, że taka sytuacja znacząco ułatwi proces tworzenia, a następnie testowania aplikacji. Cóż, pewnie tak właśnie jest. Nadal jednak mamy do czynienia z multiplatformowością, co z kolei wiąże się z pewnymi wyzwaniami.

Jak pisać aplikacje na różne platformy mobilne?

Pierwszym problemem, przed którym stają deweloperzy, jest dobór odpowiednich narzędzi. Przede wszystkim, aby skompilować aplikację dla iOS niezbędny jest komputer działający pod kontrolą macOS. A przynajmniej jest to jedyne rozwiązanie zgodne z prawem i licencją Apple. Oznacza to, że aby zespoły piszące ten sam program na różne platformy mogły współpracować, niezbędne jest albo współistnienie dwóch ekosystemów (jeden oparty na sprzęcie z sadu i drugi stworzony z komputerów PC operujących na Windowsie lub Linuksie), albo ujednolicenie parku maszynowego. Żadne z tych rozwiązań nie pozostaje jednak pozbawione wad.

Kolejną decyzją, przed którą stają deweloperzy, jest wybór odpowiedniego języka programowania. Tutaj na szczęście można przebierać wśród szerszej gamy opcji. Lepiej jest zdecydować się na technologię obsługiwaną przez niemal wszystkie istniejące platformy (nawet te zapomniane), czy coś dedykowanego konkretnemu systemowi?

Natywnym językiem dla iOS jest Swift, zaś dla Androida Kotlin oraz Java. Oczywiście, istnieją odpowiednie narzędzia pozwalające na stosowanie wymienionych wyżej technologii multiplatformowo, ale tylko w ograniczonym zakresie. Kompilator Swifta dla Androida obsługuje jedynie niektóre architektury procesorów, zaś iOS nie posiada natywnej maszyny wirtualnej Java. Problem ten można częściowo obejść, pisząc kod w jednym z wielu innych języków wspieranych przez oba systemy. Nie jest to jednak tak proste, jak mogłoby się wydawać. Aplikacje nie są samodzielne, wykorzystują biblioteki zaimplementowane w system operacyjny na którym są uruchamiane. Nawet jeśli logika programu zostanie napisana w jednym z uniwersalnych języków, niezbędne jest dołączenie modułów w Swifcie lub Kotlinie, aby odwołać się do pamięci czy odpowiednich instrukcji procesora. Czasy, gdy cały rynek komputerów domowych oparty był o chip MOS 6502, minęły. W świecie procesorów ARM funkcjonuje wiele mikroarchitektur, zatem znany z iPhone 15 układ A17 Bionic jest tylko częściowo kompatybilny ze Snapdragonem 8 Gen 2 napędzającym Samsunga S23. A to dopiero początek problemów.

Aplikacja musi działać

Chciałbym napisać, że w poprzednim akapicie omówiono całą problematykę kompatybilności kodu między platformami, ale to byłaby nieprawda. W rzeczywistości tematy poruszone powyżej to jedynie wierzchołek góry lodowej. Aspekt techniczny jest istotny, ale nie da się opisać różnic w programowaniu na różne platformy bez uwzględnienia aspektu ideowego.

Apple kładzie duży nacisk na optymalizację kodu. Sami dają tu dobry przykład, choćby poprzez wyrzucanie z systemu sterowników i procedur, które nie są już potrzebne. Dzięki temu kolejne odsłony iOS, wydawane w rocznych cyklach, mają stosunkowo niewielki bagaż kompatybilności wstecznej. Jednocześnie, takie działanie niejako wymusza na deweloperach wykorzystywanie nowych technologii i dostosowywanie aplikacji do zmian w systemie.

Fragmentacja rynku smartfonów z Androidem jest o wiele większa niż iPhone’ów. W maju 2023 roku aż 81% smartfonów od Apple korzystało z najnowszej wówczas wersji systemu, zaś wydania starsze niż dwuletnie gościły na 6% aktywnych urządzeń. Dla porównania, najnowsza wersja Androida gościła w październiku 2023 roku na mniej niż 37% urządzeń, zaś ponad 42% smartfonów napędzanych jest przez zielonego robota w wersji starszej niż ta z 2021 roku. Tak wysoki odsetek wynika z braku odgórnych regulacji wymuszających odpowiednio długi cykl aktualizacji. Skutkiem jest konieczność sztucznego zachowywania wstecznej kompatybilności, co utrudnia nie tylko pisanie, ale również optymalizację aplikacji.

Nie można zapominać o tym, że Google niejako zrzuca z siebie odpowiedzialność za zapewnienie stabilnego działania ich produktu, co jest nieuniknione przy tak ogromnej liczbie konfiguracji. Deweloperzy muszą zadbać o to, by stworzone przez nich programy radziły sobie na niskopółkowych SoC Mediateka i flagowych Snapdragonach. Aby wyświetlały się poprawnie niezależnie od proporcji ekranu ani jego kształtu (w tym zakrzywień, dziur i notchy). W przypadku iPhone jest to o tyle ułatwione, że obecnie funkcjonuje mniej niż 10 konfiguracji wyświetlaczy, zaś programy mają zdefiniowanych kilka sposobów wyświetlania interfejsu zależnych od modelu.

U mnie działa inaczej

Przechodzimy do ostatniej z głównych różnic między aplikacjami na iOS i Androida. Jest nią obsługa. Steve Jobs wyznawał zasadę „jeden przycisk – lub mniej”. Stąd iPhone wykorzystywały do nawigacji pojedynczy klawisz, służący do przywoływania ekranu głównego. Pozostałe akcje, takie jak cofanie, uruchamiano w sposób zdefiniowany przez twórców. Inna sprawa, że zazwyczaj było to umieszczone w lewym górnym rogu pole dotykowe, aby zachować spójność wewnątrz systemu. Dość wcześnie zaczęto też implementować gesty.

Dla porównania, Android od zawsze stosował dedykowany klawisz cofania. Menu kontekstowe wywoływało się nie gestem ani przytrzymaniem palca, lecz kliknięciem odpowiedniej ikony. Co więcej, w systemie od Google o wiele wcześniej zaimplementowano widżety, do dziś ich obsługa jest o wiele bardziej zaawansowana niż w iOS. Potrafią więcej, są bardziej elastyczne.

Wiele różnic w obsłudze wynika z historii obu systemów. Android zaczynał jako oprogramowanie dla aparatów cyfrowych, pierwotnie nie miał nawet zaimplementowanej klawiatury ekranowej, domyślnym sposobem jego obsługi były przyciski. Interfejs iPhone’a był za to stworzony do obsługi za pomocą ekranów dotykowych.

Jak przetestować aplikacje dla tak różnych platform?

Mam nadzieję, że lektura powyższego artykułu ułatwi zrozumienie problematyki tworzenia wieloplatformowych aplikacji mobilnych. Teraz, gdy wiecie, na co należy zwrócić uwagę tworząc program działający na różnych mobilnych systemach operacyjnych, można przejść do kolejnego etapu. Mianowicie, do rozważań nad wyzwaniami, które są stawiane przed testerami multiplatformowych aplikacji. A o tym już wkrótce na naszym blogu!

https://www.statista.com/statistics/272698/global-market-share-held-by-mobile-operating-systems-since-2009/
https://www.statista.com/statistics/565270/apple-devices-ios-version-share-worldwide/
https://gs.statcounter.com/android-version-market-share/mobile/worldwide/

Zgoda na pliki cookie według RODO z Real Cookie Banner