Ponad rok temu poinformowaliśmy naszych klientów o tym, że pracujemy nad wypuszczeniem naszej aplikacji dla urządzeń z systemem operacyjnym iOS. Mieliśmy już w pełni funkcjonalną aplikację na systemy Android, więc byliśmy przekonani, że już niebawem ukaże się analogiczna wersja dla użytkowników urządzeń Apple. Wbrew naszym oczekiwaniom aplikacja ukazała się w wersji beta dopiero w tym roku. Dlaczego? W tym wpisie wyjaśniamy trudności, które napotkaliśmy na naszej drodze!
Krok 1: Poproś o pomoc specjalistę
Z początkiem września 2019 roku rozpoczęliśmy współpracę z zewnętrznym partnerem w celu stworzenia multiplatformowego stacku dla systemów Android i iOS. Dzięki zastosowaniu tej technologii duża część kodu źródłowego aplikacji na te dwa najpopularniejsze mobilne systemy operacyjne byłaby wspólna, co ułatwiłoby dalsze utrzymanie i rozwój apki. Wszystko szło stosunkowo gładko aż do marca 2020 roku, kiedy przygotowano proof of concept z wykorzystaniem stworzonej przez Google technologii Flutter. W OneMeter zawsze stawialiśmy na nowoczesne technologie, więc perspektywa wykorzystania frameworku rozwijanego przez “giganta z Mountain View” wydawała się obiecująca. Zaczęliśmy więc tworzyć nowe wersje aplikacji na Androida i iOS, głównie przygotowując grafikę i badając komunikację BLE podczas korzystania z tej technologii. Rozwój został wstrzymany w związku z informacją od zewnętrznego partnera o zakończeniu prac nad nowym stackiem komunikacyjnym z wykorzystaniem Kotlin Multiplatform.
Krok 2: Synergia pracy dwóch zespołów
W kwietniu rozpoczął się rozwój aplikacji na iOS. Zapewniliśmy wsparcie zewnętrznemu partnerowi w zakresie rozwoju iOS i rozpoczęliśmy integrację nowego stacku z naszą obecną aplikacją na Androida. Podczas rozwoju napotkaliśmy kilka problemów, których wcześniej nie byliśmy w stanie przewidzieć, co znacząco spowolniło prace. Utknęliśmy, rozwiązując jedynie drobne przeszkody takie jak logowania Apple ID i Facebooka czy też obchodzenie braków w bibliotece do obsługi multiplatformowego kodu.
Krok 3: Zrób to sam
Nie widząc postępów w naszej współpracy z dotychczasowym partnerem technologicznym, postanowiliśmy we wrześniu 2020 kontynuować prace nad aplikacją samodzielnie. Początkowe założenia, iż do istniejącego kodu musimy dodać jedynie funkcje aktualizacji oprogramowania i kilka drobnych poprawek, okazały się jedynie życzeniem. Zmian było znacznie więcej. Wcześniej nie pracowaliśmy z aplikacjami na iOS i wiele rzeczy stanowiło dla nas wyzwanie. Byliśmy zaskoczeni, że nie możemy łatwo wprowadzać zmian w stacku wieloplatformowym, a niektóre zmiany całkowicie psują aplikację. Debugowanie i badanie problemów zajęło wiele dni. W wyniku przeprowadzonej analizy, dowiedzieliśmy się, dlaczego aplikacja ma problemy w wielu miejscach. Zaczęliśmy zgłaszać problemy w bibliotekach i uzyskiwać wsparcie od ich wydawców ale zrozumienie natury tych problemów zajęło dużo czasu:
1. Większość prac związanych z tworzeniem kodu wieloplatformowego dotyczyła Androida
Wiele problemów i niedociągnięć Kotlin Native było dla nas nieznanych w wyniku zastosowania Kotlin JVM, który jest najbardziej przetestowaną i stabilną wersją języka. Kotlin Native ma zupełnie inny model pamięci i niektóre biblioteki nie działają na nim tak samo.
2. Niedojrzałość bibliotek
Zastosowana przez nas biblioteka Ktor sprawiała wiele problemów. W dalszym ciągu wiele błędów spowodowanych przez nią czeka na naprawę. Nowa wersja rozwiązuje niektóre problemy i umożliwia funkcjonowanie nowej aktualizacji programu i wersji językowej. Część bibliotek jest kompatybilna tylko z Kotlin JVM i jesteśmy zmuszeni szukać alternatyw oraz nauczyć się ich używać. Niektóre funkcje nie są obsługiwane i musimy je wdrożyć samodzielnie.
3. Kotlin 1.4
Wydanie Kotlin 1.4 niesie ze sobą wiele korzyści i wiele problemów. Pozwoliło nam to na lepsze i łatwiejsze zarządzanie bibliotekami używanymi w zasobach wieloplatformowych. Wprowadził typy generyczne atrybuty objc i wprowadził wiele zmian w modelu pamięci Kotlin Native, szczególnie w iOS. Powodowało to awarie aplikacji iOS częściej niż oczekiwaliśmy. Ten błąd występował w poprzedniej wersji języka i przyczyniał się do powstawania zakłóceń niektórych funkcji aplikacji, ale nie powodował awarii całości. Musieliśmy więc poświęcić więcej czasu na jednorazowe rozwiązanie tego problemu, a to przyczyniło się do opóźnienia całości przygotowań nowej wersji aplikacji.
4. Istota rozwiązania
Trudność w implementacji niektórych funkcjonalności wynika również ze sposobu działania naszego ekosystemu. Urządzenie OneMeter komunikuje się z telefonem za pomocą zaimplementowanego przez naszych programistów protokołu technologii BLE. Aplikacja OneMeter to rozwiązanie składające się z wielu elementów. To nie tylko interfejs do obsługi bezprzewodowego urządzenia audio czy prosta przeglądarka danych. Zaimplementowanie komunikacji między urządzeniem zewnętrznym tego typu a smartfonem to dość pracochłonny proces, a mnogość różnych typów liczników poszczególnych producentów dodatkowo wydłuża procedury testów kompatybilności. Wdrażanie nowych elementów aplikacji dodatkowo komplikują ograniczenia dot. komunikacji bezprzewodowej różnych systemów operacyjnych (iOS, Android) zmieniane wraz z aktualizacjami tych systemów (np. w celach poprawy zabezpieczeń czy wydłużenia czasu pracy na baterii).
Obecnie wypuściliśmy już dwie beta wersje naszej aplikacji na iOS i nie zwalniamy tempa, mając nadzieję, że w niedalekiej perspektywie ukaże się kompletna aplikacja w sklepie Apple. Jesteśmy na etapie rugowania poszczególnych błędów i wdrażania funkcjonalności, które zapewnią intuicyjne korzystanie z naszej aplikacji.
