Ferrostar is a modern SDK for building turn-by-turn navigation applications. It combines a Rust core with platform-native UI layers for Android, iOS, and the web. That architecture is important: navigation logic can stay portable, while the visible product experience still feels native.
The 0.50.0 release is especially relevant for Android developers because it migrates Ferrostar's Jetpack Compose map UI to the official MapLibre Compose APIs. The 0.51.0 release then completes the removal of the older MapLibre Compose Playground dependency.
On a personal note, 0.50.0 was also my first Ferrostar release as a contributor. I primarily worked on #853, the Android MapLibre Compose migration, which became the main change in this release. I also contributed follow-up API adaptations, camera padding behavior, and Android demo app improvements in the same release cycle. This post is my practical reading of why the release matters from someone who touched the integration details.
The short version
If you are using Ferrostar only through high-level UI components and default behavior, the migration should be manageable. If you customized the map at a lower level, you should expect work: style handling, map state, content slots, camera access, and custom sources or layers now follow the official MapLibre Compose model.
- For Android developers: the map UI now sits closer to the MapLibre Compose ecosystem instead of a smaller project-specific wrapper.
- For product teams: this improves the long-term path for custom navigation experiences, not only the demo screen.
- For CTOs: it reduces integration risk by aligning Ferrostar with a broader open-source map UI layer.
Why MapLibre Compose matters
Navigation SDKs are rarely integrated as-is. Real products need branded map styles, custom route overlays, different location behavior, bottom sheets, incident markers, fleet-specific data, offline states, and special camera behavior. A navigation SDK that is hard to customize quickly becomes a product bottleneck.
Jetpack Compose is a good fit for this kind of UI because state, layout, and customization can be expressed directly in Kotlin. MapLibre Compose brings that model to map rendering. Ferrostar's migration means Android teams can use normal MapLibre Compose concepts when they need to draw custom layers, pass map options, control camera state, or work with app-specific map content.
The official Ferrostar customization guide documents the main integration shifts: pass a BaseStyle instead of a plain style URL, create a NavigationMapState, use MapOptions, and add custom sources or layers through the map content slot. Those are not cosmetic changes. They move customization into the same model that MapLibre Compose itself uses.
Routing engines and map technology
It is worth being precise about what Ferrostar is and is not. Ferrostar is not a routing engine, a map renderer, or a basemap provider. It is the navigation SDK that connects route data, location updates, state management, guidance logic, and native UI components.
On the routing side, Ferrostar includes support for Valhalla-based APIs and OSRM-compatible route responses. The documented commercial routing integrations include Stadia Maps and GraphHopper, and the route provider architecture allows custom providers on iOS and Android, including offline or domain-specific routing backends.
On the map side, Ferrostar's bundled UI components are built around MapLibre technology. That includes MapLibre Native on mobile, MapLibre GL JS on the web, and now the official MapLibre Compose APIs for Android. Basemaps can come from providers that serve compatible vector tiles, for example Stadia Maps, MapTiler, Jawg, or Mapbox tile endpoints.
What changed in Ferrostar 0.50.0
The central change in 0.50.0 is the Android MapLibre UI migration. The release also includes improvements around configurable navigation and non-navigation location managers, non-navigation insets, route deviation handling, navigation session recording documentation, demo app usability, and dynamic screen-based navigation camera padding.
From an app integration perspective, the important point is not the number of merged pull requests. It is that Ferrostar's Android surface becomes easier to reason about if your team already thinks in Compose and MapLibre terms. The route, the puck, the camera, and surrounding UI can be treated as product building blocks instead of as a closed widget.
The Android demo app work is also more important than it may sound. A good demo app is not just marketing. It is a living integration reference. When the demo includes better bottom sheet behavior, recenter controls, and realistic navigation UI states, it becomes easier for teams to evaluate the SDK and copy working patterns into a production app.
What 0.51.0 adds
Version 0.51.0 is smaller, but it is still part of the same story. It removes the MapLibre Compose Playground dependency and replaces Material Icons usage with custom drawable resources. In other words, it cleans up the dependency graph after the larger 0.50.0 migration.
For teams evaluating an SDK, this kind of cleanup matters. A release that only migrates to a better abstraction is useful. A follow-up release that removes the old dependency and reduces extra assumptions is better. It shows that the migration is not just additive technical debt.
Migration notes for Android teams
The exact migration effort depends on how deeply your app customized Ferrostar's map UI. For a simple implementation, the work may be limited to updated API names and setup code. For a custom map, plan a focused migration pass.
- Review every place where the app passes map style configuration.
- Replace older low-level map access patterns with
NavigationMapStateand MapLibre Compose state APIs. - Move custom overlays, markers, sources, and layers into the provided map content slot where appropriate.
- Recheck camera behavior in portrait, landscape, split-screen, and bottom-sheet-heavy layouts.
- Run a real navigation or replay session after the code compiles, not only a static map preview.
Why this is interesting beyond Android
The business case for Ferrostar is not simply that it is open source. The stronger argument is architectural control. In many mobility, logistics, field-service, and outdoor products, navigation is not a commodity screen. It is part of the workflow: dispatch rules, vehicle constraints, user guidance, proof of service, safety rules, and customer promises all show up in the navigation experience.
A composable navigation stack lets teams keep product-specific behavior close to their own application architecture. That can reduce the pressure to fork a black-box SDK, work around fixed UI decisions, or accept a generic navigation UX that does not fit the product.
For decision makers, the tradeoff is clear: a flexible open-source SDK may require more engineering ownership than a fully packaged proprietary solution, but it can also avoid lock-in and make custom behavior cheaper over the lifetime of a serious product.
FAQ
Is Ferrostar 0.50.0 a breaking release?
Yes, especially around lower-level Android map customization. High-level integrations should be less affected, but teams should still read the release notes and the updated Android customization guide before upgrading.
Should I upgrade directly to 0.51.0?
In most cases, yes. If you are planning the MapLibre Compose migration now, 0.51.0 is the cleaner target because it includes the post-0.50 cleanup.
Is this only relevant if I use Stadia Maps?
No. Ferrostar is an open-source project and works naturally with Stadia Maps routing and basemaps, but it is not limited to that setup. The architectural point is broader: it is a modern, composable navigation SDK built around portable core logic, native UI layers, and room for custom routing integrations.
What should I test after migration?
Test route display, puck behavior, camera tracking, recenter behavior, off-route states, rerouting, bottom sheet overlap, landscape layout, and any custom map layers. Navigation bugs often hide in transitions and moving-state behavior, not in the initial screen.
Bottom line
Ferrostar 0.50.0 and 0.51.0 make the Android side of the SDK more aligned with the direction of modern Kotlin UI development. The release is technical, and it does require care if your app customizes the map deeply. But strategically it is a good move: less project-specific wrapping, more shared ecosystem, and a clearer path for product-grade navigation UI.