I was excited about the new APIs added to Network.framework in iOS 26 that offer structure concurrency support out of the box and a more modern API design in general. However I have been unable to use them to create a device-to-device QUIC connection. The blocker I ran into is that NetworkListener's run method requires the network protocol to conform to OneToOneProtocol, whereas QUIC conforms to MultiplexProtocol. And there doesn't seem to be any way to accept an incoming MultiplexProtocol connection? Nor does it seem possible to turn a UDP connection into a QUIC connection using NetworkConnection.prependProtocols() as that also only works for network protocols conforming to OneToOneProtocol. I suspect this is an accidental omission in the API design (?), and already filed a Feedback (FB18620438). But maybe I am missing something and there is a workaround or a different way to listen for incoming QUIC connections using the new NetworkListener? QUIC.TLS has methods peerAuthenticationRequired(Bool) and peerAuthenticationOptional(Bool), which makes me think that peer to peer QUIC connections are intended to be supported? I would also love to see documentation for those methods. For example I wonder what exact effect peerAuthenticationRequired(false) and peerAuthenticationOptional(false) would have and how they differ.

I’m working on an iOS parental-control app that needs to block specific network traffic (e.g. certain domains or URLs). We’ve already obtained the Family Controls entitlement (since our app is explicitly a parental-control solution), but we do not use MDM to supervise devices. In testing, our NEFilterDataProvider extension only activates when the device is enrolled under a managed Family Controls profile. I am aware that we can use a PacketTunnel to achieve this but i was wondering if there is any simpler solution to this? Thanks for you time!

Hello, I am planning to build content filter application for iOS platform and based on the documentation I have read, it's not clear if I can just inspect/monitor network traffic and not filter or block URLs in the NEFilterDataProvider. Is this a valid use case ? With this approach, will the App get rejected during the App review.?

IMPORTANT The resume rate limiter is now covered by the official documentation. See Use background sessions efficiently within Downloading files in the background. So, the following is here purely for historical perspective. NSURLSession’s background session support on iOS includes a resume rate limiter. This limiter exists to prevent apps from abusing the background session support in order to run continuously in the background. It works as follows: nsurlsessiond (the daemon that does all the background session work) maintains a delay value for your app. It doubles that delay every time it resumes (or relaunches) your app. It resets that delay to 0 when the user brings your app to the front. It also resets the delay to 0 if the delay period elapses without it having resumed your app. When your app creates a new task while it is in the background, the task does not start until that delay has expired. To understand the impact of this, consider what happens when you download 10 resources. If you pass them to the background session all at once, you see something like this: Your app creates tasks 1 through 10 in the background session. nsurlsessiond starts working on the first few tasks. As tasks complete, nsurlsessiond starts working on subsequent ones. Eventually all the tasks complete and nsurlsessiond resumes your app. Now consider what happens if you only schedule one task at a time: Your app creates task 1. nsurlsessiond starts working on it. When it completes, nsurlsessiond resumes your app. Your app creates task 2. nsurlsessiond delays the start of task 2 a little bit. nsurlsessiond starts working on task 2. When it completes, nsurlsessiond resumes your app. Your app creates task 3. nsurlsessiond delays the start of task 3 by double the previous amount. nsurlsessiond starts working on task 3. When it completes, nsurlsessiond resumes your app. Steps 8 through 11 repeat, and each time the delay doubles. Eventually the delay gets so large that it looks like your app has stopped making progress. If you have a lot of tasks to run then you can mitigate this problem by starting tasks in batches. That is, rather than start just one task in step 1, you would start 100. This only helps up to a point. If you have thousands of tasks to run, you will eventually start seeing serious delays. In that case it’s much better to change your design to use fewer, larger transfers. Note All of the above applies to iOS 8 and later. Things worked differently in iOS 7. There’s a post on DevForums that explains the older approach. Finally, keep in mind that there may be other reasons for your task not starting. Specifically, if the task is flagged as discretionary (because you set the discretionary flag when creating the task’s session or because the task was started while your app was in the background), the task may be delayed for other reasons (low power, lack of Wi-Fi, and so on). Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" (r. 22323366)

