How iOS 12 Handles AR Session Interruption

With the release of iOS 12 and ARKit 2, Apple introduced significant improvements to how augmented reality experiences handle disruptions like incoming phone calls, multitasking, or sensor occlusion. Rather than requiring users to reset their scene and re-scan their physical environment after an interruption, iOS 12 allows an ARSession to preserve its spatial awareness through a process called relocalization. This article explains the lifecycle of AR session interruptions in iOS 12, the underlying delegate notifications, and how the relocalization feature restores virtual content to its correct real-world coordinates.

Interruption Triggers and Delegate Callbacks

An ARSession can be interrupted by several external events, including moving the application to the background, receiving a phone call, or experiencing severe sensor limitation (such as covering the camera). When an interruption occurs, the session pauses frame processing to conserve system resources.

ARKit informs the application of these lifecycle events through the ARSessionObserver protocol:

  • sessionWasInterrupted(_:): Called immediately when the session halts. Developers typically use this method to pause animations, stop sound effects, or freeze interaction timers, as camera frames and anchor tracking are temporarily suspended.
  • sessionInterruptionEnded(_:): Triggered when the interruption ceases (for example, when the user reopens the app). At this stage, the session resumes processing sensor data, but the tracking state will not immediately return to normal.

The Relocalization Process

Prior to iOS 12, ending an interruption often required running a new configuration with resetTracking, which removed existing anchors and forced users to rebuild their AR environment from scratch. iOS 12 resolves this using relocalization, powered by the internal mechanics of ARWorldMap.

When sessionInterruptionEnded(_:) fires, the tracking state of the camera changes:

  1. Limited Tracking State: The ARCamera.TrackingState changes to .limited with the reason .relocalizing.
  2. Feature Matching: While in this state, ARKit attempts to match the current visual feed from the camera against the point cloud and feature points captured immediately before the interruption.
  3. Restoring Coordinates: Once the user points the camera at an area that was previously scanned, ARKit reconciles the coordinate systems, smoothly snaps virtual anchors back into place, and shifts the tracking state back to .normal.

Implementing User Guidance and Fallbacks

Because relocalization requires visual correspondence between the current view and the pre-interruption environment, clear user interface feedback is essential. When the tracking state enters .limited(.relocalizing), the application should instruct the user to point the device toward the physical space viewed prior to the interruption.

If the user has moved to a completely different room or location during the interruption, relocalization may fail to recover the coordinate map. To handle this scenario, developers implement a timeout mechanism. If the tracking state does not return to .normal within a defined period (such as 10 to 15 seconds), the session can be explicitly restarted by invoking run(_:options:) with the .resetTracking and .removeExistingAnchors options, cleanly restarting the AR experience.