Transport Layer Security (TLS) is the most important security protocol on the Internet today. Most notably, TLS puts the S into HTTPS, adding security to the otherwise insecure HTTP protocol. IMPORTANT TLS is the successor to the Secure Sockets Layer (SSL) protocol. SSL is no longer considered secure and it’s now rarely used in practice, although many folks still say SSL when they mean TLS. TLS is a complex protocol. Much of that complexity is hidden from app developers but there are places where it’s important to understand specific details of the protocol in order to meet your requirements. This post explains the fundamentals of TLS, concentrating on the issues that most often confuse app developers. Note The focus of this is TLS-PKI, where PKI stands for public key infrastructure. This is the standard TLS as deployed on the wider Internet. There’s another flavour of TLS, TLS-PSK, where PSK stands for pre-shared key. This has a variety of uses, but an Apple platforms we most commonly see it with local traffic, for example, to talk to a Wi-Fi based accessory. For more on how to use TLS, both TLS-PKI and TLS-PSK, in a local context, see TLS For Accessory Developers. Server Certificates For standard TLS to work the server must have a digital identity, that is, the combination of a certificate and the private key matching the public key embedded in that certificate. TLS Crypto Magic™ ensures that: The client gets a copy of the server’s certificate. The client knows that the server holds the private key matching the public key in that certificate. In a typical TLS handshake the server passes the client a list of certificates, where item 0 is the server’s certificate (the leaf certificate), item N is (optionally) the certificate of the certificate authority that ultimately issued that certificate (the root certificate), and items 1 through N-1 are any intermediate certificates required to build a cryptographic chain of trust from 0 to N. Note The cryptographic chain of trust is established by means of digital signatures. Certificate X in the chain is issued by certificate X+1. The owner of certificate X+1 uses their private key to digitally sign certificate X. The client verifies this signature using the public key embedded in certificate X+1. Eventually this chain terminates in a trusted anchor, that is, a certificate that the client trusts by default. Typically this anchor is a self-signed root certificate from a certificate authority. Note Item N is optional for reasons I’ll explain below. Also, the list of intermediate certificates may be empty (in the case where the root certificate directly issued the leaf certificate) but that’s uncommon for servers in the real world. Once the client gets the server’s certificate, it evaluates trust on that certificate to confirm that it’s talking to the right server. There are three levels of trust evaluation here: Basic X.509 trust evaluation checks that there’s a cryptographic chain of trust from the leaf through the intermediates to a trusted root certificate. The client has a set of trusted root certificates built in (these are from well-known certificate authorities, or CAs), and a site admin can add more via a configuration profile. This step also checks that none of the certificates have expired, and various other more technical criteria (like the Basic Constraints extension). Note This explains why the server does not have to include the root certificate in the list of certificates it passes to the client; the client has to have the root certificate installed if trust evaluation is to succeed. In addition, TLS trust evaluation (per RFC 2818) checks that the DNS name that you connected to matches the DNS name in the certificate. Specifically, the DNS name must be listed in the Subject Alternative Name extension. Note The Subject Alternative Name extension can also contain IP addresses, although that’s a much less well-trodden path. Also, historically it was common to accept DNS names in the Common Name element of the Subject but that is no longer the case on Apple platforms. App Transport Security (ATS) adds its own security checks. Basic X.509 and TLS trust evaluation are done for all TLS connections. ATS is only done on TLS connections made by URLSession and things layered on top URLSession (like WKWebView). In many situations you can override trust evaluation; for details, see Technote 2232 HTTPS Server Trust Evaluation). Such overrides can either tighten or loosen security. For example: You might tighten security by checking that the server certificate was issued by a specific CA. That way, if someone manages to convince a poorly-managed CA to issue them a certificate for your server, you can detect that and fail. You might loosen security by adding your own CA’s root certificate as a trusted anchor. IMPORTANT If you rely on loosened security you have to disable ATS. If you leave ATS enabled, it requires that the default server trust evaluation succeeds regardless of any customisations you do. Mutual TLS The previous section discusses server trust evaluation, which is required for all standard TLS connections. That process describes how the client decides whether to trust the server. Mutual TLS (mTLS) is the opposite of that, that is, it’s the process by which the server decides whether to trust the client. Note mTLS is commonly called client certificate authentication. I avoid that term because of the ongoing industry-wide confusion between certificates and digital identities. While it’s true that, in mTLS, the server authenticates the client certificate, to set this up on the client you need a digital identity, not a certificate. mTLS authentication is optional. The server must request a certificate from the client and the client may choose to supply one or not (although if the server requests a certificate and the client doesn’t supply one it’s likely that the server will then fail the connection). At the TLS protocol level this works much like it does with the server certificate. For the client to provide this certificate it must apply a digital identity, known as the client identity, to the connection. TLS Crypto Magic™ assures the server that, if it gets a certificate from the client, the client holds the private key associated with that certificate. Where things diverge is in trust evaluation. Trust evaluation of the client certificate is done on the server, and the server uses its own rules to decided whether to trust a specific client certificate. For example: Some servers do basic X.509 trust evaluation and then check that the chain of trust leads to one specific root certificate; that is, a client is trusted if it holds a digital identity whose certificate was issued by a specific CA. Some servers just check the certificate against a list of known trusted client certificates. When the client sends its certificate to the server it actually sends a list of certificates, much as I’ve described above for the server’s certificates. In many cases the client only needs to send item 0, that is, its leaf certificate. That’s because: The server already has the intermediate certificates required to build a chain of trust from that leaf to its root. There’s no point sending the root, as I discussed above in the context of server trust evaluation. However, there are no hard and fast rules here; the server does its client trust evaluation using its own internal logic, and it’s possible that this logic might require the client to present intermediates, or indeed present the root certificate even though it’s typically redundant. If you have problems with this, you’ll have to ask the folks running the server to explain its requirements. Note If you need to send additional certificates to the server, pass them to the certificates parameter of the method you use to create your URLCredential (typically init(identity:certificates:persistence:)). One thing that bears repeating is that trust evaluation of the client certificate is done on the server, not the client. The client doesn’t care whether the client certificate is trusted or not. Rather, it simply passes that certificate the server and it’s up to the server to make that decision. When a server requests a certificate from the client, it may supply a list of acceptable certificate authorities [1]. Safari uses this to filter the list of client identities it presents to the user. If you are building an HTTPS server and find that Safari doesn’t show the expected client identity, make sure you have this configured correctly. If you’re building an iOS app and want to implement a filter like Safari’s, get this list using: The distinguishedNames property, if you’re using URLSession The sec_protocol_metadata_access_distinguished_names routine, if you’re using Network framework [1] See the certificate_authorities field in Section 7.4.4 of RFC 5246, and equivalent features in other TLS versions. Self-Signed Certificates Self-signed certificates are an ongoing source of problems with TLS. There’s only one unequivocally correct place to use a self-signed certificate: the trusted anchor provided by a certificate authority. One place where a self-signed certificate might make sense is in a local environment, that is, securing a connection between peers without any centralised infrastructure. However, depending on the specific circumstances there may be a better option. TLS For Accessory Developers discusses this topic in detail. Finally, it’s common for folks to use self-signed certificates for testing. I’m not a fan of that approach. Rather, I recommend the approach described in QA1948 HTTPS and Test Servers. For advice on how to set that up using just your Mac, see TN2326 Creating Certificates for TLS Testing. TLS Standards RFC 6101 The Secure Sockets Layer (SSL) Protocol Version 3.0 (historic) RFC 2246 The TLS Protocol Version 1.0 RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1 RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3 RFC 4347 Datagram Transport Layer Security RFC 6347 Datagram Transport Layer Security Version 1.2 RFC 9147 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision History: 2025-11-21 Clearly defined the terms TLS-PKI and TLS-PSK. 2024-03-19 Adopted the term mutual TLS in preference to client certificate authentication throughout, because the latter feeds into the ongoing certificate versus digital identity confusion. Defined the term client identity. Added the Self-Signed Certificates section. Made other minor editorial changes. 2023-02-28 Added an explanation mTLS acceptable certificate authorities. 2022-12-02 Added links to the DTLS RFCs. 2022-08-24 Added links to the TLS RFCs. Made other minor editorial changes. 2022-06-03 Added a link to TLS For Accessory Developers. 2021-02-26 Fixed the formatting. Clarified that ATS only applies to URLSession. Minor editorial changes. 2020-04-17 Updated the discussion of Subject Alternative Name to account for changes in the 2019 OS releases. Minor editorial updates. 2018-10-29 Minor editorial updates. 2016-11-11 First posted.

