I'm developing an iOS application in Swift that performs API calls using URLSession.shared. The requests work correctly when the app is in the foreground. However, when the app transitions to the background (for example, when the user switches to another app), the ongoing API calls are either paused or do not complete as expected.
What I’ve tried:
Using URLSession.shared.dataTask(with:) to initiate the API requests
Observing application lifecycle events like applicationDidEnterBackground, but haven't found a reliable solution to allow requests to complete when backgrounded
Goal:
I want certain API requests to continue running or be allowed to complete even if the app enters the background.
Question:
What is the correct approach to allow API calls to continue running or complete when the app moves to the background?
Should I be using a background URLSessionConfiguration instead of URLSession.shared?
If so, how should it be properly configured and used in this scenario?
Networking
RSS for tagExplore the networking protocols and technologies used by the device to connect to Wi-Fi networks, Bluetooth devices, and cellular data services.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
On "Accessory Interface Specification CarPlay Addendum R10", it says that it is recommended that the accessory uses a MIMO (2x2) hardware configuration, does this imply that WiFi 5 and SISO (1X1) will be phased out in the near future?
When will WiFi 6 MIMO (2x2) become mandatory?
On "Accessory Interface Specification CarPlay Addendum R10", it says that Spatial Audio is mandatory. However, for aftermarket in-vehicle infotainment (IVI) system due to the number of speakers are less than 6, is it allowed not to support spatial audio for this type of aftermarket IVI system?
Dear Developers,
I would like to suggest an optimization for the logic governing the download and installation queue for app updates.
Currently, when multiple applications are awaiting updates, the prioritization does not appear to consider the update payload size. My proposal is to implement a logic that prioritizes the download and installation of updates with a smaller delta size (fewer MB) before those with a larger delta.
Practical Example: A 1MB update would be processed before a 500MB update, even if their arrival order in the queue was inverted.
Potential Benefits:
Perceived Speed Optimization (UX): Users would gain access to functional applications more quickly, especially in scenarios with multiple pending updates.
Network Efficiency: In limited or intermittent bandwidth scenarios, completing smaller downloads first can reduce the chance of download failures and optimize network resource utilization.
Device Resource Management: Frees up temporary storage and processing resources more rapidly for smaller updates.
I believe this optimization would bring significant gains in terms of User Experience (UX) and the operational efficiency of the platform.
Thank you for your attention and consideration.
Sincerely,
Hello,
I have a peer to peer networking setup in my app that uses Network Framework with Bonjour and QUIC via NWBrowser, NWListener, NWConnection, and NWEndpoint and all works as expected.
I watched the videos about the new iOS 26 Networking stuff (NetworkBrowser, NetworkListener, NetworkConnection) and wanted to try and migrate all my code to use the the new APIs (still use Bonjour and NOT use Wi-Fi Aware) but hit some issues. I was following how the Wi-Fi Aware example app was receiving messages
for try await messageData in connection.messages {
but when I got things setup with QUIC in a similar fashion I got the following compile error
Requirement from conditional conformance of '(content: QUIC.ContentType, metadata: QUIC.Metadata)' to 'Copyable'
Requirement from conditional conformance of '(content: QUIC.ContentType, metadata: QUIC.Metadata)' to 'Escapable'
Requirement from conditional conformance of '(content: QUIC.ContentType, metadata: QUIC.Metadata)' to 'Copyable'
Requirement from conditional conformance of '(content: QUIC.ContentType, metadata: QUIC.Metadata)' to 'Escapable'
When I asked Cursor about what I was facing its response was as follows: "The connection.messages stream changed in the new Network APIs: it now yields typed (content, metadata) tuples. Iterating with for try await incoming in connection.messages asks the compiler to conform that tuple to Copyable/Escapable; for QUIC the tuple isn’t copyable, so you hit the conditional-conformance error."
I am curious if you've been able to use the new iOS 26 network APIs with QUIC?
Thank you,
Captadoh
I use eapolcfg in Apple's open source eap8021x repository to connect to the enterprise network.
1.https://github.com/gfleury/eap8021x-debug
https://opensource.apple.com/source/eap8021x/eap8021x-304.100.1/
Our enterprise network authentication is PEAP. So far, I have created a profile using the following commands and have done the access.
./eapolcfg createProfile --authType PEAP --SSID myssid --securityType WPA2 --userDefinedName MyProfile
./eapolcfg setPasswordItem --password mypassword --name myname --SSID myssid
./eapolcfg startAuthentication --interface en0 --SSID myssid
After I performed this series of operations, I passed
BOOL success = [self.interface associateToEnterpriseNetwork:network identity:nil username:username password:password error:&error];
Connection will pop up the following pop-up window, sometimes associateToEnterpriseNetwork will fail. I don't know what went wrong, is it that I missed some steps through the eapolcfg [tool?]
This function also reports the following error:Error Domain=com.apple.coreWLAN.EAPOL.error Code=1
"(null)"
Please answer my questions. Thank you very much
We are developing a custom vpn client using Packet Tunnel Provider extension. Our VPN use Client Certificate authentication.
Certificates need to be delivered to device using MDM. We plan to deliver certificates and other settings using configuration profiles with com.apple.vpn.managed and com.apple.security.pkcs12 payloads.
There are some things we do not understand:
What entitlements do we need? Do we need additional entitlements except com.apple.developer.networkingextension and com.apple.managed.vpn.shared?
What is the process to get com.apple.managed.vpn.shared entitlement?
Is ADP (not ADEP) enough for such application?
Good morning,
I have been playing with he new Networking framework released in beta, and i think its amazing how powerful and simple it is.
However i have been tackling some issues with it, it seems that the NetworkListener does not allow us to configure a specific endpoint for any of the protocols, UDP, TCP (QUIC, TLS)
Is this intended or just not missing features as of the Beta ?
I figured out how to use bonjour to get a port (as i am brand new to using Networking on macOS and Swift)
I get that the use of this is mainly as a client to connect to servers, but it would make more sense to have a high level abstraction of what already exist, wouldn't it be more intuitive to configure a NetworkEndpoint that contains either a Bonjour Service or an endpoint with configured port that we can then configure on the Listener, instead of doing .service(...) ?
Hi everyone,
I'm currently experimenting with building a simple DNS filter using Apple's Packet Tunnel framework. Here's the flow I'm trying to implement:
Create a TUN interface
Set up a UDP socket
Read packets via packetFlow.readPackets
Parse the raw IP packet
Forward the UDP payload through the socket
Receive the response from the server
Reconstruct the IP packet with the response
Write it back to the TUN interface using packetFlow.writePackets
Here’s an example of an intercepted IP packet (DNS request):
45 00 00 3c 15 c4 00 00 40 11 93 d1 c0 a8 00 64 08 08 08 08 ed 6e 00 35 00 28 e5 c9 7f da 01 00 00 01 00 00 00 00 00 00 04 74 69 6d 65 05 61 70 70 6c 65 03 63 6f 6d 00 00 01 00 01
And here’s the IP packet I tried writing back into the TUN interface (DNS response):
45 00 00 89 5e 37 40 00 40 11 0b 11 08 08 08 08 c0 a8 00 64 00 35 ed 6e 00 75 91 e8 7f da 81 80 00 01 00 04 00 00 00 00 04 74 69 6d 65 05 61 70 70 6c 65 03 63 6f 6d 00 00 01 00 01 c0 0c 00 05 00 01 00 00 0c fb 00 11 04 74 69 6d 65 01 67 07 61 61 70 6c 69 6d 67 c0 17 c0 2c 00 01 00 01 00 00 03 04 00 04 11 fd 74 fd c0 2c 00 01 00 01 00 00 03 04 00 04 11 fd 74 7d c0 2c 00 01 00 01 00 00 03 04 00 04 11 fd 54 fb
Unfortunately, it seems the packet is not being written back correctly to the TUN interface. I'm not seeing any expected DNS response behavior on the device.
Also, I noticed that after creating the TUN, the interface address shows up as 0.0.0.0:0 in Xcode. The system log includes this message when connecting the VPN:
NWPath does not have valid interface: satisfied (Path is satisfied), interface: utun20[endc_sub6], ipv4, dns, expensive, uses cellular
Does anyone know how to properly initialize the TUN so that the system recognizes it with a valid IP configuration? Or why my written-back packet might be getting ignored?
Any help would be appreciated!
I'm able to discover a service with Bonjour, which gets me an nw_browse_result_t from which I can get an nw_endpoint_t and then an nw_connection_t. That's all fine. But this particular service runs on 3 ports. The port numbers of the other 2 ports are in the txt record (but they are well-known and stable anyway).
How can I create 2 more nw_connection_t to the same host/IP but on a different port?
I already have this working with NSNetService, but am trying to update to Network.framework.
I've found nw_endpoint_get_address() but the docs say it returns null "if the endpoint is not of type nw_endpoint_type_address" and indeed nw_browse_result_t gives me an nw_endpoint_type_bonjour_service.
Topic:
App & System Services
SubTopic:
Networking
Hi there,
We are facing some issues regarding TLS connectivity:
Starting with iOS 26, the operating system refuses to open TLS sockets to local devices with self-signed certificates over Wi-Fi. In this situation, connection is no longer possible, even if the device is detected on the network with Bonjour.
We have not found a workaround for this problem.
We've tryied those solutions without success:
Added the 'NSAppTransportSecurity' key to the info.plist file, testing all its items, such as "NSAllowsLocalNetworking", "NSExceptionDomains", etc.
Various code changes to use properties such as "sec_protocol_options_set_local_identity" and "sec_protocol_options_set_tls_server_name" to no avail.
Brutally import the certificate files into the project and load them via, for example, "Bundle.main.url(forResource: "nice_INTERFACE_server_cert", withExtension: "crt")", using methods such as sec_trust_copy_ref and SecCertificateCopyData.
Download the .pem or .crt files to the iPhone, install them (now visible under "VPN & Device Management"), and then flag them as trusted by going to "Settings -> General -> Info -> Trust". certificates"
The most critical part seems to be the line
sec_protocol_options_set_verify_block(tlsOptions.securityProtocolOptions, { $2(true) }, queue)
whose purpose is to bypass certificate checks and validate all of them (as apps already do). However, on iOS26, if I set a breakpoint on leg$2(true),` it never gets there, while on iOS 18, it does.
I'll leave as example the part of the code that was tested the most below. Currently, on iOS26, the handler systematically falls back to .cancelled:
func startConnection(host: String, port: UInt16) {
self.queue = DispatchQueue(label: "socketQueue")
let tlsOptions = NWProtocolTLS.Options()
sec_protocol_options_set_verify_block(tlsOptions.securityProtocolOptions, { $2(true) }, queue)
let parameters = NWParameters(tls: tlsOptions)
self.nwConnection = NWConnection(host: .init(host), port: .init(rawValue: port)!, using: parameters)
self.nwConnection.stateUpdateHandler = { [weak self] state in
switch state {
case .setup:
break
case .waiting(let error):
self?.connectionDidFail(error: error)
case .preparing:
break
case .ready:
self?.didConnectSubject.onNext(Void())
case .failed(let error):
self?.connectionDidFail(error: error)
case .cancelled:
self?.didDisconnectSubject.onNext(nil)
@unknown default:
break
}
}
self.setupReceive()
self.nwConnection.start(queue: queue)
}
These are the prints made during the procedure. The ones with the dot are from the app, while the ones without are warnings/info from Xcode:
🔵 INFO WifiNetworkManager.connect():52 - Try to connect onto the interface access point with ssid NiceProView4A9151_AP
🔵 INFO WifiNetworkManager.connect():68 - Connected to NiceProView4A9151_AP
tcp_output [C13:2] flags=[R.] seq=215593821, ack=430284980, win=4096 state=CLOSED rcv_nxt=430284980, snd_una=215593821
nw_endpoint_flow_failed_with_error [C13 192.168.0.1:443 in_progress channel-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], dns, uses wifi, LQM: unknown)] already failing, returning
nw_connection_copy_protocol_metadata_internal_block_invoke [C13] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection
nw_connection_copy_protocol_metadata_internal_block_invoke [C13] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection
nw_connection_copy_connected_local_endpoint_block_invoke [C13] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection
nw_connection_copy_connected_remote_endpoint_block_invoke [C13] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection
nw_connection_copy_protocol_metadata_internal_block_invoke [C14] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection
nw_connection_copy_protocol_metadata_internal_block_invoke [C14] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection
nw_connection_copy_connected_local_endpoint_block_invoke [C14] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection
nw_connection_copy_connected_remote_endpoint_block_invoke [C14] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection
[C14 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel
[C14 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel
nw_connection_copy_protocol_metadata_internal_block_invoke [C15] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection
nw_connection_copy_protocol_metadata_internal_block_invoke [C15] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection
nw_connection_copy_connected_local_endpoint_block_invoke [C15] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection
nw_connection_copy_connected_remote_endpoint_block_invoke [C15] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection
nw_connection_copy_protocol_metadata_internal_block_invoke [C16] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection
nw_connection_copy_protocol_metadata_internal_block_invoke [C16] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection
nw_connection_copy_connected_local_endpoint_block_invoke [C16] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection
nw_connection_copy_connected_remote_endpoint_block_invoke [C16] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection
[C16 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel
[C16 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel
🔴 ERROR InterfaceDisconnectedViewModel.connect():51 - Sequence timeout.
Topic:
App & System Services
SubTopic:
Networking
Tags:
Foundation
Developer Tools
Nearby Interaction
iOS
I am developing an App based on Network Extension that lets all network requests on device access the Internet through a private Relay.
I created an empty iOS App and only the entitlements file and ViewController.swift(Main.storyboard) file have been modified. The code was copied from the official video https://developer.apple.com/videos/play/wwdc2023/10002/
But, running the App on iPhone, the saveToPreferences API reported Error Domain=NERelayErrorDomain Code=3 "(null)" and the App doesn't look like it's changed at all (it doesn't jump to the Settings - VPN&Relay). Does anyone know why?Any reply would be greatly appreciated.
The contents of the entitlements file:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.developer.networking.networkextension</key>
<array>
<string>relay</string>
</array>
</dict>
</plist>
ViewController.swift:
import UIKit
import NetworkExtension
class ViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view.
}
@IBAction func tap(_ sender: Any) {
let newRelay = NERelay()
let relayURL = URL(string: "https://relay.example.com:443/")
newRelay.http3RelayURL = relayURL
newRelay.http2RelayURL = relayURL
newRelay.additionalHTTPHeaderFields = ["Authorization" : "PrivateToken=123"]
let manager = NERelayManager.shared()
manager.relays = [newRelay]
manager.matchDomains = ["internal.example.com"]
manager.isEnabled = false
manager.saveToPreferences { err in
print(err)
}
}
}
This is the log on the publisher side.
Publisher discovered the subscriber, but could not pair.
Follow up is sent with response rejected
I have an iOS app that connects to a server running on macOS by leveraging NWListener & NWBrowser. It also makes use of the peerToPeer functionality / AWDL offered via the Network framework. This works great in the iOS app. Now I would like to add support for Shortcuts / App Intents in general.
The NWConnection on its own is also working great in the App Intent, but only if I provide the host/port manually, which means I can't use the peer to peer functionality. If I try to run my NWBrowser in the AppIntent it immediately changes its state to failed with a NoAuth (-65555) error:
nw_browser_cancel [B1517] The browser has already been cancelled, ignoring nw_browser_cancel().
nw_browser_fail_on_dns_error_locked [B1518] DNSServiceBrowse failed: NoAuth(-65555)
NWClientManager: Browser failed: -65555: NoAuth
I haven't found documentation/information on whether NWBrowser should work in an AppIntent extension or not.
Hello,
Since the release of iOS 26.0, we are seeing DNS traffic being blocked from within our NEPacketTunnelExtension on some devices. We have not isolated exact reproduction steps, but DNS resolves successfully for a period of time after enabling "iCloud Private Relay" (varying from 1-day to 2-weeks), until it then fails as MDNSResponder then returns:
mDNSResponder [Q37046] DetermineUnicastQuerySuppression: Query suppressed for <mask.hash: 'REDACTED'> Addr (blocked by policy)
DNS resolution continues to fail for all domains with the above until the device is rebooted.
The Packet Tunnel intentionally does not have a DNS server set and this occurs for traffic from the Extension yet off-tunnel, which needs resolution from the system DNS server (and this configuration works perfectly for a period of time before being "blocked by policy").
The following do not resolve the issue once DNS queries are being "blocked by policy" on affected devices: disconnecting then reconnecting the vpn; toggling airplane mode for 10+ seconds; switching connection between WiFi & cellular data; disabling iCloud Private Relay.
We have currently only seen this on unmanaged devices running iOS 26.0 or 26.1 beta and with iCloud Private Relay enabled. We did not see this issue on iOS 16,17 nor 18. We also have not yet seen this when iCloud Private Relay is disabled nor on iOS 26.0.1, however we cannot confirm whether they too are also affected.
Is there a known a bug with iOS 26.0 & 26.1 Beta 1 that could cause this? How can we prevent DNS requests from NEPacketTunnelExtension being sporadically "blocked by policy" until the device is rebooted?
Many thanks in advance.
We have used ::gethostname to retrieve hostname in our tunnel provider extension and found it returns "localhost" on iOS 17+. So we changed to use [[NSProcessInfo processInfo] hostName]. However it often caused 30+ delay in the extension process on a few devices and always returns "localhost".
The sysdiagnose shows a lot of DNS query logs as below:
default mDNSResponder 2025-03-19 17:15:12.453769 +0800 75281: 0x11ad501 [R80937] DNSServiceCreateConnection START PID[79767](ACExtension)
default mDNSResponder 2025-03-19 17:15:12.453892 +0800 75281: 0x11ad501 [R80938] DNSServiceQueryRecord START -- qname: <mask.hash: 'fNnSAdyuhKXqCny8+neXvw=='>, qtype: PTR, flags: 0x15000, interface index: -1, client pid: 79767 (ACExtension), name hash: 84de01e1
default mDNSResponder 2025-03-19 17:15:12.458395 +0800 75281: 0x11ad501 [R80939] DNSServiceQueryRecord START -- qname: <mask.hash: '2X6qN/YT0yh2psKwrGWokg=='>, qtype: PTR, flags: 0x15000, interface index: 0, client pid: 79767 (ACExtension), name hash: f25c923e
default mDNSResponder 2025-03-19 17:15:12.462924 +0800 75281: 0x11ad501 [R80940] DNSServiceQueryRecord START -- qname: <mask.hash: 'peyRWEblLKbNvcOXPjSeMQ=='>, qtype: PTR, flags: 0x15000, interface index: 0, client pid: 79767 (ACExtension), name hash: 83323cc4
Hello Apple Developer Community,
We are developing a full-tunnel VPN app for macOS that utilizes a packet tunnel network system extension (via NEPacketTunnelProvider). We're committed to using a system extension for this purpose, as it aligns with our requirements for system-wide tunneling. The app is sandboxed and intended for distribution on the Mac App Store.
Here's the workflow:
The app (running in user context) downloads a VPN profile from our server.
It generates private keys, appends them to the profile, and attempts to save this enhanced profile securely in the keychain.
The packet tunnel system extension (running in root context) needs to access this profile, including the private keys, to establish the VPN connection.
We've encountered challenges in securely sharing this data across the user-root boundary due to sandbox restrictions and keychain access limitations. Here's what we've tried so far, along with the issues:
Writing from the App to the System Keychain:
Attempted to store the profile in the system keychain for root access. This fails because the sandboxed app lacks permissions to write to the system keychain. (We're avoiding non-sandboxed approaches for App Store compliance.)
Extension Reading Directly from the User Login Keychain:
Tried having the extension access the user's login keychain by its path.
We manually added the network extension (located in /Library/SystemExtensions//bundle.systemextension) to the keychain item's Access Control List (ACL) via Keychain Access.app for testing.
This results in "item not found" errors, likely due to the root context not seamlessly accessing user-keychain items without additional setup.
Using Persistent References in NETunnelProviderProtocol:
The app stores the profile in the user keychain and saves a persistent reference (as Data) in the NETunnelProviderProtocol's identityReference or similar fields. The extension then attempts to retrieve the item using this reference.
We manually added the network extension (located in /Library/SystemExtensions//bundle.systemextension) to the keychain item's Access Control List (ACL) via Keychain Access.app for testing.
However, this leads to error -25308 (errSecInteractionNotAllowed) when the extension tries to access it, possibly because of the root-user context mismatch or interaction requirements.
Programmatically Adding the Extension to the ACL:
Explored using SecAccess and SecACL APIs to add the extension as a trusted application. This requires SecTrustedApplicationCreateFromPath to create a SecTrustedApplicationRef from the extension's path.
Issue 1: The sandboxed app can't reliably obtain the installed extension's path (e.g., via scanning /Library/SystemExtensions or systemextensionsctl), as sandbox restrictions block access.
Issue 2: SecTrustedApplicationCreateFromPath is deprecated since macOS 10.15, and we're hesitant to rely on it for future compatibility.
We've reviewed documentation on keychain sharing, access groups (including com.apple.managed.vpn.shared, but we're not using managed profiles/MDM) as the profiles are download from a server, and alternatives like XPC for on-demand communication, but we're unsure if XPC is suitable for sensitive data like private keys during tunnel creation. And if this is recommended what is going to be the approach here.
What is the recommended, modern approach for this scenario? Is there a non-deprecated way to handle ACLs or share persistent references across contexts? Should we pursue a special entitlement for a custom access group, or is there a better pattern using NetworkExtension APIs?
Any insights, code snippets, or references to similar implementations would be greatly appreciated. We're targeting macOS 15+.
Thanks in advance!
I'm looking for help with a network extension filtering issue. Specifically, we have a subclass of NEFilterDataProvider that is used to filter flows based upon a set of rules, including source IP and destination IP. We've run into an issue where the source IP is frequently 0.0.0.0 (or the IPv6 equivalent) on outgoing flows. This has made it so rules based upon source IP don't work. This is also an issue as we report these connections, but we're lacking critical data. We were able to work around the issue somewhat by keeping a list of flows that we allow that we periodically check to see if the source IP is available, and then report after it becomes available.
We also considered doing a "peekBytes" to allow a bit of data to flow and then recheck the flow, but we don't want to allow data leakage on connections that should be blocked because of the source IP.
Is there a way to force the operating system or network extension frameworks to determine the source IP for an outbound flow without allowing any bytes to flow to the network?
STEPS TO REPRODUCE
Create a network filtering extension for filtering flows using NEFilterDataProvider
See that when handleNewFlow: is called, the outgoing flow lacks the source IP (is 0.0.0.0) in most cases
There is this post that is discussing a similar question, though for a slightly different reason. I imagine the answer to this and the other post will be related, at least as far as NEFilterDataProvider:handleNewFlow not having source IP is considered.
Thanks!
Development environment
Xcode 26.0 Beta 6
iOS 26 Simulator
macOS 15.6.1
To verify TLS 1.3 session resumption behavior in URLSession, I configured URLSessionConfiguration as follows and sent an HTTP GET request:
let config = URLSessionConfiguration.ephemeral
config.tlsMinimumSupportedProtocolVersion = .TLSv13
config.tlsMaximumSupportedProtocolVersion = .TLSv13
config.httpMaximumConnectionsPerHost = 1
config.httpAdditionalHeaders = ["Connection": "close"]
config.enablesEarlyData = true
let session = URLSession(configuration: config, delegate: nil, delegateQueue: nil)
let url = URL(string: "https://www.google.com")!
var request = URLRequest(url: url)
request.assumesHTTP3Capable = true
request.httpMethod = "GET"
let task = session.dataTask(with: request) { data, response, error in
if let error = error {
print("Error during URLSession data task: \(error)")
return
}
if let data = data, let responseString = String(data: data, encoding: .utf8) {
print("Received data via URLSession: \(responseString)")
} else {
print("No data received or data is not UTF-8 encoded")
}
}
task.resume()
However, after capturing the packets, I found that the ClientHello packet did not include the early_data extension.
It seems that enablesEarlyData on URLSessionConfiguration is not being applied.
How can I make this work properly?
The Wi‑Fi Alliance’s Wi‑Fi Aware data communication uses IPv6.
However, in Chapter 53 “Wi‑Fi Aware” of the Accessory Design Guidelines for Apple Devices, Release R26, it is stated that “The Neighbor Discovery Protocol (NDP) for IPv6 address resolution is not supported.”
This has caused confusion among developers: Does Apple’s Wi‑Fi Aware data communication actually use IPv6?
What is the impact of “The Neighbor Discovery Protocol (NDP) for IPv6 address resolution is not supported” in Apple’s implementation?
I have a question. I work for a mobile operator, and when you insert the SIM, the default APN is automatically configured. However, afterward, using the internal Device Manager platform, we send the corresponding APN of an MVNO to that MSISDN. However, the iPhone device (any model, recent iOS versions) receives the notification of the APN change, but it doesn't reflect the change in the APN settings menu. Do you know how we could make the iPhone device reflect the APN change?