When my URLSessionDelegate receives a server trust challenge (NSURLAuthenticationMethodServerTrust) and I respond with .useCredential for an enterprise self-signed cert, does the decision get cached for subsequent requests on the same URLSession, or is the delegate called again on every connection to the same host?

Hello, I filed feedback 22592307 around crashes my team and I are seeing in libquic now that we have adopted HTTP/3 for a large portion of our network usage. During the state of the union it was stated that libquic has been fully re-written in Swift by the WebKit team. Is that swift version the new implementation of libquic in iOS 27? If not, what will be the best way to adopt it without leaving the URLSession ecosystem?

Is the system default for this still false as of the OS 27 releases? When would you recommend setting it to true?

With iOS 27's improvements to seamless Wi-Fi/cellular transitions, is there guidance for apps and frameworks doing background network requests on how to handle a transition mid-request? Do in-flight URLSession tasks survive a network path change automatically, or should apps build their own retry logic?

We develop a healthcare emergency-alerting app with a native watchOS companion app. We've hit a network routing issue on watchOS that we cannot work around with any public API, and it breaks a safety-critical flow (triggering an emergency alarm from the watch). Environment watchOS 26.5 on Apple Watch SE3, paired with iPhone SE 2nd Gen on iOS 26.5 Watch app deployment target: watchOS 9.0 Plain URLSession (async/await), default configuration plus waitsForConnectivity = false, allowsExpensiveNetworkAccess = true, allowsConstrainedNetworkAccess = true HTTPS to our own backend (valid public TLS certificate, no pinning) Steps to reproduce Pair the watch with the iPhone. Both on the same known Wi-Fi network. On the iPhone: turn OFF Wi-Fi and cellular data. Keep Bluetooth ON. The watch remains connected to its known Wi-Fi network (or would be, if the system brought the radio up). Trigger any HTTPS request from the watch app (foreground). Expected Since the companion iPhone has no internet, the watch should satisfy the request over its own Wi-Fi. Actual The request is routed through the companion link (ipsec1, "companion preference: prefer" in the logs) and fails after the TLS handshake dies inside the tunnel: Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9816 (errSSLClosedNoNotify) The watch never fails over to its own Wi-Fi, no matter how many times we retry or how long we wait. The same request succeeds within seconds if the user disables Bluetooth on the iPhone (watch then joins Wi-Fi directly), or restores the iPhone's internet. What we already tried waitsForConnectivity = true doesn't help; a path exists (the tunnel), it just doesn't work. Fresh URLSession per retry, backoff retries still routed via the tunnel. Per TN3135 we understand low-level networking is not available to a normal app: we prototyped NWConnection with prohibitedInterfaceTypes = [.other], and indeed on device NWPathMonitor stays .unsatisfied even when the watch has working Wi-Fi, exactly as TN3135 describes. So Network framework is not an escape hatch for us, and we are not looking to abuse the audio-streaming/CallKit carve-outs. Questions Is the companion-preferred routing supposed to fail over to the watch's own Wi-Fi when the iPhone is reachable over Bluetooth but has no internet? If yes, on what timescale, and is there anything an app can do to help the system notice the dead path sooner? Is there ANY supported way for a foreground watchOS app to express "do not use the companion link for this request"? We found only the private _companionProxyPreference SPI, which we obviously can't ship. If the answer to both is "no", what is the recommended pattern for safety-critical requests in this state is failing fast and instructing the user to disable iPhone Bluetooth really the intended UX? Related earlier reports of the same behavior: https://developer.apple.com/forums/thread/759321 https://developer.apple.com/forums/thread/107964

I have an iOS app that now cannot connet to websocket servers when building with new SDKs. The app that i have deployed in appstore can connect to the existing websocket servers we use but when i build the same code with the new SDKs (Nex XCode) the app connects to the websocket server and then disconnect right after that so no messages are received and no messages are sent. What has changed and what do i need to change in the app? Or do i need to change somehing else somewhere else?