Do we have clear document around multiple content filter applications running on single device.? While the documentation says 8 content filters and Only one filter available for system-wide use, there is no clear mention about below scenarios - Which content filter will get precedence? System-wide or App managed? Can there be mulitple Content filters configured for same managed application? Will all control provider running on the device get notified about network traffic ? I searched the forums to get a clear answer but seems older threads where nothing was conclusive. Thanks in advance for the help !!

Our application currently uses NEFilterPacketProvider to filter network traffic based on Layer 4 rules (5-tuple: source IP, destination IP, source port, destination port, and protocol) on a packet-by-packet basis. We now want to extend this filtering to also consider the associated process—for example, allowing traffic from a specific source IP to a destination IP and port only if it's associated with a specific local process. That is, we’d like to make filtering decisions not just based on the 5-tuple, but also on the identity of the process either sending or receiving the traffic. We’ve looked into NEFilterSocketProvider, which does expose Layer 7 information such as process identifiers. However, it doesn’t seem to be tightly synchronized with the packet flow handled by NEFilterPacketProvider. As a result, there’s a risk that we might only get process information after the TCP handshake is complete, or before the socket is fully bound—at which point some of the 5-tuple fields (such as the local port) may still be unavailable. What we need is a way to correlate the 5-tuple with the relevant process name (either sender or receiver) at the time the first packet—e.g., a SYN packet—is about to be sent or received. Is there a recommended way to achieve this kind of early, process-aware filtering using NetworkExtension APIs?

We have a Java application built for macOS. On the first launch, the application prompts the user to allow local network access. We've correctly added the NSLocalNetworkUsageDescription key to the Info.plist, and the provided description appears in the system prompt. After the user grants permission, the application can successfully connect to a local server using its hostname. However, the issue arises after the system is rebooted. When the application is launched again, macOS does not prompt for local network access a second time—which is expected, as the permission was already granted. Despite this, the application is unable to connect to the local server. It appears the previously granted permission is being ignored after a reboot. A temporary workaround is to manually toggle the Local Network permission off and back on via System Settings > Privacy & Security, which restores connectivity—until the next reboot. This behavior is highly disruptive, both for us and for a significant number of our users. We can reproduce this on multiple systems... The issues started from macOS Sequoia 15.0 By opening the application bundle using "Show Package Contents," we can launch the application via "JavaAppLauncher" without any issues. Once started, the application is able to connect to our server over the local network. This seems to bypass the granted permissions? "JavaAppLauncher" is also been used in our Info.plist file

I'm trying to use ThreadNetwork API to manage TheradNetworks on device (following this documentation: https://developer.apple.com/documentation/threadnetwork/), but while some functions on THClient work (such as getPreferedNetwork), most don't (storeCredentials, retrieveAllCredentials). When calling these functions I get the following warning/error: Client: -[THClient getConnectionEntitlementValidity]_block_invoke - Error: -[THClient storeCredentialsForBorderAgent:activeOperationalDataSet:completion:]_block_invoke:701: - Error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service with pid 414 named com.apple.ThreadNetwork.xpc was invalidated from this process." UserInfo={NSDebugDescription=The connection to service with pid 414 named com.apple.ThreadNetwork.xpc was invalidated from this process.} Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service with pid 414 named com.apple.ThreadNetwork.xpc was invalidated from this process." UserInfo={NSDebugDescription=The connection to service with pid 414 named com.apple.ThreadNetwork.xpc was invalidated from this process.} Failed to store Thread credentials: Couldn’t communicate with a helper application. STEPS TO REPRODUCE Create new project Add Thread Network capability via Xcode UI (com.apple.developer.networking.manage-thread-network-credentials) Trigger storeCredentials let extendedMacData = "9483C451DC3E".hexadecimal let tlvHex = "0e080000000000010000000300001035060004001fffe002083c66f0dc9ef53f1c0708fdb360c72874da9905104094dce45388fd3d3426e992cbf0697b030d474c2d5332302d6e65773030310102250b04106c9f919a4da9b213764fc83f849381080c0402a0f7f8".hexadecimal // Initialize the THClient let thClient = THClient() // Store the credentials await thClient.storeCredentials(forBorderAgent: extendedMacData!, activeOperationalDataSet: tlvHex!) { error in if let error = error { print(error) print("Failed to store Thread credentials: \(error.localizedDescription)") } else { print("Successfully stored Thread credentials") } } NOTES: I tried with first calling getPreferedNetwork to initiate network permission dialog Tried adding meshcop to bojur services Tried with different release and debug build configurations

