Overview

OS 6.1.2 focuses on stability, map reliability, and session hardening. It resolves three production crashes seen in 6.1.0, restores plot plans and ArcGIS layers on the map, routes all native API calls through a single authenticated path, speeds up app launch by opening offline databases on demand, keeps previously loaded pages usable offline, and stops notification alert tones the moment a responder taps, swipes, or acknowledges.

New Features

• No new features are included in this release.

Feature Enhancements

Unified Session and Authentication Handling

• What - Improved how the iOS application handles authenticated network requests by routing native API activity through a consistent authentication process. Token expiration and session expiration are now handled uniformly, including a single logout process when a session expires.
• Why - Consistent authentication handling provides a more predictable experience when a user's session expires and helps prevent duplicate logout messages or inconsistent behavior between different areas of the application.
• How
  • Continue using the mobile application normally.
  • Native requests automatically use the updated authenticated network process.
  • If the user's session expires, the application automatically handles the expiration and initiates the appropriate logout workflow.
  • No configuration changes are required.
• Use Case - A responder whose session expires while using the application receives a consistent logout experience rather than multiple alerts or different behaviors depending on which mobile workflow was active.

Faster Application Startup

• What - Improved application startup performance by changing when offline databases are opened. Instead of opening all applicable offline databases during application launch, the databases are now opened when they are first needed by a supported workflow.
• Why - Deferring offline database initialization reduces work performed during application startup and can shorten the time required to reach a usable application state, particularly on slower devices.
• How
  • Launch the First Due Mobile App normally.
  • Offline databases are no longer opened automatically as part of the initial startup process.
  • When a supported workflow requires offline information, the applicable database is opened automatically.
  • No user configuration is required.
• Use Case - A responder launching the application to quickly review a new incident can reach the usable application interface sooner without waiting for offline databases that may not be needed during that session.

Offline WebView Reloading

• What - Improved offline behavior for previously loaded web-based pages. When connectivity is unavailable, reloading a WebView page that has already been loaded can now use available cached content instead of automatically attempting a network request that cannot be completed.
• Why - Maintaining access to previously loaded information when connectivity is interrupted provides a more resilient field experience and reduces unnecessary failures when users are operating with limited or no network access.
• How
  • Open a supported web-based page while connected.
  • If connectivity is later lost, return to or reload the previously loaded page.
  • When cached content is available, the application can use that content rather than requiring a successful network request.
  • Availability of information while offline depends on content having previously been loaded and cached.
• Use Case - A responder opens operational information while connected and subsequently moves into an area with poor connectivity. If the previously loaded page is refreshed, available cached content can remain accessible instead of the reload immediately failing.

Offline Navigation Handling

• What - Improved how navigation to offline-capable modules is handled from the Options menu when the device is offline, providing clearer gating between workflows that can operate without connectivity and those that require an active connection.
• Why - Clearly distinguishing offline-capable workflows helps users understand which application functions remain available when network connectivity is unavailable.
• How
  • Open the Options menu while operating without connectivity.
  • Select an available offline-capable module using the existing navigation.
  • Navigation availability is automatically determined based on the module's offline support.
  • Features that require connectivity remain subject to their existing online requirements.
• Use Case - A responder operating in an area without cellular or Wi-Fi connectivity can use the Options menu to access supported offline functionality without attempting to enter workflows that require an active network connection.

Foreground Notification Tone Control

• What - Improved foreground notification behavior so an active alert tone stops immediately when the user interacts with the notification by tapping the banner, swiping it away, or selecting Acknowledge.
• Why - Once a responder has acted on a notification, continuing to play the alert tone is unnecessary and can be distracting during response operations. Stopping the sound immediately provides clear feedback that the user's interaction has been recognized.
• How
  • Receive a notification while actively using the application.
  • Tap the notification banner, swipe the notification away, or select Acknowledge.
  • The active alert tone stops immediately.
  • The application does not need to wait for a server response before stopping the sound.
• Use Case - A responder receives an alert while reviewing another incident and selects Acknowledge. The notification tone immediately stops, allowing the responder to continue working without waiting for the acknowledgement request to finish processing.

Fixes

Concurrent Network Request Crash

• What - Fixed a production crash that could occur when multiple network requests started at approximately the same time, including situations where the incident list and dispatch synchronization processes were running concurrently.
• Why - Multiple application services may request information simultaneously during normal responder operations. Correctly handling concurrent requests reduces the risk of unexpected application closures during synchronization.
• How
  • Continue using incident and dispatch workflows normally.
  • Simultaneous network activity is now handled using the corrected processing behavior.
  • No user action or configuration is required.
• Use Case - A responder opens the application while incident information and dispatch updates are synchronizing at the same time without encountering the previously identified crash.

Low Device Storage Crash

• What - Fixed a crash that could occur when the application attempted to save data while the iOS device had insufficient available storage space.
• Why - Mobile devices may occasionally operate with limited storage. Handling low-storage conditions more safely reduces the likelihood that an unsuccessful data write will unexpectedly close the application.
• How
  • Continue using the application normally.
  • The application now more safely handles the identified low-storage condition when attempting to save information.
  • Maintaining adequate available device storage is still recommended for normal application operation.
• Use Case - A responder using an iOS device with very limited remaining storage encounters a data-saving operation without the application unexpectedly closing because of the previously identified condition.

Map Crash During Logout or Account Switching

• What - Fixed a map-related crash that could occur when a user logged out or switched accounts while the map screen was active.
• Why - Users who work with multiple accounts or need to end a session should be able to transition between accounts safely regardless of which application screen is currently open.
• How
  • Use the map normally.
  • Log out or switch accounts using the existing account workflow.
  • The active map is now handled safely as the current session ends.
  • No additional configuration is required.
• Use Case - A responder viewing the map can switch to another configured account without first leaving the map screen and without triggering the previously identified application crash.

Google Maps Foreground Crash

• What - Updated the application's diagnostics SDK to address a Google Maps crash that could occur when returning the application to the foreground.
• Why - Responders frequently move between First Due and other mobile applications during active operations. Improving map stability when returning to First Due reduces interruptions to navigation and situational awareness.
• How
  • Use the Responder Map normally.
  • Move First Due to the background as needed.
  • Return to the application.
  • The updated application components address the identified Google Maps crash condition.
  • No user configuration is required.
• Use Case - A responder switches from First Due to another application and then returns to the Responder Map without encountering the previously identified Google Maps crash.

Plot Plans Not Displaying on Mobile

• What - Fixed an issue where configured plot plans could be visible on the web platform but fail to display in the iOS mobile application.
• Why - Plot plans provide important visual information about properties and incident locations. Consistent availability between web and mobile helps ensure responders can access the same operational information while in the field.
• How
  • Open the applicable location or map workflow containing a configured plot plan.
  • View the location using the iOS mobile application.
  • Available plot plan information now displays as expected.
  • No additional mobile configuration is required.
• Use Case - A responder arriving at a property can view the same configured plot plan from an iPhone or iPad that is available to users accessing the location through the web platform.

ArcGIS Layers with Custom Base Maps

• What - Fixed an issue where ArcGIS layers could become hidden when certain custom base maps, including supported aerial WMTS base maps, were selected.
• Why - Operational map layers need to remain visible regardless of the supported base map selected by the user. Hidden layers can prevent responders from seeing important mapped information.
• How
  • Open the applicable Map.
  • Select a configured custom base map.
  • Enable the desired ArcGIS layers.
  • Supported ArcGIS layers now remain visible with the affected custom base maps.
• Use Case - A responder switches to a configured aerial base map while reviewing an incident and can continue seeing applicable ArcGIS operational layers instead of having them disappear.