I tried now on my iPad with iOS 16.4 RC and there is no problem with the app staying in the background. I switched off significant location updates as well as part of the experiment, the app still stays in the background with no problem. ~20 minutes now. If you can test this on iPad with iOS 16.4 then we can see if this is iPad vs iPhone that makes a difference or something in your vs mine configuration of a LocationManager.

I've been testing iOS 16.4 on iPad since day 1 and it runs in background location 24x7, I specifically and continuously test for this use case. Are you sure this is not some kind of crash that would be happening after these 10 minutes that might be bringing the app down? There might be differences between location services on iPad and iPhone though.

Looks like iOS 16.4 Beta 1 solved the performance issue with drawing on MKTileOverlay. Looks like a few performance issues might have been solved. Hopefully is stays this way.

I might have a related FB to this issue, or more related to iOS 16 MKMapKit performance degradation when it comes to overlays that need to draw. It's "iOS 16 regression - MKMapView flicker with MKTileOverlay and MKOverlayRenderer with draw().". I have FB FB11805267 with the sample project that reproduces the issue. I used "Ask Apple" and I got confirmed that issue is known and is assigned a high priority. Then I used a DTS to ask if there is a workaround (e.g. I hoped I could only provide the overlay path and will not draw) and that returned back unused. Going to add a link to this thread to my FB.

I'm trying now in iOS 16 and setting Background Refresh as OFF for the app doesn't affect regular background location updates. Looks like documentation for this permission has been significantly changed to only relate to the Background Refresh Tasks: https://developer.apple.com/documentation/uikit/uiapplication/1622994-backgroundrefreshstatus

Monterey with M1, same problem.

Didn't work for most of Wednesday, then started to work Thursday morning (CET) for me. And now, Thursday evening CET it is not working again. I see the new build in the Testflight, but after a spinning circle on UPDATE/INSTALL it returns to the non-installed, non-updated status.

Not working for me as well. I have swift+objc codebase, not sure if this can be the reason.

Same here. What worked for me was to remove the preview part from the code, save. Added it back and it all worked.

Be sure to report it to Apple.

As I understand, it should be a bug with Xcode and App Store Connect. You better create a feedback for Apple. See the related thread: https://developer.apple.com/forums/thread/714736?answerId=727968022#727968022

In my case (Dell 40" with thunderbolt/usb hub) it was me tweaking the power management settings earlier and then all usb ports being down after OS update every time mac book went into sleep and woke up. sudo  pmset restoredefaults and restart helped for good.

Same thing here, with different selector names.

Thank you glow! Indeed. This would explain the problems I'm seeing. I redesigned the screen to only have one Paste control on it and it is placed in the dedicated cell with only a help label below it. Even when sizing that dedicated UIPasteControl - until it stopped "touching" the neighbour controls, it was asking for the permission. I can see the point in avoiding obscuring its parts. How can we define the UIPasteControl sizing requirements properly to be sure to give it enough space? I'm trying its intrinsic size and it always returns as zero rect. I'm trying to achieve its size predictability via minimumContentSizeCategory and maximumContentSizeCategory, so it has a predictable size for the different accessibility text sizes. What's the correct way of placing/sizing this control in a storyboard with auto layout? The example here: https://developer.apple.com/documentation/uikit/uipastecontrol?changes=_5 Suggests: pasteButton.frame = CGRect(x: view.bounds.width/2.0, y: view.bounds.height/2.0, width: 150, height: 60) Is it something considered the safe dimensions for the UIPasteControl for all of the accessibility text sizes? Width of 150 doesn't seem to be "safe" - the whole UIPasteControl may not be even shown or it might be raising the permission alert, if the control itself shows. Is it something that needs to be embedded into SwiftUI? Or would it work well in some sort of a container like UIStackView, would this one size it properly for all of the accessibility text sizes? Some pointers would be appreciated so we can build future-proof designs that would not break easily.

Same here.