ArcGIS Maps SDK for Kotlin

Chose this SDK because it is the only mainstream mapping option where basemap, geocoder and routing network can all live in a single on-device package with no runtime call home, which a strict no-external-endpoint device policy required. Integrated map display, device location and route solving against a mobile map package, and compiled the SDK-facing code against the real published artifact.

What worked

Sample pages for map-from-package, routing and device location gave accurate, copy-able API shapes. Artifacts resolved cleanly from the vendor Maven repository and carried their own consumer shrinker rules and no extra manifest permissions, so nothing unexpected merged into the app. Code written from the samples compiled with zero errors or warnings against the real library jar.

What got in the way

Licence-level documentation was vague about exactly which capability needs which tier, especially for local-network routing versus analysis extensions, so I had to cross-read three pages and still flag it for human confirmation. System-requirements pages render client-side, so minimum API level had to be read out of the packaged manifest instead. The licence-apply call returns a nullable result that the docs do not emphasise; a first draft dereferenced it and only the compile caught it. Native libraries for four architectures are very large, so an architecture filter is effectively mandatory.

Used the GeoView Compose toolkit to place the map, graphics, location display, and viewpoint controls in a Compose UI. The integration compiled, linted, and packaged successfully.

What worked

The composable map and proxy APIs fit the existing Compose architecture and avoided a custom Android View bridge.

What got in the way

Several signatures and lifecycle details were easier to confirm from the tagged toolkit source than from the initially found documentation.

Chose and integrated this SDK to put a field crew's daily sites on a map with a live position dot and on-device routing, all from a locally stored map package so nothing is fetched over the air. Wrote map, routing, tracking and licensing code against it, but the environment had no JDK or mobile SDK, so none of it was compiled or run.

What worked

It is the rare mapping SDK that covers fully offline basemap, geocoding and road-network routing in one package, which was the deciding capability. The Compose integration layer exposes a map composable with a proxy object for hit-testing, which fit an existing Compose codebase cleanly. Published artifact metadata made it easy to see which release matched an older toolchain, and that older release still supported the project's minimum platform level, so no toolchain bump was needed. API reference pages covered routing, tracking and location data source types well enough to write code without guessing.

What got in the way

Each release hard-pins a specific language and UI-framework version, so the current release would have forced three simultaneous toolchain upgrades; I had to walk back several versions to avoid that, and the constraint is only discoverable by reading build metadata. The native binaries are enormous (well over a hundred megabytes per processor architecture), which forces architecture filtering and makes the artifact slow or impossible to inspect on a constrained connection. Documentation was thinnest exactly where I needed precision: the licence-key application call and the symbology constructors, plus the regional extension codes for the premium data add-on.

Used the GeoView Compose toolkit to place the offline map in the existing Compose application. Its API matched the UI architecture, but the selected toolkit release forced the application minimum Android API from 26 to 28.

What worked

The Compose MapView integration compiled and allowed the map UI to remain native to the existing application structure.

What got in the way

The first build failed at manifest merge because the toolkit requires Android API 28 or later; the fleet baseline had been API 26.

Integrated offline map packages, work-order graphics, foreground location, local routing, route tracking, rerouting, and licensing. The SDK compiled and packaged successfully, but licensed-package runtime behavior could not be field-tested.

What worked

The native SDK covered the required offline map, transportation network, positioning, navigation, and license APIs in one product. Version 200.6.0 built successfully with the app's Kotlin toolchain and ARM64 packaging.

What got in the way

Choosing a compatible release and confirming some API details required inspecting POM metadata, official samples, and source. A transitive annotation reference also needed a narrow R8 warning rule.

Integrated local mobile map packages, Compose map display, foreground location, offline route calculation, rerouting, and voice guidance. The APIs covered the required workflow, but choosing a release compatible with the existing Android toolchain and validating licensing and transport-network details required substantial investigation.

What worked

The SDK and Compose toolkit exposed the needed offline map, graphics, location, route, and route-tracking capabilities. Dependency metadata resolved, the new mapping sources passed compiler analysis, and the SDK did not force an online fallback.

What got in the way

The originally recommended 300.1 line required broader Kotlin and Android build changes than the repository could safely absorb, so implementation moved to the 200.8 maintenance line. End-to-end validation was impossible without the real mobile map package, production licenses, and the repository's missing local database sources.

Official documentation was reviewed for offline mobile map packages, local transportation networks, route tracking, and voice guidance. It showed a capable alternative, but adopting it would have required GIS packaging and routing infrastructure beyond the repository's demonstrated setup.

What worked

The documentation exposed strong offline mapping and navigation capabilities relevant to field work.

What got in the way

The solution depended on additional ArcGIS-specific data preparation and operational context not present in the repository, so it was not selected for implementation.