Tworzenie wieloplatformowych aplikacji mobilnych

Budujemy aplikacje na iOS i Androida z jednej bazy kodu w React Native: jeden zespół, jeden backend, wydania w obu sklepach jednocześnie. Jeśli Waszemu produktowi lepiej posłuży wersja natywna, powiemy o tym przed wyceną.

Kiedy jedna baza kodu to dobra odpowiedź

Podejście wieloplatformowe sprawdza się, gdy aplikacja opiera się na treściach i zapytaniach do serwera. Słabo działa wtedy, gdy produkt żyje z wymagającej grafiki, ciągłego przetwarzania w tle lub najnowszych funkcji platform.

Potrzebujecie MVP na iOS i Androida i chcecie sprawdzić rynek, zanim zapłacicie za dwie aplikacje natywne
Aplikacja opiera się na feedach, katalogach, formularzach, rezerwacjach, profilach i wiadomościach
Nowe funkcje muszą trafiać do użytkowników iPhone'ów i Androida tego samego dnia
Budżet wystarcza na jeden zespół programistów, a nie na dwa
Wasza platforma webowa potrzebuje aplikacji towarzyszącej z tymi samymi kontami i danymi
Macie aplikację w React Native od innego zespołu, którą trzeba dokończyć lub zaktualizować

Co obejmuje usługa

Ocena platformy

Przed wyceną przechodzimy przez funkcje i mówimy, czy React Native pasuje. Jeśli kluczowa część wymaga kodu natywnego, wskazujemy, gdzie jest i jak dużej części aplikacji dotyczy.

Projekt dla obu platform

Jeden projekt dopasowany do konwencji iOS i Androida: nawigacji, gestów, okien systemowych, działania przycisku wstecz. Nie projekt z iPhone’a rozciągnięty na Androida.

Programowanie w React Native

Wspólny kod ekranów, logiki biznesowej i zapytań do serwera. Pracujemy w sprintach, a każdy kończy się buildem na obie platformy, który możecie zainstalować i wypróbować.

Moduły natywne

Tam, gdzie wspólny kod nie sięga wystarczająco daleko – SDK dostawcy, funkcja sprzętowa czy praca w tle – piszemy moduły natywne w Swift i Kotlin i podłączamy je do aplikacji.

Jeden backend dla obu aplikacji

API, baza danych, panel administracyjny i powiadomienia push budowane raz i używane przez obie aplikacje, a także przez wersję webową, jeśli jej potrzebujecie. Python lub PHP (Laravel), dobrane do zadania.

Testy, publikacja i aktualizacje

Testy na prawdziwych iPhone’ach i telefonach z Androidem, publikacja w App Store i Google Play oraz aktualizacje po starcie, w tym podnoszenie wersji React Native i jego bibliotek.

Gdzie podejście wieloplatformowe działa, a gdzie nie

Jedna baza kodu na iOS i Androida kosztuje zwykle wyraźnie mniej niż dwie aplikacje natywne i zajmuje mniej czasu, bo większość kodu, projektu i testów jest wspólna. Ten kompromis działa, gdy aplikacja wyświetla treści, listy i formularze oraz komunikuje się z serwerem. Działa słabo, gdy produkt opiera się na interfejsach pełnych animacji, funkcjach opartych na aparacie, długim przetwarzaniu w tle lub API platform, które najpierw trafiają do natywnych SDK. Mówimy, który z tych przypadków dotyczy Waszego produktu, przed wyceną, a nie po pierwszym wydaniu.

Dobrze pasuje: aplikacje z treściami, katalogi, marketplace'y, aplikacje do rezerwacji i usług
Dobrze pasuje: MVP, które od pierwszego dnia musi być w obu sklepach
Lepiej natywnie: wymagająca grafika i animacje, funkcje oparte na aparacie
Lepiej natywnie: ciągła praca w tle i najnowsze API platform

Jeden zespół, jeden backend, jeden kalendarz wydań

Przy dwóch aplikacjach natywnych utrzymujecie dwie bazy kodu, dwa zestawy błędów i często dwie daty wydań. W React Native funkcję pisze się raz i trafia ona do obu sklepów jednocześnie, a za obie platformy odpowiadają ci sami ludzie. Część serwerowa też jest wspólna: jedno API i jeden panel administracyjny obsługują obie aplikacje i w razie potrzeby klienta webowego. Tak właśnie zbudowano Metacognit.me, aplikację do korekcji metapoznawczej i diagnostyki psychotypu: klient w React Native na iOS i Androida oraz backend w Pythonie.

Gotowość na przejście na natywne rozwiązanie, jeśli kiedyś nastąpi

Start z podejściem wieloplatformowym niczego nie blokuje. Backend i API przetrwają przejście na natywne aplikacje, kod klienta – nie. Dlatego projektujemy API tak, aby przyszły klient natywny lub webowy mógł z niego korzystać bez zmian, a części specyficzne dla platform izolujemy w modułach natywnych. Przeprowadzaliśmy migracje w obu kierunkach. Dla Quaker, aplikacji kulinarnej firmy zajmującej się dostawą jedzenia w Dubaju, zastąpiliśmy aplikację hybrydową na przestarzałej technologii dwoma natywnymi klientami, gdy różnice między platformami zaczęły mieć znaczenie dla produktu.

