Watch app doesn't receive location updates on watchOS 10 beta

I forget to add that issue affects not only builds installed from Xcode or TestFlight, but also one from App Store.

I am also having the same issue and it seems to have stopped working when I started to transition my app to support iOS17 and WatchOS10. My TestFlight users running WatchOS10 are having the same problem.

Ok, I traced my issue back to when I took the Xcode recommended setting to upgrade my watch app into a single app, removing the extension.

My TestFlight build prior to that works, this build doesn't.

However, I can't figure out the problem with the single watch app, I have a hunch the location permission setting is referring to the old bundle id (extension).

I reverted the commit which turned my watch app into a single app and uploaded to TestFlight.

Location services are working again.

I am also facing same issue with my watch os app. Whenever I remove app from device and install new from test flight then I'm not getting location authentication alert in watch os 10 beta. (It's working fine before watch os 10 beta)

Right now I'm using following workaround. (This workaround will reset all the apps locations and privacy)

1. Make sure iPhone and watch is connected with Bluetooth.
2. Remove watch app from background.
3. Goto Settings app ->General->Transfer or Reset iPhone->Reset->Reset Location and Privacy.
4. Open watch app again then you will receive location authentication alert.

@WeatherGods Thanks a lot for sharing your solution! Meanwhile I have tried to create blank project with only phone and separate watch app and locations in the watch version worked for me. So I think single app per se should not be source of the problem. Unfortunately for me it's not so easy to switch back to watch extension as the change was done more than one year ago.

We're also seeing this problem and submitted a bug report (FB13130970). If you haven't done it yet, I suggest you do it too so it gets more awareness at Apple. Let's hope this gets fixed before the final release.

We're having the same problem with our watch app with recent watchOS10 betas (couple weeks), that is, watch app fails to receive locations as described in first post. Looks like location authorisation status gets corrupted for some reason. We've isolated this problem into a separate project (iPhone + watch app), 100% reproducible. A standalone watch app does not show this problem. On our way to file a bug report too.

This is also related to the same Issue: FB13119312 (LocationButton does not work)

I'm also seeing the same, now on the RC build. This is on a new app and my first time developing for watchOS, so I thought it was just something I was doing wrong - but after trying it out on a watchOS 9 watch - everything works perfectly fine. On watchOS 10 RC + built with Xcode 15 RC my app gets authorizedWhenInUse when I call CLLocationManager.authorizationStatus, so I then proceed to request location, where I then get denied with Error Domain=kCLErrorDomain Code=1 "(null)"

I've even tried using the new way to fetch location using async/await (CLLocationUpdate.liveUpdates()), but seems to be the same issue, just in that case the task never completes or fails, I just never get a location. iOS app works fine on iOS 16/17. Watch app works on watchOS 9.

Anyone find any workarounds? I was excited to launch my first watchOS app at the watchOS 10 launch, but this bug has put a damper on things, and my app doesn't really work without current location. And I can't build with prior Xcode versions as I'm using watchOS 10 specific features...

watchOS 10 RC update.

I had my Apple watch on 10 beta 8, with the companion app stuck in the location problem described above. Upgraded both iPhone & watch to the RC releases, uninstalled the apps, and installed & run iPhone app from Xcode, went to watch app and installed it on the watch, started there. Same problem, watch app still stuck in the location request. Killed+uninstalled both apps, reset location permissions on iPhone, restarted the iPhone (not the watch), did the installation process again (Xcode run to iPhone + watch app to reinstall on the watch), and it worked.

I noticed that for companion apps, location permissions are listed on the iPhone (Settings > your app, location is first line) & not on the watch itself. When the problem occurs, that first location line is absent. My hypothesis is that something breaks the location permission of our app that reinstallation of both apps can't fix & a global reset of location permissions (+ Face ID access for all apps) is the only way out.

About what breaks it, I don't know. It seems that for companion apps, the iPhone is handling the permission for both devices. I suspect that maybe installing a new version of the app on iOS from Xcode while the watch app is running might be cause, or something similar (like running the watch app directly from Xcode with the iOS still at a previous version).

It is not clear if that can occur to end users that only install through App Store (no Xcode run). But if you happen to create the bug on your device, no app uninstall, no TF install, no App Store reinstall can fix it by itself.

Not too sure where to go from here. Would be interesting to know (for those with shipping apps) whether end users report such issues or if it is limited to those who run it at least once through Xcode. It is also possible that the problem won't reappear starting from the RC (did not experience it yet - will report if it's back).

@rsebbe all my watchOS10 TestFlight users experienced the problem, so I assume that normal App Store users will have this problem.

The global reset of location permissions doesn't feel like a solution as I assume it resets permissions for all apps? Can't see many users agreeing to that for a fix for one app.

As I said previously, what worked for me was backing out the single app watch recommendation which I applied. After that it was working again for everyone. I appreciate this isn't a solution for all of us.

