After update to IOS18, my app crashed. following is the exception got from xcode: Trapped uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSFileManager createDirectoryAtURL:withIntermediateDirectories:attributes:error:]: URL is nil' ( 0 CoreFoundation 0x0000000194a79098 47427277-EE15-3C17-AD68-6886B0380B5E + 540824 1 libobjc.A.dylib 0x0000000191d7b2e4 objc_exception_throw + 88 2 Foundation 0x0000000193741f48 12E17A7A-B65F-35EE-82D7-CBC31004E223 + 1154888 3 CFNetwork 0x0000000195eeb2bc FA95B718-E8EB-34BD-90FA-8FB1AFE016D6 + 164540 4 CFNetwork 0x0000000195eeac7c FA95B718-E8EB-34BD-90FA-8FB1AFE016D6 + 162940 5 libdispatch.dylib 0x000000010342a71c _dispatch_client_callout + 20 6 libdispatch.dylib 0x000000010343bf04 _dispatch_lane_barrier_sync_invoke_and_complete + 176 7 CFNetwork 0x0000000195eeaa88 FA95B718-E8EB-34BD-90FA-8FB1AFE016D6 + 162440 8 CFNetwork 0x0000000195ee9b20 FA95B718-E8EB-34BD-90FA-8FB1AFE016D6 + 158496 9 CFNetwork 0x0000000195ee95f4 FA95B718-E8EB-34BD-90FA-8FB1AFE016D6 + 157172 10 CFNetwork 0x0000000195ee907c FA95B718-E8EB-34BD-90FA-8FB1AFE016D6 + 155772 11 CFNetwork 0x0000000195ee34b0 FA95B718-E8EB-34BD-90FA-8FB1AFE016D6 + 132272 12 CFNetwork 0x0000000195f942c4 FA95B718-E8EB-34BD-90FA-8FB1AFE016D6 + 856772 13 CFNetwork 0x0000000195f94214 FA95B718-E8EB-34BD-90FA-8FB1AFE016D6 + 856596 14 CFNetwork 0x0000000195f9330c FA95B718-E8EB-34BD-90FA-8FB1AFE016D6 + 852748 15 libdispatch.dylib 0x0000000103428a30 _dispatch_call_block_and_release + 32 16 libdispatch.dylib 0x000000010342a71c _dispatch_client_callout + 20 17 libdispatch.dylib 0x00000001034325e8 _dispatch_lane_serial_drain + 828 18 libdispatch.dylib 0x0000000103433394 _dispatch_lane_invoke + 460 19 libdispatch.dylib 0x0000000103434b20 _dispatch_workloop_invoke + 2264 20 libdispatch.dylib 0x00000001034405f0 _dispatch_root_queue_drain_deferred_wlh + 328 21 libdispatch.dylib 0x000000010343fc00 _dispatch_workloop_worker_thread + 580 22 libsystem_pthread.dylib 0x000000021bddfc7c _pthread_wqthread + 288 23 libsystem_pthread.dylib 0x000000021bddc488 start_wqthread + 8 ) This app works fine until ios 18 appear. Could you help me? thanks

My app often fails to access the network (other apps on the device can access the network normally), and restarting the app is also ineffective. I need to open and close the flight mode to restore the app's network I used to suspect the background refresh was the cause, but removing the background refresh still occasionally causes this problem.

Users are reporting that 3rd-party software that leverages Apple's Network Extensions (such as LuLu and Windows Defender) are causing networking issues after upgrading to macOS 15. However as such products were working seamlessly on macOS 14.* and nothing in the code of these products changed between then and now, this would point to bug in macOS. Users have mentioned the following work arounds: Disabling the internal (macOS) firewall Upgrading to macOS 15.1 beta More info about the issues and these "workarounds" here and here.. Looking for any guidance / insight / technical details from Apple, as users are (understandably) blaming these tools and their developers 😭 Of course if there are updated APIs or some other changes in macOS 15 that developers should consider / conform to, to ensure compatibility that'd be great to know too!

Hello, I make a matter device with extended color light functions. I add the mode select cluster in device to set work mode of device. I can not find the work mode in Apple Home application, only the light related functions show in UI. I tested my device with chip-tool, and read out the mode from device. B.R. Ray

Hi, just got upgraded this morning and now I can't use my local Tomcat install as server for my apps. I can access it in safari using localhost, but not using my computers IP. I start it from terminal. I looked everywhere in settings, and searched online of course, but have been unable to find an answer. Anyone knows how I can fit it? Input appreciated.

