When someone sees this, do they see it repeatedly? Yes, and it is an ongoing issue over a couple of app and iPadOS versions. I will consider asking the users for sysdiagnose data. Since the issue does not seem to relate to "crashes", but "freezing" or similar and thus have no stack trace etc, I'm not sure I could make something out of those sysdiagnose logs. But at least we could use them for bug reports. Because I assume that it might be good if we did the bug reporting work for the users. Thank you

I think the question remains; where is .safeAreaBar supposed to be placed, when you're using a ScrollView on the page? I'm also using the .top setting. I haven't been able to find some usage example of this. It seems that if we attach the .safeAreaBar onto the scrollview itself, the scrollview content is correctly offset at first, such that the safeareabar contents do not overlap the scrollviews unless scrolled. If we put the safeareabar higher in the hierarchy, the scrollview contents are not offset and we unfortunately get overlap. Would help a ton to get some insight here. As a workaround, perhaps it would work by putting the safeareabar high in the hierarchy (like onto the first view in the SwiftUI view body), and then manually offsetting the scrollview offset somehow. Still need to figure out how to find the correct offset here...

For some reason, since the last 2-3 releases, suddenly we see a steep decrease in these background terminations for the 90th percentile. I've been working on this app for years and the number was always 2+ like seen in the bars on the left side. But since the last few releases it suddenly went down quickly. I wouldn't swear (because I never do😅 ) but I don't think we've done anything that would improve this to the app. I'm wondering if the reporting for this on the Apple/App Store backend has changed somehow.

This just happened in macoS 15.4, Xcode 16.2. I haven't seen it before. The workaround seems to fix it, but it also wipes most/all Xcode settings

I came here because I was trying to test "Ask to buy" (for In App Purchases) in the sandbox, but have been unable to do so because there seems to be no way (that I know of at least) to create a full parent and child account setup in the sandbox. When you create sandbox account in App Store Connect, there's no way to enter the age for the sandbox account. My assumption is that an account needs to be below 13 years of age to be deemed a child account. Any input on this?

In case someone still looks here... it seems that it is not possible to resolve Ask to buy (by approving, rejecting) in the sandbox. https://developer.apple.com/documentation/storekit/testing-at-all-stages-of-development-with-xcode-and-the-sandbox

"Clear Purchase History" used either from device's App Store / Sandbox area, or from App Store Connect, seems to delete purchases, but at the same time it seems that it doesn't really delete all transactions or history of introductory offers properly. If I delete all history for a sandbox user, it does work to get the introductory offer at a later point when clicking on a purchase button in-app (or outside app). However the "isEligibleForIntroOffer" does not return true for those users anymore.

I'm seeing similar problems. I think UI testing in Xcode cloud cannot be used (yet...). I have simple test code like this: XCTAssert(buttonBack.waitForExistence(timeout: 1.0)) ... so it's supposed to wait for existence of that button for 1 second, and then fail the test if it cannot find the button, right? It works fine locally (of course), but it also works fine in Bitrise. But when running in Xcode Cloud, it fails there and I have this log: Just look at the timestamps to the right, it's looking for that button way longer than the specified time. and it even retries a few times before failing the test there.

Submitting to testflight, we got warnings for a notification extension as well, despite having added a privacy manifest for the main app target.

Thanks for this thread. I also was working on UI tests the other day, and today when I came back the addUIInterruptionMonitor() thing didn't work anymore. Seems like I was using an iOS 16 device that other day, and today an iOS 17. It seems the workaround also worked. Please fix this. And possibly ping this thread when it is? Thanks everyone.

We're also having the same issue, and it's still ongoing (about a year later), however the stats tell that this crash only happens to users below iOS 16.4. So it seems fixed (or at least not happening anymore) since iOS 16.4. We also target iPadOS, only 1% of crashes happen there but again no iPadOS crashes since 16.4.

Out of the blue this error suddenly popped up on Xcode, release 15.0.1. The error message is bogus for sure. What helped was "Product>Clean Build Folder...", then a rebuild+launch to device!

If you're using some kind of VPN in macOS, then one thing to try is to turn that VPN off. I am having trouble connection iOS 17 devices to Xcode 15 as long as I'm using Cisco's AnyConnect VPN. It seems to be a "kind of" known problem.

What's worse, the feature still almost never works. Especially if you work in environments that require VPN on dev machine as well as iDevice.

Another update. I've been able to reproduce the problem on all of these devices so far, if following a certain procedure. iPhone 13 Pro max, iOS 16.1.1 iPhone Xs, iOS 16.1.1 iPhone 13, iOS 16.1.1 Open Youtube app. Play a video in landscape on the iPhone. While still in landscape, click on the cast button, select Airplay, connect some external device (screen or speaker, does probably not matter) Disconnect Airplay / play the video on the iPhone again. Switch to portrait mode. While in portrait and video is playing, open the Airplay popup again. Try to tap on an external speaker/screen, but you'll notice the popup is not responsive so you probably cannot choose any device. <<< this is the problem