We have a Java application built for macOS. On the first launch, the application prompts the user to allow local network access. We've correctly added the NSLocalNetworkUsageDescription key to the Info.plist, and the provided description appears in the system prompt. After the user grants permission, the application can successfully connect to a local server using its hostname. However, the issue arises after the system is rebooted. When the application is launched again, macOS does not prompt for local network access a second time—which is expected, as the permission was already granted. Despite this, the application is unable to connect to the local server. It appears the previously granted permission is being ignored after a reboot. A temporary workaround is to manually toggle the Local Network permission off and back on via System Settings > Privacy & Security, which restores connectivity—until the next reboot. This behavior is highly disruptive, both for us and for a significant number of our users. We can reproduce this on multiple systems... The issues started from macOS Sequoia 15.0 By opening the application bundle using "Show Package Contents," we can launch the application via "JavaAppLauncher" without any issues. Once started, the application is able to connect to our server over the local network. This seems to bypass the granted permissions? "JavaAppLauncher" is also been used in our Info.plist file Removing the following plist in Recovery Mode seems to resolve the issue rm "/Volumes/Macintosh HD/Library/Preferences/com.apple.networkextension.plist" Is this safe to do?

Hi, I had a few questions regarding the multicast networking entitlement. What are the criteria for approval? Do ad-hoc multicast protocols fall under the approval criteria? How long do approvals for multicasting generally take?

We have a Java application built for macOS. On the first launch, the application prompts the user to allow local network access. We've correctly added the NSLocalNetworkUsageDescription key to the Info.plist, and the provided description appears in the system prompt. After the user grants permission, the application can successfully connect to a local server using its hostname. However, the issue arises after the system is rebooted. When the application is launched again, macOS does not prompt for local network access a second time—which is expected, as the permission was already granted. Despite this, the application is unable to connect to the local server. It appears the previously granted permission is being ignored after a reboot. A temporary workaround is to manually toggle the Local Network permission off and back on via System Settings > Privacy & Security, which restores connectivity—until the next reboot. This behavior is highly disruptive, both for us and for a significant number of our users. We can reproduce this on multiple systems... The issues started from macOS Sequoia 15.0 By opening the application bundle using "Show Package Contents," we can launch the application via "JavaAppLauncher" without any issues. Once started, the application is able to connect to our server over the local network. This seems to bypass the granted permissions? "JavaAppLauncher" is also been used in our Info.plist file Removing the following plist in Recovery Mode seems to resolve the issue rm "/Volumes/Macintosh HD/Library/Preferences/com.apple.networkextension.plist" Is this safe to do?

