I’m attempting to run Apple’s ScreenTime API while my app is in the background When debugging on a device my background restrictions functionality works, but on TestFlight it does not. This is the error message when analyzing the device in XCodes Console BackgroundTaskSuspended. Background entitlement: NO When the proper entitlements are added this error doesn't allow for the build to be uploaded to TestFlight. Provisioning profile "iOS Team Provisioning Profile: com.xxx.xxx" doesn't include the UIBackgroundModes entitlement. I have the proper entries in the “Signing and Capabilities” of the project, but my functionality will not run in the background when the app is not launched. I just need a function to run that calls Apple's ScreenTime API while my app is in the background. Other apps have achieved the functionality I’m looking for so I know it’s possible, but this is the roadblock I’m running into.

I created an app. One if its functionalities is receive Remote Notification in the background, while app is monitoring Significant Location Changes (SLC). This functionality worked fine. I was receiving these notifications correctly. Sometimes instantly, sometime with small or large delay. And then I send the app for review. It was rejected with 3 remarks: The app or metadata includes information about third-party platforms that may not be relevant for App Store users, who are focused on experiences offered by the app itself (I wrote that app communication works both for iOS and Android.) The app declares support for audio in the UIBackgroundModes key in your Info.plist but we are unable to locate any features that require persistent audio. EULA (End User License Agreement) is missing for in-app purchases. After the rejection the app is no longer receiving these notifications. They are there, since the app receives them, when I open app, or significant location change is detected. It also works, when I run the app directly from Xcode (in debug mode), not from TestFlight nor in Sandbox. It seem to me like Apple somehow spoiled my background capabilities on purpose or accidentally. Is it possible? What can I do with it? Is it the case that I should just fix the review remarks and send the app back to review, and once the app passes it, it will work again? Or should I not count on it? Any suggestions? I asked Apple using: https://developer.apple.com/contact/topic/#!/topic/select but so far no response.

I'm developing a safety-critical monitoring app that needs to fetch data from government APIs every 30 minutes and trigger emergency audio alerts for threshold violations. The app must work reliably in background since users depend on it for safety alerts even while sleeping. Main Challenge: iOS background limitations seem to prevent consistent 30-minute intervals. Standard BGTaskScheduler and timers get suspended after a few minutes in background. Question: What's the most reliable approach to ensure consistent 30-minute background monitoring for a safety-critical app where missed alerts could have serious consequences? Are there special entitlements or frameworks for emergency/safety applications? The app needs to function like an alarm clock - working reliably even when backgrounded with emergency audio override capabilities.

