For me it was trip mode. XCode 15 Beta 3, shows no indication it's downloading anything, but nsurlsessiond along with its startup indicated that it is downloading several GB.

I know this is an old thread, but you're not able to send a background push with a priority of 10 today. What this means is sure, your app cannot refresh content until the user has unlocked their phone (when on cellular), but this also means that background apps with the proper entitlements, cannot receive a reliable push on when to do something. For example, an audio app in the background cannot receive a reliable way to stop playing. A new push category for such a use case 'background-entitled' or something would be a good addition. Unless someone has a better idea. Today, the only way to do this is with a WebSocket connection, but that too is problematic. Its killed after just 10 seconds of inactivity, so you need to constantly send a ping / pong. This actually makes battery consumption vastly worse than if Apple would kindly allow background apps a new push category, or allow them to receive a background (content-available) push, since they're already running. Unfortunately it doesn't seem to be the case, when on Cellular. On WiFi they are in fact delivered to the app immediately. Even including a foreground notification before a background one doesn't work, and despite the app already running, it will not receive the background notification.

Yes, but today there are many use cases for a background app to want a "reliable" / "instantaneous" background notification... I wish Apple would either: Add a new APNS push type for apps that need this type of functionality, with justification Allow background apps that are already running to receive their background notifications It seems these background pushes are also designed to be very limited in number (just ~ 3 per hour)... But what is a background app to do? Take Spotify for example, if you want to stop the music remotely, change the song, adjust the volume, playlist etc? It's a bit strange, because Android doesn't have such tight restrictions with respect to push messages or background apps and their battery life is quite good. There are many iOS "silos" which make routine programming difficult and the user experience worse... Does anyone have a better idea for the Spotify example? You could use a WebSocket, but that too is closed immediate upon entering the background, and connecting again it's just closed after just 5-10 seconds on iOS... Push seems like the most power efficient way, but seemly it can't be done?

Not to my knowledge. You should see any BLE device in the Bluetooth Scan section. Download nRF Connect on your iPhone, it should help you debug your BLE advertising.

Hello, We have found iOS to be particularly difficult to work with in this regard. There are many use cases for maintaining a BLE connection for streaming data and especially for notifying a server of events. Think about heart rate monitors, security systems, car diagnostics, you name it. On Android OS, there is no such restriction and seemingly battery life doesn't seem to suffer. Our users love our Android Apps, but on iOS they complain about missing data and lost connections. I just need to tell them it's an iPhone thing and if they want a better experience, until Apple changes this old restriction for BLE / Server connections in the background, to deal with it or move onto an Android phone. CPU's are incredibly efficient these days so honestly pinging a server over BLE or maintaining a connection in the background between the device and server is actually incredibly resource light. What's not resource light, is how you can prevent iOS from killing your app... What we found has worked, is to constantly send characteristic writes every few seconds from the device to the iPhone to keep the BLE connection active and your app awake. You probably can't connect to your server though, incredibly frustrating. This is an unfortunate workaround because, if you think about it, it is actually making the user experience worse and the battery drain (although quite small) more prevalent by keeping the BLE connection more active and not switching to a higher sniff sub rating or longer connection interval. When you factor in the large ram size of today's iPhones, this issue should really be a non-starter.