Hello Apple Support Team, We are experiencing a performance issue with HTTP/3 in our iOS application during testing. Problem Description: Network requests using HTTP/3 are significantly slower than expected. This issue occurs on both Wi-Fi and 4G networks, with both IPv4 and IPv6. The same setup worked correctly in an earlier experiment. Key Observations: The slowdown disappears when the device uses: · A personal hotspot. · Network Link Conditioner (with no limitations applied). · Internet sharing from a MacBook via USB (where traffic was also inspected with Wireshark without issues). The problem is specific to HTTP/3 and does not occur with HTTP/2. The issue is reproducible on iOS 15, 18.7, and the latest iOS 26 beta. HTTP/3 is confirmed to be active (via assumeHttp3Capable and Alt-Svc header). Crucially, the same backend endpoint works with normal performance on Android devices and using curl with HTTP/3 support from the same network. I've checked the CFNetwork logs in the Console but haven't found any suspicious errors or obvious clues that explain the slowdown. We are using a standard URLSession with basic configuration. Attempted to collect qlog diagnostics by setting the QUIC_LOG_DIRECTORY=~/ tmp environment variable, but the logs were not generated. Question: What could cause HTTP/3 performance to improve only when the device is connected through a hotspot, unrestricted Network Link Conditioner, or USB-tethered connection? The fact that Android and curl work correctly points to an issue specific to the iOS network stack. Are there known conditions or policies (e.g., related to network interface handling, QoS, or specific packet processing) that could lead to this behavior? Additionally, why might the qlog environment variable fail to produce logs, and are there other ways to obtain detailed HTTP/3 diagnostic information from iOS? Any guidance on further diagnostic steps or specific system logs to examine would be greatly appreciated. Thank you for your assistance.

