We have developed an iPad application using the ARCL (AR + CoreLocation) library to render Point of Interest (POI) annotations in both an AR view and a standard MapView. The application performs as expected on standard devices. However, we have some iPad covered with strong magnet. This creates significant magnetic interference, resulting in a 90° to 180° heading offset, rendering the AR POI placement and MapView orientation unusable. Technical Challenges & Constraints: Hardware Lock: The magnetic cover is a mandatory business requirement and cannot be removed during field use. Sensor Failure: The internal magnetometer cannot provide an accurate North reference due to the proximity of the cover’s magnets. While CoreLocation and CoreMotion use sensor fusion, the magnetometer remains the primary source for absolute heading. Alternative Orientation Tracking: Is there a documented method to bypass the magnetometer and derive device orientation using only the Gyroscope and Accelerometer (e.g., relative tracking) while still maintaining alignment with geographic coordinates in CoreLocation? Programmatic Offsets: Are there known APIs or mathematical workarounds to programmatically "nullify" or offset a constant magnetic bias once the device is inside the cover? so we can use that offset for ARView and in Mapview as well.

On Apple Watch (reported several times, but also on a powerful Ultra3), the CMAltimeter occasionally stops delivering updates for a while (a couple of minutes) then resumes. This makes for a terrible user experience. What could cause this? Is there a way to (best case) prevent this, or (workaround) detect it? This is production critical, any help would be greatly appreciated. Thanks a lot!

Our App has a feature that needs to determine if the phone was stationary during the last 10 seconds. For the past several years, we have been using CMMotionActivityManager for this feature and it has worked very reliably. We query motion activity for the past 10 seconds (using queryActivityStarting(from:to:to:) method) and check for any events where the stationary property is false. However, the behavior of CMMotionActivityManager has changed in iOS 16.4 Beta: CMMotionActivityManager no longer reports motion as it did on iOS 16.3 and earlier versions. With iOS 16.4 Beta, CMMotionActivityManager will falsely return events where the stationary property is true (or return no events) even though the phone was in motion during the query interval. There are times when it does return motion events correctly, but that only happens if the phone is in constant motion for a sustained period of time. This behavior is drastically different from previous iOS versions where even the slightest bit of movement would generate motion events. i'm really hoping this is an issue in the beta and will be sorted out soon. Feedback Filed: FB12005598

I'm building a sleep tracker for couples — the headline feature is a notification to your partner the moment you fall asleep (and another when you wake up), detected on the Apple Watch from accelerometer and heart-rate data. The detection has to happen within minutes of onset for the product to make sense. My setup HKObserverQuery on heart rate with enableBackgroundDelivery(.immediate), re-registered on foreground. WKApplicationRefreshBackgroundTask rescheduled every 15 minutes. CMSensorRecorder.recordAccelerometer(forDuration: 12 * 3600) re-armed on every wake. A van Hees-style stillness classifier reading the last ~35 minutes of the buffer, with heart rate as a soft confirmer. HealthKit and Motion & Fitness authorized on both iPhone and watch. The observer's completionHandler() is called on every branch and the handler stays well under the 15-second watchdog. No HKWorkoutSession as my app is not a workout. Questions Is CMSensorRecorder paused or deprioritized while the Apple Watch's automatic sleep detection has classified the user as asleep? On a worn watch with the recorder armed for 12 hours, accelerometerData(from:to:) over a 35-minute window inside the auto-detected sleep period returns zero samples. The exact same call an hour later, once the watch has decided the user is awake, returns roughly ten thousand samples for an equivalent window. The user never activated Sleep Focus or Theater Mode — the only sleep-related state at play is the watch's own automatic detection, the same one that writes Core / REM / Deep stages into Apple Health. Is this documented power management I missed, or is it unexpected? Happy to file Feedback with a sysdiagnose during the window if you confirm it shouldn't behave this way. Is there a sanctioned non-workout path on current watchOS for detecting sleep onset within a few minutes of it happening? A full night recently produced a five-hour stretch with zero observer callbacks and zero background-refresh deliveries between bedtime and wake. The historical guidance to third-party sleep apps has been to reconstruct nights post-hoc from sleepAnalysis samples rather than attempt live detection. Is that still the recommendation today, or is there an API I've missed that would give an onset-focused app tighter wakes around bedtime? What is the current App Store review stance on HKWorkoutSession for sleep tracking? Would an app that auto-starts a .other / indoor workout only when its own classifier detects pre-sleep signals at the user's typical bedtime, ends the session as soon as onset is confirmed, never starts one outside that gated condition, and explicitly discloses "sleep tracking via workout session" in the App Store metadata — be an acceptable pattern, or grounds for rejection regardless of disclosure?

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?

