Sea Spotter — a mobile app for reporting marine wildlife sightings
Our own product. Sailors report marine wildlife sightings — dolphins, whales, orcas and more — and the app turns them into an activity map and alerts others nearby. iOS and Android, multiple languages, subscriptions, AI-powered species-name translation.
- platforms from one codebase
- 2
- languages
- 7
- months to build the app
- 2
- end-to-end tests before every release
- e2e
The product
Sea Spotter is an app for sailors who want to share sightings of marine wildlife — dolphins, whales and orcas among others. Every report lands on a shared map showing where and when animals were seen. Users can subscribe to an area and get notified when someone nearby reports a sighting — including warnings about orca interactions with yachts.
It is our own product, so we can describe it by name and in detail.
How we built it
We built the app in two months — May and June 2026. The following weeks went into preparing for and getting through the store review process — today the app is available on the App Store and Google Play.
One codebase, two platforms. The app is built with React Native (Expo) and TypeScript: maps with a heat layer in which older sightings gradually lose weight, geolocation, photos, dark mode and seven languages.
A Supabase backend. PostgreSQL with PostGIS answers spatial questions — who is subscribed to the area where a sighting has just appeared. Server functions handle notifications, paid-subscription sync and cleanup of old photos. The schema evolves through versioned migrations.
AI where it makes sense. Species names are translated into every app language by a language model. The function uses two providers and fails over automatically when one does not respond.
Monetisation and quality. Premium subscriptions in both stores, error monitoring, end-to-end tests on devices before every release, and an automated build and release process. The app comes with a product website featuring a species map and legal documents in every language.
Getting into the stores takes longer than building the app
The most surprising lesson of the whole project: getting an app into the stores can take longer than building it. The code was ready after two months; publication is a separate project with its own timeline, one developers have limited control over.
- Google Play requires a new personal developer account to run a closed test with at least 12 testers for 14 consecutive days before you can even apply for production access. The first full review of a new app usually takes several business days.
- The App Store lets you test internally in TestFlight without review, but external testing goes through beta review, and release through full app review.
- Paperwork on both sides: declarations of the data collected (location, photos), a privacy policy at a public URL before submission, configured subscription products, screenshots and descriptions — in each of the app's seven languages.
The takeaway for clients: a mobile project plan must treat publication as a stage of its own, with buffer time and the paperwork running in parallel. It cannot be bolted on at the end.
Maps: two platforms, two engines
On iOS we use Apple Maps — the system's native component, available in apps with no per-view fees. It is the simplest and cheapest path: the map looks and behaves the way iPhone users expect.
On Android we chose Mapbox, which costs nothing up to a threshold of monthly active users and charges per user above it. We monitor that threshold and have a set point at which we will revisit the decision — comparing it again with the Google Maps SDK and open-source MapLibre.
Two engines mean two implementations, so we put the map behind a single interface with a separate file per platform. The rest of the app does not know which engine runs underneath — and switching providers means replacing one component, not rebuilding the app. Differences still surface in the details: Apple Maps has no native heatmap, so we draw the heat layer ourselves as an SVG overlay, identical on both platforms.
Which map provider pays off
Provider prices change, but the cost structure is fairly stable. This is how we assess it today:
- Apple MapKit (iOS) — no per-view fees in native apps, as part of the Apple developer programme membership. On websites (MapKit JS) there is a free daily quota of map views and service calls. Usually the best choice for an iPhone app.
- Google Maps Platform — displaying the map in native mobile apps is currently free, but the services that usually come with a map are paid: place search, geocoding, routes, and maps in the browser — each with a free monthly cap and a charge for every further thousand calls. Worth it when you need exactly that Google data; costs grow with the number of requests, so model them from day one.
- Mapbox — billed per monthly active user in mobile apps, with a free tier. Strong control over styling and layers. Worth it for apps that stay within the free tier or need a custom map look.
- MapLibre and OpenStreetMap data — open libraries with no licence fees, but you have to serve the map tiles yourself or buy them from a provider (OpenStreetMap's public servers are not meant to back apps). The cost moves from licensing to hosting and maintenance. Worth it at large scale, for offline maps, or when data must stay on your own infrastructure.
- Simple maps on websites — the species map on the Sea Spotter product website runs on the open Leaflet library; for a static visualisation that is enough and needs no provider account.
Our rule: model map costs for the growth scenario (monthly users and request volume), not for launch day — and put the map behind your own interface from the start, so that switching providers is a business decision, not an app rewrite.
What we learned
Our own product is our proving ground: solutions that worked here — spatial queries, location-based notifications, AI with provider failover, end-to-end tests for mobile apps — we reuse in client projects.