Sea Spotter — aplikacja mobilna do zgłaszania obserwacji zwierząt morskich

O produkcie

Sea Spotter to aplikacja dla żeglarzy, którzy chcą dzielić się obserwacjami zwierząt morskich — m.in. delfinów, wielorybów i orek. Każde zgłoszenie trafia na wspólną mapę, która pokazuje, gdzie i kiedy zwierzęta były widziane. Użytkownicy mogą zasubskrybować wybrany obszar i dostać powiadomienie, gdy ktoś w pobliżu zgłosi obserwację — w tym ostrzeżenie o interakcjach orek z jachtami.

To nasz własny produkt, dlatego możemy opisać go z nazwy i ze szczegółami.

Mapa obserwacji — Zrzuty ekranu z wersji na iPhone'a — mapa, zgłoszenie obserwacji, najnowsze obserwacje i profil.

Zgłoszenie obserwacji — Zrzuty ekranu z wersji na iPhone'a — mapa, zgłoszenie obserwacji, najnowsze obserwacje i profil.

Jak to zbudowaliśmy

Aplikację zbudowaliśmy w dwa miesiące — od maja do czerwca 2026 roku. Kolejne tygodnie zajęło przygotowanie i przejście procesu publikacji — dziś aplikacja jest dostępna w App Store i Google Play.

Jedna baza kodu, dwie platformy. Aplikacja powstała w React Native (Expo) i TypeScript. Mapy z warstwą cieplną, w której stare obserwacje stopniowo tracą wagę, geolokalizacja, zdjęcia, tryb ciemny i siedem wersji językowych.

Backend na Supabase. PostgreSQL z rozszerzeniem PostGIS liczy zapytania przestrzenne — kto subskrybuje obszar, w którym właśnie pojawiła się obserwacja. Funkcje serwerowe obsługują powiadomienia, synchronizację subskrypcji płatnych i porządkowanie starych zdjęć. Schemat bazy rozwija się przez wersjonowane migracje.

AI tam, gdzie ma sens. Nazwy gatunków są tłumaczone na wszystkie języki aplikacji przez model językowy. Funkcja korzysta z dwóch dostawców i przełącza się automatycznie, gdy jeden nie odpowiada.

Monetyzacja i jakość. Subskrypcje premium w obu sklepach, monitorowanie błędów, testy end-to-end na urządzeniach przed każdym wydaniem, zautomatyzowany proces budowania i publikacji. Do aplikacji dołącza strona produktu z mapą gatunków i dokumentami prawnymi w każdym języku.

Publikacja w sklepach trwa dłużej niż budowa aplikacji

Najbardziej zaskakujący wniosek z całego projektu: wprowadzenie aplikacji do sklepów może zająć więcej czasu niż jej zbudowanie. Kod był gotowy po dwóch miesiącach; publikacja to osobny projekt z własnym harmonogramem, na który programiści mają ograniczony wpływ.

Google Play wymaga od nowego konta deweloperskiego (prywatnego) przeprowadzenia testów zamkniętych z co najmniej 12 testerami przez 14 kolejnych dni, zanim w ogóle można złożyć wniosek o dostęp do produkcji. Pierwszy pełny przegląd nowej aplikacji to zwykle kilka dni roboczych.
App Store pozwala testować wewnętrznie w TestFlight bez przeglądu, ale już testy zewnętrzne przechodzą przegląd beta, a publikacja — pełny przegląd aplikacji.
Formalności po obu stronach: deklaracje dotyczące zbieranych danych (lokalizacja, zdjęcia), polityka prywatności dostępna pod publicznym adresem przed zgłoszeniem, skonfigurowane produkty subskrypcyjne, zrzuty ekranu i opisy — w każdym z siedmiu języków aplikacji.

Wniosek dla klientów: harmonogram projektu mobilnego musi zawierać publikację jako osobny etap, z zapasem czasu i równolegle prowadzonymi formalnościami. Nie da się jej „dokleić” na koniec.

