MapConductorWhy MapConductor
Code that shows a map is usually welded to one map SDK. When the time comes to move, the rewrite is not confined to the map — it reaches into your screen logic. MapConductor replaces that weld with one shared API.
01 · The problem
Pricing and contracts move
Map API billing changes. You want to move, and your own code is what stops you.
The same feature, written three times
A different map SDK on Android, iOS and the web means markers behave differently and camera numbers mean different things. Every spec discussion happens three times.
The numbers disagree
What zoom 14 shows, and how far apart two points are, drift between environments when you lean on each SDK utilities. QA ends up adjudicating which one is right.
Volume breaks it
Past a few thousand markers a naive implementation makes the camera stutter. The fix differs per provider, and each one is another rewrite.
02 · What MapConductor does
Your app depends only on the unified API. Drivers absorb the per-provider differences, and switching comes down to swapping one dependency and one view type.
Shared coordinates and state
GeoPoint, MarkerState and MapCameraPosition mean the same thing and carry the same name on all three platforms. No provider types leak through.
Zoom and distance agree
Zoom is normalised onto one scale, and distance, heading and area come from the SDK own implementation. Identical inputs give identical numbers on every provider.
Just hand over the state
Hand over the array of what should exist now; Core diffs it against last time and applies only what moved. You never track adds, updates and removals yourself.
Volume is handled inside the SDK
Past 2,000 markers the internal rendering engine switches to raster tiles on its own. Camera work stays smooth at tens of thousands and not a line of your code changes. The threshold is a map-view option if you want a different one.
03 · Not just a thin wrapper
A wrapper that only dispatches to each SDK ends up limited by whichever SDK does least. MapConductor draws the missing pieces itself, so appearance and behaviour stay put when the provider changes.
04 · What it buys the team
Putting one shared API in the middle changes what kind of code you can write. Code with no map SDK name in it survives a change of provider, and a move to another platform.
One API to learn
Every map SDK names things its own way, so each change of provider and each move to another platform means learning it again. With MapConductor there is one API, carrying the same names and the same meanings on Android, iOS and React. What someone learns on one platform holds on the next, and onboarding does not grow with the number of providers.
Code that owes nothing to a map SDK
GeoPoint and MarkerState belong to no map SDK. Building a route, testing whether a point falls inside an area, deciding what to show — that logic can be written without a single SDK type in it, so changing provider is not a rewrite. Shared map components can be factored out as a library instead of one build per provider.
05 · Seen from the data side
Everything above is written from the app side. What MapConductor is after is not only freedom from vendor lock-in, but the freedom to decide which vendor you lean on separately from which map SDK you draw with.
A commercial SDK is usually where you land
Unless the whole stack is open, production work lands on some commercial map SDK. Contracts and procurement sometimes leave exactly one option. What MapConductor is for is not having to throw away what you already own when that happens.
Data apart from the SDK that drew it
Map data, geocoding and tiles have come bundled with the SDK of the vendor that supplies them. Separate the two and content built up in, say, ArcGIS can be put to work on a map drawn by something else.
Geocoding only, data only
A provider that offers geocoding, or one dataset, and no map SDK of its own has had few places to be used. Split display from data and it can sit on top of any map.
06 · Seen from a map SDK provider
A shared layer can look, from a map SDK vendor's side, like something that dilutes them. That is not how MapConductor is built. Only the part every provider already has is unified; what each vendor is good at stays reachable.
Customers from outside
Once several providers can be driven the same way, apps built on someone else's SDK become reachable. A lower switching cost cuts both ways — it also loosens the hold on the customers you have — but what remains as a reason to be chosen is price, coverage and how well you draw, rather than the cost of leaving.
Your differentiators stay visible
What is unified is the part every provider already has. Calling getMapViewHolder() on the state object hands back the native map view and map instance, so anything only your SDK offers is written against your own API. A wrapper that hid everything would erase what makes each provider different; this one does not.
Competing on a shared footing
After HTML5 settled what browsers had to implement, browsers stopped competing on compatibility and started competing on speed and capability. Map SDKs are no different: with a shared interface in place, the question becomes how fast, how accurately and how widely you can draw. A common layer is not a brake on individual SDKs — it points their progress the same way.
07 · When it fits, and when it does not
- One map experience across several platforms
- Keeping the option to change provider later
- Markers, shapes and camera work as the core of the feature
- Thousands to tens of thousands of markers
- Distances and areas that have to agree everywhere
- A provider-specific showpiece — custom shaders, one vendor exclusive layer
- Turn-by-turn navigation and other features that are the SDK own product
- One platform, one provider, and no intention of ever changing
Mixing is still possible: the native map instance is always reachable, so the unusual parts can be written against the provider directly.