This blog covers ArcGIS Field Maps, ArcGIS Survey123, ArcGIS QuickCapture, and ArcGIS Navigator.

For many organizations, one or more of the ArcGIS mobile apps are used and relied on by field teams throughout their daily work, whether it’s locating the asset they are working on, or recording data from the field.

These apps are updated through the Apple App Store and Google Play. Unlike desktop or on-premise software where you control when updates are deployed, app store releases are available to your field teams as soon as they’re published.

Every release includes new capabilities, improvements to existing functionality, and bug fixes.

Best practice is to adopt the latest version as quickly as possible. To minimize risk, validate your current workflows ahead of the release using the Early Adopter Community (EAC), then move to production.

Release Types

There are three types of releases for ArcGIS mobile apps:

Assessing Impact

The first thing to do when it comes to a new release is assess the impact of what’s coming on the workflows you have in production. There are several lenses to examine this through:

1. Is there new functionality that will help my team in the field?
2. Has existing functionality my team uses today changed?
3. Are there interface changes that field teams may need to be made aware of?
4. Is this a major release where it’s been advised to test?

Esri conducts extensive testing before every release, but given the complexity of enterprise environments, local validation is recommended, even if you do not plan to introduce new capabilities to the team.

Test Strategy

How much testing you do depends on your organization, your workflows, and what’s in the release. Not every release needs the same level of effort. Below are three tiers of testing; pick the level that matches the risk.

Before you start, document the key workflows your field teams rely on day to day. This becomes your test plan. If you don’t know what to test, talk to the people doing the work, they’ll tell you how they use it and what matters.

Beta versions from the Early Adopter Community can be installed alongside the current release version on the same device. This means you can test without disrupting your field teams’ production workflows. Consider involving your mobile workers in the testing effort since they know the workflows best and can flag issues that may not surface in a controlled environment.

Tier 1 Smoke Testing

A quick confidence check. Open the app, sign in, load your map, and run through your most common workflow end-to-end. The goal isn’t to test every feature, it’s to catch anything obvious that would interrupt work. This is the minimum you should do for every release.

Tier 2 Acceptance Testing

Targeted testing of what makes your deployment unique. If your field teams work offline, test offline. If they operate behind a VPN, test behind a VPN. If they use ArcGIS Enterprise, test with this environment. Focus on the conditions and workflows your mobile workers encounter, not a generic checklist.

Tier 3 Functional Testing

A thorough walkthrough of specific functional areas, GPS capture, offline sync, form entry, tasks, and so on. This level of testing is most relevant when the release notes indicate changes to features you depend on.

It is not recommended to test with production maps and data during the beta period. Use representative test data that mirrors your production environment.

Release Communications

Knowing what’s coming, and when, is how you decide which testing tier to apply and when to start.

Before Release

Each release has a beta period through the Early Adopter Community (EAC). Sign up for the apps your organization uses, and you’ll receive an email when a beta build is available, along with what’s included and what’s ready to test. There may be several beta builds during a cycle as new capabilities are previewed ahead of the release.

Beta builds are accompanied by a blog on Esri Community detailing what’s coming. Subscribe to the RSS feed to get notified when new posts are published.

This is your window to start testing, before the release reaches your field teams.

At Release

Each app publishes a release blog and updated What’s New documentation covering everything in the release. If you’ve already tested during the beta period, these are your confirmation that what you validated is now in production. If you haven’t, this is your prompt to start.

Managing Rollout

How you roll out a new release depends on whether your organization uses a Mobile Device Management (MDM) system. Either way, the testing and communication guidance above applies, the difference is how much control you have over when the update reaches your field teams.

With an MDM

Controlling when updates are deployed to users can be configured with Apple Business Manager and Managed Google Play. This means you can hold the current version in production while you validate the new release, then roll out on your own schedule.

A phased approach works well here:

1. Pilot group, deploy the new release to a small group of testers who validate your core workflows.
2. Wider validation, expand to a broader group that covers more of your deployment’s complexity, different regions, connectivity conditions, or workflow types.
3. General rollout, once validated, push the update to all devices.

This does mean your field teams will be on a previous version during the validation period. See Support for Previous Versions below for what that means.

For more detail on MDM configuration, see ArcGIS Field Apps and Mobile Device Management (MDM).

Without an MDM

Without an MDM, app store updates will reach your field teams as soon as they’re published, or whenever their devices auto-update. Your primary testing window is the beta period through the Early Adopter Community, before the release goes live.

It’s worth knowing how auto-update behaves on each platform:

• iOS: auto-update is a device-level setting. Turning it off disables updates for all apps, not just ArcGIS.
• Android: auto-update can be configured per app, giving you more granular control.

Disabling auto-update is generally not recommended as a long-term strategy because it means devices won’t receive improvements, performance fixes, or bug fixes. If your organization does choose to delay updates at the device level, check with your IT department and be aware of the support implications for previous versions, below.

Support for Previous Versions

If your organization holds back a release while validating, whether through an MDM or by disabling auto-update, it’s important to understand what support looks like for the version you’re running.

The ArcGIS mobile apps follow a three-stage product lifecycle:

• General Availability: the current release, fully supported.
• Mature Support: when a new version is released, the previous version enters Mature Support for 90 days. It remains supported during this period, but bug fixes will only be applied to future releases.
• Retired: after the 90-day Mature Support window, the previous version is retired and no longer supported.

Two things worth noting:

• Previous versions cannot be reinstalled: Once a device is updated, you cannot roll back. If you’re using an MDM to control rollout, validate before you deploy.
• The 90-day window is your buffer, not your target: It exists so organizations have time to validate and transition, not so they can defer updates indefinitely.

For full details on the product lifecycle for each app, see Changes to the Field Operations Mobile Apps Product Life Cycle.