Introduction

Crashes around stopDeviceMotionUpdates() are usually not caused by the stop call itself in isolation. More often, the real issue is lifecycle or threading: the app starts and stops motion updates from different places, deallocates the owner too early, or races with work still running on a queue. If the crash seems iPad-only, that often means timing or device-specific execution order is exposing a bug that already existed.

Start With a Predictable Motion Manager Lifecycle

The first rule is simple: create one CMMotionManager, keep it alive for as long as you need motion updates, and stop updates before the owning object disappears.

1import CoreMotion
2import Foundation
3
4final class MotionController {
5    private let motionManager = CMMotionManager()
6    private let queue = OperationQueue()
7
8    func start() {
9        guard motionManager.isDeviceMotionAvailable else { return }
10
11        queue.name = "motion.queue"
12        motionManager.deviceMotionUpdateInterval = 1.0 / 60.0
13
14        motionManager.startDeviceMotionUpdates(to: queue) { motion, error in
15            if let error = error {
16                print("Motion error:", error)
17                return
18            }
19
20            if let motion = motion {
21                print(motion.attitude.roll)
22            }
23        }
24    }
25
26    func stop() {
27        if motionManager.isDeviceMotionActive {
28            motionManager.stopDeviceMotionUpdates()
29        }
30    }
31}

That pattern avoids one common bug: calling stopDeviceMotionUpdates() on a manager that has already been torn down or replaced.

Stop From a Controlled Context

A lot of crashes come from calling start and stop from unrelated parts of the app without coordination. It is safer to funnel those actions through one owner object instead of letting several view controllers or render callbacks manipulate CoreMotion directly.

For example, this is safer than scattering motion-control calls throughout the app:

1final class MotionController {
2    private let motionManager = CMMotionManager()
3    private let queue = OperationQueue()
4
5    private(set) var isRunning = false
6
7    func startIfNeeded() {
8        guard !isRunning, motionManager.isDeviceMotionAvailable else { return }
9        isRunning = true
10        motionManager.startDeviceMotionUpdates(to: queue) { _, _ in }
11    }
12
13    func stopIfNeeded() {
14        guard isRunning else { return }
15        motionManager.stopDeviceMotionUpdates()
16        isRunning = false
17    }
18}

A single control point makes repeated start-stop sequences easier to reason about.

Watch for Queue and Deallocation Races

If your motion handler updates UI, game state, or rendering state, the stop call may race with work still being processed elsewhere. That does not mean stopDeviceMotionUpdates() is wrong. It means the app still has code assuming updates are active while the manager is shutting down.

Common danger patterns include:

• motion callback captures self strongly and outlives its owner
• owner deinitializes while background work still references it
• UI is touched from the motion queue instead of the main thread
• one thread calls stop while another thread immediately recreates or replaces the manager

If you update UI from motion data, hop back to the main queue explicitly:

1motionManager.startDeviceMotionUpdates(to: queue) { [weak self] motion, error in
2    guard let self = self, let motion = motion else { return }
3
4    DispatchQueue.main.async {
5        print(motion.attitude.pitch)
6        _ = self
7    }
8}

The weak capture avoids extending the owner's lifetime accidentally.

Tie Start and Stop to App or View Lifecycle

A clean place to stop motion updates is when the relevant screen disappears or when the app moves out of the active state.

1override func viewDidAppear(_ animated: Bool) {
2    super.viewDidAppear(animated)
3    motionController.startIfNeeded()
4}
5
6override func viewWillDisappear(_ animated: Bool) {
7    super.viewWillDisappear(animated)
8    motionController.stopIfNeeded()
9}

That is much easier to debug than starting from one subsystem and stopping from another unrelated callback.

Debug the Real Crash Site

If the stack trace only shows stopDeviceMotionUpdates(), do not stop there. Check:

• whether the manager is still valid
• whether the callback queue is touching deallocated objects
• whether the crash occurs after repeated start-stop cycles
• whether UI or renderer shutdown overlaps the stop call

An iPad-only crash often points to timing, not to a fundamentally different API contract. Faster or slower execution can reveal races that other devices do not expose consistently.

Common Pitfalls

The first pitfall is creating several CMMotionManager instances and losing track of which one is active. The stop call then hits the wrong lifecycle boundary.

Another issue is calling stop while callbacks are still mutating state owned by an object that is already disappearing. The crash looks like a CoreMotion problem even though the real bug is ownership or queue safety.

Developers also sometimes update UI directly from the motion callback queue. That can create hard-to-reproduce crashes unrelated to the sensor call itself.

Finally, avoid speculative fixes such as random delays around stop. Make the lifecycle deterministic instead.

Summary

• 'stopDeviceMotionUpdates() crashes are often caused by lifecycle or threading bugs around the motion manager.'
• Keep one clear owner for CMMotionManager and stop updates before that owner goes away.
• Coordinate start and stop calls instead of scattering them across the app.
• Use weak captures and main-thread hops when callbacks interact with UI or owner state.
• Treat iPad-only behavior as a sign to investigate race conditions and teardown order carefully.