Hi, I'm working on a sample app to enable two-way data transfer between Mac, iOS, and Android devices. The devices will be in close proximity to each other. To implement this, I used Google's Nearby API, which supports cross-platform communication. The approach has worked well for Mac and iOS devices, even across different networks. However, while Mac and Android devices communicate successfully when on the same network, they fail to discover each other when on different networks. Mac :left_right_arrow: iOS-----Works fine in all scenarios. Mac :left_right_arrow: Android-------Works only when both devices are on the same network, but fails to discover each other on different networks. Is there any alternative approach to achieve reliable cross-platform communication, or any technical documentation that could help with this? Thanks in advance!

Hello; we observe slow behavior on some macOS systems which were upgraded from macOS Ventura to macOS Sonoma. , when they are connected to the company networks. Investigation learns that the getaddrinfo call querying ipv6 is taking 5 seconds before returning. Querying information for ipv4 (ai_famlly AF_UNSPEC) returns in few mSec correct. For ipv6, I tried struct addrinfo ai_family AF_INET6 and ai_flags AI_DEFAULT , as well as AI_ALL but no help. Querying for ipv6 lasts 5 seconds. Is there a fix or workaround for this? When switching off Wi-Fi , the getaddrinfo returns in few mSec ( similar to the ipv4 check ). The version is macOS Sonoma 14.6.1 , but also observed on other Sonoma 14.x versions and other sites/companies worldwide.

Hello, I recently upgraded my iPhone 13 to iOS 18.0, and I've encountered an issue with VPN applications. After downloading and installing the required certificate for the VPN, I noticed that it does not appear in the "Certificate Trust Settings." Because of this, I am unable to mark the certificate as "trusted," which results in the VPN application's features not functioning properly. This issue is critical for my VPN usage, and it was not present in previous iOS versions. Could you please provide guidance or suggest a solution to this problem? Thank you for your assistance!

Hello, I'm trying to implement a PIN request feature for a Sony TV in my iOS app. The goal is to keep the PIN entry window open on the TV until the user enters the PIN. However, I'm encountering an issue where the connection is closed immediately when using Swift's URLSession, while the same request works as expected in Postman. Here's my Swift code: let parameters = """ { "method": "actRegister", "params": [ { "clientid": "MyDevice:1", "nickname": "My Device", "level": "private" }, [ { "value": "yes", "function": "WOL" } ] ], "id": 1, "version": "1.0" } """ guard let postData = parameters.data(using: .utf8) else { completion(.failure(NSError(domain: "Invalid data", code: 0, userInfo: nil))) return } var request = URLRequest(url: URL(string: "http://\(ipAddress)/sony/accessControl")!,timeoutInterval: 30) request.addValue("application/json", forHTTPHeaderField: "Content-Type") request.httpMethod = "POST" request.httpBody = postData let task = URLSession.shared.dataTask(with: request) { data, response, error in if let error = error { completion(.failure(error)) return } guard let data = data else { completion(.failure(NSError(domain: "No data received", code: 0, userInfo: nil))) return } if let responseString = String(data: data, encoding: .utf8) { print("Response: \(responseString)") } } task.resume() When I send this request using Postman, the PIN window on the TV stays open as expected. I receive a 401 response, which is normal for this type of request. In Postman, I can simulate the unwanted behavior by sending the request twice in quick succession, which closes the PIN window. However, when I run this code in the iPhone Simulator, the PIN window on the TV closes immediately after appearing. What I've tried: Increasing the timeoutInterval Using URLSession.shared.dataTask and URLSession(configuration:delegate:delegateQueue:) Implementing URLSessionDataDelegate methods Expected behavior: The PIN window should stay open on the TV until the user enters the PIN or a timeout occurs. Actual behavior: The PIN window appears briefly on the TV and then closes immediately. Questions: Why does the behavior differ between Postman and my Swift code? How can I modify my Swift code to keep the connection open and the PIN window displayed on the TV? Is there a way to prevent URLSession from automatically closing the connection after receiving the 401 response? Any insights or suggestions would be greatly appreciated. Thank you! Environment: iOS 15+ Swift 5 Xcode 13+

Hi all, My co-worker today noticed that on his Mac running a beta of Sequoia, the IPv6 multicast functionality of our application was no longer working. This same executable works fine under Sonoma and earlier versions of MacOS, and has worked fine for a number of years. Under Sequoia, however, calls to sendto() a packet to an IPv6-link-local-multicast address (e.g. ff12::bead:cede:deed:feed, preceeded by a call to setsockopt(fd, IPPROTO_IPV6, IPV6_MULTICAST_IF, ...) to specify the appropriate network interface index) return -1 and set errno to EHOSTUNREACH aka "No route to host". The interesting thing about it is, this problem only occurs if we launch our app by double-clicking on its icon; if we instead run the app from Terminal (e.g. by entering ./MyApp.app/Contents/MacOS/MyApp), the multicast functionality works as expected. Our app is signed and notarized in all the usual expected ways. My question is, is this "just" a networking regression in the Sequoia beta, or is there some new requirement in macOS/Sequoia for IPv6-link-local-multicast-using apps to have a multicast entitlement (a la iOS) or something?

