Telemetry That Keeps Location Coordinates on Device

Hangangjari has no login and sends only limited operational state such as widget use, notification-setting saves, and API latency. Current location coordinates, names, email addresses, and advertising identifiers are excluded from telemetry.

Before adding an event, the review checks whether its fields are needed for reliability or performance and whether retention and access limits can be explained.

Location Stays on the Device

Hangangjari uses the current location only on the device when sorting nearby parks or parking lots.

sequenceDiagram
  autonumber
  participant User as User
  participant App as iOS app
  participant Location as Location service
  participant Server as Server API

  User->>App: View nearby places
  App->>Location: Request current location
  Location-->>App: Coordinates or nil
  App->>App: Sort parks/lots
  App-xServer: No coordinate upload

If location permission is missing, the app receives nil and limits only nearby sorting. The server API returns the park and parking-lot data used for sorting but neither receives nor stores the user’s current coordinates.

Pseudonymous Events

Events use a pseudonymous install hash instead of an account. The app stores a seed on the device and creates a hash with a scope.

The server does not receive names, email addresses, advertising identifiers, or location coordinates. It receives only the minimum fields needed to observe app operation.

Representative fields are:

Field	Purpose
event type	What happened
surface/entrypoint	Whether it came from app, widget, or notification
park ID / lot ID	Which park or parking-lot context
information freshness bucket	Whether the information seen was fresh or old
duration/status/reason	Slow points and failure reasons
pseudonymous install hash	Distinguishes install units without accounts

Park and lot IDs are used only to separate feature-level errors; they are not combined with install hashes to build long-term movement histories. The install hash is not an account, but it can link repeated events, so its retention and access are limited.

Telemetry Delivery Separate from App Responses

The event reporter stores telemetry in a file queue and sends bounded batches asynchronously. A failed delivery retries after backoff.

flowchart LR
  Event["App event"] --> Queue["Device file queue"]
  Queue --> Batch["Bounded batch"]
  Batch --> API["Telemetry endpoint"]
  API -->|Accepted| Metrics["Prometheus/DB metrics"]
  API -.->|Failure| Retry["Backoff retry"]
  Retry --> Queue

Batch count and size are limited so telemetry delivery does not delay app responses.

Performance Signals and Behavior Signals

App events and performance events are separate. Performance telemetry watches technical signals such as API path, status code, duration, and cache use. Looking at usage patterns and checking API stability are different goals.

On the server, Hangangjari records metrics such as accepted event count, rejection reasons, ingestion duration, and push acknowledgements. These metrics are used to observe app health, not to profile users.

Dashboards center on performance signals used to find API latency and errors. Park and lot context is used only to separate feature failures.

APNs Device Tokens and Notification Settings

Notifications are the exception where server-side storage is needed. APNs device tokens, interested parks/lots, notification thresholds, and quiet hours are required so the server can send notifications requested by users.

The push area follows these retention rules.

• Store required values only when notifications are enabled.
• Limit APNs device-identifying values to delivery purpose.
• Clean up invalid device tokens and old subscriptions.
• Keep reason codes in notification rules and delivery audit to protect users.

The push server stores device tokens and settings to deliver notifications selected by the user. Delivery audits record send or suppression reasons without copying message bodies or tokens into operational logs.

Policy Documents That Match the App

The iOS Privacy Manifest declares collected-data categories and reasons for Required Reason API use. The privacy policy explains server-transmitted data, purposes, retention, and deletion to users. Both are checked against actual telemetry fields.

The policy documents state these choices:

• No accounts or login.
• No advertising-identifier based tracking.
• No server upload of location coordinates.
• App events use pseudonymous install hashes and minimal operational signals.
• APNs device tokens are for sending notifications.
• If public source data may include sensitive strings, limit them before storage/display.

Matching Transmitted Fields to Policy

Hangangjari keeps current coordinates on the device and includes only required fields plus a pseudonymous install hash in performance and feature events. The file queue limits batch size and retries, and the Privacy Manifest and privacy policy are checked against transmitted fields.

Apple’s Privacy Manifest documentation defines the declaration fields used in this review.