ArcGIS Blog

Announcements

Developers

Announcing the Deprecation of ArcGIS Maps SDK for Local Server

By Mike Branscomb and Rex Hansen and Nick Furness

The ArcGIS Maps SDK for Local Server has been deprecated and will be retired in 2030. If you have applications that use Local Server, it is time to start planning your migration to the use of core capabilities provided directly by ArcGIS Maps SDKs for Native Apps.

What is ArcGIS Maps SDK for Local Server?

ArcGIS Maps SDK for Local Server (also known as “Local Server”) is an optional component available for the ArcGIS Maps SDKs for .NET, Java, and Qt. Originally launched in 2012 as ArcGIS Runtime SDK for Local Server, it was renamed in December 2022 to align with the broader rebranding of the ArcGIS Runtime SDKs to ArcGIS Maps SDKs for Native Apps, commonly referred to as the Native Maps SDKs.

Local Server was designed to support offline data workflows and provide GIS capabilities in custom desktop applications. By utilizing Local Server, developers could integrate offline spatial analysis and data manipulation capabilities into their desktop apps through local geoprocessing services that run directly on user devices without requiring network connectivity. Additionally, Local Server enabled developers to access various on-device data formats as map image layers and feature layers. These layers were sourced from local map and feature services hosted by Local Server, which were created from map packages initially authored with ArcMap and, since 2019, ArcGIS Pro.

What’s the timeline? 

The last release of Local Server will be ArcGIS Maps SDK for Local Server 200.8, scheduled for release in Q3 2025. This will be a long-term support release (LTS) and follows the LTS Product Life Cycle of two years of General Availability (GA), one year of Extended Support, and two years of Mature Support, before retirement in 2030.

Why is Local Server deprecated?

Local Server is deprecated because most of it’s capabilities are now available directly in the Native Maps SDKs. The SDKs have advanced significantly since their initial releases over a decade ago, gradually phasing out the need for Local Server in many situations. For example, since 2016 the Native Maps SDKs have added support for reading and querying features directly from local, on-device mobile geodatabases. Mobile geodatabases offer high-performance cross-platform display, query, and feature editing capabilities with a significantly smaller footprint than a Local Server deployment. In addition, Native Maps SDKs provide more comprehensive support for offline feature data editing workflows through mobile maps and geodatabases using sync-enabled feature services, further removing the dependency on Local Server. See the Esri Developer guide for more information about building offline mapping apps, and for SDK-specific topics see Offline maps, scenes, and data (.NET) or Offline maps, scenes, and data (Qt).

Local Server is only available only for the Linux and Windows desktop operating systems. Migrating to functionality available directly in Native Maps SDKs opens up access to a broader range of development platforms. Native Maps SDKs include support for Kotlin, Flutter, and Swift, as well as support for additional operating systems such as Android, iOS, and macOS. Compared to deploying Local Server with your desktop app, using core capabilities available directly in Native Maps SDKs enables you to create native desktop and mobile applications with a smaller on-device footprint, better performance, and greater flexibility, including the ability to distribute through app stores.

Although Local Server offered significant functional versatility, the workflows and artifacts associated with it were unfamiliar to many developers. Leveraging the functionality available natively within a Native Maps SDK instead of using Local Server, enables you to implement more application logic in code, all within the same integrated development environment you use daily, and with greater support for version control, enhancing productivity and shortening dev/test/debug/fix cycles.

How will this deprecation affect you?

If you have developed applications using the ArcGIS Maps SDKs for .NET, Java, or Qt, and have implemented features that depend on Local Server, you need to migrate to the use of core capabilities within the Native Maps SDKs. As mentioned earlier, there are numerous advantages to migrating. Because the last Local Server release later this year will be supported for 5 years, you will have plenty of time to complete your migration.

The current release of Local Server does include functionality that is not yet available natively in the Native Maps SDKs. This includes direct access to ArcGIS Enterprise geodatabases and a host of geoprocessing tools. Future releases of the Native Maps SDKs will include support for direct access to Enterprise geodatabases (on supported platforms) and the Native Maps SDKs roadmap includes a series of high-performance on-device spatial analysis tools across all supported platforms, which will replace the need for Local Server.

Where can you get more information? 

For more information, please refer to the Deprecation Notice for the ArcGIS Maps SDK for Local Server. As you plan your migration, if you encounter functionality that relies on Local Server and you cannot determine the appropriate migration path, please email ArcGISLocalServerDeprecation@esri.com and provide details of your workflow, including the tools, operations, and/or data formats required. It’s also worth noting the deprecation of the ArcGIS Maps SDK for Java was announced in 2024. For broader questions about capabilities of the Native Maps SDKs, please reach out to us on Esri Community.

In this first post covering the deprecation of Local Server, we’ve discussed the reasons for the deprecation, introduced the overall migration story, and mentioned the high-level benefits of migrating to core capabilities in the Native Maps SDKs. Stay tuned for another post in which we’ll review some common areas of Local Server functionality and provide specific migration paths.

Share this article