Mapy: dwie platformy, dwa silniki

Na iOS korzystamy z Apple Maps — natywnego komponentu systemu, dostępnego w aplikacjach bez opłat za wyświetlenia mapy. To najprostsza i najtańsza ścieżka: mapa wygląda i zachowuje się tak, jak oczekuje użytkownik iPhone'a.

Na Androidzie wybraliśmy Mapbox, który do określonego progu aktywnych użytkowników miesięcznie nie kosztuje nic, a powyżej nalicza opłatę za każdego użytkownika. Próg monitorujemy i mamy wyznaczony moment, w którym wrócimy do decyzji — wtedy porównamy go ponownie z Google Maps SDK i otwartym MapLibre.

Dwa silniki oznaczają dwie implementacje, więc zamknęliśmy mapę za jednym interfejsem z osobnym plikiem dla każdej platformy. Reszta aplikacji nie wie, który silnik działa pod spodem — a zmiana dostawcy to wymiana jednego komponentu, nie przebudowa aplikacji. Różnice i tak wychodzą w szczegółach: Apple Maps nie mają natywnej mapy cieplnej, więc warstwę cieplną rysujemy sami jako nakładkę SVG, identyczną na obu platformach.

Który dostawca map się opłaca

Ceny dostawców się zmieniają, ale struktura kosztów jest dość stała. Tak oceniamy ją dziś:

Apple MapKit (iOS) — w aplikacjach natywnych bez opłat za wyświetlenia, w ramach członkostwa w programie deweloperskim Apple. Na stronach WWW (MapKit JS) obowiązuje dzienny bezpłatny limit wyświetleń i zapytań. Dla aplikacji na iPhone'a zwykle najlepszy wybór.
Google Maps Platform — samo wyświetlanie mapy w natywnych aplikacjach mobilnych jest dziś bezpłatne, ale płatne są usługi, które zwykle idą w parze z mapą: wyszukiwanie miejsc, geokodowanie, trasy, a także mapy w przeglądarce — każda z bezpłatnym miesięcznym limitem i opłatą za kolejne tysiące wywołań. Opłaca się, gdy potrzebujesz właśnie tych danych Google; koszty rosną z liczbą zapytań, więc trzeba je liczyć od początku.
Mapbox — rozliczenie za aktywnych użytkowników miesięcznie w aplikacjach mobilnych, z bezpłatnym progiem. Duża kontrola nad stylem i warstwami. Opłaca się dla aplikacji, które mieszczą się w progu albo potrzebują własnego wyglądu mapy.
MapLibre i dane OpenStreetMap — otwarte biblioteki bez opłat licencyjnych, ale kafelki mapy trzeba serwować samemu albo kupić od dostawcy (publiczne serwery OpenStreetMap nie są przeznaczone do obsługi aplikacji). Koszt przesuwa się z licencji na hosting i utrzymanie. Opłaca się przy dużej skali, mapach offline albo gdy dane muszą zostać na własnej infrastrukturze.
Proste mapy na stronach WWW — na stronie produktu Sea Spotter mapa gatunków działa na otwartej bibliotece Leaflet; do statycznej wizualizacji to wystarcza i nie wymaga konta u dostawcy.

Nasza zasada: liczyć koszt map w scenariuszu wzrostu (użytkownicy miesięcznie i liczba zapytań), a nie dla dnia premiery — i od początku zamknąć mapę za własnym interfejsem, żeby zmiana dostawcy była decyzją biznesową, a nie przepisaniem aplikacji.

Czego się nauczyliśmy

Produkt własny jest dla nas poligonem: rozwiązania, które sprawdziły się tutaj — geozapytania, powiadomienia zależne od lokalizacji, AI z przełączaniem dostawców, testy e2e w aplikacjach mobilnych — wykorzystujemy w projektach dla klientów.