General:
TN3151 Choosing the right networking API
Networking Overview document — Despite the fact that this is in the archive, this is still really useful.
TLS for App Developers DevForums post
Choosing a Network Debugging Tool documentation
WWDC 2019 Session 712 Advances in Networking, Part 1 — This explains the concept of constrained networking, which is Apple’s preferred solution to questions like How do I check whether I’m on Wi-Fi?
TN3135 Low-level networking on watchOS
Adapt to changing network conditions tech talk
Foundation networking:
DevForums tags: Foundation, CFNetwork
URL Loading System documentation — NSURLSession, or URLSession in Swift, is the recommended API for HTTP[S] on Apple platforms.
Network framework:
DevForums tag: Network
Network framework documentation — Network framework is the recommended API for TCP, UDP, and QUIC on Apple platforms.
Network Extension (including Wi-Fi on iOS):
See Network Extension Resources
Wi-Fi Fundamentals
Wi-Fi on macOS:
DevForums tag: Core WLAN
Core WLAN framework documentation
Wi-Fi Fundamentals
Secure networking:
DevForums tags: Security
Apple Platform Security support document
Preventing Insecure Network Connections documentation — This is all about App Transport Security (ATS).
Available trusted root certificates for Apple operating systems support article
Requirements for trusted certificates in iOS 13 and macOS 10.15 support article
About upcoming limits on trusted certificates support article
Apple’s Certificate Transparency policy support article
Technote 2232 HTTPS Server Trust Evaluation
Technote 2326 Creating Certificates for TLS Testing
QA1948 HTTPS and Test Servers
Miscellaneous:
More network-related DevForums tags: 5G, QUIC, Bonjour
On FTP DevForums post
Using the Multicast Networking Additional Capability DevForums post
Investigating Network Latency Problems DevForums post
Local Network Privacy FAQ DevForums post
Extra-ordinary Networking DevForums post
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Network
RSS for tagNetwork connections send and receive data using transport and security protocols.
Posts under Network tag
200 Posts
Sort by:
Post
Replies
Boosts
Views
Activity
Hi, I've noticed a weird behavior happening on Sequoia with DF bit:
On machine where SIP is disabled, when I do /sbin/ping -D -s 1400 8.8.8.8 I do see the DF bit in wireshark
On machine where SIP is enabled, when I do /sbin/ping -D -s 1400 8.8.8.8 I do not see the DF bit in wireshark
The -D flag should set the DF bit but for some reason it doesn’t if the SIP is enabled.
Perhaps there was any change in permission/entitlements mechanism in Sequoia that can explain it ? I'm using the built-in ping command so maybe it should be signed with more entitlements ?
Swift recently added support for Int128. However, they do need NOT seem to be supported in SwiftData. Now totally possible I'm doing something wrong too.
I have the project set to macOS 15 to use a UInt128 in @Model class as attribute. I tried using a clean Xcode project with Swift Data choosen in the macOS app wizard.
Everything compiles, but it fails at runtime in both my app and "Xcode default" SwiftData:
SwiftData/SchemaProperty.swift:380: Fatal error: Unexpected property within Persisted Struct/Enum: Builtin.Int128
with the only modification to from stock is:
@Model
final class Item {
var timestamp: Date
var ipv6: UInt128
init(timestamp: Date) {
self.timestamp = timestamp
self.ipv6 = 0
}
}
I have tried both Int128 and UInt128. Both fails exactly the same. In fact, so exactly, when using UInt128 it still show a "Int128" in error message, despite class member being UInt128 .
My underlying need is to store an IPv6 addresses with an app, so the newer UInt128 would work to persist it. Since Network Framework IPv6Address is also not compatible, it seems, with SwiftData. So not a lot of good options, other an a String. But for an IPv6 address that suffers from that same address can take a few String forms (i.e. "0000:0000:0000:0000:0000:0000:0000:0000" =="0:0:0:0:0:0:0:0" == "::") which is more annoying than having a few expand Int128 as String separator ":".
Ideas welcomed. But potentially a bug in SwiftData since Int128 is both a Builtin and conforms to Codable, so from my reading it should work.
Hello Apple Developer Team,
Based on the mandate to update the APNs certificate by February 24, 2025 for certificate-based authentication, a question from the team has been brought up that maybe Apple or the community can help answer. Since our implementation uses token-based authentication, I’m seeking clarification on a couple of points:
1. Does the certificate update affect token-based connections at all?
2. What is the rationale behind updating certificates for certificate-based authentication, and are there any implications or benefits for developers using token-based authentication?
Understanding these details will help us ensure our system remains compliant and optimally configured. Any guidance or further clarification you can provide would be greatly appreciated.
Thank you!
Hi Everyone,
I’m working on a communication system for my app using NWConnection with the UDP protocol. The connection is registered to a custom serial dispatch queue. However, I’m trying to understand what the behavior will be in a scenario where the connection is canceled while there are still pending receive operations in progress.
Scenario Overview:
The sender is transmitting n = 100 packets to the receiver, out of which 40 packets have already been sent (i.e., delivered to the Receiver).
The receiver has posted m = 20 pending receive operations, where each receive operation is responsible for handling one packet.
The receiver has already successfully processed x = 10 packets.
At the time of cancellation, the receiver’s buffer still holds m = 20 packets that are pending for processing, and k = 10 pending receive callbacks are in the dispatch queue, waiting to be executed.
At same time when the 10th packet was processed another thread triggers .cancel() on this accepted NWConnection (on the receiver side), I need to understand the impact on the pending receive operations and their associated callbacks.
My Questions:
What happens to the k = 10 pending receive callbacks that are in the dispatch queue waiting to be triggered when the connection is canceled? Will these callbacks complete successfully and process the data? Or, because the connection is canceled, will they complete with failure?
What happens to the remaining pending receive operations that were initiated but have not yet been scheduled in the dispatch queue? For the pending receive operations that were already initiated (i.e., the network stack is waiting to receive the data, but the callback hasn’t been scheduled yet), will they fail immediately when the connection is canceled? Or is there any chance that the framework might still process these receives before the cancellation fully takes effect?
We have a requirement to create a production quality application that also acts as HTTPS server for certain communication.
The preference is for the server to support HTTP/1.1, HTTP/2 and HTTP/3 communication asynchronously, though not mandatory to support all the HTTP versions. Wanted to get the guidance, on which stack should be used, that is most reliable and that gives the maximum long term compatibility, sustainability and reliability.
What is the recommended 'in-built' or 'available by default' stack on Apple Platform ?
For HTTPS on HTTP/1.1 with synchronous mode operations ?
For HTTPS on HTTP/1.1 with asynchronous mode operations ?
For HTTPS on HTTP/2 with synchronous mode operations ?
For HTTPS on HTTP/2 with asynchronous mode operations ?
For HTTPS on HTTP/3 with asynchronous mode operations ?
For HTTPS on HTTP/1.1 + HTTP/2 with synchronous mode operations ?
For HTTPS on HTTP/1.1 + HTTP/2 with asynchronous mode operations ?
For HTTPS on HTTP/1.1 + HTTP/2 + HTTP/3 with asynchronous mode operations ?
What the generally recommended server stack that a typical application uses whether 'in-built' or 'available by default on Apple ' or 'not-available by default on Apple' stack.
From the available stacks , we tried to evaluate the below stacks:
https://opensource.apple.com/projects/swiftnio/ : We understand that while it’s not preinstalled as part of Apple's OSes, it is an official Swift package supported by Apple and can easily be added to your project. At the moment it supports HTTP/1.1 and HTTP/2. The link https://github.com/apple/swift-nio/issues/1730says that HTTP/3 will get added in the future.
Is there any other HTTPS stack (built-in or third-party) that is recommended to the used on Apple's platform ? Our application is expected to be working on macOS, iOS, iPadOS, tvOS and watchOS.
We understand that macOS also includes Apache HTTPD server. As our application is not primarily a Web Server (and also supports other protocols both in client and server mode), it looks integrating HTTPS directly into the application using a lightweight HTTP library with SSL/TLS support is a better option, in place of Apache HTTPD.
From the document we know that swift-nio uses BoringSSL (swift-nio-ssl) which is prepackaged along with the swift-nio library, and it does not use the default Secure Transport. What is the reason being not using Secure Transport ? Now does it become the responsibility of the application using swift-nio to take care of updating BoringSSL with the patches.
I am trying to programmatically block some egress and ingress connections using bsd packet filters. My program writes rules in a file and this file is loaded using an anchor in /etc/pf.conf (main ruleset) . Rules work as intended. But when there is network change like turn on/off wifi , and change in wifi nw the main ruleset is getting flushed and i have to reapply (pfctl -q -f /etc/pf.conf) to get the rules back in place.
Looking for guidance to keep the main ruleset intact irrespective of system changes.
I am developing an Xcode app with a job feed, with profile view, with chat eg. I fetch using federatet queries to my microservices thru Apollo Router. Infront of the Apollo Router i Have a Kong that adds a X user ID, that the microservices use for personalized feed and other user info. The info is stored with SwiftData. My thought is that i should add a better way of controlling when i need to fetch. I have a “lastupdateAPI” with different entities (profile, profile picture eg). So when nothing has changed we do not fetch. But rather then using a own API for this, isnt ETag better? Or is it any other recommendations with Xcode Swiftui. Good strategies for not fetching what i already have?
Reproduce:
Download live-caller-id-lookup-example
Add
let url = URL(string: "http://another-macbook.local:80")!
let task = URLSession.shared.dataTask(with: url) {(data, response, error) in
guard let data = data else { return }
print(String(data: data, encoding: .utf8)!)
}
task.resume()
anywhere in the code
run PIRService target in xcode
Result: no dialogue, host is unreachable
Works fine when launching same binary from terminal
We have encountered an issue with the app where it fails to progress beyond the splash screen. Interestingly, the problem seems to resolve itself after either reinstalling the app or restarting the phone. This behavior is observed specifically in version 18.3.1.
Could this issue be related to a network connection or initialization problem in this version? Any insights or recommendations would be appreciated.
Thank you for your assistance!
I am currently developing an app using WKWebView.
In iOS 17, Apple introduced ProxyConfiguration, and I have two questions regarding its usage:
Is there a way to use ProxyConfiguration to distinguish between HTTP and HTTPS traffic?
I have reviewed the documentation but couldn’t find a clear method for this.
As an alternative approach, I am attempting to determine the request scheme within WKWebView and switch proxyConfigurations just before loading the request.
My current implementation sends requests to hoge_a by default and switches to hoge_b only for HTTP traffic.
if #available(iOS 17.0, *) {
if URLString.contains("http:") {
webView.configuration.websiteDataStore.proxyConfigurations = [hoge_b]
}
}
webView.load(request)
if #available(iOS 17.0, *) {
if URLString.contains("http:") {
webView.configuration.websiteDataStore.proxyConfigurations = [hoge_a]
}
}
2. Since I modify proxyConfigurations every time webView.load(request) is called, are there any potential issues or concerns with this approach?
I would appreciate any insights you may have on either of these questions.
When installing a new version the app while a tunnel is connected, seemingly the old packet tunnel process gets stopped but the new one does not come back up. Reportedly, a path monitor is reporting that the device has no connectivity. Is this the expected behavior?
When installing an update from TestFlight or the App store, the packet tunnel instance from the old tunnel is stopped, but, due to the profile being on-demand and incldueAllNetworks, the path monitoring believes the device has no connectivity - so the new app is never downloaded. Is this the expected behavior?
During development, the old packet tunnel gets stopped, the new app is installed, but the new packet tunnel is never started. To start it, the user has to toggle the VPN twice from the Settings app. The tunnel could be started from the VPN app too, if we chose to not take the path monitor into account, but then the user still needs to attempt to start the tunnel twice - it only works on the second try. As far as we can tell, the first time around, the packet tunnel never gets started, the app receives an update about NEVPNStatus being set to disconnecting yet NEVPNConnection does not throw.
The behavior I was naively expecting was that the packet tunnel process would be stopped only when the new app is fully downloaded and when the update is installed, Are we doing something horribly wrong here?
When setting up a packet tunnel with a profile that has includeAllNetworks set to true, we seemingly cannot send any traffic inside the tunnel using any kind of an API. We've tried using BSD sockets, as we ping a host only reachable within the tunnel to establish whether we have connectivity - this does not work. When using NWConnection from the Network framework and specifying the required interface via virtualInterface from the packet tunnel, the connection state never reaches ready. Our interim solution is to, as ridiculous as it sounds, include a whole userspace networking stack so we can produce valid TCP packets just to send into our own tunnel. We require a TCP connection within our own tunnel to do some configuration during tunnel setup. Is there no better solution?
I must be missing something. How can an iphone that is in lockdown mode, using ONLY data, no Bluetooth connected and only one singular iPhone have seven UNLISTED items on the local network in privacy and settings?
Hi folks,
I would like to ask for clarification regarding Local Network Policy. I found 2 cases where I think the behaviour differs from the documentation.
1. Use case
In a CI environment, we have multiple services (LaunchAgents) which require Local Network Access. We are fine by manually approving the Local Network Permission once (per service), but we also require these services to be able to self-update. Self update results in downloading the a binary with an (obviously) different UUID, which seems to result in re-triggering the Local Network Consent prompt. Strange thing: If I don't click either buttons (Allow of Reject), just restart macOS, it will result in an enabled entry in Privacy & Security > Local Network.
I read a reply somewhere on this forum by an Apple engineer that the approval process is a mix of Bundle ID + UUID + other components, so I would expect a new binary with the same properties (but different UUID) to be already whitelisted.
Is this behaviour intended?
2. Use Case
Given the first issue, I decided to do this in the "right way".
I was happy to read this sentence in the documentation:
If you ship a launchd agent that’s not installed using SMAppService, make macOS aware of the responsible code by setting the AssociatedBundleIdentifiers property in your launchd property list.
I have a properly setup (and code signed) Application, for which I have enabled Local Network permission in Privacy & Security.
I have a standalone LaunchAgent, which runs a long running binary from a user directory. The agent is managed with launchd, and in this sense it is "independent" from the main Application Bundle. I have setup AssociatedBundleIdentifiers in the Agent plist, to associate it with the Application. The TeamIdentifier of the 2 binaries are the same. Based on the documentation, this should be enough for my agent to signal macOS that the responsible code is the Application Bundle (which is already enabled from Local Network POV).
Instead, once the LaunchAgent starts, the Local Network Consent popup appears for the binary. I would expect the Application to be the responsible code, thus no more Consent popup.
Is this behaviour intended?
I need this service to run as user, so I cannot just circumvent the Consent popup by running as a Daemon or Root. Nor I would like to manage the Agent with ServiceManagement. What do you guys think, have I misunderstood the documentation?
I'm working on a game that uses NWBrowser and NWListener to create a connection between an iOS and tvOS app.
I've got the initial networking up and running and it works perfectly when running in the simulator(s). However, when I run on-device(s), I've found that browseResultsChangedHandler gets called multiple times for what is ostensibly the same service.
My browser handler (which runs on iOS) looks like this:
browser.browseResultsChangedHandler = { [weak self] results, changes in
if let result = browser.browseResults.first {
self?.onPeerConnected?(PeerConnection(endpoint: result.endpoint))
}
}
The first time it gets called, the interface in the NWBrowser.Result is en0, but the 2nd time it gets called, it is en0 AND awdl0.
Because my current handling is so naive, this re-invocation ends up with two connections being made to the remote server (the Apple TV).
Now, I know that this handler, by its very name, is designed to be called multiple times as things change, so I'm curious as to what strategies I might employ here.
Is there any value in tearing down any previous connections and re-connecting using the latest one? Should I just kill the browser as soon as I handle the first one? Just ignore subsequent ones?
I'm sure that, to a degree, the answer is probably "it depends"... but I'm curious to see if there might be at least some high-level strategies like "whatever you do, don't do xxxx" or "most apps do yyyy" :-)
Thanks.
We use URLSessionWebSocketTask for web socket connection. When get error we reconnect - recreate new URLSessionWebSocketTask.
Test case: off wifi on iOS device; get error(s) URLError.notConnectedToInternet. When on wifi correct create new task with connect.
This working on iOS 12, 14, 15, 16, 17. But on iOS 18 we get error URLError.notConnectedToInternet without correct connection.
class WebSocketManager {
...
func openConnection() {
webSocketTask?.cancel(with: .goingAway, reason: nil)
webSocketTask = urlSession?.webSocketTask(with: urlRequest)
webSocketTask?.resume()
listen()
}
func closeConnection() {
webSocketTask?.cancel(with: .goingAway, reason: nil)
webSocketTask = nil
}
private func listen() {
webSocketTask?.receive { [weak self] result in
guard let self else { return }
switch result {
case .failure(let error):
delegate?.webSocketManager(self, error: error)
case .success(let message):
switch message {
case .string(let text):
delegate?.webSocketManager(self, message: .text(text))
case .data(let data):
delegate?.webSocketManager(self, message: .data(data))
@unknown default:
fatalError()
}
listen()
}
}
}
}
Delegate:
func webSocketManager(_ webSocketManager: WebSocketManagerType, error: Error) {
webSocketManager.openConnection()
}
I am currently operating an app using an embedded web server that communicates over local HTTP.
Recently, when opening Safari, I started encountering the following error message:
"Safari cannot open the page. Error: Failed to navigate to an HTTP URL with HTTPS-only mode enabled."
However, I am currently in a situation where switching to HTTPS is difficult. Are there any solutions to resolve this issue besides using HTTPS?
Thank you.🙏
Hi, I’m working on a case in our organisation where we encounter regular wireless network disconnections - 30 and 60 minutes. ~ 1800 sec session is widely seen across hundreds if not thousand Macbooks.
We excluded internal wireless configuration issue and vendor specific problem as the disconnections happen on both Cisco and Ubiquiti Access Points.
Wireless Controller debugging most often show EAP timeout error.
Sniffer shows that the disassociation is initiated by Macbook.
MacOS logs show wifianalyticsd performing some actions before the disconnection (generated with sudo log show --debug [time]):
2025-02-04 14:16:31.219169+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[WAEngine gatherConsecutiveDatapathReadings:forProcessToken:andReply:]_block_invoke::4238:SDNS: WiFi Not Primary - setting suppressedReason kSymptomsDnsWiFiInterfaceNotPrimary
2025-02-04 14:16:31.219192+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine updateTimeSincePreviousTriggerForStudy:msgKey:dictKey:]::913:msgkey:WFAAWDWASDS_symptomsDnsTimeSincePreviousTriggerMinutes dictKey:dps_lastSymptomsDpsTrigger previous_TS:(null) current_TS:Tue
Feb 4 14:16:31 2025 difference:0
2025-02-04 14:16:31.219704+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine updateScreenState]::198:DPS Fast Reset Recommendation Engine: (screenON & foreGrnd traffic) is DETECTED
2025-02-04 14:16:31.219713+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine recommendSymptomsDpsRecovery:symptomsDnsStats:awdlState:currentSymptomsCondition:isLANPingSuccessful:appUsage:averageCCA:]::966:PeerDiagnostics: Data not received from peerDiagnostics
2025-02-04 14:16:31.219714+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine checkForPriorityNetwork]::256:Priority Network Check Disabled: NO IsPriorityNetwork: YES
2025-02-04 14:16:31.219732+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine isResetAllowedForKey:forPrefSelector:]::330:key:symptomsDps_lastScreenOnRecoveryWD previousWD_TS:(null) currentWD_TS:Tue Feb 4 14:16:31 2025 recommendation:YES
2025-02-04 14:16:31.219735+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine updateSymptomsDPSRecoveryWDStatsForKey:]::210:Added key: symptomsDps_numRecommendedScreenOnRecoveryWD value:1 dict:(null)
2025-02-04 14:16:31.219737+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[DPSQuickRecoveryRecommendationEngine recommendSymptomsDpsRecovery:symptomsDnsStats:awdlState:currentSymptomsCondition:isLANPingSuccessful:appUsage:averageCCA:]::1023:PeerDiagnostics: Recommendation for DNS Symptoms Recovery: Reassoc
2025-02-04 14:16:31.219740+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[WAEngine gatherConsecutiveDatapathReadings:forProcessToken:andReply:]_block_invoke::4276:PeerDiagnostics: Triggering Reassoc for symptoms-dps
2025-02-04 14:16:31.219741+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: [com.apple.wifi.analytics:Default] -[WAEngine gatherConsecutiveDatapathReadings:forProcessToken:andReply:]_block_invoke::4277:SDNS: Recommendation - kSymptomsdDPSReassoc, triggering reassoc wiith reason ReassociateOnDNSSymptoms
2025-02-04 14:16:31.220001+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: (IO80211) Apple80211SetWithIOCTL:11858 Processing APPLE80211_IOC_REASSOCIATE_WITH_CORECAPTURE
2025-02-04 14:16:31.387985+0100 0xc01342 Default 0x0 86459 0 wifianalyticsd: (IO80211) Apple80211SetWithIOCTL: Processed APPLE80211_IOC_REASSOCIATE_WITH_CORECAPTURE Ioctl error:0
WAEngine and DPSQuickRecoveryRecommendationEngine functionalities (?) play significant role in here recommending Reassociation
We can see that reassociation is being triggered because of DNS symptoms - why and where can I find them?
Recommendation for DNS Symptoms Recovery: Reassoc
I have some concerns related to shortening the lifetime of certificates, as per
https://support.apple.com/en-gb/102028
Does this apply to Private CA root certificates?
And if yes:
does it apply if I use ATS and higher level API like URLSession
does it apply it I carry my root CA cert in my app payload and use low level libraries without ATS support?
We have several apps that our business uses to connect to internal private HTTP sites. We noticed in IOS 18.3 we are getting SSL errors to the web server and noticed the issue in the Chrome Browser as well. Our team is looking at the Application Transport Security layer exceptions in our apps Info.Plist. We do notice the browser forcing HTTPS. Any insight on what could be the issue?