API zaprojektowane tak, by obsłużyć każdego przyszłego klienta, natywnego lub webowego
Kod specyficzny dla platform wydzielony w modułach natywnych
Uczciwy sygnał, gdy aplikacja wyrasta ze wspólnej bazy kodu
Konta i dane, które idą za produktem, niezależnie od tego, w czym napisano klienta

Jak przebiega projekt wieloplatformowy

Ocena i wycena

Przechodzimy przez funkcje i integracje i sprawdzamy, co wymaga kodu natywnego. Dostajecie pisemny zakres, rekomendację – React Native czy natywnie – oraz wycenę.

Projekt

Prototyp i ostateczny interfejs dopasowane do obu platform. Zatwierdzacie ekrany na iOS i Androida przed rozpoczęciem programowania.

Programowanie

Najpierw wspólny kod, moduły natywne tam, gdzie są potrzebne, a backend równolegle. Po każdym sprincie instalujecie świeże buildy na obu platformach.

Testy na urządzeniach

Testy na prawdziwych iPhone’ach i telefonach z Androidem z różnymi ekranami i wersjami systemów. Dostajecie jedno przetestowane wydanie dla obu sklepów.

Publikacja i wsparcie

Publikacja w App Store i Google Play na Waszych kontach, a potem aktualizacje, poprawki i podnoszenie wersji frameworka tak długo, jak tego potrzebujecie.

Technologie

Wieloplatformowo

Moduły natywne

Backend i API

Jak możemy współpracować

Stały zakres

Uzgodniona lista funkcji, wycena i harmonogram dla obu platform. Częsty wybór przy MVP, które ma wystartować w obu sklepach.

Dedykowany zespół

Jeden zespół wieloplatformowy stale pracujący nad Waszą aplikacją. Sprawdza się przy produktach, które często wydają nowe wersje i planują roadmapę sprint po sprincie.

Rozliczenie godzinowe

Płatność za faktycznie przepracowane godziny. Sprawdza się przy audytach istniejącej aplikacji w React Native, podnoszeniu wersji frameworka i mniejszych funkcjach.

Powiązane projekty

Metacognit.mePython, React.Native QuakerKotlin, SWIFT, PHP, Laravel

Opinie

Do każdego klienta i jego projektu podchodzimy uważnie.

Zespół Revol stale usprawnia prace rozwojowe klienta dzięki wysokiej jakości pracy i niezawodnemu wsparciu. Sprawnie się komunikuje i doskonale rozumie potrzeby oraz biznes klienta.

Tomas

CEO (Jukon, Kanada)

Praca Revol w pełni spełniła oczekiwania i zadowoliła klienta. Świeże podejście i stała gotowość do wsparcia okazały się ogromnym atutem. Kto szuka komunikatywnego, zorientowanego na klienta zespołu do realizacji swoich celów, może śmiało na nich postawić.

Andrey

CEO, Stellium (USA)

Najczęściej zadawane pytania

Czy użytkownicy zauważą, że aplikacja nie jest natywna?

W scenariuszach, do których pasuje podejście wieloplatformowe – nie. Tam, gdzie by to zauważyli, na przykład przy interfejsach pełnych animacji, funkcjach opartych na aparacie czy długiej pracy w tle, zalecamy aplikację natywną, zamiast obiecywać, że wspólny kod sobie poradzi.

O ile tańsza jest aplikacja wieloplatformowa niż dwie natywne?

Zwykle wyraźnie tańsza i szybsza, bo większość kodu, projektu i testów jest wspólna. Dokładna różnica zależy od tego, ilu funkcji specyficznych dla platform potrzebuje aplikacja. W wycenie podajemy konkretne liczby dla Waszej aplikacji, a nie ogólny procent.

Czy możemy zacząć wieloplatformowo, a później przejść na natywne aplikacje?

Tak, i przeprowadzaliśmy już migracje w obu kierunkach. Warto zaplanować to wcześnie, bo backend i API przetrwają zmianę, a kod klienta nie.

Czy publikujecie aplikacje w sklepach?

Tak. Przygotowujemy buildy, opisy i metadane, przechodzimy weryfikację w App Store i Google Play i wprowadzamy poprawki, których wymagają recenzenci. Aplikacje są publikowane na Waszych własnych kontach deweloperskich.

Jak jest liczona cena?

Dzielimy aplikację na funkcje, szacujemy każdą w godzinach i dodajemy projekt, backend, testy i publikację. Potem możecie wybrać stały zakres, dedykowany zespół lub rozliczenie godzinowe. Nie publikujemy cen, bo nakład pracy za bardzo różni się między aplikacjami.

Czy możecie przejąć istniejącą aplikację w React Native?

Zwykle tak. Zaczynamy od przeglądu kodu: wersji React Native i bibliotek, modułów natywnych, procesu budowania. Dostajecie jasny obraz stanu aplikacji i tego, czego wymagać będą pierwsze miesiące, w tym czy potrzebna jest aktualizacja, czy częściowe przepisanie.