We are seeing a consistent crash on iOS 26 that does not reproduce on iOS 17 or iOS 18. The crash occurs on a background thread ("com.apple.network.connections") with no application code in the crashed thread's stack. The crash trace begins in quic_migration_probe_path and terminates in nw_protocol_data_access_buffer + 180, suggesting a use-after-free or buffer lifetime violation during QUIC connection path migration (e.g., Wi-Fi ↔ Cellular handoff). This crash does not appear to be reproducible on demand — it correlates with network path transitions while QUIC connections are active. Our app uses standard URLSession with default/ephemeral session configurations and does not explicitly enable HTTP/3; iOS 26 is automatically upgrading eligible connections. Crash thread (abbreviated): 0 libquic.dylib quic_conn_send_packet + 144 1 libquic.dylib quic_conn_continue_sending + 424 2 libquic.dylib __quic_conn_send_frames_for_key_state_block_invoke_2 + 1244 3 Network nw_protocol_data_access_buffer + 180 ← crash 4 Network nw_protocol_data_copy_buffer 5 Network nw_endpoint_flow_output_frames 6 libquic.dylib quic_conn_send_frames_for_key_state 7 libquic.dylib quic_conn_send_frames 8 libquic.dylib quic_migration_probe_path + 1464 9 libquic.dylib quic_migration_path_established + 2608 10 libquic.dylib __quic_migration_path_event_block_invoke.21 11 libquic.dylib quic_migration_path_event 12 Network nw_protocol_implementation_connected There is no app code in the crashed thread. This is a regression introduced in iOS 26, where libquic.dylib was separated into its own dynamic library and new path migration probe logic was introduced. iOS → iOS 26 Networking → URLSession / Network.framework

When a VPN is active, RCS messaging does not work on iOS 18. I work on an iOS VPN app, and we were very appreciative of the excludeCellularServices network flag that was released during the iOS 16 cycle. It's a great solution to ensure the VPN doesn't interfere with cellular network features from the cellular provider. Separately - As a user, I'm excited that iOS 18 includes RCS messaging. Unfortunately, RCS messaging is not working when our VPN is active (when checking on the iOS 18 release candidate). My guess is that RCS is not excluded from the VPN tunnel, even when excludeCellularServices is true. It seems like RCS should be added in this situation, as it is a cell provider service. Can RCS be added as a service that is excluded from the VPN tunnel when excludeCellularServices is true? (I've also sent this via feedback assistant, as 15094270.)

Hello, it seems Multipeer Connectivity is deprecated. We are looking to connect multiple Vision Pros together that are in the same physical space but in unknown network setups (That might block P2P communication and Multicasting). We are building an app with unity and already have networking solution that we are looking to extend to work with something like multipeer connectivty? Am I reading the docs right that "Apple peer-to-wifi" is the replacement. And that by using the "includePeerToPeer" property this will work. Would it be possible in this way that the Vision Pros discover and communicate with each other even if not connected to an AP?

While updating our test devices to iOS 26, we noticed that the connection between devices are flaky. Often when connecting to a Peer from a device running iOS 26 we can observe the invite coming through and when accepting said invite, both ends going to .connecting state and a while later going back to .notConnected within the peer(_ peerID: MCPeerID, didChange state: MCSessionState) function. This happens regularly and retrying the invitation process several times usually resolves it. Do anyone have any information or guidance on how to resolve this issue?

