Mobile Response (iOS): Release Notes May 2026 (Version 6.0.2)
iOS Release Notes (iOS Version 6.0.2)
New Features
Extensible In-App Notification Banners
What - Implemented a redesigned in-app notification banner system that replaces the previous non-extensible architecture with a unified SwiftUI-based framework. The new banner experience introduces priority-based color theming, category-specific icons, multi-account agency logo support, and a scalable notification model capable of supporting future modules and notification types. Notification banners now visually distinguish incidents, chat, messaging, scheduling, status updates, and network connectivity alerts using dedicated icons and color-coded priorities, while preserving all existing interactions such as tap actions and swipe-to-dismiss behavior.
Why - As additional modules and notification types were added to the platform, the previous banner implementation became difficult to maintain and extend. The updated framework improves responder awareness during emergency operations by making alerts easier to identify at a glance and providing clearer visual distinction between notification urgency levels and originating agencies.
How
Navigate to Notifications within the mobile application.
Receive incoming alerts as normal through dispatch, chat, messaging, scheduling, or network status updates.
Review the updated visual indicators:
High Priority notifications display with red theming.
Medium Priority notifications display with yellow theming.
Low Priority notifications display with blue theming.
Multi-account users will automatically see the associated agency logo displayed within the notification banner.
Swipe notification banners to dismiss them or tap the banner to open the related workflow.
Use Case - During a multi-agency response, a responder signed into multiple departments can immediately identify which agency generated the alert while also recognizing the urgency level of the notification through color-coded indicators. This reduces confusion during active incidents and improves situational awareness when multiple notifications are received in rapid succession.
ArcGIS Last Known Position Retention with Department Center Fallback
What - Implemented a multi-layer map position fallback system that prevents ArcGIS from defaulting to 0,0 coordinates when GPS tracking is unavailable. The enhancement introduces persistent last known position retention, offline department-center caching, and improved provider transition handling between Google Maps and ArcGIS. The system now applies a three-tier fallback chain using the responder’s last known location, cached department coverage area, or server-provided area information to maintain valid map positioning during GPS interruptions or provider changes.
Why - Responders previously experienced situations where the map centered on invalid coordinates during GPS outages, provider transitions, or app restarts, negatively impacting operational awareness. The new fallback system ensures responders maintain meaningful geographic context even when live GPS data is temporarily unavailable.
How
Open the Map view within the mobile application.
Continue using either Google Maps or ArcGIS providers as configured.
If GPS connectivity is interrupted:
The application will retain the last known valid map position.
If no recent position exists, the app will automatically center on the department coverage area.
Resume GPS connectivity normally to allow the map to automatically recenter to the responder’s live position.
No configuration changes are required to enable this functionality.
Use Case - A responder operating in a low-connectivity environment temporarily loses GPS signal while switching between map providers. Instead of displaying an invalid global location, the map remains centered on the responder’s most recent operational area, allowing crews to maintain awareness and continue navigating incident activity without interruption.Expanded Offline Map Coverage for Pilot Clients
What - Expanded offline map download coverage for a pilot group of Tahoe-region clients by adding an additional 30 miles beyond the default department response area. The enhancement introduces a configurable offline coverage expansion system managed through Firebase Remote Config and includes multiple rendering and performance optimizations to support significantly larger offline map datasets without degrading application responsiveness.
Why - Some departments regularly respond beyond their primary response polygons for mutual aid, wildland operations, or large regional incidents. Previously, responders operating outside their standard offline map boundaries could lose access to critical map data when connectivity was unavailable.
How
Navigate to Offline Maps within the mobile application.
Download offline maps as normal.
Eligible pilot agencies automatically receive expanded coverage areas extending an additional 30 miles beyond the standard response boundary.
No manual configuration is required for enabled pilot agencies.
Use Case - During a regional wildfire or large mutual-aid deployment, crews operating outside their normal district boundaries retain access to critical offline mapping data even in low-connectivity areas, improving navigation and operational continuity throughout the response.
Password Reveal Icon for Authentication Screens
What - Added password reveal and hide toggle functionality to all authentication-related password fields, including the login screen, lock screen, and account-switch dialog. The enhancement introduces a consistent eye/eye-slash icon experience with accessibility-compliant touch targets and automatic password re-obscuring when leaving the screen or backgrounding the application.
Why - Mobile keyboard entry errors frequently caused failed login attempts because users had no way to verify password accuracy before submitting credentials. The updated experience improves usability while maintaining security best practices.
How
Open the Login, Lock, or Switch Account screen.
Enter a password into the password field.
Tap the Eye Icon to reveal the password text.
Tap the Eye Slash Icon to hide the password again.
Password visibility automatically resets when:
Leaving the screen
Switching applications
Backgrounding the app
Use Case - Responders logging into the application during field operations can quickly verify typed credentials before submitting, reducing failed login attempts caused by mistyped passwords on mobile keyboards.
Feature Enhancements
“Open on Incident List” Post-Login Behavior
What - Fixed an issue where the Open on Incident List setting was not consistently respected after logout and re-login on iOS devices. The application now reevaluates the user preference after authentication and correctly opens the Incidents tab when the setting is enabled.
Why - Users experienced inconsistent landing page behavior after reauthentication, causing the app to open on the Map tab instead of the configured Incident List view. This enhancement aligns the behavior across all app entry flows and improves consistency between iOS and Android platforms.
How
Navigate to App Settings.
Enable Open on Incident List.
Log out and log back into the application.
The application will now automatically open on the Incidents tab after authentication.
Use Case - A dispatcher or responder who prefers monitoring active incidents immediately after login can now rely on the app consistently opening to the Incident List view, reducing additional navigation during active operational periods.
Default Station Visibility for Bidirectional Clients
What - Restored visibility of the Default Station setting for bidirectional clients using the On Station responder status. The updated logic now properly recognizes bidirectional status configurations and displays the setting when applicable for unit responders.
Why - During the SwiftUI migration effort, the condition controlling visibility of the Default Station option did not account for expanded bidirectional responder workflows. This prevented some responders from configuring their default station assignment.
How
Navigate to App Settings.
Open Responder Status Settings.
Ensure the account is configured for bidirectional status layouts.
Unit responders using On Station status will now see the Default Station option automatically.
Select the preferred station to save it as the default assignment.
Use Case - Unit responders operating from multiple stations can configure their preferred station once and avoid repeatedly selecting the same station during status changes throughout a shift.
Incident Icons Color-Coded by Call Type
What - Updated incident icons throughout the application to use distinct colors and iconography for each incident type group, including Fire, Medical, Hazmat, MVA, Rescue, Law, Marine, Aircraft, and Other incidents. Icons now display consistently across incident lists, map markers, mini-maps, nearby hydrants, and notifications in both light and dark appearance modes.
Why - Previously, all incident types used a uniform icon style that made it difficult for responders to quickly distinguish between call categories during active operations. The updated visual design improves rapid recognition.
How
Open the Incident List or Map view.
Review incident icons displayed throughout the application:
Fire incidents display red-orange icons.
Medical incidents display green icons.
Hazmat incidents display yellow icons.
MVA incidents display blue icons.
Additional incident categories display their assigned colors automatically.
No user configuration is required.
Use Case - During periods of high call volume, responders can immediately identify the nature of incidents directly from the map or incident list without opening each dispatch, allowing for faster prioritization and situational assessment.
WebView Performance Improvements for In-App Web Pages
What - Optimized the mobile application's WebView layer through a coordinated set of improvements including a shared WebKit process pool, prefetched authentication tokens, reduced redundant JavaScript execution, and improved first-load handling for embedded web pages. These changes reduce native-side overhead and improve load performance for User Settings and other in-app web experiences.
Why - Users experienced delays when opening web-backed screens within the mobile application, particularly on User Settings pages. The enhancements reduce the mobile-side overhead contributing to those delays while establishing a stronger performance foundation for future WebView optimization efforts.
How
Open any web-backed feature such as:
User Settings
Dashboard
Street View
Incident Command
Navigate through embedded web pages as normal.
Performance improvements automatically optimize:
WebView initialization
Authentication token retrieval
Embedded page loading
Session reuse
JavaScript execution efficiency
Use Case - Responders opening web-backed screens from the app menu experience faster page initialization and smoother navigation transitions, especially when repeatedly switching between operational tools during active incidents.
Fixes
Chat Message Delivery Reliability
What - Resolved multiple issues affecting Pusher-based chat message delivery, including missed messages, inconsistent channel subscriptions, reconnection failures, and duplicate suppression logic. The update improves message synchronization, reconnect handling, and notification-to-chat navigation reliability across all app states.
Why - Some users experienced missing chat messages or inconsistent synchronization during WebSocket interruptions, particularly in large multi-user group conversations. The updated implementation improves overall chat reliability and consistency.
How
Open the Chat module.
Continue using group and direct messaging as normal.
The application now automatically:
Reconnects to chat channels after interruptions.
Synchronizes missed messages after reconnecting.
Prevents duplicate message display.
Correctly routes notification taps into conversations.
Use Case - During a prolonged incident response where responders move between connectivity zones, chat conversations continue synchronizing correctly after reconnecting, ensuring no operational communications are missed.
External Display Launch Stability
What - Fixed a crash-on-launch issue affecting iPads connected to external displays through AirPlay, HDMI, or screen mirroring. The application now correctly handles secondary display scene connections during startup.
Why - The SwiftUI lifecycle migration introduced a startup conflict when external display scenes were initialized, preventing the app from launching successfully on connected iPads.
How
Connect an iPad to an external display using AirPlay, HDMI, or screen mirroring.
Launch the mobile application normally.
The application will now open successfully without crashing.
Use Case - Departments using iPads for station command boards or briefing room displays can now reliably launch and operate the application while connected to external monitors during operational planning or incident coordination.
Near Places Crash Resolution
What - Fixed a fatal crash caused by excessive memory usage during paginated loading of nearby places data on large map areas. The update introduces pagination limits and incremental data merging to prevent unbounded memory growth.
Why - Users viewing large operational regions with dense place data could encounter application crashes caused by memory exhaustion during extended pagination requests.
How
Open the Map view.
Navigate to large geographic areas with nearby places enabled.
The application now incrementally processes nearby place data without exceeding memory limits.
Use Case - Responders monitoring regional operations across large districts can pan and zoom the map extensively without triggering application instability or unexpected crashes.
Unit Tracking Profile Image Accuracy
What - Fixed intermittent issues where unit tracking icons displayed incorrect profile images due to cache key collisions. The caching system now uses stable URL-based identifiers to ensure each unit consistently displays the correct image.
Why - Some departments using large tracking deployments or shared agency configurations experienced incorrect avatar images appearing on maps and unit lists, creating potential responder identification confusion.
How
Open the Map or Unit List view.
Review tracked unit icons and profile images.
The application now consistently displays the correct image for each unit automatically.
Use Case - During mutual aid operations involving multiple agencies, dispatchers and responders can confidently identify tracked units by their correct profile images without cross-department image mix-ups.
Authentication Token Preflight Validation
What - Implemented authentication preflight validation to prevent API requests from being sent with invalid or empty authentication tokens after logout. The application now blocks unauthorized requests before transmission and uses a dedicated unauthenticated client for login workflows.
Why - Background polling processes continued sending requests after logout, generating unnecessary authentication failures and server-side errors.
How
Log out of the mobile application normally.
The application will now automatically stop authenticated polling requests after logout.
Reauthenticate through the standard login workflow as needed.
Use Case - Users switching accounts or logging out during shift changes no longer generate unnecessary authentication failures in the background, improving system efficiency and reducing server-side error noise.
DND Date Picker Button Visibility
What - Fixed an iPhone layout issue where the Accept and Cancel buttons were hidden on the Do Not Disturb date picker screen, preventing users from confirming or canceling DND schedules.
Why - The previous sheet presentation layout clipped toolbar controls on smaller devices, preventing completion of DND scheduling actions.
How
Tap the Bell Icon from the Map screen.
Select Do Not Disturb scheduling.
The Accept and Cancel buttons will now display correctly on iPhone and iPad devices in both portrait and landscape orientation.
Use Case - Responders temporarily disabling notifications during training, meetings, or overnight shifts can now reliably configure and confirm DND schedules without interface navigation issues.
Regional Preplan Layers Permission Validation
What - Fixed an issue where the application could request regional preplan layer data even when users lacked permission to access those layers. The app now validates permissions before making requests and clears restricted layer data when access is unavailable.
Why - Unauthorized requests generated unnecessary server-side permission errors and created inconsistent layer-loading behavior during account changes or permission updates.
How
Open the Map view with regional preplans enabled.
The application now automatically validates the Regional Preplan permission before requesting layer data.
Users without permission will no longer receive restricted layer requests.
Use Case - Agencies managing multiple responder roles with varying access permissions can ensure only authorized personnel load regional preplan data while maintaining clean account-switching behavior and consistent map performance.
Notification Settings Persistence from Map Bell
What - Fixed an issue where notification preferences configured from the Bell Icon on the Map screen did not persist after force-closing and reopening the application. Notification and Do Not Disturb preferences now correctly synchronize local and server-side state immediately after saving.
Why - Users experienced situations where notification settings appeared to revert after relaunching the application because local preference state was not refreshed after server updates completed.
How
Open the Map screen.
Tap the Bell Icon.
Configure notification or Do Not Disturb settings.
Save the preference changes.
Force-close and reopen the application.
The updated preferences will now persist correctly.
Use Case - Responders configuring temporary notification suppression during meetings, training, or overnight operations can now rely on their settings remaining active even after restarting the application.