I have the same (or similar) issue. SpringBoard getting over 100% CPU load and the computer is overheating when I launch Xcode. Workaround, which seem to work quite well, is to Force Quit SpringBoard in Activity Monitor every time I start Xcode session. Then the process is reinstated, but with the normal usage. I run Xcode: Version 15.0.1 (15A507) My computer: MacBook Air M1, 16GB, macOS Sonoma, 14.1.1

Thanks for your swift reply. Sorry for small delay on my side. I have been preparing the so called Test Project (see (2) below) Correct - the leaks I attached come from the Instruments / Leaks tool. I am not sure what you exactly mean by "Test project". I assumed you wanted to have a new, simple project containing the core functionality to reproduce the leaks issue. I created such basic-functionality project, stripping off all unnecessary elements and code, just leaving the core: location tracking. I kept the structure of my app though (so it is not as simple as it could be for such functionality), as it might help to investigate the case, I think. And finally YES, I observe the same leaks in this test project as in my main project - 5 leaks every time I press "<back" button, which stops location tracking. In the Leak tool, when I choose any of the leaks, and then choose in the right panel the bold marked Stack trace "closure #1 in LocationsHandler.startLocationUpdates()" I get this code marked: Task() { do { self.updatesStarted = true 5x 336 bytes let updates = CLLocationUpdate.liveUpdates() for try await update in updates { I do not know how to share the link to my project though.

Thanks. I have registered the issue. Its number is: FB17062925

I have done some test recently, and apparently visit of @DTS Engineer helped. In recent (iOS 18.3.1) version the memory leak is no longer there. Apple fixed the issues with memory leak in CoreLocation.

Now I have installed the app from TestFlight on another device (with different Apple ID), on iPad. On this device background notifications work as they did on my iPhone before the rejection. Background notifications are received correctly. Now I return to my problematic iPhone. I removed the app from my it, I restarted it, then I installed the same version as in did on iPad, from TestFlight as on iPad, but from my developer's Apple ID, and... nothing changed. I DO NOT receive NOT A SINGLE notification in the background on my iPhone. The same version of app installed from TestFlight on both devices! BTW. I think Notification Service Extension is not a solution for me. Background Notifications I receive, come from Firebase Cloud Messaging system, so there is nothing to modify in them. And, I emphasize, these messages are corerctly build to be delivered in the background. They worked on my iPhone before rejection, they work now on iPad, and I have not touched their structure for months. They are 100% correct. What is wrong with iOS on my iPhone, or rather how can I fix it? The test on iPad shows it is not a problem of app not its build. You said that there are limitations on background notification. In my case the limitation is 0%. Is this correct? Definitely the reason is not that the app is considered as the rare used app, as I open it dozens time a day - it is under continuous test.

I am very sorry, if I spam here. I am not sure if comments to your post @Engineer reached you. Since I haven't heard anything from you for 3 days I decided to repeat it in a new reply-post. In short. I cannot send you APNS-ID for specific notification that has not been received by my app, as the notifications are generated externally by Google FCM. I can provide you my APNS token, but, for security reasons, I do not think it is wise to share it here, in public place. What I did to test if it throttling mechanism which limits my app's background notifications, I sent 4 notifications (via Google FCM) from 4 different devices. 1 iPad, and 3 Android based devices. I did it on 15-08-2025, 9:04-06 UTC. I turned off the notification for most commonly using notification apps in advance. Since then (for 3 days) I have received 3 or 4 not related to my app notifications (first one came after more then 1 hour after I sent my notifications), for apps I missed (I turned off the notifications for them too immediately after). NONE of the 4 notifications I sent on 15-08-2025, 9:04-06 UTC have been received until now! Even though there were almost no other notifications received. I haven'r open my app since the beginning of an experiment, nor I haven't change its location (so no Significant Location Change event have occured, which wakes my app). I do not know if these messages are still in the queue or dropped by APNs. For me it doesn't look as throttling mechanism problem, as there were no other notifications coming and yet no background messaging was allowed for my app. I will remind that it (background notifications) worked before the rejection and it still works on other device (iPad) with different Apple ID user. Would you be able to track this issue on your side APNs <-> iOS?

Unfortunately, no — I haven’t found any solution. An Apple engineer helped determine that this is indeed an iOS issue: background notifications are received by my app, but they are forcibly dropped by the system. Apparently, there was no deadline set for this state in my iOS, so my app was punished indefinitely. It lasted for 2 months. The case itself was forwarded (by the Apple engineer) to the iOS Notifications team at Apple about a month ago, but they haven’t contacted me. In the meantime, I tried uninstalling the app, resetting the iPhone (from Settings), and upgrading the system several times (including to iOS 26). More recently, I uninstalled the app for 1 week, hoping to give the system time to “forget it” (I had no idea if this would help, but being permanently blocked doesn’t make sense either, right?). After that, I installed beta 26.1 and reinstalled the app, but nothing worked. Finally, I tried the ultimate solution: “Erase All Content and Settings” from iPhone settings. This worked, and my app now receives background notifications again (no changes to the app binary/content were made, to be clear). I consider this a workaround, not a solution — it only fixes a system that had entered a weird state concerning how my app was being handled.