Most apps perform ordinary network operations, like fetching an HTTP resource with URLSession and opening a TCP connection to a mail server with Network framework. These operations are not without their challenges, but they’re the well-trodden path. If your app performs ordinary networking, see TN3151 Choosing the right networking API for recommendations as to where to start. Some apps have extra-ordinary networking requirements. For example, apps that: Help the user configure a Wi-Fi accessory Require a connection to run over a specific interface Listen for incoming connections Building such an app is tricky because: Networking is hard in general. Apple devices support very dynamic networking, and your app has to work well in whatever environment it’s running in. Documentation for the APIs you need is tucked away in man pages and doc comments. In many cases you have to assemble these APIs in creative ways. If you’re developing an app with extra-ordinary networking requirements, this post is for you. Note If you have questions or comments about any of the topics discussed here, put them in a new thread here on DevForums. Make sure I see it by putting it in the App & System Services > Networking area. And feel free to add tags appropriate to the specific technology you’re using, like Foundation, CFNetwork, Network, or Network Extension. Links, Links, and More Links Each topic is covered in a separate post: The iOS Wi-Fi Lifecycle describes how iOS joins and leaves Wi-Fi networks. Understanding this is especially important if you’re building an app that works with a Wi-Fi accessory. Network Interface Concepts explains how Apple platforms manage network interfaces. If you’ve got this far, you definitely want to read this. Network Interface Techniques offers a high-level overview of some of the more common techniques you need when working with network interfaces. Network Interface APIs describes APIs and core techniques for working with network interfaces. It’s referenced by many other posts. Running an HTTP Request over WWAN explains why most apps should not force an HTTP request to run over WWAN, what they should do instead, and what to do if you really need that behaviour. If you’re building an iOS app with an embedded network server, see Showing Connection Information in an iOS Server for details on how to get the information to show to your user so they can connect to your server. Many folks run into trouble when they try to find the device’s IP address, or other seemingly simple things, like the name of the Wi-Fi interface. Don’t Try to Get the Device’s IP Address explains why these problems are hard, and offers alternative approaches that function correctly in all network environments. Similarly, folks also run into trouble when trying to get the host name. On Host Names explains why that’s more complex than you might think. If you’re working with broadcasts or multicasts, see Broadcasts and Multicasts, Hints and Tips. If you’re building an app that works with a Wi-Fi accessory, see Working with a Wi-Fi Accessory. If you’re trying to gather network interface statistics, see Network Interface Statistics. There are also some posts that are not part of this series but likely to be of interest if you’re working in this space: TN3179 Understanding local network privacy discusses the local network privacy feature. Calling BSD Sockets from Swift does what it says on the tin, that is, explains how to call BSD Sockets from Swift. When doing weird things with the network, you often find yourself having to use BSD Sockets, and that API is not easy to call from Swift. The code therein is primarily for the benefit of test projects, oh, and DevForums posts like these. TN3111 iOS Wi-Fi API overview is a critical resource if you’re doing Wi-Fi specific stuff on iOS. TLS For Accessory Developers tackles the tricky topic of how to communicate securely with a network-based accessory. A Peek Behind the NECP Curtain discusses NECP, a subsystem that control which programs have access to which network interfaces. Networking Resources has links to many other useful resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision History 2025-07-31 Added a link to A Peek Behind the NECP Curtain. 2025-03-28 Added a link to On Host Names. 2025-01-16 Added a link to Broadcasts and Multicasts, Hints and Tips. Updated the local network privacy link to point to TN3179. Made other minor editorial changes. 2024-04-30 Added a link to Network Interface Statistics. 2023-09-14 Added a link to TLS For Accessory Developers. 2023-07-23 First posted.

I've built a VPN app that is based on wireguard on macOS (I have both AppStore ver. and Developer ID ver). I want to achieve split tunneling function without changing the system route table. Currently, I'm making changes in PacketTunnelProvider: NEPacketTunnelProvider. It has included/excluded routes that function as a split tunnel, just that all changes are immediately reflected on the route table: if I run netstat -rn in terminal, I would see all rules/CIDRs I added, displayed all at once. Since I have a CIDR list of ~800 entries, I'd like to avoid changing the route table directly. I've asked ChatGPT, Claude, DeepSeek, .etc. An idea was to implement an 'interceptor' to intercept all packets in packetFlow(_:readPacketsWithCompletionHandler:), extract the destination IP from each packet, check if it matches your CIDR list, and either reinject it back to the system interface (for local routing) or process it through your tunnel. Well, LLMs could have hallucinations and I've pretty new to macOS programming. I'm asking to make sure I'm on the right track, not going delusional with those LLMs :) So the question is, does the above method sounds feasible? If not, is it possible to achieve split tunneling without changing the route table?

Greetings.I have an app today that uses multipeer connectivity extensively. Currently, when the user switches away from the app, MPC disconnects the session(s) - this is by design apparently (per other feedback). I'd like to hear if anyone has experimented with iOS9 multitasking / multipeer and whether MPC sessions can stay alive?Thanks

Hi,I am trying to create an NAT64 Network with Sharing options to test my Apps.I did follow the guide provided here https://forums.developer.apple.com/thread/14213But even with the option key pressed the "Create NAT64 Network" check box is still missing.I am using a OS X 10.11Any ideas?!

Hello eveybody,Currently I'm working on an app which connects to a device. During testing I encounter an internal error of NEHotspotConfigurationErrorDomain. See the log snippet:Domain=NEHotspotConfigurationErrorDomain Code=8 "internal error." UserInfo={NSLocalizedDescription=internal error.}This error appears randomly. In one day I encountered it three times. The only solution I can think of is catching this error somehow and then telling the user to restart the device.After this error appears, the wifi functionality of iOS in all third party apps seems to be broken. Only restarting helps as far as I know. Also there seems to be nothing we as app developers can do about it. Therefor I wonder if there is some way to prevent this error somehow? The only solution I can think of is catching this error somehow and then telling the user to restart the device.Also since there is not much information about this error on the web, it would be really nice if someone can clarify whats going on with this error.Regards.

