Aplikacje mobilne

Aplikacja mobilna ma sens wtedy, gdy użytkownicy korzystają z produktu często, w ruchu albo potrzebują funkcji telefonu: powiadomień, aparatu, lokalizacji czy pracy bez internetu. Budujemy wieloplatformowe aplikacje na iOS i Android, które korzystają z jednego kodu i łączą się z systemami, których firma już używa.

01Natywnie czy wieloplatformowo

Pierwsza decyzja dotyczy technologii. Aplikacja natywna powstaje osobno dla iOS (Swift) i dla Androida (Kotlin). Daje pełny dostęp do możliwości systemu, ale oznacza dwa kody do napisania i utrzymania. Podejście wieloplatformowe pozwala napisać większość aplikacji raz i wydać ją na obie platformy.

Najczęściej pracujemy w dwóch technologiach wieloplatformowych:

• React Native renderuje natywne komponenty interfejsu, a logikę pisze się w TypeScripcie. Dobrze sprawdza się w aplikacjach, które mają wyglądać i działać jak natywne.
• Capacitor uruchamia aplikację webową w natywnej powłoce z dostępem do funkcji urządzenia. To dobry wybór, gdy firma ma już aplikację webową i chce wykorzystać jej kod.

Dla większości aplikacji biznesowych podejście wieloplatformowe wystarcza. Aplikację natywną rozważamy, gdy projekt wymaga głębokiego dostępu do funkcji systemu albo bardzo wymagającej grafiki. Porównanie obu podejść opisujemy szerzej w artykule natywnie czy hybrydowo, a o samym Capacitorze piszemy w osobnym wpisie.

02Jak wygląda projekt

Pracujemy w siedmiu etapach: odkrycie, strategia, design, rozwój, testy, wdrożenie i skalowanie. Zaczynamy od użytkowników: kto korzysta z aplikacji, w jakich sytuacjach i czego potrzebuje w telefonie, a czego nie. Aplikacja mobilna nie powinna być kopią całego systemu. Lepiej działa, gdy skupia się na kilku zadaniach wykonywanych często i szybko.

Potem projektujemy interfejs z myślą o małym ekranie, obsłudze kciukiem i przerwanej uwadze. Prototypy sprawdzamy na prawdziwych urządzeniach, zanim zaczniemy rozwój. Rozwój prowadzimy iteracyjnie, a kolejne wersje udostępniamy do testów przez TestFlight i ścieżki testowe Google Play, żeby zespół po stronie klienta mógł je sprawdzić na swoich telefonach.

03Offline, synchronizacja i backend

Aplikacje używane w terenie muszą działać także bez zasięgu. Projektujemy je w podejściu offline-first: dane są zapisywane lokalnie na urządzeniu, a po odzyskaniu połączenia synchronizowane z serwerem. Najtrudniejsza część to konflikty, gdy te same dane zmieniono w dwóch miejscach, dlatego zasady ich rozwiązywania ustalamy na etapie projektu.

Aplikacja mobilna prawie zawsze potrzebuje backendu: kont użytkowników, danych, powiadomień push i integracji z innymi systemami. Jeśli firma ma już aplikację webową z dobrym API, aplikacja mobilna może z niego korzystać. Jeśli nie, budujemy backend razem z aplikacją, tak jak przy aplikacjach webowych na zamówienie.

04Publikacja i rozwój

Przygotowujemy aplikację do publikacji w App Store i Google Play: opisy, zrzuty ekranu, ustawienia prywatności i wymagania obu sklepów. Prowadzimy ją przez proces weryfikacji i reagujemy na uwagi recenzentów.

Po publikacji zajmujemy się aktualizacjami, zgodnością z nowymi wersjami iOS i Androida, monitoringiem błędów i kolejnymi funkcjami. Warto zaplanować to w budżecie od początku, bo sklepy regularnie zmieniają wymagania. O tym, jak rozłożyć koszty między pierwszą wersję a pełny produkt, piszemy w artykule o koszcie budowy aplikacji mobilnej.

Chcesz sprawdzić, czy Twoja firma potrzebuje aplikacji mobilnej i w jakiej technologii ją zbudować? Opisz nam, kto i do czego będzie z niej korzystać, a zaproponujemy, od czego zacząć.