I would love to use Background GPU Access to do some video processing in the background. However the documentation of BGContinuedProcessingTaskRequest.Resources.gpu clearly states: Not all devices support background GPU use. For more information, see Performing long-running tasks on iOS and iPadOS. Is there a list available of currently released devices that do (or don't) support GPU background usage? That would help to understand what part of our user base can use this feature. (And what hardware we need to test this on as developers.) For example it seems that it isn't supported on an iPad Pro M1 with the current iOS 26 beta. The simulators also seem to not support the background GPU resource. So would be great to understand what hardware is capable of using this feature!

my app need tracking location all the time both foreground and background. Please suggest how to prevent the app from being terminated. or detect when app is terminated.

Basically the title. I am trying to implement a local notification to trigger, regardless of internet connection, around 3-5pm if a certain array in the app is not empty to get the user to sync unsaved work with the cloud. I wanted to used the BGAppRefreshTask as I saw it was lightweight and quick for just posting a banner notification but after inspecting it in the console, it looks like it needs internet connection to trigger. Is this the case or am I doing something wrong? Should I be using the BGProcessingTask instead?

Hello everyone, We are building an iOS app using React Native that connects to a custom Bluetooth Low Energy (BLE) accessory. The accessory continuously sends small chunks of audio data to the app through BLE (basically every time the user speaks), which are then streamed in real time to our server via WebSocket for transcription and processing. We need to know if the following behavior is allowed by iOS runtime and App Store review policies: Can the app open a WebSocket connection in the background (not permanently, just briefly, several times a day) triggered by BLE activity from a registered accessory? Is there a limit to this? Clarifications: The app is not expected to remain permanently awake. Only during accessory-triggered events. WebSocket is required due to the real-time nature of streaming STT and delivering quick responses (via notifications). If allowed, are there any specific Info.plist declarations or entitlements we must include? Thanks in advance! Fran

Summary: I'm developing an iOS audio app in Flutter that requires background audio playback for long-form content. Despite having a paid Apple Developer Program account, the "Background Modes" capability does not appear as an option when creating or editing App IDs in the Developer Portal, preventing me from enabling the required com.apple.developer.background-modes entitlement. Technical Details: In the app that I am developing, users expect uninterrupted playback when app is backgrounded or device is locked similar to Audible, Spotify, or other audio apps that continue playing in background The Problem: When building for device testing or App Store submission, Xcode shows: Provisioning profile "iOS Team Provisioning Profile: com.xxxxx-vxxx" doesn't include the com.apple.developer.background-modes entitlement. However, the "Background Modes" capability is completely missing from the Developer Portal when creating or editing any App ID. I cannot enable it because the option simply doesn't exist in the capabilities list. What I've Tried: Multiple browsers/devices: Safari, Chrome, Firefox, incognito mode, different computers Account verification: Confirmed paid Individual Developer Program membership is active New App IDs: Created multiple new App IDs - capability never appears for any of them Documentation review: Followed all Apple documentation for configuring background execution modes Different regions: Tried changing portal language to English (US) Cache clearing: Logged out, cleared cookies, tried different sessions Apple Support Response: Contacted Developer Support (Case #102633509713). Received generic documentation links and was directed to Developer Forums rather than technical escalation. Has anyone else experienced the "Background Modes" capability missing from their Developer Portal? Has anyone successfully used the App Store Connect API to add background-modes when the GUI doesn't show it? What's the proper escalation path when Developer Support provides generic responses instead of technical assistance? Things I have attempted to solve this: audio_service package: Implemented as potential workaround, but still requires the system-level entitlement Manual provisioning profiles: Cannot create profiles with required entitlement if capability isn't enabled on App ID Other perhaps important facts about the environment where I am building the app: macOS Sonoma Xcode 15.x Flutter 3.5.4+ Apple Developer Program (Individual, paid)

I'm looking to maximise my Watch app's widget to be as up to date as possible. If we imagined the app was a simple step counter, and we wanted to display the users count as up to date as possible. We can conclude: We don't care about widget timelines beyond the current entry as we can't predict the future! We need to refresh the count as often as possible The refresh should be very quick with a straightforward HealthKit query, no networking or heavy work needed. We will assume the user has the complication/widget on their active Watch face. With the standard WidgetKit APIs we can expire the timeline after 15 minutes and in my experimentation a Watch app can usually update its widget timeline at that frequency if it's on the Watch face. I'm experimenting with two methods to try and improve refreshes further A user's step count might not have recently changed when the timeline update is called. I was therefore looking into the HealthKit enableBackgroundDelivery API (which requires the HealthKit Background Delivery entitlement to be enabled) to get updates limited to once an hour from a HKObserverQuery, I can then call the WidgetCenter.shared.reloadAllTimelines() from there. WatchOS also support the BGAppRefreshTaskRequest(identifier:"") and .backgroundTask(.appRefresh) APIs. I can request updates once every 15 minutes here too and then call the WidgetCenter.shared.reloadAllTimelines(). With option 1, this update opportunity is great as it will specifically update when there's new steps so even once an hour this would be helpful (A real shame to be limited to once an hour even if this used up WidgetKit standard reload budgets: FB13879817, FB11677132, FB10016177). But I can't determine if this update takes away one of the standard timeline expiration updates that already run 4 times an hour? Could I observe additional Health types to get additional updates? Do I need the Background Modes Capability as well as the HealthKit Background Delivery for this in Xcode or just the HealthKit one? With option 2, I can't find a suitable option in the (short) list of supported background modes in Xcode. Does not selecting any mean my app will get 0 refreshes from this route and so should not be implemented in my use case?

When my app enter to background, I start a background task, and when Expiration happens, I end my background task. The code likes below: backgroundTask = [[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler:^{ dispatch_async(dispatch_get_main_queue(), ^{ if (backgroundTask != UIBackgroundTaskInvalid) { [[UIApplication sharedApplication] endBackgroundTask:backgroundTask]; backgroundTask = UIBackgroundTaskInvalid; [self cancel]; } }); }]; When the breakpoint is triggered at the endBackgroundTask line, I also get the following log: [BackgroundTask] Background task still not ended after expiration handlers were called: <UIBackgroundTaskInfo: 0x282d7ab40>: taskID = 36, taskName = Called by MyApp, from MyMethod, creationTime = 892832 (elapsed = 26). This app will likely be terminated by the system. Call UIApplication.endBackgroundTask(:) to avoid this. The log don't appear every time, so why is that? Is there something wrong with my code?

Hi Team! Has anyone found a reliable way to detect CarPlay connection without the app needing to be in the foreground? I’m exploring a concept where, for example, as someone nears home while driving, a prompt appears on the CarPlay screen asking “Would you like to turn on the lights / open garage?” triggered by proximity and CarPlay connection. Would be cool to have it work automatically, but knowing you're in the car is kind of important. From what I can see, apps can’t reliably detect CarPlay connection unless they’re actively open on the CarPlay screen. Most background detection methods (like external screen connect notifications) appear deprecated. That is, unless you're specifically approved as a "messaging" or "navigation" app that appear to get special privilages to send alerts from the background. If I send an alert (or poll Carplay periodically) it just gives silent/dead response. Is there any approach, framework, entitlement, or UI pattern that could allow a passive trigger or background detection while driving with CarPlay connected? I can't see any way to bring an app to the foreground either. Not looking to abuse any rules... just want to understand if anyone’s found a clean, approved workaround. Thanks in advance!

Hi Apple Dev Team & Community, We’ve encountered an issue with background location updates when using an XCFramework we’ve built from our main app. Context: We have a standalone app called TravelSafely that reliably performs background location updates and alerts, even during sleep mode. From this app, we extracted some core functionality into an XCFramework, including location management, and provided it as an SDK to a client. We created a demo app to test this SDK in isolation. Problem: In the demo app, we notice that location updates work fine in the foreground. However, in the background or sleep mode, location updates sometimes stop completely. When we bring the app to the foreground again, location resumes. This does not happen in the original standalone app. What We’ve Already Checked: UIBackgroundModes includes location Info.plist has the required permissions Location is started correctly using startUpdatingLocation We maintain strong references and use background tasks as needed Question: Why would an app using a binary XCFramework (with location logic) behave differently from the original app in terms of background execution? Is there any known issue or recommendation when working with SDKs/XCFrameworks that need to manage background tasks and location updates? Any insights or recommendations to maintain proper background behavior would be highly appreciated. Thank you!

Hey everyone, I have an issue I'm running into – maybe someone has the expertise to help! I've created an app that adds Intents to the Shortcuts app, to interact with S3-compatible object storage. Everything works fine, until you decide to upload/download a large file, that your internet connection cannot handle in the ~30-second intent timeout. I've explored uploading files with a background task which seems to work somehow, but the bigger issue would be downloading larger files, as other parts of the subsequent shortcut may rely on it. To the question: Is there some way of increasing the timeout for a shortcuts intent, or a way to "trick" shortcuts into letting my custom intents download/upload files without timing out? Thanks so much!

Hi all, Since updating to iOS 18.4, I'm experiencing a regression with AppIntents triggered from Widgets. In my app, I use AppIntents inside a WidgetKit extension to control HomeKit devices. This setup was working perfectly up to iOS 18.3. However, starting with iOS 18.4, when the AppIntent is triggered from the widget and the main app is not running, the action fails with this error: Error Domain=HMErrorDomain Code=80 "Missing entitlement for API." UserInfo={ NSLocalizedFailureReason=Handler does not support background access, NSLocalizedDescription=Missing entitlement for API. } Interestingly, the exact same AppIntent works fine if the app is still alive in the background — it seems like the failure only occurs when the intent is handled by the widget process. This looks like a behavior change or new restriction introduced in iOS 18.4. Has anyone experienced the same? Is there a new entitlement needed, or a recommended workaround? Thanks in advance!

I would like to inquire about the feasibility of developing an iOS application with the following requirements: The app must support real-time audio communication based on UDP. It needs to maintain a TCP signaling connection, even when the device is locked. The app will run only on selected devices within a controlled (closed) environment, such as company-managed iPads or iPhones. Could you please clarify the following: Is it technically possible to maintain an active TCP connection when the device is locked? What are the current iOS restrictions or limitations for background execution, particularly related to networking and audio? Are there any recommended APIs or frameworks (such as VoIP, PushKit, or Background Modes) suitable for this type of application?

Hello forum, I want to keep my app running in the background after user swaps up, for the purpose of workout tracking. start up the task and continuously receipt GPS updates process the location data show the data on a live activity Two examples Strava paddlelogger Question: Does this mean, these two apps would just pause when the .backgroundTimeRemaining becomes 0? How does a workout app "work" in background mode, do I need to handle budget running out?

We've seen a recent increase in background terminations: blue - System Pressure orange - Task Timeout I'm trying to understand the increase in system-pressure terminations, since there's no corresponding increase in memory at suspension. Are there other system resources for which iOS will terminate an app?