Skip to main content

Roadmap

v1 ships the core of a family location app, end to end. Nothing below it is built yet, so read this as intent rather than a promise. Roughly ordered by value.

Near term​

Measured against the family safety apps Hearth sets out to be a self-hosted version of, these are the gaps that remain after 1.0. The tracker's tiers, places with arrival and departure alerts, check-ins, SOS, crash detection, low battery alerts, trips, history, and the member statuses other apps show ("location permission off", "at Home since") are all there.

  • A Hearth organisation for push. The app relies on Expo push, and every push to a build goes out under the Expo project, Firebase project and Apple push key it was built with. That is fine for somebody building with their own keys, and it is why the store builds cannot carry personal ones. The plan is Hearth's own Expo organisation, Firebase project and Apple developer account, with a small relay in front of Expo that passes only Hearth's notification types and limits each server and each phone. A store build could then push for any server. It needs a legal entity and some funding, at today's prices about $99 a year for Apple and $25 once for Google Play. If you can help, open an issue.
  • Driving events on trips: hard braking, rapid acceleration, phone use while driving, and a weekly driving summary. The sensor pass already sees the braking, as driving insights below explains.
  • A time-boxed approximate mode, a "bubble": share a rough area for the next few hours and snap back to precise on its own. Pause already has a timer. Approximate does not.
  • Group messaging inside a circle. Quick messages and check-ins cover the short form today.
  • Direct APNs / FCM push drivers, so a build made with your own keys can push without Expo in the path. The PushDriver interface is one send() method. See server/src/services/push.ts.
  • A web client in apps/web. Read-mostly map and feed for the desktop, on top of the existing API, websocket and Web Push driver. CORS_ORIGINS and the VAPID plumbing are already in place for it.
  • Driving insights. The trip detector already stores max and average speed, and the on-device sensor pass already recognises a harsh brake and then throws it away, because there is nowhere to put it. Give it a home: count them per trip and show them on the trip detail screen.
  • Scheduled place alerts, as in "tell me if Sami has not arrived at School by 08:45". Needs a per-place schedule table and one more job step.
  • Maestro E2E flows for the app's critical paths (server → login → circle → place → check-in).
  • More locales. The i18n scaffold supports them, but v1 is English only.

Medium term​

  • Offline map packs via MapLibre's OfflineManager, so the map still works in the countryside.
  • Shared ETA, or "on my way". A check-in variant that publishes a destination and live ETA until arrival.
  • Battery work beyond the moving and stationary split and the OS motion classifier, which are what pay for themselves today. A measured comparison of the classifier against the GPS-only fallback would say how much a refused permission actually costs.
  • Circle-level place sharing, meaning you copy a place into another circle.
  • End-to-end encrypted history, with client-side keys and the server holding only ciphertext, for people who don't trust their own server host. Presence would stay plaintext for geofencing, or geofences would move client-side.

Ideas​

An Apple Watch or Wear OS glance. Bluetooth tag support, an ESP32 with GPS reporting to the same API. Home Assistant integration via the websocket.

Contributions welcome. See CONTRIBUTING.md.