Satellite Communication framework, experiences a failure in receiving network path updates when a device transitions from Satellite to a fringe LTE area. The iOS Status Bar correctly updates to show "LTE," but our application does not receive the corresponding network path update (e.g., via NWPathMonitor). This leaves our app UI locked in "Satellite Mode," while the user sees "LTE" in the status bar, causing critical user confusion. Feedback: FB20976940

Device type: iPad Air 11-inch (M3) OS version: iPadOS 26.0.1 Summary: Login is working in all my devices. Login is not working during AppReview Details: I am working in India. Since 2 weeks I am submitting my iOS app in review. I have provided credentials for sign-in. But AppleReviewTeam are getting Error in Login page only. Same credentials are working in My iPhone, Friends's iPhone, Simulators and all devices. I have also tried using VPN with US, and other locations. I am able to login successfully every single time. I tried to check logs in our backend. But there are no logs on time of Review and Error at AppleReview. It means app is not even able to contact backend. We are not using any Geo-Restriction as well. I asked for further details like Ip-address range to check if AWS has added their address in blocklist. AppStoreReviewer won't provide any detail about their VPN. How am i supposed to troubleshoot this issue ? If someone has faced similar kind of issue Your help will be appreciated. Thanks in advance.

Hi everyone, I’ve run into a consistent issue on multiple Apple Vision Pro devices where downloads using URLSessionConfiguration.background are between 4× and 10x slower than when using URLSessionConfiguration.default. This issue is systematic and can easily be reproduced. This only happens on device, in the simulator, both configurations download files at the expected speed with respect to the network speed. Details: Tested on visionOS 26.0.1 and 26.1 (public releases) Reproduced across 2 Vision Pro (currently testing on a third one) Reproduced on 2 different Wi-fi networks (50mb/s and 880mb/s) From my tests this speed issue seems to affects multiple apps on my device: Stobo Vision (our app), Immersive India, Amplium Not server-related (reproduces with Apple CDN, S3, and DigitalOcean) I’ve built a small sample project that makes this easy to reproduce, it downloads a large file (1.1 GB video) using two managers: One with URLSessionConfiguration.default One with URLSessionConfiguration.background You can also try it with your own file url (from an s3 for example) Expected behavior: Background sessions should behave similarly to default sessions in terms of throughput, just as they do in the simulator. To be clear I am comparing both config when running in the foreground, not in the background. Actual behavior: Background sessions on Vision Pro are significantly slower, making them less usable for large file downloads. On this screenshot it's even reaching 27x slower than the expected speed. Default config takes ~97s to download and Background config takes ~2640s. I do now have the fastest internet connection but 44min to download 90.5MB is extremely slow. Has anyone else seen this behavior or found a workaround? Or is this an expected behavior from URLSessionConfiguration.background? If I'm doing something wrong please let me know Repo link: https://github.com/stobo-app/DownloadConfigTesting

Hi there, When running the app, I found on my Firebase Crashlytics, sometimes got error like this when using Wi-Fi: Error Domain=kCFErrorDomainCFNetwork Code=-1009 "(null)" UserInfo={_kCFStreamErrorDomainKey=1, _kCFStreamErrorCodeKey=50, _NSURLErrorNWResolutionReportKey=Resolved 0 endpoints in 1ms using unknown from cache, _NSURLErrorNWPathKey=unsatisfied (Denied over Wi-Fi interface), interface: utun6, ipv4, dns, uses wifi, LQM: unknown} I've run through the threads, found this link, but I think this issue is different on the interface. It would be great there is and idea how to troubleshoot this issue. Thank you.

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