General: Forums subtopic: App & System Services > Networking 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 forums 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 TN3179 Understanding local network privacy Adapt to changing network conditions tech talk TCP and UDP ports used by Apple software products support article Understanding Also-Ran Connections forums post Extra-ordinary Networking forums post Foundation networking: Forums tags: Foundation, CFNetwork URL Loading System documentation — NSURLSession, or URLSession in Swift, is the recommended API for HTTP[S] on Apple platforms. Moving to Fewer, Larger Transfers forums post Testing Background Session Code forums post Network framework: Forums tag: Network Network framework documentation — Network framework is the recommended API for TCP, UDP, and QUIC on Apple platforms. Building a custom peer-to-peer protocol sample code (aka TicTacToe) Implementing netcat with Network Framework sample code (aka nwcat) Configuring a Wi-Fi accessory to join a network sample code Moving from Multipeer Connectivity to Network Framework forums post NWEndpoint History and Advice forums post Wi-Fi (general): How to modernize your captive network developer news post Wi-Fi Fundamentals forums post Filing a Wi-Fi Bug Report forums post Working with a Wi-Fi Accessory forums post — This is part of the Extra-ordinary Networking series. Wi-Fi (iOS): TN3111 iOS Wi-Fi API overview technote Wi-Fi Aware framework documentation WirelessInsights framework documentation iOS Network Signal Strength forums post Network Extension Resources Wi-Fi on macOS: Forums tag: Core WLAN Core WLAN framework documentation Secure networking: Forums tags: Security Apple Platform Security support document Preventing Insecure Network Connections documentation — This is all about App Transport Security (ATS). WWDC 2017 Session 701 Your Apps and Evolving Network Security Standards [1] — This is generally interesting, but the section starting at 17:40 is, AFAIK, the best information from Apple about how certificate revocation works on modern systems. WWDC 2025 Session 314 Get ahead with quantum-secure cryptography 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 What’s new for enterprise in iOS 18 support article — This discusses new key usage requirements. Prepare your network environment for stricter security requirements support article — This is primarily of interest to folks developing management software, for example, an MDM server. Technote 2232 HTTPS Server Trust Evaluation Technote 2326 Creating Certificates for TLS Testing QA1948 HTTPS and Test Servers Miscellaneous: More network-related forums tags: 5G, QUIC, Bonjour On FTP forums post Using the Multicast Networking Additional Capability forums post Investigating Network Latency Problems forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] This video is no longer available from Apple, but the URL should help you locate other sources of this info.

We're encountering an issue with our Network Extension (utilizing NEPacketTunnelProvider and NETransparentProxy) on macOS 14.5 (23F79). On some systems, the VPN fails to automatically start after a reboot despite calling startVPNTunnel(). There are no error messages. Our code attempts to start the tunnel: ....... do { try manager.connection.startVPNTunnel() Logger.default("Started tunnel successfully") } catch { Logger.error("Failed to launch tunnel") } ...... System log analysis reveals the tunnel stopping due to userLogout (NEProviderStopReason(rawValue: 12)) during reboot. However, the Transparent Proxy stops due to userInitiated (NEProviderStopReason(rawValue: 1)) for the same reboot. We need to understand: Why the VPNTunnel isn't starting automatically. Why the userLogout reason is triggered during reboot. Additional Context: We have manually started the VPN from System Settings before reboot.

Dear apple: Our app uses the BSD socket interface for socket communication over the local area network. However, when using the socket's connect interface, some iPhone devices fail, and the socket has also bound the local Wi-Fi card's IP using the bind interface. The errno is 65, indicating "no route." We have checked that the app has already requested local network permissions and permissions to use the local area network. The TCP server on the other end is also listening normally. Please help us see if any additional permissions need to be requested. Thank you