I'm building a freediving app for Apple Watch Ultra using the shallow depth entitlement (com.apple.developer.submerged-shallow-depth-and-pressure). My app uses WKExtendedRuntimeSession with the underwater-depth background mode, and it works correctly — the session starts, Water Lock activates automatically, and Crown hold water ejection ends the session as expected. However, the app does not appear in Settings > General > Auto-Launch > When Submerged on the watch. Other third-party apps (including one that hasn't been updated in ~2 years and presumably only has the shallow entitlement) do appear in this list. My configuration: WKBackgroundModes: ["underwater-depth", "workout-processing"] WKSupportsAutomaticDepthLaunch: true (Boolean, in watch app Info.plist) Entitlement verified in both the signed binary and provisioning profile watchOS 26.3, Apple Watch Ultra 2 Tested with: development build, TestFlight, and direct Xcode deploy. Watch restarted after each. The app does not appear in any case. The documentation at https://developer.apple.com/documentation/coremotion/accessing-submersion-data states: "Adding the underwater-depth Background Mode capability also adds your app to the list of apps that the system can autolaunch when the wearer submerges the watch." Does auto-depth-launch require the full depth entitlement (com.apple.developer.submerged-depth-and-pressure), or should the shallow entitlement be sufficient? Is there an additional step required for the app to appear in the When Submerged list? Any guidance appreciated.

I’m running into a hardware reality. MEMS sensor thermal drift. If a user zeroes out the tilt indoors at 20°C and then takes the phone outside in the cold, the accelerometer baseline shifts just enough as the device cools to throw off the readings. I want to apply a simple thermal compensation curve to the CoreMotion data to keep the "zero" perfectly level regardless of the weather. However, ProcessInfo.thermalState only gives broad buckets (nominal, fair, etc.) which doesn't help me calculate a continuous offset for a phone cooling down degree by degree. Is there any public API, or even a proxy metric, that can give me a rough battery or internal temperature integer? I don’t need high resolution decimals. Just a general device temp to offset the hardware drift. Any undocumented tricks or proxy metrics anyone has used to handle this?

When iterating over a CMSensorDataList (which conforms to NSFastEnumeration) returned by CoreMotion's CMSensorRecorder's accelerometerData(from:to:) method, we sometimes see the crash below, with the frame above pointing to the close brace of the for loop iterating over the list. 0 CoreMotion 0x000000019fcf01dc CLInternalGetPinnedLocationAuthorizationState + 423316 1 CoreMotion 0x000000019fcf036b CLInternalGetPinnedLocationAuthorizationState + 423715 2 CoreMotion 0x000000019fcf02cb CLInternalGetPinnedLocationAuthorizationState + 423555 3 CoreMotion 0x000000019fbb8553 CLMotionActivity::isStatic() const + 1751823 It has been incredibly difficult to reproduce. We managed to reproduce a similar crash stack twice in a separate app that misused accelerometerData(from:to:) by providing a from and to Date that were more than 12 hours apart and iterating over the returned data, but it only occurred twice in many hours of testing. We hope to know if this could be a bug in Core Motion or it is definitely in our SDK, or if there is any way to fail gracefully in this scenario.

Hey everyone, I was wondering if it is possible to access the raw data of the gyroscope and accelerometer of the Airpod 3 pro? I found different answers online - some say I can only get some processed data, but in the Core Motion documentation it reads as it might be possible to get raw data. Any clear answer for this one? Thanks!

as i want to tract activity of iphone user using core motion framework , guide me through .