Hello, I have searched here on the forums for "WiFi Aware" and have read through just about every post. In a lot of them the person says they were able to get the example app https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps working with their iOS devices. I, for some reason, am not able to get the example app to fully work. I am able to build the app and load the app onto two physical iPhone 12 minis (both are running iOS 26.0.1). I follow the steps shown at the link share above but I get stuck because I can't get past the "enter this pin code to connect" step. I make one device be a host of a simulation and the other device the viewer of a simulation. On each device I tap the "+" button. On the viewer device I tap the discovered device. On the host device I then see the pin. I then enter the pin on the viewer device. After this step nothing happens. My only choice on the viewer device is to tap "cancel" and exit the "enter the pin step". If I go into the actual device settings (Settings -> Privacy & Security -> Paired Devices) I see that the devices are "paired" but the app doesn't seem to think so. Are there some special settings I need to turn on for the app to work properly? In an attempt to figure out what was going wrong I took the example app and paired it down to just send back simple messages based on user button taps. These are my logs from when I start up the app and start one device as the hoster and one as the viewer. Selected Mode: Hoster Start NetworkListener [L1 ready, local endpoint: <NULL>, parameters: udp, traffic class: 700, interface: nan0, local: ::.0, definite, attribution: developer, server, port: 62182, path satisfied (Path is satisfied), interface: nan0[802.11], ipv4, uses wifi, LQM: unknown, service: com.example.apple-samplecode.Wi-FiAwareSample8B4DX93M9J._sat-simulation._udp scope:0 route:0 custom:107]: waiting(POSIXErrorCode(rawValue: 50): Network is down) [L1 ready, local endpoint: <NULL>, parameters: udp, traffic class: 700, interface: nan0, local: ::.0, definite, attribution: developer, server, port: 62182, path satisfied (Path is satisfied), interface: nan0[802.11], ipv4, uses wifi, LQM: unknown, service: com.example.apple-samplecode.Wi-FiAwareSample8B4DX93M9J._sat-simulation._udp scope:0 route:0 custom:107]: ready [L1 failed, local endpoint: <NULL>, parameters: udp, traffic class: 700, interface: nan0, local: ::.0, definite, attribution: developer, server, port: 62182, path satisfied (Path is satisfied), interface: nan0[802.11], ipv4, uses wifi, LQM: unknown, service: com.example.apple-samplecode.Wi-FiAwareSample8B4DX93M9J._sat-simulation._udp scope:0 route:0 custom:107]: failed(-11992: Wi-Fi Aware) nw_listener_cancel_block_invoke [L1] Listener is already cancelled, ignoring cancel nw_listener_cancel_block_invoke [L1] Listener is already cancelled, ignoring cancel nw_listener_cancel_block_invoke [L1] Listener is already cancelled, ignoring cancel Networking failed: -11992: Wi-Fi Aware Error acquiring assertion: <Error Domain=RBSAssertionErrorDomain Code=2 "Could not find attribute name in domain plist" UserInfo={NSLocalizedFailureReason=Could not find attribute name in domain plist}> <0x105e35400> Gesture: System gesture gate timed out. Selected Mode: Viewer Start NetworkBrowser [B1 <nw_browse_descriptor application_service _sat-simulation._udp bundle_id=com.example.apple-samplecode.Wi-FiAwareSample8B4DX93M9J device_types=7f device_scope=ff custom:109>, generic, interface: nan0, attribution: developer]: ready nw_browser_update_path_browser_locked Received browser Wi-Fi Aware nw_browser_cancel [B1] The browser has already been cancelled, ignoring nw_browser_cancel(). [B1 <nw_browse_descriptor application_service _sat-simulation._udp bundle_id=com.example.apple-samplecode.Wi-FiAwareSample8B4DX93M9J device_types=7f device_scope=ff custom:109>, generic, interface: nan0, attribution: developer]: failed(-11992: Wi-Fi Aware) nw_browser_cancel [B1] The browser has already been cancelled, ignoring nw_browser_cancel(). Networking failed: -11992: Wi-Fi Aware Error acquiring assertion: <Error Domain=RBSAssertionErrorDomain Code=2 "Could not find attribute name in domain plist" UserInfo={NSLocalizedFailureReason=Could not find attribute name in domain plist}> This guy stands out to me Networking failed: -11992: Wi-Fi Aware but I can't find any info on what it means. Thank you

I am seeking assistance with how to properly handle / save / reuse NWConnections when it comes to the NWBrowser vs NWListener. Let me give some context surrounding why I am trying to do what I am. I am building an iOS app that has peer to peer functionality. The design is for a user (for our example the user is Bob) to have N number of devices that have my app installed on it. All these devices are near each other or on the same wifi network. As such I want all the devices to be able to discover each other and automatically connect to each other. For example if Bob had three devices (A, B, C) then A discovers B and C and has a connection to each, B discovers B and C and has a connection to each and finally C discovers A and B and has a connection to each. In the app there is a concept of a leader and a follower. A leader device issues commands to the follower devices. A follower device just waits for commands. For our example device A is the leader and devices B and C are followers. Any follower device can opt to become a leader. So if Bob taps the “become leader” button on device B - device B sends out a message to all the devices it’s connected to telling them it is becoming the new leader. Device B doesn’t need to do anything but device A needs to set itself as a follower. This detail is to show my need to have everyone connected to everyone. Please note that I am using .includePeerToPeer = true in my NWParameters. I am using http/3 and QUIC. I am using P12 identity for TLS1.3. I am successfully able to verify certs in sec_protocal_options_set_verify_block. I am able to establish connections - both from the NWBrowser and from NWListener. My issue is that it’s flaky. I found that I have to put a 3 second delay prior to establishing a connection to a peer found by the NWBrowser. I also opted to not save the incoming connection from NWListener. I only save the connection I created from the peer I found in NWBrowser. For this example there is Device X and Device Y. Device X discovers device Y and connects to it and saves the connection. Device Y discovers device X and connects to it and saves the connection. When things work they work great - I am able to send messages back and forth. Device X uses the saved connection to send a message to device Y and device Y uses the saved connection to send a message to device X. Now here come the questions. Do I save the connection I create from the peer I discovered from the NWBrowser? Do I save the connection I get from my NWListener via newConnectionHandler? And when I save a connection (be it from NWBrowser or NWListener) am I able to reuse it to send data over (ie “i am the new leader command”)? When my NWBrowser discovers a peer, should I be able to build a connection and connect to it immediately? I know if I save the connection I create from the peer I discover I am able to send messages with it. I know if I save the connection from NWListener - I am NOT able to send messages with it — but should I be able to? I have a deterministic algorithm for who makes a connection to who. Each device has an ID - it is a UUID I generate when the app loads - I store it in UserDefaults and the next time I try and fetch it so I’m not generating new UUIDs all the time. I set this deviceID as the name of the NWListener.Service I create. As a result the peer a NWBrowser discovers has the deviceID set as its name. Due to this the NWBrowser is able to determine if it should try and connect to the peer or if it should not because the discovered peer is going to try and connect to it. So the algorithm above would be great if I could save and use the connection from NWListener to send messages over.