Hi all, I'm developing an TCP socket SDK in C. The SDK is using Apple Network Framework and encountered some wired bad access issue occasionally on function nw_connection_send. Looking into the trace stack, it was bad access issue in nw_write_request_create, when it is trying to release a reference. However, I could not found more doc/source code details about nw_write_request_create. // on socket destroy, we will release the related nw_connection. increase_ref_count(socket) nw_connection_t nw_connection = socket->nw_connection; dispatch_data_t data = dispatch_data_create(message_ptr->ptr, message_ptr->len, dispath_event_loop, DISPATCH_DATA_DESTRUCTOR_FREE); // > Bad Access here < // While I check `nw_connection` and `data`, both seems available while the function get called. I tried to call dispatch_retain on `data`, but it was not helpful. nw_connection_send( nw_connection, data, NW_CONNECTION_DEFAULT_MESSAGE_CONTEXT, false, ^(nw_error_t error) { // process the message, we will release message_buf in this function. completed_fn(message_buf); reduce_ref_count(socket) } While I check nw_connection and data, both seems available while the function get called. I tried to call dispatch_retain on data, but it was not helpful. Is there any way to narrow down which object is releasing? As the issue happened occasionally (9 failure out of 10 attempts when I run multiple unit tests at the same time, and I rarely see it when I ran a single unit test). I would assume it was actually a race condition here. Is there a way to track down which object is released? I do understand it would be hard to track without knowing more design details of my SDK, but any related suggestions or ideas would be appreciated. Thanks in advance. More related source code: struct nw_socket{ nw_connection_t nw_connection; nw_parameters_t socket_options_to_params; dispatch_queue_t event_loop; // ... bunch of other parameters... struct ref_count ref_count; } static int s_socket_connect_fn( const struct socket_endpoint *remote_endpoint, struct dispatch_queue_t event_loop) { nw_socket = /*new socket memory allocation, increasing ref count*/ nw_endpoint_t endpoint = nw_endpoint_create_address(/* process remote_endpoint */); nw_socket->nw_connection = nw_connection_create(endpoint, nw_socket >socket_options_to_params); nw_release(endpoint); nw_socket->nw_connection->set_queue(nw_socket->nw_connection, event_loop); nw_socket->event_loop = event_loop; nw_connection_set_state_changed_handler(nw_socket->nw_connection, ^(nw_connection_state_t state, nw_error_t error) { // setup connection handler } nw_connection_start(nw_socket->nw_connection); nw_retain(nw_socket->nw_connection); } // nw_socket is ref counted, call the destroy function on ref_count reduced to 0 static void s_socket_impl_destroy(void *sock_ptr) { struct nw_socket *nw_socket = sock_ptr; /* Network Framework cleanup */ if (nw_socket->socket_options_to_params) { nw_release(nw_socket->socket_options_to_params); nw_socket->socket_options_to_params = NULL; } if (nw_socket->nw_connection) { nw_release(nw_socket->nw_connection); // Print here, to make sure the nw_connection was not released before nw_connection_send call. nw_socket->nw_connection = NULL; } // releasing memory and other parameters } static int s_socket_write_fn( struct nw_socket *socket, const struct bytePtr* message_ptr, // message_ptr is a pointer to allocated message_buf socket_on_write_completed_fn *completed_fn, void *message_buf) { // Ideally nw_connection would not be released, as socket ref_count is retained here. increase_ref_count(socket->ref_count); nw_connection_t nw_connection = socket->nw_connection; struct dispatch_queue_t dispatch_event_loop = socket->event_loop; dispatch_data_t data = dispatch_data_create(message_ptr->ptr, message_ptr->len, dispath_event_loop, DISPATCH_DATA_DESTRUCTOR_FREE); // > Bad Access here < // While I check `nw_connection` and `data`, both seems available while the function get called. I tried to call dispatch_retain on `data`, but it is not helpful. nw_connection_send( nw_connection, data, NW_CONNECTION_DEFAULT_MESSAGE_CONTEXT, false, ^(nw_error_t error) { // process the message, we will release message_buf in this function. completed_fn(message_buf); reduce_ref_count(socket) } }

as part of the iOS 17 apple added Network details capability to the shortcut app is there any update about the ability of getting the Network details such as RSSI , PHY in iOS 18?

The app needs to maintain internet communication under the following conditions: Both Wi-Fi and cellular networks are active. The Wi-Fi network has no internet connection. The cellular network has an active internet connection.