So small update - I made a test app using Xcode 15 RC, my same location service used in the main app and a simple UI to request location and display it + any errors on both the phone and the watch. And...everything works fine.

My guess is prior Xcode beta versions had some build configuration issue set on the target, so I'm going to make a branch, delete my existing apple watch app target, and recreate a new one on the RC and see if that works.

@rsebbe @jclardy Good news everyone! It seems that if you install iOS 17 RC on device that never had pervious iOS 17 beta locations are received on the watch as expected! If you install on the watch simulator which you have not used with previous betas locations works there too. So I assume it should work in production as only minority of users would install your app on the beta iOS.

Also after you reset location permissions globally it starts to work. Till you delete and install the app again - then association is broken again. It might be that location permission even work in beta 6-8 if you just upgrade the app without deleting it at some moment. But for developer it's hard to trace.

The issue is unfortunately not fully solved with iOS 17 RC:

1. Previous versions of the app which updated after installing RC doesn't have the issue
2. Freshly installed versions of the app on RC doesn't have this issue
3. As soon as app is deleted and installed again on RC - locations are broken

OK did some additional testing here. We can reproduce the problem 100% using Xcode in a separate (simple) sample app. Our app isn't shipping yet, so unsure about App Store installation (see discussion below).

Using Xcode 15.0, watchOS 10.0 / iOS 17.0 (all GM versions).

Corruption procedure

• with app absent from both devices, from Xcode, do a run directly on the watch. This also installs the iOS app as a side affect.
• on the watch, auth status shows 0 (NotDetermined)
• requestWhenInUseAuthorization() does not show the auth sheet

From this, auth state is corrupt and there's no way out (no combo of uninstall / reinstall both apps & device reboot will help) - it stays broken unless you apply the reset procedure below. Other working companion apps are not affected, just this particular app.

Reset procedure

• uninstall the iOS app (this automatically uninstalls the watch app)
• iPhone > Settings > General Transfer or Reset > Reset > Reset location & privacy
• reboot both device
• reinstall with iOS first & keep it on iPhone at all times.

From that, any kind of installation of watch app will work (Xcode run, watch app installs) & permission problems won't re-occur.

What remains unclear to me at this time as our app isn't shipping yet: other people here mentioned it happened on TF/App Store build. Did that happen for devices that were corrupt by the above procedure first, or for fresh App Store / TF installs? I suspect this could occur if the watch app is installed directly on the watch (which triggers iOS) as opposed to installed from iPhone's watch app initially.

The reset procedure is not viable (ok for development, not for end users as it implies privacy sheets for all apps on the device). Another remark, I did try to reproduce it with shipping companion apps (could not so far - if you can please tell), but I noticed Strava would request all permissions on the iPhone side (watch app is blocked in modal state until that is done by user on the iPhone), which could be a workaround to ship a companion app if App Store release is also affected by this issue.

Same problem here on watchOS 10. When calling requestWhenInUseAuthorization (or any other version of it) nothing happens. There is no system-dialog popping up only the delegate complaining about Error Domain=kCLErrorDomain Code=1.

It must be something with the project setup though. I made a small sample app and there it is working. I tried removing the setting my app to App is only available as a standalone watchOS app and then the popup appears. I don't want that setting though. I do have a companion app.

Edit: I just discovered this message in the console app:

{
    "msg":"#AuthPrompt #Warning Delaying authorization request placed while insufficiently in-use",
    "ClientKeyPath":i<my-bundle-id>.watchkitapp:, 
    "requestType":0, 
    "inUseLevel":0
}

Any chance this is fixed in watchOS 10.0.1?

I've tried a WatchOS Companion App and a WatchOS Standalone app (runs without iPhone checked) with XCode 15 RC. After deinstallation and reinstallation of the watch-App the error occurs in both scenarios. No chance to fix it. Users of my App already reporting that it happens in production with the App downloaded from the Appstore.

I have the same problem with a standalone app for the Apple Watch. The problem occurs both in the simulator (10.0) and on real hardware (10.0.1).

Can confirm that. I‘ve tested different apps from the AppStore, always same behaviour.

Has anyone tried the new 10.1 beta yet? This issue is incredibly frustrating.

I am having the same issue with my app on 10.0.1. Open Water Swim. I only noticed it upon deleting and re-installing the app. If I perform clLocationManager.requestWhenInUseAuthorization() I get a big fat nothing. I will look into that crazy reset procedure and also file a bug report. This is the second bug relating to Core Location. There is also a serious degradation of GPS data (at least on the Ultra). I filed two bugs for this, one in beta FB12587468 and the newer one in release FB13192409. I would say Apple has really introduced some serious issues with core location on this release, and I would not be surprised if some folks end up losing jobs. Good riddance.

This appears to be fixed in the 10.1 beta.