Hoping this might peak someones interest regarding proxy authorisation handling specifically during a device's SetupAssistant phase. Our problem in this instance relies with the AuthBroker's handling of proxy authorisation challenges. With Apple's devices proxy auth is handled through AuthBroker which will make subsequent calls to GSS/ keychain if applicable to handle proxy Auth with CFNetwork. Whilst this process functions quite well in the large part it's functionality around prompt suppression causes issues during the setupAssistant phase. To avoid prompt fatigue AuthBroker Agent has a flag for a given proxy authorisation host (combination of host + port) that's responsible for reporting if a system prompt has been raised in the past. If it has AuthBroker will suppress prompting for the active session. This creates a problem with SetupAssistant in that AuthBroker agent is not allowed to raise system prompts in this state. As a result it instaed triggers a default not now handling: default 2026-04-27 20:34:43.565424 -0700 AuthBrokerAgent [0x100a7ee60] activating connection: mach=false listener=false peer=true name=com.apple.cfnetwork.AuthBrokerAgent.peer[119].0x100a7ee60 default 2026-04-27 20:34:43.565608 -0700 AuthBrokerAgent [0x100a80350] activating connection: mach=false listener=false peer=true name=com.apple.cfnetwork.AuthBrokerAgent.peer[158].0x100a80350 default 2026-04-27 20:34:43.565924 -0700 AuthBrokerAgent Fetching proxy credential for query <private> default 2026-04-27 20:34:43.566135 -0700 AuthBrokerAgent Request <private> 0x65a873860 default 2026-04-27 20:34:43.567245 -0700 AuthBrokerAgent Not internal release, disabling SIRL default 2026-04-27 20:34:43.576369 -0700 AuthBrokerAgent CFNetwork Diagnostics [3:1] 20:34:43.575 { CopyDefaultCredential: (null) Store: shared credential storage 0x100a7d320, session 0xad7010040, persistent 0x100a7d3e0 Space: https://someproxy.example.com:3128/, NTLM (Hash 774a6617a1f9d1ae) Result: null } [3:1] default 2026-04-27 20:34:43.576451 -0700 AuthBrokerAgent Prompting user 0x65a873860 default 2026-04-27 20:34:43.578299 -0700 AuthBrokerAgent Cache loaded with 6300 pre-cached in CacheData and 69 items in CacheExtra. default 2026-04-27 20:34:43.606794 -0700 AuthBrokerAgent User selected alternate response, won't prompt again 0x65a873860 default 2026-04-27 20:34:43.606820 -0700 AuthBrokerAgent Not sending a credential 0x65a873860 default 2026-04-27 20:34:43.606829 -0700 AuthBrokerAgent Fetching proxy credential complete result (null) This flows onto Authbroker requests executed after setupAssistant and prevents the device from prompting until an effective restart: default 2026-04-28 13:37:46.710956 +1000 Setup Buddy exiting... default 2026-04-28 13:38:06.658658 +1000 AuthBrokerAgent [0xad6864000] activating connection: mach=false listener=false peer=true name=com.apple.cfnetwork.AuthBrokerAgent.peer[278].0xad6864000 default 2026-04-28 13:38:06.659238 +1000 AuthBrokerAgent Fetching proxy credential for query <private> default 2026-04-28 13:38:06.661957 +1000 AuthBrokerAgent Request <private> 0xa4eccc760 default 2026-04-28 13:38:06.662597 +1000 AuthBrokerAgent SecSecurityClientGet new thread! default 2026-04-28 13:38:06.813050 +1000 AuthBrokerAgent CFNetwork Diagnostics [3:7] 13:38:06.809 { CopyDefaultCredential: (null) Store: shared credential storage 0x100a7d320, session 0xad7010040, persistent 0x100a7d3e0 Space: https://someproxy.example.com:3128/, NTLM (Hash 774a6617a1f9d1ae) Result: null } [3:7] default 2026-04-28 13:38:06.813088 +1000 AuthBrokerAgent Will not prompt since user previously dismissed prompt 0xa4eccc760 default 2026-04-28 13:38:06.813091 +1000 AuthBrokerAgent Not sending a credential 0xa4eccc760 default 2026-04-28 13:38:06.814867 +1000 AuthBrokerAgent Fetching proxy credential complete result (null) Is there any chance to get this handling updated so that SetupAssistant reset AuthBroker's prompting state on conclusion to allow for system prompt exposure to the user without requiring a device restart.

We are implementing a Network Extension that uses NETransparentProxyProvider. For browser TCP flows we terminate in the extension and re‑originate traffic with NWConnection. Per documentation, we set NWParameters.preferNoProxies = true on that NWConnection so it should not use the system HTTP/HTTPS proxy configuration, including PAC‑selected explicit proxies. Observation: With System Settings → Network → Proxies → Automatic proxy configuration pointing at a PAC file that returns something like PROXY 127.0.0.1:8888 for relevant traffic, we still see our NWConnection traffic show up at the local explicit proxy as a normal CONNECT host:443 tunnel. That suggests PAC / explicit proxy selection is still being applied to sockets we believed were opted out via preferNoProxies. This is affecting interoperability: the browser may evaluate PAC with a hostname (e.g. a site configured as DIRECT), while a separate NWConnection may be evaluated in a context where the logical host is an IPv4 literal, so the same PAC script can return PROXY for what the user thinks is the “same” destination. We had expected preferNoProxies to remove the second leg from PAC/proxy entirely. Expected: NWConnection with preferNoProxies == true should connect without opening an explicit CONNECT session to the PAC‑configured proxy (unless there is documented behavior that NE‑originated traffic is intentionally exempt from this flag). Actual: Traffic from the NWConnection path still reaches the explicit proxy (we can log CONNECT … on a minimal local proxy). Environment: macOS Tahoe 26.5 (25F71), Network Extension / App Proxy provider, PAC served over local http, Safari as client. Questions: Is preferNoProxies guaranteed to bypass PAC‑selected explicit proxies for NWConnection from Network Extension processes, or are there known exceptions (e.g. certain interfaces, MDM, networkserviceproxy, etc.)? If this is by design, what is the supported way for an NE to open an outbound TCP connection that must not inherit system PAC/proxy?

We are currently investigating a serious issue related to Wi-Fi Aware and AccessorySetupKit. We found that some devices which originally supported Wi-Fi Aware may suddenly report that Wi-Fi Aware is not supported. After this happens, calling the following API fails: ASAccessorySession.showPicker(for:completionHandler:) API documentation: https://developer.apple.com/documentation/accessorysetupkit/asaccessorysession/showpicker(for:completionhandler:) The error returned is: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable.” Related logs: error: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable." 21:27:33.116061+0800 deviceaccessd Activating DASession: CID 0x7FC70001, BundleID xxxx, PID 542, WiFiAwareSupported: no 2026-05-26 21:27:33.118<103>21:27:33.118[E][WiFiAware::WA]@"":[ASK] showPicker callback error: Error Domain=ASErrorDomain Code=450 "Current device is not Wi-Fi Aware capable." UserInfo={ NSDebugDescription=Current device is not Wi-Fi Aware capable., cuErrorMsg=Current device is not Wi-Fi Aware capable., NSLocalizedFailureReason=Current device is not Wi-Fi Aware capable. } Device information: Device: iPhone 16 Pro OS Version: 26.5 The device was previously able to use Wi-Fi Aware successfully. However, after the issue occurs, the system reports: WiFiAwareSupported: no The only known way to recover so far is to erase all content and settings / factory reset the device. This is not an acceptable workaround for end users and may cause a severe user experience issue. We would like to ask for your help with the following questions: Under what conditions would an iPhone that supports Wi-Fi Aware suddenly be reported as not Wi-Fi Aware capable? Is WiFiAwareSupported: no determined by hardware capability, system configuration, region setting, privacy/security policy, entitlement state, or some cached system state? Is there any known issue in AccessorySetupKit or Wi-Fi Aware on iOS 26.5 that could cause this behavior? Is there a way to recover the Wi-Fi Aware capability without requiring a factory reset? Are there any additional logs, sysdiagnose profiles, or diagnostic commands you recommend us to collect when this issue occurs? This issue is critical for us because users who encounter it will no longer be able to proceed with accessory setup, even though their device should support Wi-Fi Aware. Please let us know if you need a sysdiagnose, sample project, full device logs, or additional reproduction information. We would appreciate any guidance on the root cause and possible workaround.

Actual Result: After showPicker(for:), the system AccessorySetupUI RemoteAlert brings up a remote keyboard. User taps are dispatched to AccessorySetupUI’s UIRemoteKeyboardWindow instead of the picker content window. App-side endEditing(true) / resignFirstResponder cannot dismiss it because the keyboard belongs to the system AccessorySetupUI remote scene. Key Evidence: 19:51:54.066: App window snapshot before showPicker has no UITextEffectsWindow. 19:51:54.009968: ASAccessorySession ### showPickerWithDisplayItems 19:51:54.013299: AccessorySetupUI showPickerWithOverrideBundleID 19:51:54.051591: AccessorySetupUI reports remote keyboard onscreen, frame {{0, 623}, {440, 333}} 19:51:54.095643: display layout shows com.apple.AccessorySetupUI foreground and com.osmo.tech obscured. 19:51:56.207/19:51:56.305: touch events are sent to and logged as KeyboardTouch touch down/up. Questions for Apple: Is AccessorySetupKit picker expected to show a keyboard when no text input is focused? Is it a system bug that UIRemoteKeyboardWindow covers/intercepts the “Find Accessories” action? Is there any public API for a third-party app to dismiss the keyboard inside AccessorySetupUI RemoteAlert? If this is expected behavior, what is the recommended workaround or required picker/display item configuration?

wifip2pd leaks file descriptors during repeated Wi-Fi Aware NDP cycles → EMFILE → Wi-Fi Aware permanently broken Summary Under repeated Wi-Fi Aware (NAN) datapath connect/teardown cycles, wifip2pd leaks file descriptors until it hits the per-process limit (EMFILE, "Too many open files"). After that, wifip2pd can no longer create the socket needed to configure the nan0 interface, so updating the nan0 IPv6 link-local address fails with Apple80211Error Bad file descriptor. From the app's side, the NDP datapath is established but the NetworkConnection never gets a local IPv6 address and stays stuck in .preparing. The condition does not self-heal and is not cleared by restarting the app — only a reboot (or wifip2pd restart) recovers Wi-Fi Aware. Configuration iPhone 16 Pro Max, iOS 26.5 Network framework (new Swift NetworkConnection / NetworkBrowser Wi-Fi Aware API) System component: wifip2pd Where the problem is The leak and the failure are entirely inside wifip2pd (the per-process descriptor table fills up). The chain is: fd leak in wifip2pd → EMFILE ("Too many open files", errno 24) → socket() fails → cannot set nan0 IPv6 link-local address (Apple80211 ioctl on invalid fd → EBADF) → app NWConnection NWPath = satisfied but localEndpoint = nil → NetworkConnection stuck in .preparing, times out Abnormal console logs (the evidence) The smoking-gun lines from the unified log / Console (process wifip2pd): wifip2pd <Error> Failed to create socket: Too many open files wifip2pd <Error> Failed to update nan0 IPv6 address to [fe80::30c1:22ff:fe97:fefb] (from [fe80::e8a0:9bff:fe25:4d5c]) because <Apple80211Error Bad file descriptor> wifip2pd <Error> nw_path_shared_necp_fd necp_open failed [24: Too many open files] # errno 24 = EMFILE wifip2pd(Network) <Error> File descriptor is bad, could not create socket Counts over one ~11.5-minute failing capture: wifip2pd "Too many open files": 45 occurrences (a healthy capture has 0). nan0 IPv6 address update: 2 success / 13 fail (the 2 successes are before exhaustion; everything after fails with "Bad file descriptor"). Healthy device, for contrast — the IPv6 update succeeds on every NAN MAC rotation, and the app connection then works: wifip2pd Successfully updated nan0 IPv6 address to [fe80::f4c4:14ff:fe28:784a] # → app NWPath: status=satisfied, local=fe80::f4c4:14ff:fe28:784a%nan0 → NetworkConnection .ready Two facts that localize the bug: The leak is in wifip2pd, not the app. wifip2pd is one persistent daemon (constant pid) whose fd count only grows; the client app was restarted multiple times during the test and that did not release the descriptors. All "Too many open files" lines are emitted by wifip2pd. The NDP datapath itself still succeeds — only socket/interface-address configuration fails: kernel nan0: handleDataPathEstablished: NAN-DP Data path ESTABLISHED ... encrypt 1, EstDPs 1 wifip2pd #### Data Confirmed With Peer: ... port: 9004 Application-layer symptom (developer-facing) The same client code works before exhaustion and fails after: Before: NetworkConnection<UDP> reaches .ready; NWPath.localEndpoint = fe80::…%nan0. After: NetworkConnection<UDP> stays .preparing; every onPathUpdate reports status=satisfied, interfaces=["nan0"], local=nil; it times out and retries forever. The decisive developer-visible signal is NWPath.status == .satisfied together with localEndpoint == nil on nan0. Correlating timestamps confirms the contradiction: the console shows Data Confirmed With Peer ... port 9004 ~9–10 s before the app's NetworkConnection gives up, while the matching nan0 IPv6 update fails with "Bad file descriptor". The datapath is up at L2, but the connection is unusable because no local address was ever assigned. Steps to Reproduce Pair an iPhone with a Wi-Fi Aware peer that publishes a datapath service (_media-sync._udp, paired device, NCS-SK-CCM-128). Repeatedly establish and tear down the NDP datapath. In our case the peer device repeatedly powers off/on; each cycle forces a fresh browse + re-pair + NDP establish (the peer's NAN MAC is randomized each boot). Loop this; wifip2pd is never restarted, so the leak accumulates (failure appeared by ~the 9th iteration). Expected vs Actual Expected: wifip2pd releases the descriptors of each completed/torn-down browse/subscribe/datapath session; fd count stays bounded; nan0 IPv6 updates keep succeeding; NetworkConnection reaches .ready. Actual: wifip2pd fd count grows until EMFILE; nan0 IPv6 update then fails permanently; NetworkConnection is stuck .preparing for the rest of the wifip2pd process lifetime. Impact Any app using Wi-Fi Aware NDP datapaths under frequent connect/teardown eventually loses all Wi-Fi Aware connectivity. The failure is sticky for the wifip2pd lifetime and is invisible to / unrecoverable by the client app. Workaround Reboot the device (resets wifip2pd). The client can only slow the leak (fewer reconnects, prompt release of NetworkConnection), not prevent it, since the descriptors leak inside wifip2pd. To confirm / fix A sysdiagnose captured during the reproduction should show wifip2pd's open-fd count growing monotonically per connect/teardown cycle (which descriptor type leaks per browse/subscribe/datapath). Repro signature to grep in the logs: wifip2pd emitting Failed to create socket: Too many open files, necp_open failed [24: Too many open files], and Failed to update nan0 IPv6 address ... Apple80211Error Bad file descriptor.

I’m encountering a persistent issue with my Network Extension (specifically NEFilterDataProvider) and would really appreciate any insights. The extension generally works as expected, but after some time — especially after sleep/wake cycles or network changes — a global network outage occurs. During this state, no network traffic works: pings fail, browsers can’t load pages, etc. As soon as I stop the extension (by disabling it in System Preferences), the network immediately recovers. If I re-enable it, the outage returns instantly. I’ve also noticed that once this happens, the extension stops receiving callbacks like handleNewFlow(), and reinstalling the app or restarting the extension doesn’t help. The only thing that resolves the issue is rebooting the system. After reboot, the extension works fine again — until the problem reoccurs later. I asked AI about this behavior, and it suggested the possibility that the kernel might have marked the extension as untrusted, causing the system to intentionally block all network traffic as a safety mechanism. Has anyone experienced similar behavior with NEFilterDataProvider? Could there be a way to detect or prevent this state without rebooting? Is there any logging or diagnostic data I should collect when it happens again? Any guidance or pointers would be greatly appreciated. Thanks in advance!

Why is the WiFiAware framework not importable in Mac Catalyst? Are there any plans to support Wi-Fi Aware technology on Mac Catalyst in the future?

As shown in the image, Apple's Wi-Fi Aware framework mentions support for Mac 26.0+

I'm working on developing a transparent proxy provider extension, and I am trying to figure out how to handle a change in configuration that would result in a different verdict from handleNewFlow() Consider the following scenario: The proxy provider is started with configuration A, and a bunch of packet flows get a verdict of NO from handleNewFlow(). These flows are now handled by the system and get routed out to the internet normally. Some application changes the protocolConfiguration property to configuration B, and the proxy provider detects this change via KVO. This new configuration changes the verdict that would have been returned from handleNewFlow() to YES, requiring that traffic to be handled by the transparent proxy provider instead of the system. These flows should be closed (eg: by calling closeReadWithError()) but the proxy provider has no record of them because we previously returned NO Is there a way that a transparent proxy provider can get the operating system to close the currently open flows so that they can be re-evaluated by handleNewFlow() and directed into the transparent proxy instead?

Context Our enterprise application is offline-first for iOS and iPadOS, designed to work completely offline, storing a very large local database (DB) and many attached files (images and videos) locally. Users create and update entities on the device.1 When connectivity is available, the app performs a bidirectional sync: local changes (including multi-gigabyte files) are uploaded, and thousands of DB updates are pulled down and applied locally. The Challenge: Foreground Requirement The complete sync process often requires 10 to 20 minutes to finish. Users expect their devices to proactively sync when online, even if it takes this long. Our fundamental problem is that, at present, users must keep the app in the foreground to complete the task. We have confirmed that on iOS, the system aggressively terminates the app process, typically after 30 seconds of being sent to the background. We currently advise users with large projects to keep the app in the foreground and connected to power.2 Existing Mitigation and Technical Details We have implemented several best practices to optimize transfers and manage device resources: We use battery checks before initiating large transfers, with a low battery threshold (around 15%) to pause actions if the device will enter a danger zone.2 Our upload mechanism uses HTTP Range Requests to implement a resumable single-stream approach for maximum throughput, ensuring that if a connection drops mid-transfer (even at 1.2 GB of a 2.5 GB file), we only re-transfer the remaining bytes, rather than losing all progress. This addresses network resilience and speed but not the OS background limitation.3 The Core Issue The various background options provided by iOS and iPadOS do not appear deterministic enough to reliably handle the immediate, extended data synchronization (uploading GB files and pulling down substantial DB changes) that we require. We are seeking a solution where a user-initiated task engages in background work almost immediately, reliably continuing for 10–20+ minutes after the user leaves the app or locks the screen, allowing for more "natural" device usage. Our Question for Apple Engineering Given the high volume of data transfer and the need for deterministic, extended background execution, what is Apple's current recommended, official approach for an enterprise app that requires prolonged background syncs—specifically, how can we architect this on iOS/iPadOS to reliably continue the upload and download of large data sets and database updates after the app moves out of the foreground?