GLMap for Flutter, Kotlin Multiplatform, and React Native is now available in beta. Install the packages from pub.dev, the Globus Maven repository, or npm to bring native maps, search, routing, and offline data to Android and iOS apps while writing your feature code in Dart, Kotlin, or TypeScript.

Try the demos, add GLMap to your app, and tell us what works—and what gets in the way. Your feedback will help shape the APIs, examples, and integration experience before a stable release.

A traveler types Zlotaa 59 while looking for a destination in Warsaw. They mean Złota 59. Your app should help them get there—not ask them to become better at spelling Polish street names.

GLSearch now handles common typos in online map search. It helps people find addresses, businesses, and places even when they miss a letter, add an extra one, or mix up the spelling. The goal is simple: less retyping between opening your app and choosing a destination.

Search in a map app looks like one operation: type a place, get a result. In an offline map it is two decisions. First, understand what the words mean. Then decide which local map files are worth searching.

GLMap keeps streets, addresses, and places in detailed regional maps. Alongside them is a compact world map containing countries, regions, and important cities. One C++ search engine uses these sources on iOS, Android, and in our online search service.

The map center normally tells the engine where to start. If you are in Warsaw and type cafe, that is exactly what you want. But suppose you are planning a trip and type Eiffel Tower Paris France. The map is still centered on Warsaw; the words clearly point to Paris.

Search only around Warsaw and the Eiffel Tower never appears. Search every regional map and even a simple autocomplete request may open files across the planet. The rule we arrived at is: the map center is a bias; geography written by the user is intent.

Over the past months we rebuilt GLMap search around that rule. It can now route the Eiffel Tower query to France, find Wrocław from the keyboard-friendly spelling Wroclaw, keep Paris Optique in Warsaw, and find a small village missing from the world map — all while the phone is in airplane mode.

GLMap 2.0 is our largest SDK update in years. It adds 3D terrain, one search flow for online and offline data, new pedestrian routing profiles, Vulkan rendering on Android, and much smaller reference applications for Swift and Kotlin.

The goal is not a longer API. It is a more capable map that remains compact to integrate, works with downloaded data, and behaves consistently across iOS and Android.

A mountain map should show more than roads and contour lines. It should make the shape of the landscape immediately clear: the valley ahead, the ridge beside a route, and the elevation separating two nearby points.

GLMap SDK 2.0 turns the map itself into that landscape. The same vector map rises with the terrain, while labels, tracks, markers, and elevation overlays stay in place.

Terrain is one of the headline features in the GLMap 2.0 release. Here is what it adds and how little an application needs to change to use it.

A walking route across a city and a hiking route up a mountain should not share the same clock.

Routing engines are good at distance, turn costs, access rules, and road classes. Hiking time is harder. A two-kilometer trail can be easy, slow, dangerous, or all three, depending on slope, descent, surface, visibility, and how the local trail network publishes reference times.

Globus routing is built on Valhalla, and Valhalla tiles already contain the graph, the route shape, and elevation. We wanted to know whether that information was enough to make hiking ETAs less optimistic, without breaking tile compatibility and without a formula that only works in one mountain range.

We built a corpus of reference hiking times, tested several formulas, rejected most of them, used a deliberately expensive research hook to find what worked, and then moved the result into production Valhalla code.

The first Globus predicted-traffic release for Valhalla had a deliberately simple shape: coverage everywhere, and richer temporal detail only where the data could support it.

The June navigation data update keeps that shape. There is still no new API, no separate traffic overlay, and no integration change for SDK customers; the traffic layer is still baked into the regular map and navigation data update.

The changes are in the model underneath. It now handles local time correctly, treats recent evidence more carefully, and does not widen weekly profiles where freshness already explains the signal better.

At 08:12 on a Monday, a delivery driver leaves the depot on a route built on Sunday afternoon. The routing engine that built it does not know that the arterial out of the warehouse jams between 08:00 and 08:30. The driver knows, and so does anyone who lives nearby.

Most people assume predicted traffic already works in their routing engine. Valhalla supports it, but only if someone feeds it good data. Over the last several months at Globus, we have been doing that work.

This post covers what we shipped, what we threw away, and why a deliberately small layer turned out to matter more than a more ambitious one.

Better Navigation UI with Track Arrows​

v1.13.0 makes navigation routes clearer with directional arrows along your track. Plus: a new helper for displaying user location, Android stability fixes, and better cross-platform API parity.

API Refinement, Smarter Tile Loading, and Cross-Platform Consistency​

v1.12.0 is all about polish and performance. We've cleaned up coordinate conversion APIs, optimized tile loading to reduce bandwidth waste, and standardized naming across platforms to make your code more maintainable.

TL;DR​

1. Unified screen-to-map conversion API on Android – now uses android.graphics.PointF, eliminating the old MapPoint/Point mix-up
2. Property clean-up on iOS – mapZoom → mapScale (and heads-up about v1.13 renaming of mapZoomLevel)
3. Smarter tile pipeline on both platforms – fewer aborts, fewer duplicate downloads, better cache hit-rate
4. NDK r28.1 & 16 KB page-size support for Android – rebuilt libs and updated CMake configs