Cross-Platform Indoor Navigation SDKs

The Problem

Walkk builds indoor navigation for hospitals, exhibition halls, and large venues — the spaces Google Maps doesn't cover. Their SDK needed to run on iOS (Swift), Android (Kotlin), and Flutter (Dart) with a consistent API surface across all three. Three platforms, one architecture, one engineer.

What Made It Hard

Three codebases, one API contract. The SDK had to behave identically on iOS, Android, and Flutter from the client developer's perspective. WalkkMapView works the same way regardless of platform. That means three separate implementations of the same architecture — BLE scanning, offline-first event queueing, permission handling, AR overlay — all maintaining API parity.

BLE on iOS is adversarial. Apple imposes strict background restrictions on Bluetooth Low Energy. The SDK had to navigate permission flows, background modes, and Apple's CoreBluetooth constraints without breaking the positioning accuracy that the product depends on. This required understanding Apple's restrictions deeply enough to architect around them, not fight them.

Seven weeks for three production-grade SDKs. Not prototypes. Not demos. Packaged deliverables: Swift Package Manager (SPM) for iOS, AAR via Maven for Android, Dart package for Flutter. Each with a demo app. Each with offline-first networking and event queueing. The only way this is possible is by running parallel Claude Code sessions — one session per platform, each holding the full SDK context for its target. Three development tracks running simultaneously.

The Architecture

API facade pattern. WalkkMapView is the single entry point on each platform. The client developer doesn't see BLE management, tile caching, or positioning algorithms — just a map component with a clean interface. Platform-specific complexity is fully encapsulated.

Offline-first networking. Events queue locally when offline and sync when connectivity returns. BLE signals are processed on-device. The SDK doesn't depend on a live connection to function.

Packaging:

• iOS: Swift Package (SPM), distributed via GitHub registry
• Android: AAR library, distributed via Maven
• Flutter: Dart package with platform channel bridges to native BLE layers

The Outcome

Three production SDKs delivered in 7 weeks. Each platform packaged, documented, and shipped with a demo app. 222 hours logged across all three tracks. Real engineering time approximately half that — Claude Code running parallel sessions per platform compressed a 4-month scope into 7 weeks. The client received SDKs ready for their own developer documentation and integration.