I have created a NEPacketTunnelProvider which seems to work currently in testing. However I have noticed that the DNS do not go through the TUN interface, even setting a bogus DNS server in NEPacketTunnelNetworkSettings still has no effect and I'm able to browse just fine. I also know that there is the DNS Proxy Provider, can it be used in conjuction with Packet Tunnel Provider? Though from what I have read this is not available for the general public and can only be used on supervised / managed devices? Are there any supported methods of running a local DNS server, say on 127.0.0.1 and redirect all DNS queries to this server?

BEHAVIOR App runs great on first install. If I close the app and reopen, many times the network requests fail, most likely due to too many open files. If I restart the app 4 times, everything seems to load fine (until next time). A fresh install works as well. APP Flutter app. Utilizes flutter map package, which displays map tile layers. Otherwise, pulls JSON/API data every so often. Heavy/frequent pulling of tile images (typically ~1000 during a single pan). PROBLEM DEVICES: Issues ONLY happens on physical iPhones (tested on 11 and 15). iOS simulators work fine. Androids work fine On the Androids or simulator, I can pan the map and pull 3000+ tile images, and overlay data, with no issues. TESTING I have inspected disposal methods, closing network clients, even tried "exit(0)" in various places. Have tried app lifecycle widgets on paused, detached, resumed. Nothing changes the behavior. At one point, I thought I had the issue fixed when I changed my DNS from 1.1.1.1 to automatic, since all the working devices seemed to have router-defined DNS and my test device had manual IP. But then the problem came back again. COMMON ERRORS (upon restart) SocketException: Connection failed (OS Error: Too many open files, errno = 24) SocketException: Failed host lookup: 'site.com' (OS Error: nodename nor servname provided, or not known, errno = 8) Sometimes failed to load assets as well (icons, etc). QUESTIONS What is being "fixed" by reopening the app 4 times in a row on the iOS side? Is there anything I can do in the native code, so that the app always restarts fresh, and doesn't "hang on" to anything that may be causing the OS Errors? Could it be an IPv4 / IPv6 issue? REFERENCES I did recently find this dart thread as well, not sure if it is fully the same issue: https://github.com/dart-lang/http/issues/197 Flutter Map Repo for Tile Layers: https://github.com/fleaflet/flutter_map/tree/7632ccc6d95cf4b0d02760f6d259495e7a1d09d0/lib/src/layer/tile_layer DIO Package: https://pub.dev/packages/dio

Hello, We have filtering logic that is being loaded into PacketTunnelProvider network extension for processing web traffic. The issue we are facing is the 50MB cap is being hit after browsing a few websites and the OS terminates the PacketTunnelProvider. What would be the best way to tackle this problem? A few ideas come to mind and would appreciate any support on them: using IPC (Inter Process Communication) to move the filtering logic back to the main app (if this is possible) we could move the filtering in Filter Control Provider however the limitation on there is that we cannot perform HTTP response modification which is imperative for the workings of the filtering. We have same solution working fine on Android and app is using about 270MB in worst case (however in Android there is no limit to network extension as the VPN provider runs inside the app) The project target market is in excess of 50,000 devices We would appreciate any support on the matter.

Hi,team: I am testing a product and found that my 12.6.0 and 14.5.0 computers will cause other app processes to exit when starting my network filter, but 10, 11, 13, and 14.6.1 will not. I can see the exit log of the app from launchd.log. Why is this? The log is as follows: 2024-09-12 19:34:36.783374 (gui/501/app_bundleid [546]) : exited due to SIGPIPE | sent by App[546] 2024-09-12 19:34:36.783383 (gui/501/app_bundleid [546]) : service state: exited 2024-09-12 19:34:36.783386 (gui/501/app_bundleid [546]) : internal event: EXITED, code = 0 2024-09-12 19:34:36.783389 (gui/501/app_bundleid [546]) : job state = exited 2024-09-12 19:34:36.783411 (gui/501 [100005]) : service inactive: app_bundleid 2024-09-12 19:34:36.783414 (gui/501/app_bundleid [546]) : service state: not running 2024-09-12 19:34:36.783582 (pid/546 [App]) : shutting down

The latest version of macOS 15 is unable to retrieve the SSID. We need to consult with Apple regarding this issue: Question: Is there a way for macOS to silently retrieve the SSID and BSSID? If special permissions are required, can company devices with MDM/ABM installed retrieve them silently?

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. 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 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.

I've been wondering what is the memory limit for network extensions. Specifically, I'm using the NEPacketTunnelProvider extension point.The various posts on this forum mention 5 MB and 6 MB for 32-bit and 64-bit respectively. However I find that (at least on iOS 10) the upper limit seems to be 15 MB. Is this the new memory limit for extensions?