I've had a Unreal Engine project that uses libwebsocket to make a websocket connection with SSL to a server. Recently I made a build using Unreal Engine 5.4.4 on MacOS Sequoia 15.5 and XCode 16.4 and for some reason the websocket connection now fails because it can't get the local issuer certificate. It fails to access the root certificate store on my device (Even though, running the project in the Unreal Editor works fine, it's only when making a packaged build with XCode that it breaks) I am not sure why this is suddenly happening now. If I run it in the Unreal editor on my macOS it works fine and connects. But when I make a packaged build which uses XCode to build, it can't get the local issuer certificate. I tried different code signing options, such as sign to run locally or just using sign automatically with a valid team, but I'm not sure if code signing is the cause of this issue or not. This app is only for development and not meant to be published, so that's why I had been using sign to run locally, and that used to work fine but not anymore. Any guidance would be appreciated, also any information on what may have changed that now causes this certificate issue to happen. I know Apple made changes and has made notarizing MacOS apps mandatory, but I'm not sure if that also means a non-notarized app will now no longer have access to the root certificate store of a device, in my research I haven't found anything about that specifically, but I'm wondering if any Apple engineers might know something about this that hasn't been put out publicly.

Hello everyone, We are currently facing an issue when testing our hybrid mobile application (built with Ionic and Angular) on the iOS Simulator. The app works perfectly on physical iOS devices — all HTTP requests complete successfully. However, when running the same build on the iOS Simulator, every HTTP request fails with the following error: { "headers": { "normalizedNames": {}, "lazyUpdate": null, "headers": {} }, "status": 0, "statusText": "Unknown Error", "url": "https://api.bizify.com.br/demo/api/ping", "ok": false, "name": "HttpErrorResponse", "message": "Http failure response for https://api.bizify.com.br/demo/api/ping: 0 Unknown Error", "error": { "isTrusted": true } } We have confirmed that the API endpoint https://api.bizify.com.br/demo/api/ping is reachable and secured with a valid SSL certificate. This issue occurs only in the iOS Simulator — not on Android devices or physical iOS devices. Has anyone encountered this issue before? Any insights on why the iOS Simulator might be blocking or failing these HTTPS requests — and how we could resolve it — would be greatly appreciated.

Is there a way to create a data roaming or cellular profile or shortcut so that we can turn data off for certain sets of apps when we travel (and turn them all back on when we're back)?

Our iOS/iPad app is built with React Native. We use Axios as our HTTP client. Our app has been out on the app store for 2+ years and we've never had issues with reviews. Since iOS 26 came out, our app has been constantly getting rejected because the Apple tester keeps facing network timeout issues when our app makes requests to our API services. Our API stack is already configured to support IPv6 networks, and our regular user base does not run into the issues the Apple tester is seeing. None of our developers nor our internal testers have been able to reproduce the issue the Apple tester is facing. We've tried a number of things to debug the potential issue: Added a ping check on app startup. We used the native fetch present in React Native apps as well as our Axios client (with the default XHR/HTTP adapter). None of the pings make it to our API services. Added higher timeouts on app startup to let the Apple tester have more time to reach our services while their simulator device is able to connect. We've read that the environment that Apple testers use can sometimes take longer to establish an initial connection, even though packages like NetInfo from React Native report that they are connected to WiFi as soon as the app starts. Switched our Axios client adapter to use the native fetch. We did this since we noticed that Mixpanel, our tracking library, uses the native fetch in their React Native SDK and we've confirmed that requests on their end do make it through when the Apple tester is testing our app. We're running out of ideas since the issue is pretty obscure and we haven't been able to reproduce it yet, not even by following the Apple guide to set up a local IPv6 NAT64 network to be as close to their environment as possible. We've also tried testing the app while connected to VPNs from different locations to no avail. Like I said before, we noticed that this issues started for the Apple tester with the release of iOS 26, so we're wondering if there are known issues in the community that might relate to what we're experiencing. The most recent finding we've made is that some other developers report new issues with HTTP 3/QUIC on iOS. We've seen recommendations about turning off explicit support for HTTP 3 on our services, which seems to have helped other developers.

For important background information, read Extra-ordinary Networking before reading this. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Working with a Wi-Fi Accessory Building an app that works with a Wi-Fi accessory presents specific challenges. This post discusses those challenges and some recommendations for how to address them. Note While my focus here is iOS, much of the info in this post applies to all Apple platforms. IMPORTANT iOS 18 introduced AccessorySetupKit, a framework to simplify the discovery and configuration of an accessory. I’m not fully up to speed on that framework myself, but I encourage you to watch WWDC 2024 Session 10203 Meet AccessorySetupKit and read the framework documentation. IMPORTANT iOS 26 introduced WiFiAware, a framework for setting up communication with Wi-Fi Aware accessories. Wi-Fi Aware is an industry standard to securely discover, pair, and communicate with nearby devices. This is especially useful for stand-alone accessories (defined below). For more on this framework, watch WWDC 2025 Session 228 Supercharge device connectivity with Wi-Fi Aware and read the framework documentation. For information on how to create a Wi-Fi Aware accessory that works with iPhone, go to Developer > Accessories, download Accessory Design Guidelines for Apple Devices, and review the Wi-Fi Aware chapter. Accessory Categories I classify Wi-Fi accessories into three different categories. A bound accessory is ultimately intended to join the user’s Wi-Fi network. It may publish its own Wi-Fi network during the setup process, but the goal of that process is to get the accessory on to the existing network. Once that’s done, your app interacts with the accessory using ordinary networking APIs. An example of a bound accessory is a Wi-Fi capable printer. A stand-alone accessory publishes a Wi-Fi network at all times. An iOS device joins that network so that your app can interact with it. The accessory never provides access to the wider Internet. An example of a stand-alone accessory is a video camera that users take with them into the field. You might want to write an app that joins the camera’s network and downloads footage from it. A gateway accessory is one that publishes a Wi-Fi network that provides access to the wider Internet. Your app might need to interact with the accessory during the setup process, but after that it’s useful as is. An example of this is a Wi-Fi to WWAN gateway. Not all accessories fall neatly into these categories. Indeed, some accessories might fit into multiple categories, or transition between categories. Still, I’ve found these categories to be helpful when discussing various accessory integration challenges. Do You Control the Firmware? The key question here is Do you control the accessory’s firmware? If so, you have a bunch of extra options that will make your life easier. If not, you have to adapt to whatever the accessory’s current firmware does. Simple Improvements If you do control the firmware, I strongly encourage you to: Support IPv6 Implement Bonjour [1] These two things are quite easy to do — most embedded platforms support them directly, so it’s just a question of turning them on — and they will make your life significantly easier: Link-local addresses are intrinsic to IPv6, and IPv6 is intrinsic to Apple platforms. If your accessory supports IPv6, you’ll always be able to communicate with it, regardless of how messed up the IPv4 configuration gets. Similarly, if you support Bonjour, you’ll always be able to find your accessory on the network. [1] Bonjour is an Apple term for three Internet standards: RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses RFC 6762 Multicast DNS RFC 6763 DNS-Based Service Discovery WAC For a bound accessory, support Wireless Accessory Configuration (WAC). This is a relatively big ask — supporting WAC requires you to join the MFi Program — but it has some huge benefits: You don’t need to write an app to configure your accessory. The user will be able to do it directly from Settings. If you do write an app, you can use the EAWiFiUnconfiguredAccessoryBrowser class to simplify your configuration process. HomeKit For a bound accessory that works in the user’s home, consider supporting HomeKit. This yields the same onboarding benefits as WAC, and many other benefits as well. Also, you can get started with the HomeKit Open Source Accessory Development Kit (ADK). Bluetooth LE If your accessory supports Bluetooth LE, think about how you can use that to improve your app’s user experience. For an example of that, see SSID Scanning, below. Claiming the Default Route, Or Not? If your accessory publishes a Wi-Fi network, a key design decision is whether to stand up enough infrastructure for an iOS device to make it the default route. IMPORTANT To learn more about how iOS makes the decision to switch the default route, see The iOS Wi-Fi Lifecycle and Network Interface Concepts. This decision has significant implications. If the accessory’s network becomes the default route, most network connections from iOS will be routed to your accessory. If it doesn’t provide a path to the wider Internet, those connections will fail. That includes connections made by your own app. Note It’s possible to get around this by forcing your network connections to run over WWAN. See Binding to an Interface in Network Interface Techniques and Running an HTTP Request over WWAN. Of course, this only works if the user has WWAN. It won’t help most iPad users, for example. OTOH, if your accessory’s network doesn’t become the default route, you’ll see other issues. iOS will not auto-join such a network so, if the user locks their device, they’ll have to manually join the network again. In my experience a lot of accessories choose to become the default route in situations where they shouldn’t. For example, a bound accessory is never going to be able to provide a path to the wider Internet so it probably shouldn’t become the default route. However, there are cases where it absolutely makes sense, the most obvious being that of a gateway accessory. Acting as a Captive Network, or Not? If your accessory becomes the default route you must then decide whether to act like a captive network or not. IMPORTANT To learn more about how iOS determines whether a network is captive, see The iOS Wi-Fi Lifecycle. For bound and stand-alone accessories, becoming a captive network is generally a bad idea. When the user joins your network, the captive network UI comes up and they have to successfully complete it to stay on the network. If they cancel out, iOS will leave the network. That makes it hard for the user to run your app while their iOS device is on your accessory’s network. In contrast, it’s more reasonable for a gateway accessory to act as a captive network. SSID Scanning Many developers think that TN3111 iOS Wi-Fi API overview is lying when it says: iOS does not have a general-purpose API for Wi-Fi scanning It is not. Many developers think that the Hotspot Helper API is a panacea that will fix all their Wi-Fi accessory integration issues, if only they could get the entitlement to use it. It will not. Note this comment in the official docs: NEHotspotHelper is only useful for hotspot integration. There are both technical and business restrictions that prevent it from being used for other tasks, such as accessory integration or Wi-Fi based location. Even if you had the entitlement you would run into these technical restrictions. The API was specifically designed to support hotspot navigation — in this context hotspots are “Wi-Fi networks where the user must interact with the network to gain access to the wider Internet” — and it does not give you access to on-demand real-time Wi-Fi scan results. Many developers look at another developer’s app, see that it’s displaying real-time Wi-Fi scan results, and think there’s some special deal with Apple that’ll make that work. There is not. In reality, Wi-Fi accessory developers have come up with a variety of creative approaches for this, including: If you have a bound accessory, you might add WAC support, which makes this whole issue go away. In many cases, you can avoid the need for Wi-Fi scan results by adopting AccessorySetupKit. You might build your accessory with a barcode containing the info required to join its network, and scan that from your app. This is the premise behind the Configuring a Wi-Fi Accessory to Join the User’s Network sample code. You might configure all your accessories to have a common SSID prefix, and then take advantage of the prefix support in NEHotspotConfigurationManager. See Programmatically Joining a Network, below. You might have your app talk to your accessory via some other means, like Bluetooth LE, and have the accessory scan for Wi-Fi networks and return the results. Programmatically Joining a Network Network Extension framework has an API, NEHotspotConfigurationManager, to programmatically join a network, either temporarily or as a known network that supports auto-join. For the details, see Wi-Fi Configuration. One feature that’s particularly useful is it’s prefix support, allowing you to create a configuration that’ll join any network with a specific prefix. See the init(ssidPrefix:) initialiser for the details. For examples of how to use this API, see: Configuring a Wi-Fi Accessory to Join the User’s Network — It shows all the steps for one approach for getting a non-WAC bound accessory on to the user’s network. NEHotspotConfiguration Sample — Use this to explore the API in general. Secure Communication Users expect all network communication to be done securely. For some ideas on how to set up a secure connection to an accessory, see TLS For Accessory Developers. Revision History 2025-11-05 Added a link to the Accessory Design Guidelines for Apple Devices. 2025-06-19 Added a preliminary discussion of Wi-Fi Aware. 2024-09-12 Improved the discussion of AccessorySetupKit. 2024-07-16 Added a preliminary discussion of AccessorySetupKit. 2023-10-11 Added the HomeKit section. Fixed the link in Secure Communication to point to TLS For Accessory Developers. 2023-07-23 First posted.

Hello, I understand that to discover and pair a device or accessory with Wi-Fi Aware, we can use either the DeviceDiscoveryUI or AccessorySetupKitUI frameworks. During the pairing process, both frameworks prompt the user to enter a pairing code. Is this step mandatory? What alternatives exist for devices or accessories that don't have a way to communicate a pairing code to the user (for example, devices or accessories without a display or voice capability)? Best regards, Gishan

Getting -10985 error from urlSession while attempting to make a connection. Not sure why this is happening if anyone is aware please help

My app attempts to upload events and logging data when the user backgrounds the app (i.e., when applicationDidEnterBackground is triggered) by creating an uploadTask using a URLSession with a URLSessionConfiguration.background. When uploading these events after being backgrounded, we call beginBackgroundTask on UIApplication, which gives us about 25-30 seconds before the expirationHandler gets triggered. I am noticing, however, that the expirationHandler is frequently called and no upload attempts have even started. This might be reasonable if, for example, I had other uploads in progress initiated prior to backgrounding, but this is not the case. Could someone confirm that, when initiating an uploadTask while the app is backgrounded using a backgroundSession, there's really no way to predict when that upload is going to begin? My observation is that about 10-20% of the time it does not begin within 20 seconds of backgrounding, and I have many events coming from clients in the field showing as much.

Network.framework: Happy Eyeballs cancels also-ran only after WebSocket handshake (duplicate WS sessions) Hi everyone 👋 When using NWConnection with NWProtocolWebSocket, I’ve noticed that Happy Eyeballs cancels the losing connection only after the WebSocket handshake completes on the winning path. As a result, both IPv4 and IPv6 attempts can send the GET / Upgrade request in parallel, which may cause duplicate WebSocket sessions on the server. Standards context RFC 8305 §6 (Happy Eyeballs v2) states: Once one of the connection attempts succeeds (generally when the TCP handshake completes), all other connections attempts that have not yet succeeded SHOULD be canceled. This “SHOULD” is intentionally non-mandatory — implementations may reasonably delay cancellation to account for additional factors (e.g. TLS success or ALPN negotiation). So Network.framework’s current behavior — canceling after the WebSocket handshake — is technically valid, but it can have practical side effects at the application layer. Why this matters WebSocket upgrades are semantically HTTP GET requests (RFC 6455 §4.1). Per RFC 9110 §9.2, GET requests are expected to be safe and idempotent — they should not have side effects on the server. In practice, though, WebSocket upgrades often: include Authorization headers or cookies create authenticated or persistent sessions So if both IPv4 and IPv6 paths reach the upgrade stage, the server may create duplicate sessions before one connection is canceled. Questions / Request Is there a way to make Happy Eyeballs cancel the losing path earlier — for example, right after TCP or TLS handshake — when using NWProtocolWebSocket? If not, could Apple consider adding an option (e.g. in NWProtocolWebSocket.Options) to control the cancellation threshold, such as: after TCP handshake after TLS handshake after protocol handshake (current behavior) That would align the implementation more closely with RFC 8305 and help prevent duplicate, non-idempotent upgrade requests. Context I’m aware of Quinn’s post Understanding Also-Ran Connections. This report focuses specifically on the cancellation timing for NWProtocolWebSocket and the impact of duplicate upgrade requests. Although RFC 6455 and RFC 9110 define WebSocket upgrades as safe and idempotent HTTP GETs, in practice they often establish authenticated or stateful sessions. Thus, delaying cancellation until after the upgrade can create duplicate sessions — even though the behavior is technically RFC-compliant. Happy to share a sysdiagnose and sample project via Feedback if helpful. Thanks! 🙏 Example log output With Network Link Conditioner (Edge): log stream --info --predicate 'subsystem == "com.apple.network" && process == "WS happy eyeballs"' 2025-11-03 17:02:48.875258 [C3] create connection to wss://echo.websocket.org:443 2025-11-03 17:02:48.878949 [C3.1] starting child endpoint 2a09:8280:1::37:b5c3:443 # IPv6 2025-11-03 17:02:48.990206 [C3.1] starting child endpoint 66.241.124.119:443 # IPv4 2025-11-03 17:03:00.251928 [C3.1.1] Socket received CONNECTED event # IPv6 TCP up 2025-11-03 17:03:00.515837 [C3.1.2] Socket received CONNECTED event # IPv4 TCP up 2025-11-03 17:03:04.543651 [C3.1.1] Output protocol connected (WebSocket) # WS ready on IPv6 2025-11-03 17:03:04.544390 [C3.1.2] nw_endpoint_handler_cancel # cancel IPv4 path 2025-11-03 17:03:04.544913 [C3.1.2] TLS warning: close_notify # graceful close IPv4

I am trying to communicate with the backend of my project. So I need to install the certificate into the simulator. I have the .pem file but when I drag-dropped it into the simulator, I got the error "Simulator device failed to complete the requested operation.". The simulator is an iPhone 16 Pro running iOS 18.5. Is there any way to install the cert to my simulator? PS: I can't use Apple Configurator or MDM because I am using the office's Mac. And I can't install anything there. So I can only do it manually.

My application (using a nested framework for networking) was working correctly on iPadOS 18, but failed to perform a UDP broadcast operation after upgrading the device to iPadOS 26. The low-level console logs consistently show a "Permission denied" error. Symptoms & Error Message: When attempting to send a UDP broadcast packet using NWConnection (or a similar low-level socket call within the framework), the connection fails immediately with the following error logged in the console: nw_socket_service_writes_block_invoke [C2:1] sendmsg(fd 6, 124 bytes) [13: Permission denied] (Error code 13 corresponds to EACCES). Verification Steps (What I have checked): Multicast Networking Entitlement is Approved and Applied: The necessary entitlement (com.apple.developer.networking.multicast) was granted by Apple. The Provisioning Profile used for signing the Host App Target has been regenerated and explicitly includes "Multicast Networking" capability (see attached screenshot). I confirmed that Entitlements cannot be added directly to the Framework Target, only the Host App Target, which is the expected behavior. Local Network Privacy is Configured: The Host App's Info.plist contains the NSLocalNetworkUsageDescription key with a clear usage string. Crucially, the Local Network Access alert does not reliably appear when the Broadcast function is first called (despite a full reinstall after OS upgrade). Even when Local Network Access is manually enabled in Settings, the Broadcast still fails with EACCES. Code Implementation: The Broadcast is attempted using NWConnection to the host 255.255.255.255 on a specific port. Request: Since all required entitlements and profiles are correct, and the failure is a low-level EACCES on a newly updated OS version, I suspect this may be a regression bug in the iPadOS 26 security sandbox when validating the Multicast Networking Entitlement against a low-level socket call (like sendmsg). Has anyone else encountered this specific Permission denied error on iPadOS 26 with a valid Multicast Entitlement, and is there a known workaround aside from switching to mDNS/Bonjour?