Introducing MapConductor: A Unified API for Mobile Maps SDKs

Working with map SDKs should be straightforward. But anyone who has built a map-heavy mobile app knows the truth:

• Each SDK uses different concepts and APIs
• Camera behavior varies across Google Maps, Mapbox, ArcGIS, HERE, etc.
• Geometry rendering (polylines, polygons, circles) differs by platform.
• Switching SDKs mid-project can mean rewriting entire modules.

In other words:

We keep solving the same problems over and over again, simply because map SDKs don’t speak the same language.

This is exactly the pain point MapConductor aims to address.

What MapConductor Is — Today

MapConductor is an open-source middleware layer that lets you work with multiple mobile map SDKs through a unified API.

And to be clear unfront:

MapConductor currently supports Android only, with a Jetpack Compose -first API. iOS and JavaScript support are planned, but not available yet.

At the current stage, MapCoductor focuses on the essentials: map operations and geometry rendering.

✔ Already implemented (Android / Jetpack Compose)

You can use the same API to control:

• Map movement & camera operations
• Markers (pins)
• Polylines
• Polygons
• Circles
• Geodesic polylines and polygons
• Tap interaction (unified where possible)

✔ Supported SDKs (as of today)

• Google Maps
• Mapbox
• ArcGIS
• HERE
• MapLibre

The key value:

In most cases, the same Compose code works across all supported map SDKs.

No need to rewrite your UI or business logic just because the map backend changes.

Before / After: How MapConductor Changes Everyday Development

Before Working with multiple SDKs means writing multiple versions of the same thing:

// Google Maps
googleMap.addMarker(MarkerOptions().position(...))

// Mapbox
mapboxMap.addAnnotation(
  PointAnnotationOptions().withPoint(...)
)

// ArcGIS
graphicsOverlay.graphics.add(
  Graphic(...)
)

After (with MapConductor)

// Replace MapView with your chosen map provider, such as GoogleMapView, MapboxMapView
MapView(
  onMarkerClick = {  marker ->
    // onClick
  },
) {

  Marker(position = position)

}

Switch the driver — keep your code.

But the problem is deeper than just APIs

Even if SDKs exposed identical method names, their conceptual models still differ — sometimes dramatically.

And unless those conceptual gaps are abstracted away, developers are forced to learn and maintain multiple mental models.

One of the clearest example is the camera model.

Conceptual differences between map SDKs — the camera example

Most developers assumes “moving the camera” means the same thing everywhere. But that’s not the case.

1. Most SDKs (Google Maps, Mapbox, HERE, MapLibre) → The camera always points to the center of the map. If you tilt moves the camera itself, which affects the visible region differently.
2. ArcGIS Maps SDK → The camera is defined by a camera position in 3D space, not the map center.

Why this matters

• Camera animations are not portable
• Reproducing UI/UX consistency across SDKs is extremely hard
• Developers must memorize SDK-specific camera rules
• Docs & StackOverflow answers rarely transfer across SDKs

This fragmentation is exactly what MapConductor tries to smooth over by providing a provider-neutral camera model that behaves predictably across SDKs.

Why This Matters for Android Developers

Even if its current early stage, MapConductor already brings practical benefits:

● Prototype faster Compare multiple SDKs without rewriting your map layer.

● Avoid vendor lock-in If licensing or pricing changes, just switch the driver. Keep your logic code.

● Avoid vendor lock-in Different regions prefer different map providers — MapConductor makes switching trivial.

● Consistent geometry behavior Geodesic lines & polygons behave reliably across SDKs.

● Cleaner, declarative architecture Your Compose UI stays SDK-agnostic.

MapConductor is not a new map engine — it’s a compatibility layer that protects your app from fragmentation.

How It Works (High-Level Architecture)

MapConductor is organized into layers:

1. Driver Layer SDK-specific adapters that implement the unified interface.
2. Geometry & camera engine (Core Layer) Provides consistent behavior for shapes and camera movement across SDKs.
3. Unified Compose API Layer Declarative APIs your Android app calls.

This architecture also makes future ports

• iOS (SwiftUI)
• Web (JavaScript, React, React Native, Capacitor, Apache Cordova)
• Flutter
• Kotlin Multiplatform / Compose Multiplatform

much more attainable — though today, the implementation is Android — only.

Roadmap — Realistic and Transparent

✔ Expand features in the Android core SDK

✔ iOS SDK prototype

✔ Flutter SDK prototype

✔ JavaScript SDK prototype

✔ More drivers for more SDKs

✔ Documentation, samples, and community guides

✔ Building a global OSS community

Our long-term direction:

A vendor-neutral foundation for map app development.

Call for Feedback — We Need Early Adopters

MapConductor is early, but already useful for:

• Rapid prototyping
• Workshops & teaching
• Teams migrating between SDKs
• Apps that need future flexibility
• Developers experimenting with MapLibre or ArcGIS

We welcome:

• Bug reports
• Feature requests
• Driver contributions
• API design feedback
• “This feels strange” comments

Your voice will directly shape the API while it’s still flexible.

Closing: Toward the “Democratization of Map development”

Map development shouldn’t depend on hidden SDK quirks, vendor lock-in, or conceptual inconsistencies.

Developers should be able to choose any map provoder — without rewriting their apps.

MapConductor aims to make that possible: an open, unified API that lets you focus on your product, not SDK differences.

And we’d love for you to join us in building this ecosystem.

Github: https://github.com/MapConductor/android-sdk

Docs: https://docs-android.mapconductor.com/