HyperTrack Tracking Start Flow: Technical Deep Dive

Introduction

This document provides a comprehensive technical overview of HyperTrack's tracking start flow architecture, explaining how the system achieves reliable tracking initiation across iOS and Android platforms. The architecture employs multiple redundant mechanisms to ensure high success rates for Time-to-First-Event (TTFE) and Time-to-First-Location (TTFL) metrics, even when individual components fail. Additionally, key engineering choices, such as a Rust-based SDK, a custom binary protocol, and CRDT-driven state design—further enhance reliability, correctness, and performance.

System Architecture Overview

HyperTrack's tracking start flow is built around a multi-layered, fault-tolerant architecture that combines:

1. Platform-initiated tracking via Order and Worker APIs
2. Silent push notification based wakeup mechanisms
3. Significant location change monitoring
4. CRDT-based tracking intent synchronization
5. App lifecycle event handling

This system is designed to handle the inherent limitations of mobile operating systems while maximizing tracking reliability and minimizing battery usage.

Core Components

1. Tracking Intent Management with CRDT Algorithms

HyperTrack uses Conflict-free Replicated Data Types (CRDTs) to ensure eventual consistency of tracking intent across distributed components.

The implementation guarantees that:

• Tracking Intent conflicts are automatically resolved using timestamp-based precedence
• Eventual consistency is achieved, even during network partitions or app suspensions
• Multiple tracking intent sources (platform, mobile app, server) can safely interact without corrupting state

Additionally, the tracking intent is implemented as a CRDT, allowing concurrent updates from both the SDK and remote APIs. Once connectivity is restored, the tracking intent state merges predictably.

2. Platform-Side Tracking Initiation

The platform initiates tracking via either Orders or Workers APIs:

• An order is created with the desired tracking intent
• A silent push notification is sent to the worker’s device
• The SDK receives the order and updates its local state
• A CRDT merge finalizes the resolved tracking intent

3. Silent Push Notification Wakeup Mechanisms

iOS

• Silent push notifications wake the app in the background
• Requires proper background mode configuration for location and remote notifications permissions
• Automatic swizzling handles lifecycle hooks
• Completion handlers ensure proper state sync

Limitations and Considerations

• Silent pushes will not wake the app if it has been force-quit (swiped up) by the user
• iOS enforces rate limits on silent push notifications, typically allowing only 2–3 silent pushes per hour
• Exceeding these thresholds can cause silent pushes to be throttled or dropped, leading to drops in TTFE/TTFL metrics
• These restrictions make it essential to combine push with fallback triggers like significant location change and app lifecycle hooks to ensure reliability
• For more details, refer to Apple’s official guidance on Pushing background updates to your app

Android

• Uses Firebase Cloud Messaging (FCM) for reliable background wakeups
• A persistent foreground service handles active tracking
• Handles boot recovery for resilience across reboots

4. Significant Location Change Monitoring (iOS)

iOS-specific fallback:

• Triggers app wakeup when significant movement is detected
• Ensures background execution eligibility even if push fails
• Supports energy-efficient tracking reactivation

5. App Lifecycle Event Handling

Across both platforms:

• Lifecycle events are hooked to synchronize state
• Foreground transitions trigger service restarts if needed
• Ensures recovery from terminated or backgrounded states

Advanced SDK and Server Engineering

SDK and Server in Rust

HyperTrack’s SDK and the server it communicates with are implemented in Rust, chosen for:

• High performance and low CPU overhead, enabling extended background operation with minimal battery drain
• Low memory footprint, reducing risk of termination by OS watchdogs on memory-constrained devices
• Strong correctness guarantees, leveraging Rust’s type system to eliminate illegal state transitions and reduce crash risks

Real-Time Communication via WebSockets

• SDK maintains a persistent WebSocket connection (when network is available)
• Tracking start commands are delivered instantly, typically in microseconds to milliseconds
• Geo-location data is streamed to the backend using the same low-latency channel

Custom Binary Protocol

• Communication uses a custom, structure-free binary protocol
• Prioritizes speed and low network overhead, outperforming Protobuf by an order of magnitude in internal benchmarks
• Optimized tradeoffs ensure minimal bandwidth consumption and high throughput

Final-State Machine Design

• The SDK is modeled as a final state machine, leveraging algebraic data types
• Ensures the SDK is always in a well-defined and valid state, regardless of external conditions
• Property-based testing validates state transitions, increasing system reliability

Application Not Responding (ANR) Protection

• All SDK calls are guaranteed to return within under 1 second, even under heavy load
• Prevents blocking operations and ensures responsiveness in the host application

Tracking Start Flow Sequence

1. Platform Initiation

Platform → API Call → Silent Push Notification → Device

2. Device Wakeup (Multiple Paths)

Path A: Silent Push Notification → App Background Execution → Tracking Intent Sync  
Path B: Significant Location Change → App Background Execution → Tracking Intent Sync  
Path C: App Foreground → Tracking Intent Sync (if push failed)

3. Tracking Intent Synchronization

SDK Tracking Intent + Platform Tracking Intent → CRDT Merge → Resolved Tracking Intent State

4. Tracking Initiation

Resolved Tracking Intent → Location Permission Check → Start Location Updates

Reliability Mechanisms

1. Redundant Wakeup Channels

• Primary: Silent push notifications
• Secondary: Significant location changes
• Tertiary: App foreground events

2. Tracking Intent Conflict Resolution

• CRDT-based merging ensures state consistency
• Temporal precedence governs updates
• Supports async behavior and network latency

3. Graceful Degradation

• Resilient to failures in push or app lifecycle
• Uses multiple fallback paths for wakeup
• Preserves predictable tracking behavior even in degraded conditions

Platform-Specific Optimizations

iOS

• Silent push and significant location monitoring
• Lifecycle-managed sync
• Minimal background footprint due to low memory usage

Android

• Persistent foreground tracking with boot recovery
• Firebase Cloud Messaging for reliable delivery
• Rust-based service minimizes ANR risks

Security and Privacy Considerations

• Users retain full control over location permissions
• Remote tracking intents cannot override disabled permissions
• All communication uses secure, authenticated channels (WebSocket and REST)

Real-World TTFE Insights Across HyperTrack Customers

Analysis of Customer Data

• C1: >90% of events within 10 minutes — high app activity and favorable network/device conditions
• C2: Slower Android start — indicative of stricter background policies or under-optimized push setup
• C3: Subpar iOS performance — likely due to push delivery issues or cold starts

Recommendations

• Ensure background execution capabilities are configured correctly
• Pre-warm tracking intents and combine wakeup paths
• Guide customers to allow battery and network optimizations
• Instrument lifecycle hooks to resume tracking reliably

Conclusion

HyperTrack’s tracking initiation system is engineered for performance, reliability, and efficiency.

By combining:

• A Rust-based SDK and server with a lightweight binary protocol
• CRDT-based tracking intent resolution
• Real-time WebSocket communication
• Multi-path wakeup mechanisms

the architecture delivers industry-leading TTFE and TTFL metrics with minimal battery impact and maximal resilience, ensuring that tracking starts quickly, predictably, and securely, even under adverse conditions.

This document contains proprietary technical information about HyperTrack's internal architecture. Please handle with appropriate confidentiality measures.