Shipping Feyz: aplikacja do refleksji religijnej w React Native, od projektu pobocznego do sklepów
Jak baza kodu TypeScript React Native umożliwiła przeniesienie Tawakkul na Feyz dzięki zarządzaniu sklepem, lepszej wydajności na starszych urządzeniach oraz interfejsowi użytkownika sprzyjającemu skupieniu.
Wielu inżynierów ma skryty cel, jakim jest doprowadzenie niezależnego pomysłu z pustego repozytorium aż do publicznych sklepów aplikacji. Ten etap może wydawać się odległy przez długi czas. Dzięki produktowi mobilnemu wieloplatforamowemu o nazwie Feyz – który początkowo nosił roboczą nazwę Tawakkul – ten cel stał się gotowym plikiem binarnym dostępnym w App Store i Play Store. Wśród projektów React Native ten wyróżnia się szczególnym znaczeniem, ponieważ skłonił do podjęcia decyzji produkcyjnych, a nie tylko do korzystania z przykładowych rozwiązań.
Pochodzenie produktu i wyraźniejszy kierunek interfejsu
Feyz nie pojawił się znikąd. Postępy przyspieszyły po współpracy z kolegą-developerem, który przedstawił wieloplatforamowe frameworki natywne i oferował ciągłe wsparcie podczas początkowego okresu nauki.
Wizją produktu było stworzenie schludnego środowiska o minimalnych rozpraszaczach, które pomoże ludziom łączyć duchową świadomość z codzennymi refleksjami wierzącymi w tłumie obowiązków. Analiza istniejących aplikacji z tej samej kategorii ujawniła poważną lukę. Wiele z nich albo ukrywało dobre doświadczenie użytkownika pod chaotycznymi, przestarzałymi interfejsami, albo odwracało uwagę przez powolne, słabo zoptymalizowane elementy. To, co zaczęło się jako szkic małej aplikacji pomocniczej, rozwinęło się w skoncentrowany projekt o wyższych standardach jakości.
Wybór React Native dla obu platform
Planowanie wdrożenia rodziło typowe pytanie: oddzielne bazy kodu natively w Swift i Kotlin, czy wspólny podejście międzyplatformowe. React Native okazał się lepszy pod względem logistyki – pojedyncza baza kodu w TypeScript, która generuje binarne pliki interfejsu natively dla Androida i iOS, skraca czas realizacji projektu i eliminuje dublowanie logiki produktowej.
Projekt stał się również salą lekcyjną do nauki React Native w warunkach rzeczywistych. Praca przeszła poza strukturyzowane kursy wideo i ogólne repozytoria przykładów. Zamiast projektowania statycznych ekranów, skupiono się na asynchronicznym ładowaniu stanu, dynamicznych punktach końcowych oraz komponentach układu, które musiały poprawnie funkcjonować przy różnych gęstościach pikseli.
Architektura rozwoju i zarządzanie po wdrożeniu
Przeniesienie aplikacji wieloplatformowej z lokalnego emulatora do recenzji w oficjalnym sklepie wprowadza zupełnie inne wyzwania. Okazało się, że prosty kod komponentów jest łatwiejszy do zrealizowania. Dojrzałość projektu nadeszła wraz z rozwiązywaniem problemów związanych z wdrażaniem.
Najpierw doświadczenie użytkownika musiało pozostać intuicyjne: usunięto zbędne elementy menu, układ był minimalistyczny, a refleksje duchowe dostępne poprzez jeden prosty w użyciu punkt interakcji. Po drugie, telemetria i przepływ danych wymagały dokładnej kalibracji, aby stan aplikacji był przewidywalny bez blokowania głównego wątku na starszym sprzęcie. Po trzecie, konfiguracja platformy natywnej oznaczała konieczność dostosowania uprawnień Androida, drzew zależności CocoaPods oraz ustawień lokalnych pakietów, aby uniknąć awarii w trakcie działania aplikacji.
Zmiana nazwy z Tawakkul na Feyz była czymś więcej niż tylko kwestią wizualną. W miarę gromadzenia się danych z produkcji oraz stabilizacji profili odbiorców, nazwa Feyz lepiej odzwierciedlała dojrzały, inkluzywny i szerszy charakter produktu. Ta zmiana odzwierciedlała poprawy w jakości kodu i zakresie funkcjonalności, a także rozwój marki.
Czego nauczyło nas wdrażanie o umiejętnościach inżynierskich
Budowa i wypuszczanie aplikacji podważyło przekonanie, że elitarna inżynieria oznacza najsprytniejszą składnię. Wdrożenie rzeczywistego produktu wymaga odsunięcia na bok ego i myślenia jak twórca produktu. Cierpliwość wobec nieprawidłowych ustawień środowiska, spójność w obliczu cykli odrzuceń przez sklep oraz pokora przy przyjmowaniu rzeczywistych opinii użytkowników są ważniejsze niż pokazywanie algorytmów. Ukończenie aplikacji i utrzymanie jej w dobrym stanie w produkcji wymaga dyscypliny, której nie da się nauczyć od samego tworzenia nowego repozytorium. Feyz to już nie tylko folder na GitHubie – jest dowodem na to, że skupiona idea może dotrzeć do linii mety w produkcji.
Próbuj żywych wersji
Inżynierowie, projektanci oraz czytelnicy zainteresowani produktami, którzy chcą przeanalizować interfejs produkcyjny, przetestować renderowanie na różnych platformach lub zgłębić architekturę odzwierciedleń, mogą zainstalować binarne pliki z publicznych sklepów aplikacji Apple App Store i Google Play dostępnych dla Feyz.
Droga od abstrakcyjnego koncepcji do oferty w sklepie pozostaje taka sama dla każdego podobnego projektu pobocznego: należy wybrać zestaw narzędzi, który zapewnia spójność między platformami, projektować z myślą o skupieniu zamiast o mnogości funkcji, a także traktować zasady obowiązujące w sklepach oraz pomiary po uruchomieniu jako elementy pierwszorzędnej pracy inżynierskiej, a nie coś dodanego później. React Native ułatwił wydawanie aplikacji na dwóch platformach; ograniczenia produkcyjne sprawiły, że projekt stał się rzeczywistością. Proces hydratacji, który nigdy nie blokuje starszych urządzeń, uprawnienia, które przetrwają weryfikację, oraz struktury CocoaPods pozostające spójne nie są efektowne, ale one decydują o tym, czy użytkownicy w ogóle będą mogli skorzystać z funkcji odzwierciedleń.
Aplikacja duchowa bez rozpraszaczy zmusza również do drastycznych cięć w funkcjach produktu. Każdy dodatkowy element menu konkuruje o uwagę użytkownika w momencie, gdy otwiera on aplikację na krótką praktykę. Pełna klarowność typograficzna, przewidywalne aktualizacje stanu oraz synchronizacja w tle, która nie przeszkadza, to nie są dodatkowe elementy wykończeniowe – to właśnie jest produkt. Dlatego Feyz dał priorytet prostemu i bezproblemowemu dostępowi do codziennych refleksji zamiast bogatej konsoli z narzędziami pomocniczymi.
Dla zespołów oceniających React Native pod kątem stworzenia aplikacji typu niche o podobnych wymaganiach, lekcja jest praktyczna. Używając wspólnego TypeScript można przenosić logikę interfejsu użytkownika oraz biznesową pomiędzy różnymi platformami, ale nadal pojawiają się problemy związane z integracją: wymagania dotyczące uprawnień na Androidzie, grafy zależności w iOS oraz różnice pomiędzy urządzeniami. Należy wcześnie przeznaczyć czas na rozwiązanie tych problemów. Budowy w emulatorze należy traktować jako etap pośredni, a nie cel końcowy. Procesy przechowywania aplikacji, notatki o odrzuceniach oraz testy wydajności na starszych urządzeniach to elementy, które sprawiają, że projekt poboczny staje się aplikacją w pełni utrzymywaną.
Aplikacje należące do pojedynczych właścicieli uczą również odpowiedzialności za cały proces – od koncepcji, przez projekt interfejsu użytkownika, moduły TypeScript, konfigurację natywną, proces składania aplikacji aż po jej działanie w czasie rzeczywistym. To właśnie ten proces przekształca abstrakcyjny cel w coś, co użytkownicy mogą pobrać już dziś.
Literatura pokrewna
- Bare React Native, Expo czy Flutter: dopasowanie stacku mobilnego do zespołu — Praktyczne porównanie Bare React Native, Expo i Flutter: jak wyglądają w kodzie, gdzie sprawiają problemy oraz pięciopytowa metoda do wyboru między nimi.
- Flutter kontra React Native: decyzje, które pojawiają się tylko w środowisku produkcyjnym — Realistyczne porównanie Flutter i React Native, które pomija walki o najlepsze wyniki testów i skupia się na renderowaniu, języku programowania, stanie aplikacji, listach oraz ekosystemie w miarę jej rozwoju.