We are seeing a reproducible process termination involving a companion watchOS app and its paired iOS companion app when Motion & Fitness authorization is requested from the watchOS app. Context: iOS app bundle identifier: com.alpha.golfbird watchOS app bundle identifier: com.alpha.golfbird.watchkitapp The watchOS app has WKCompanionAppBundleIdentifier set to the iOS app bundle identifier. Both the iOS app and the watchOS app include NSMotionUsageDescription in their Info.plist files. The watchOS app uses CMAltimeter to read barometric altitude changes for slope-adjusted golf distance calculations. The authorization flow checks CMAltimeter.authorizationStatus(). If the status is notDetermined, it uses CMMotionActivityManager.queryActivityStarting(from:to:to:) before starting CMAltimeter updates, following the known iOS 17.4+ Core Motion authorization behavior. Observed behavior: Install or launch the watchOS companion app for the first time. Open the paired iOS companion app and keep it in the foreground. In the watchOS app, enter the feature that starts the slope/altimeter flow. watchOS shows the Motion & Fitness permission prompt. After the user grants permission, the watchOS app continues normally and CMAltimeter authorization succeeds. At approximately the same time, the foreground iOS app process is terminated. In debug builds, Xcode reports: Debug session ended with code 9: Terminated due to signal 9 In TestFlight builds, users observe that the iOS app closes and relaunches. We do not get a normal iOS crash stack trace for the iOS app, which makes this look like a system termination rather than an application exception. Expected behavior: Granting Motion & Fitness authorization from the watchOS companion app should not terminate the foreground paired iOS companion app, or there should be documented lifecycle behavior and a recommended state-restoration strategy for this case. Question: Is it expected system behavior for a watchOS companion app's Motion & Fitness / Core Motion authorization change to terminate the paired foreground iOS companion app process? If it is expected, is there any documented notification, lifecycle callback, or recommended workaround so the iOS app can preserve and restore user state without looking like a crash? If it is not expected, should this be filed as a Core Motion / watchOS / WatchKit privacy authorization bug via Feedback Assistant, and what diagnostic logs would Apple recommend attaching?