Hi everyone, I’m building a sports performance app for Apple Watch that uses the onboard IMU to analyze swings and impacts in sports like tennis and golf. The goal is to estimate club/racket head speed, ball speed, and shot quality in real time from wrist motion data. With Core Motion, I can currently get deviceMotion updates at ~100 Hz. While this is fine for general movement tracking, the actual ball impact happens much faster — 5–10 ms in tennis and ~0.5 ms in golf. Many of the high-frequency vibration/impact components are missed at 100 Hz, making it hard to directly measure or more accurately estimate certain performance metrics. Questions for Apple / community: 1. Is there a way to access raw accelerometer and gyroscope data at higher sampling rates (e.g., 500–1000 Hz) on Apple Watch? 2. If not, is this due to hardware limitations or an API/software constraint? 3. Are there any research, partner, or beta programs that allow deeper sensor access for sports-science use cases? Even modest increases in IMU sampling could unlock more accurate ball-speed estimates, impact force analysis, and strike-quality detection without needing external sensors — making Apple Watch a best-in-class wearable for precision sports analytics. Happy to share more about the current approach, sample data, and potential use cases if helpful. Thanks, Max

Can't I just add up all of the accelerations of the accelerometer and then use this physics equation to get distance? d = v(i) x t + (1/2) x a x t ^2 In this: v(i) would be 0 t = 1 second a = all accelerometer speeds added together for.1 second t = 1 second Can't I just use this equation to get vertical velocity? A lot of people have said it is impossible but It has been done with variometer apps. I can’t figure out the code. Can anyone guide me in the right direction? v(f) = v(i) + a x t v(i) = 0 a = y-axis acceleration for 1 second t = 1 second Please let me know if this is possible. Thank you so much for your help.

During regular use, RealityKit generates an excessive amount of internal logging that is not actionable by third party developers. When developing an iOS RealityKit/ARKit app, this makes the Xcode console challenging to use for regular work. (FB19173812) See screenshots below. Xcode does have an option for filtering out logging from specific SDKs, but enabling this feature to suppress the logging of RealityKit and related SDKs like PHASE is something developers have to do dozens of times each day. After a year of developing a RealityKit app, this process becomes frustrating. If SDKs like Foundation, UIKit, and SwiftUI generated as much logging as RealityKit and related SDKs, Xcode's console would be unusable. Is there any way to disable the logging of RealityKit and PHASE permanently? Thank you for any help you provide.

So I'm testing a microapp that is contained in an IPFS folder. I use a web3 website that is used to view NFTs and their IPFS files. The app has gyro controls, which are enabled through a confirmation gesture. In iOS 18.5, when I press "Request Permission" button I get the popup to allow the app to acess movement and orientation. In iOS26, pressing the button does nothing. Keep in mind that this only happens through the website, that uses iframes. When I load the IPFS file from a direct link, the popup appears with no issue. I think this might be because iOS26 uses WebGPU or it might be a bug since iOS26 is still in beta.

I’m developing an activity classifier that I’d like to input using the JSON format of CoreMotion data. I am getting the error: Unable to parse /Users/DewG/Downloads/Testing/Step1/Testing.json. It does not appear to be in JSON record format. A SequenceType of dictionaries is expected I've verified that the format I am using is JSON via various JSON validators, so I am expecting I'm just holding it wrong. Is there an example of a JSON file with CoreMotion data that I can model after?

Hello, I’m developing an app to detect movement past a strong magnet, targeting both Android and iOS. On Android, I’m using the Sensor API, which provides calibrated readings with temperature compensation, factory (or online) soft-iron calibration, and online hard-iron calibration. The equivalent on iOS appears to be the CMCalibratedMagneticField data from the CoreMotion framework. However, I’m encountering an issue with the iOS implementation. The magnetometer data on iOS behaves erratically compared to Android. While Android produces perfectly symmetric peaks, iOS shows visual peaks that report double the magnetic field strength. Additionally, there’s a "pendulum" effect: the field strength rises, drops rapidly, rises again to form a "double peak" structure, and takes a while to return to the local Earth magnetic field average. The peaks on iOS are also asymmetric. I’m wondering if this could be due to sensor fusion algorithms applied by iOS, which might affect the CMCalibratedMagneticField data. Are there other potential reasons for this behavior? Any insights or suggestions would be greatly appreciated. Thank you!