iOS 17.4 (21E217) CMAltimeter not working

  • Found a workaround.

    Apparently the issue is that as of 17.4, CMLAltimeter startRelateiveAltitudeUpdates not needs "Motion & Fitness" permission. However, normally in iOS just using a service requiring the permission will initiate the permission prompt by iOS to the user.

    The trick it to force requesting permission. let recorder = CMSensorRecorder() recorder.recordAccelerometer(forDuration: 0.1)

    will prompt the user for permission. Once granted, relative altitude data works.

  • I suggest that everybody who has the issue, files a bug report to Apple, in order to get some priority on this.

  • @baraupp I file bug before it release 1 day but not communication on the feedback and they still release it.

Add a Comment

Apple Recommended

  • Suggest you check [CMMotionActivityManager isActivityAvailable] before invoking this approach, and gracefully handle any exclusions (such as tell the user "barometer data is not available" and do not attempt to query activity). This will avoid problems on the subset of device/OS combinations that do not support Activity features. In addition, be aware that the use of NSDate "now" is fairly new, so if you support deployment prior to iOS 13 you should use [NSDate date] instead.

Add a Comment

Replies

None of the iOS Barometer apps seem to be working since 17.4...

There is a work around for it but it is not working on iPad OS 17.4 and iPhone SE, Many of our users are angry, they just gave us 1 star and bad commend. Some other guy using MAUI https://github.com/dotnet/maui/issues/20930 report it too.

We are seeing the same issue: https://github.com/justinchuby/barometer-project/issues/8.

Looks like CMAltimeter.authorizationStatus() shows notDetermined, and I have not found a good way to request this authorization.

Found a workaround. Apparently the issue is that as of 17.4, CMLAltimeter startRelateiveAltitudeUpdates not needs "Motion & Fitness" permission. However, normally in iOS just using a service requiring the permission will initiate the permission prompt by iOS to the user. The trick it to force requesting permission.

let recorder = CMSensorRecorder() recorder.recordAccelerometer(forDuration: 0.1)

will prompt the user for permission. Once granted, relative altitude data works.

  • As I said above, all the trick activate "Motion & Fitness" by altenative API will not working for the iPad OS now, because Pedometer disable for iPad, and it not working on iPhone SE2.

  • This does not work for me (tested on iPhone 11). It comes back with console messages "Warning - invoking recordDataType:forDuration: on main may lead to deadlock" and "Response invalid". I tried starting it on a background thread, but it still reports "Response invalid". Any ideas on how to make it work?

Add a Comment

Found a workaround but my post is being reviewed.

let recorder = CMSensorRecorder() 
recorder.recordAccelerometer(forDuration: 0.1)

Requests permission and gets it working.

  • This does not work for me (tested on iPhone 11). It comes back with console messages "Warning - invoking recordDataType:forDuration: on main may lead to deadlock" and "Response invalid". I tried starting it on a background thread, but it still reports "Response invalid". Any ideas on how to make it work?

Add a Comment

I have submitted feedback FB13680923 on this issue, as I see no correct way to solve the problem from the developer side (proposed workaround is not a universal fix since not all devices support sensor recording).

Post not yet marked as solved Up vote reply of s219 Down vote reply of s219

Note that the following is a work-around. I urge everybody to file a bug-report with Apple, to make sure there is pressure on Apple to fix this.

Others have suggested the CMSensorRecorder work-around. It turns out that the "Fitness Tracking" setting in the Settings App needs to be enabled for that to work.

When the authorizationStatus is .restricted, then the user first needs to switch on Settings > "Privacy & Security" > "Motion & Fitness" > "Fitness Tracking"

When the authorizationStatus is .notDetermined, then start the CMSensorRecorder. A "Motion & Fitness" privacy settings will be added to your app's settings, and the user will be asked to authorise by iOS. When the user accepts, authorizationStatus changes to .authorized and you can start the CMAltimeter.

When the authorizationStatus is .denied, the user needs to switch on the "Motion & Fitness" privacy setting of your app.

The following code worked for me:

            let status = CMAltimeter.authorizationStatus()
            switch status {
            case .notDetermined:
                // trigger a authorization popup
                let recorder = CMSensorRecorder()
                DispatchQueue.global().async {
                    recorder.recordAccelerometer(forDuration: 0.1)
                }
            case .restricted:
                popupText = "Please switch \"Fitness Tracking\" on, in the Apple Settings app, under \"Privacy & Security\" > \"Motion & Fitness\""
                showingPopup = true
            case .denied:
                popupText = "Please switch \"Motion & Fitness\" on, in the app settings"
                showingPopup = true
            default:
                print("authorized")
            }
            Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { timer in
                let status = CMAltimeter.authorizationStatus()
                if status == .authorized {
                    timer.invalidate()
                    self.altimeter.startRelativeAltitudeUpdates(to: OperationQueue.main) { (data, _error) in
                       // handle altimeter data
                    }
                }
            }

The CoreMotion team is on the case, and is looking for a solution. But I am sure you would all appreciate that fixing and releasing a problem in an operating system is not a matter of a day or two.

I would like to thank everyone here who has been suggesting workarounds to get the authorization prompt to popup, which in turn enables CMAltimeter to start working. That is indeed a good solution. Although, the API suggested here, CMSensorRecorder has a large power impact, and we do not recommend to use that as your temporary fix. CMPedometer is not only less power hungry, but also has the widest availability on iOS versions and actual devices.

So, if you were to use

CMPedometer().queryPedometerData(from: Date(), to: Date()){ (data, error) -> Void in }

somewhere in your code as appropriate, this should temporarily solve your issue. @baraupp 's solution is a clean encapsulation, and could be used by replacing CMSensorRecorder calls with CMPedometer calls.

Also to confirm @baraupp 's findings, "Fitness Tracking" must indeed be turned on in Settings for the pedometer solution to work as well.

  • All solution here useless for the iPadOS, I know that an OS is very complex, but how the QC process? A feature complete un-usable not like some bug when using it.

Add a Comment

[@Gualtier Malde](https://developer.apple.com/forums/profile/Gualtier Malde) Thanks for your response here! At this point, do you think it's worth making the effort to release a build with a workaround? Or should we wait and see if a fix is in the upcoming 17.4.1 update? We could probably only handle a couple more weeks before this issue impacts a significant enough number of our users that we will have to do the workaround, but we don't want to push it out if it's not necessary.

Thanks!

Latest 17.4.1 not solve the problem, sadly. [@Gualtier Malde](https://developer.apple.com/forums/profile/Gualtier Malde) is there any timeline for this bug? I lost many customer and revenue due to this bug.

  • Suggest you check [CMMotionActivityManager isActivityAvailable] before invoking this approach, and gracefully handle any exclusions (such as tell the user "barometer data is not available" and do not attempt to query activity). This will avoid problems on the subset of device/OS combinations that do not support Activity features. In addition, be aware that the use of NSDate "now" is fairly new, so if you support deployment prior to iOS 13 you should use [NSDate date] instead.

Add a Comment

I learned that this issue also prevents independent Watch apps from accessing CMAltimeter if their parent iPhone has been updated to 17.4-17.4.1, since iPhones manage privacy settings for their companion Watches. The workaround suggested above using "CMMotionActivityManager queryActivityStartingFromDate" works for Watch apps, with the caveat that I could not find any way for my Watch app to determine the iOS version of the parent iPhone, thus it's not possible to be selective about when to invoke the workaround.

I have long thought it was somewhat disjointed the way an independent Watch app still depends on the parent iPhone to manage privacy settings -- for many reasons -- and this is one more example why it's a bad arrangement.