Hi, i have a crash received in my Firebase Crashlytics. I couldn't figure out the root cause of the issue. Could anyone please help me with it. Crashed: com.apple.CFNetwork.Connection 0 libobjc.A.dylib 0x20b8 objc_retain_x19 + 16 1 CFNetwork 0x47398 HTTP3Fields::appendField(NSString*, NSString*) + 72 2 CFNetwork 0x41250 invocation function for block in HTTP3Stream::_buildRequestHeaders() + 240 3 CoreFoundation 0x249f0 __NSDICTIONARY_IS_CALLING_OUT_TO_A_BLOCK__ + 24 4 CoreFoundation 0x565dc ____NSDictionaryEnumerate_block_invoke_2 + 56 5 CoreFoundation 0x55b10 CFBasicHashApply + 148 6 CoreFoundation 0x8abfc __NSDictionaryEnumerate + 520 7 CFNetwork 0x793d4 HTTP3Stream::scheduleAndOpenWithHandler(CoreSchedulingSet const*, void (__CFHTTPMessage*, NSObject<OS_dispatch_data>*, CFStreamError const*) block_pointer, void (unsigned char) block_pointer) + 1120 8 CFNetwork 0x1665c HTTPProtocol::useNetStreamInfoForRequest(MetaNetStreamInfo*, HTTPRequestMessage const*, unsigned char) + 4044 9 CFNetwork 0x80c80 HTTP3ConnectionCacheEntry::enqueueRequestForProtocol(MetaConnectionCacheClient*, HTTPRequestMessage const*, MetaConnectionOptions) + 2540 10 CFNetwork 0x7fab8 HTTP3ConnectionCacheWrapper::ingestTube(Tube*, bool) + 2924 11 CFNetwork 0x257dc TubeManager::newTubeReady(Tube*, CFStreamError) + 4284 12 CFNetwork 0x57b64 invocation function for block in TubeManager::_onqueue_createNewTube(HTTPConnectionCacheKey*) + 72 13 CFNetwork 0x2fe30 Tube::_onqueue_invokeCB(CFStreamError) + 360 14 CFNetwork 0x2fc20 NWIOConnection::_signalEstablished() + 652 15 CFNetwork 0x4ba1c invocation function for block in NWIOConnection::_handleEvent_ReadyFinish() + 748 16 CFNetwork 0x4b5b0 invocation function for block in Tube::postConnectConfiguration(NSObject<OS_tcp_connection>*, NSObject<OS_nw_parameters>*, void () block_pointer) + 860 17 CFNetwork 0x4b220 BlockHolderVar<std::__1::shared_ptr<NetworkProxy>, bool, CFStreamError>::invoke_normal(std::__1::shared_ptr<NetworkProxy>, bool, CFStreamError) + 64 18 CFNetwork 0x32f2c ProxyConnectionEstablishment::postProxyConnectionConfiguration(__CFAllocator const*, std::__1::shared_ptr<TransportConnection>, NSObject<OS_nw_parameters>*, __CFHTTPMessage*, HTTPConnectionCacheKey*, std::__1::shared_ptr<MetaAuthClient>, SmartBlockWithArgs<std::__1::shared_ptr<NetworkProxy>, bool, CFStreamError>) + 664 19 CFNetwork 0x32bbc Tube::postConnectConfiguration(NSObject<OS_tcp_connection>*, NSObject<OS_nw_parameters>*, void () block_pointer) + 744 20 CFNetwork 0xc19b0 invocation function for block in NWIOConnection::_setupConnectionEvents() + 2360 21 libdispatch.dylib 0x132e8 _dispatch_block_async_invoke2 + 148 22 libdispatch.dylib 0x40d0 _dispatch_client_callout + 20 23 libdispatch.dylib 0xb6d8 _dispatch_lane_serial_drain + 744 24 libdispatch.dylib 0xc214 _dispatch_lane_invoke + 432 25 libdispatch.dylib 0xd670 _dispatch_workloop_invoke + 1732 26 libdispatch.dylib 0x17258 _dispatch_root_queue_drain_deferred_wlh + 288 27 libdispatch.dylib 0x16aa4 _dispatch_workloop_worker_thread + 540 28 libsystem_pthread.dylib 0x4c7c _pthread_wqthread + 288 29 libsystem_pthread.dylib 0x1488 start_wqthread + 8 [Here is the complete crash report.](https://developer.apple.com/forums/content/attachment/58b5bb7d-7c90-4eec-906c-4fb76861d44b)