Hello everybody! I'm currently working on a Bluetooth Low Energy Sync that is using BGTaskScheduler & successfully running periodically in the Background on iOS 26. I did watch this years WWDC Session 227 (Finish tasks in the background) & follow the recommendations as suggested. Currently, the App is only using 37 Mb (iPhone 12 mini) & no Location or other services are running in Background. However, when opening Safari & scrolling through some webpages, the App is killed because of "Terminated due to memory issue". I profiled the App & followed advice when it comes to reducing the memory footprint of the App. Are there any additional steps I can take to prevent the App being killed? Are there any recommendations for periodically scheduled Tasks when it comes to the Interval? Do more frequent Tasks (30min compared to one or two hours) have any impact? I tried many different schedules but none seem to make a difference. From my observation, the App is first suspended & eventually killed because of the Memory Pressure. Any hints, suggestions or recommendations are highly appreciated! Thanks a lot for the support!

We're developing an Electron app for MacOS App Store. When updating our app through TestFlight, TestFlight prompts "Close This App to Update", and when I click "Continue" our app would be "Terminated" for update. Now this is where things go wrong. On MacOS 15 our app seems to be gracefully terminating (We attached it with lldb and it shows that our app returns with 0 when we click "Continue") which is fine. However for MacOS 26 though, it seems that TestFlight just directly SIGKILLs our app (indicated by lldb), which means that all of our app's child processes are left orphaned. Even worse, our app is singleton, which means that when the app relaunches it fails, because the leftover child processes from the previously SIGKILLed session is still alive, and even if we want to kill those orphaned child processes we can't because our app is sandboxed thus cannot kill processes outside of the current sandbox. We captured output from log stream (app name redacted): 12-02 22:08:16.477036-0800 0x5452     Default     0x5a4a7              677    7    installcoordinationd: [com.apple.installcoordination:daemon] -[IXSCoordinatorProgress setTotalUnitsCompleted:]: Progress for coordinator: [com.our.app/Invalid/[user-defined//Applications/OurApp.app]], Phase: IXCoordinatorProgressPhaseLoading, Percentage: 99.454 123: Attempt to set units completed on finished progress: 214095161 2025-12-02 22:08:16.483056-0800 0x53ba     Default     0x5a5c9              167    0    runningboardd: (RunningBoard) [com.apple.runningboard:connection] Received termination request from [osservice<com.apple.installcoordinationd(274)>:677] on <RBSProcessPredicate <RBSProcessBundleIdentifierPredicate "com.our.app">> with context <RBSTerminateContext| explanation:installcoordinationd app:[com.our.app/Invalid/[user-defined//Applications/OurApp.app]] uuid:A3BC0629-124E-4165-ABB7-1324380FC354 isPlaceholder:N re portType:None maxTerminationResistance:Absolute attrs:[ 2025-12-02 22:08:16.488651-0800 0x53ba     Default     0x5a5c9              167    7    runningboardd: (RunningBoard) [com.apple.runningboard:ttl] Acquiring assertion targeting system from originator [osservice<com.apple.installcoordinationd(274)>:677] with description <RBSAssertionDescriptor| "installcoordinationd app:[com.our.app/Invalid/[user-defined//Applications/OurApp.app]] uuid:A3BC0629-124E-4165-ABB7-1324380FC354 isPlaceholder:N" ID:167-677-1463 target:system attributes:[ 2025-12-02 22:08:16.489353-0800 0x53ba     Default     0x5a5c9              167    0    runningboardd: (RunningBoard) [com.apple.runningboard:process] [app<application.com.our.app.485547.485561(501)>:2470] Terminating with context: <RBSTerminateContext| explanation:installcoordinationd app:[com.our.app/Invalid/[user-defined//Applications/OurApp.app]] uuid:A3BC0629-124E-4165-ABB7-1324380FC354 isPlaceholder:N reportType:None maxTerminationResistance:Absolute attrs:[ 2025-12-02 22:10:23.920869-0800 0x5a5a     Default     0x5a4c6              674    14   appstoreagent: [com.apple.appstored:Library] [A95D57D7] Completed with 1 result: <ASDApp: 0xc932a8780>: {bundleID = com.our.app; completedUnitCount = 600; path = /Applications/OurApp.app; installed = 0} 2025-12-02 22:10:32.027304-0800 0x5ae5     Default     0x5a4c7              674    14   appstoreagent: [com.apple.appstored:Library] [BEB5F2FD] Completed with 1 result: <ASDApp: 0xc932a8780>: {bundleID = com.our.app; completedUnitCount = 600; path = /Applications/OurApp.app; installed = 0} 2025-12-02 22:10:36.542321-0800 0x5b81     Default     0x5a4c8              674    14   appstoreagent: [com.apple.appstored:Library] [185B9DD6] Completed with 1 result: <ASDApp: 0xc932a8780>: {bundleID = com.our.app; completedUnitCount = 600; path = /Applications/OurApp.app; installed = 0} The line "Terminating with context" seems suspicious. This line is not seen on MacOS 15, only MacOS 26. Is this documented behavior? If so, how can we handle this?

Hi everyone, I have a question regarding the intended privacy limits of the DeviceActivityReportExtension. According to the documentation and the WWDC21 session "Meet the Screen Time API", this extension was created specifically to prevent the host application from accessing the user's underlying activity data (websites visited, app usage, screen time, etc). But I have found that my host app is actually able to reconstruct this raw activity data from the activity report. I am able to extract specific visited websites and app usage durations back into the main app. I reported this to Apple Security (Case ID: OE1100504480881 ), assuming it was a sandbox bypass. However, they closed the ticket stating that this is "expected behavior" and requires no fix. My question for Screen Time Engineers: Is the documentation incorrect? If my host app is expected to be able to read this data, is there a formal API we should be using instead of extracting it from the report extension? The current behavior contradicts the privacy limits described in the documentation, so I am confused if I should rely on this data access for my app features or if it will be patched later. Thanks.

Problem description Since macOS Sequoia, our users have experienced issues with multicast traffic in our macOS app. Regularly, the app starts but cannot receive multicast, or multicast eventually stops mid-execution. The app sometimes asks again for Local Network permission, while it was already allowed so. Several versions of our app on a single machine are sometimes (but not always) shown as different instances in the System Settings > Privacy & Security > Local Network list. And when several instances are shown in that list, disabling one disables all of them, but it does not actually forbids the app from receiving multicast traffic. All of those issues are experienced by an increasing number of users after they update their system from macOS 14 to macOS 15 or 26, and many of them have reported networking issues during production-critical moments. We haven't been able to find the root cause of those issues, so we built a simple test app, called "FM Mac App Test", that can reproduce multicast issues. This app creates a GCDAsyncUdpSocket socket to receive multicast packets from a piece of hardware we also develop, and displays a simple UI showing if such packets are received. The app is entitled with "Custom Network Protocol", is built against x86_64 and arm64, and is archived (signed and notarized). We can share the source code if requested. Out of the many issues our main app exhibits, the test app showcases some: The app asks several times for Local Network permission, even after being allowed so previously. After allowing the app's Local Network and rebooting the machine, the System Settings > Privacy & Security > Local Network does not show the app, and the app asks again for Local Network access. The app shows a different Local Network Usage Description than in the project's plist. Several versions of the app appear as different instances in the Privacy list, and behave strangely. Toggling on or off one instance toggles the others. Only one version of the app seems affected by the setting, the other versions always seem to have access to Local Network even when the toggle is set to off. We even did see messages from different app versions in different user accounts. This seems to contradicts Apple's documentation that states user accounts have independent Privacy settings. Can you help us understand what we are missing (in terms of build settings, entitlements, proper archiving...) so our app conforms to what macOS expects for proper Local Network behavior? Related material Local Network Privacy breaks Application: this issue seemed related to ours, but the fix was to ensure different versions of the app have different UUIDs. We ensured that ourselves, to no improvement. Local Network FAQ Technote TN3179 Steps to Reproduce Test App is developed on Xcode 15.4 (15F31d) on macOS 14.5 (23F79), and runs on macOS 26.0.1 (25A362). We can share the source code if requested. On a clean install of macOS Tahoe (our test setup used macOS 26.0.1 on a Mac mini M2 8GB), we upload the app (version 5.1). We run the app, make sure the selected NIC is the proper one, and open the multicast socket. The app asks us to allow Local Network, we allow it. The alert shows a different Local Network Usage Description than the one we set in our project's plist. The app properly shows packets are received from the console on our LAN. We check the list in System Settings > Privacy & Security > Local Network, it includes our app properly allowed. We then reboot the machine. After reboot, the same list does not show the app anymore. We run the app, it asks again about Local Network access (still with incorrect Usage Description). We allow it again, but no console packet is received yet. Only after closing and reopening the socket are the console packets received. After a 2nd reboot, the System Settings > Privacy & Security > Local Network list shows correctly the app. The app seems to now run fine. We then upload an updated version of the same app (5.2), also built and notarized. The 2nd version is simulating when we send different versions of our main app to our users. The updated version has a different UUID than the 1st version. The updated version also asks for Local Network access, this time with proper Usage Description. A 3rd updated version of the app (5.3, also with unique UUID) behaves the same. The System Settings > Privacy & Security > Local Network list shows three instances of the app. We toggle off one of the app, all of them toggle off. The 1st version of the app (5.1) does not have local network access anymore, but both 2nd and 3rd versions do, while their toggle button seems off. We toggle on one of the app, all of them toggle on. All 3 versions have local network access.

Hello, I have a problem with a subscription: it is not recognised by my application (under TestFlight); it is as if it did not exist. I have two subscriptions in the same group, a premium subscription that works perfectly and a basic subscription that is not recognised. I have checked everything at least twenty times. Its status is ‘Ready to submit’. I asked GPT 5.1 and Claude AI, but clearly both of their AIs are out of date and are giving me an obsolete procedure with App Store Connect options that don't exist.

App intent has a perform method that is async and can throw an error, but I can't find a way to actually await the result and catch the error if needed. If I convert this working but non-waiting, non-catching code: Button("Go", intent: MyIntent()) to this (so I can control awaiting and error handling): Button("Go") { Task { do { try await MyIntent().perform() // 👈 } catch { print(error) } } } It crashes: AppDependency with key "foo" of type Bar.Type was not initialized prior to access. Dependency values can only be accessed inside of the intent perform flow and within types conforming to _SupportsAppDependencies unless the value of the dependency is manually set prior to access. Although it is invalid since the first version is working like a charm and dependencies are registered in the @main App init method and it is in the perform flow. So how can we await the result of the AppIntent and handle the errors if needed in the app? Should I re-invent the Dependency mechanism?

Hello, I'm using PassKit with to perform Apple Pay payment in a financial application. Our approach are: On iOS application, define PKMerchantCapability threeDSecure and credit, perform apple pay experience and get the encrypted response. On PCI service, receive the encrypted data Payment token, decrypt this data, and use to perform the payment. The problem is, in MasterCard transaction the eciIndicator is missing. I want to know if has some rule or problem about it.

Hi everyone, I'm building a task management app that layers on top of EventKit/Reminders. I'm also moderating /r/AppleReminders. I see a confusion around the semantics of dates on both the developer side and on the user side. I'm trying to map the standard productivity mental model to the EKReminder implementation and hitting some walls. In productivity contexts, a task tends to have three distinct dates: Start Date: When the task becomes actionable — Don’t alert the user before this date. Notification: When the device should buzz/ping the user — Meaning that they can get started on the task. Due Date: Hard deadline — If the system works well, tasks are meant to rarely be past-deadline; productivity systems are about meeting deadlines rather than about missing them. The EventKit Reality Here is what I’m seeing in practice, and I’m hoping someone can correct me if I’m wrong: Field Description In Practice (Reminders App) startDateComponents Docs say "start date of the task" Seemingly unused? I can set it via API, but the Reminders app UI ignores it. It doesn't seem to trigger visibility in "Today" or Smart Lists. dueDateComponents Docs say "date by which reminder should be completed" Conflated. Acts as the "Date" you see in the list. It functions as the Start Date (shows in Today), Due Date (turns red tomorrow), AND Notification time (unless early alerts are set). alarms Inherited from EKCalendarItem seems to be used for the actual notifications, including "Early Reminders," but tightly coupled to the due date in the UI. My Questions: Is startDateComponents effectively a dead field? Is there any native behavior (Smart List filtering, sorting, visibility) that respects this field, or is it purely for metadata storage for third-party apps? Smart List Logic: I was hoping to create a Smart List that shows "Actionable" items (i.e., Start Date <= Today). However, the Smart List filters only offer a generic "Date" field, which maps to dueDateComponents. Has anyone successfully filtered by startDateComponents in a native Smart List? Conflation: Is there any "blessed" way to set a Due Date that is distinct from the Notification time without fighting the system? (e.g. Due Friday, but remind me Wednesday). Any insight into the intended semantics here would be huge. I'm trying to avoid fighting the framework, but the "One Date to Rule Them All" approach in the Reminders app is making it tricky to support separate Start/Due dates. Thanks!

LiveActivity using colorScheme to adapt to dark mode in iOS 26 system does not work The system keeps returning. mark, unable to switch

I have been working on a multi-platform multi-touch HID-standard digitizer clickpad device. The device uses Bluetooth Low Energy (BLE) as its connectivity transport and advertises HID over GATT. To date, I have the device working successfully on Windows 11 as a multi-touch, gesture-capable click pad with no custom driver or app on Windows. However, I have been having difficulty getting macOS to recognize and react to it as a HID-standard multi-touch click pad digitizer with either the standard Apple HID driver (AppleUserHIDEventDriver) or with a custom-coded driver extension (DEXT) modeled, based on the DTS stylus example and looking at the IOHIDFamily open source driver(s). The trackpad works with full-gesture support on Windows 11 and the descriptors seem to be compliant with the R23 Accessory Guidelines document, §15. With the standard, matching Apple AppleUserHIDEventDriver HID driver, when enumerating using stock-standard HID mouse descriptors, the device works fine on macOS 14.7 "Sonoma" as a relative pointer device with scroll wheel capability (two finger swipe generates a HID scroll report) and a single button. With the standard, matching Apple AppleUserHIDEventDriver HID driver, when enumerating using stock-standard HID digitizer click/touch pad descriptors (those same descriptors used successfully on Windows 11), the device does nothing. No button, no cursor, no gestures, nothing. Looking at ioreg -filtb, all of the key/value pairs for the driver match look correct. Because, even with the Apple open source IOHIDFamily drivers noted above, we could get little visibility into what might be going wrong, I wrote a custom DriverKit/HIDDriverKit driver extension (DEXT) (as noted above, based on the DTS HID stylus example and the open source IOHIDEventDriver. With that custom driver, I can get a single button click from the click pad to work by dispatching button events to dispatchRelativePointerEvent; however, when parsing, processing, and dispatching HID digitizer touch finger (that is, transducer) events via IOUserHIDEventService::dispatchDigitizerTouchEvent, nothing happens. If I log with: % sudo log stream --info --debug --predicate '(subsystem == "com.apple.iohid")' either using the standard AppleUserHIDEventDriver driver or our custom driver, we can see that our input events are tickling the IOHIDNXEventTranslatorSessionFilter HID event filter, so we know HID events are getting from the device into the macOS HID stack. This was further confirmed with the DTS Bluetooth PacketLogger app. Based on these events flowing in and hitting IOHIDNXEventTranslatorSessionFilter, using the standard AppleUserHIDEventDriver driver or our custom driver, clicks or click pad activity will either wake the display or system from sleep and activity will keep the display or system from going to sleep. In short, whether with the stock driver or our custom driver, HID input reports come in over Bluetooth and get processed successfully; however, nothing happens—no pointer movement or gesture recognition. STEPS TO REPRODUCE For the standard AppleUserHIDEventDriver: Pair the device with macOS 14.7 "Sonoma" using the Bluetooth menu. Confirm that it is paired / bonded / connected in the Bluetooth menu. Attempt to click or move one or more fingers on the touchpad surface. Nothing happens. For the our custom driver: Pair the device with macOS 14.7 "Sonoma" using the Bluetooth menu. Confirm that it is paired / bonded / connected in the Bluetooth menu. Attempt to click or move one or more fingers on the touchpad surface. Clicks are correctly registered. With transducer movement, regardless of the number of fingers, nothing happens.

操作步骤：1:调用let eligible = try await AgeRangeService.shared.isEligibleForAgeFeatures，返回YES后，再次调用 let response = try await AgeRangeService.shared.requestAgeRange(ageGates:18, in: viewController) switch response { case .declinedSharing: DispatchQueue.main.async { completion(.declinedSharing, nil, nil) } case .sharing(let swiftRange): DispatchQueue.main.async { let model = ARAgeRange(swiftRange: swiftRange) completion(.sharing, model, nil) }

[MTAgeRangeService requestEligibility:^(BOOL eligible) { if (eligible) { //您应用程序的用户所在的地区，需要执行特定年龄相关义务 [MTAgeRangeService requestAgeRangeWithAgeGates:18 in:[ViewU getCurrentVC] completion:^(enum ARResponseType responseType, ARAgeRange * _Nullable ageRange, NSError * _Nullable error) { [weakself.ageRangeLoadingView dissmiss]; self->_ageRangeLoadingView = nil; if (responseType == ARResponseTypeSharing) { //用户同意并分享了年龄范围 if ([ageRange.lowerBound intValue] >= 18) { //满18岁可以注册 }else{ //不到18岁不能注册，提示一下 } }else{ //用户拒绝或者其他未知错误，需要提示 }else{ } } }] ; }else{ }];

I'm facing a problem where notification permissions are working fine in the main app, but failing in the Device Activity Report Extension on iOS 26. This issue wasn’t present in earlier iOS versions. Despite having notification permissions granted in the main app, the extension fails to get authorization. iOS 26: " Before iOS 26:

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" Network Interface APIs Most developers don’t need to interact directly with network interfaces. If you do, read this post for a summary of the APIs available to you. Before you read this, read Network Interface Concepts. Interface List The standard way to get a list of interfaces and their addresses is getifaddrs. To learn more about this API, see its man page. A network interface has four fundamental attributes: A set of flags — These are packed into a CUnsignedInt. The flags bits are declared in <net/if.h>, starting with IFF_UP. An interface type — See Network Interface Type, below. An interface index — Valid indexes are greater than 0. A BSD interface name. For example, an Ethernet interface might be called en0. The interface name is shared between multiple network interfaces running over a given hardware interface. For example, IPv4 and IPv6 running over that Ethernet interface will both have the name en0. WARNING BSD interface names are not considered API. There’s no guarantee, for example, that an iPhone’s Wi-Fi interface is en0. You can map between the last two using if_indextoname and if_nametoindex. See the if_indextoname man page for details. An interface may also have address information. If present, this always includes the interface address (ifa_addr) and the network mask (ifa_netmask). In addition: Broadcast-capable interfaces (IFF_BROADCAST) have a broadcast address (ifa_broadaddr, which is an alias for ifa_dstaddr). Point-to-point interfaces (IFF_POINTOPOINT) have a destination address (ifa_dstaddr). Calling getifaddrs from Swift is a bit tricky. For an example of this, see QSocket: Interfaces. IP Address List Once you have getifaddrs working, it’s relatively easy to manipulate the results to build a list of just IP addresses, a list of IP addresses for each interface, and so on. QSocket: Interfaces has some Swift snippets that show this. Interface List Updates The interface list can change over time. Hardware interfaces can be added and removed, network interfaces come up and go down, and their addresses can change. It’s best to avoid caching information from getifaddrs. If thats unavoidable, use the kNotifySCNetworkChange Darwin notification to update your cache. For information about registering for Darwin notifications, see the notify man page (in section 3). This notification just tells you that something has changed. It’s up to you to fetch the new interface list and adjust your cache accordingly. You’ll find that this notification is sometimes posted numerous times in rapid succession. To avoid unnecessary thrashing, debounce it. While the Darwin notification API is easy to call from Swift, Swift does not import kNotifySCNetworkChange. To fix that, define that value yourself, calling a C function to get the value: var kNotifySCNetworkChange: UnsafePointer<CChar> { networkChangeNotifyKey() } Here’s what that C function looks like: extern const char * networkChangeNotifyKey(void) { return kNotifySCNetworkChange; } Network Interface Type There are two ways to think about a network interface’s type. Historically there were a wide variety of weird and wonderful types of network interfaces. The following code gets this legacy value for a specific BSD interface name: func legacyTypeForInterfaceNamed(_ name: String) -> UInt8? { var addrList: UnsafeMutablePointer<ifaddrs>? = nil let err = getifaddrs(&addrList) // In theory we could check `errno` here but, honestly, what are gonna // do with that info? guard err >= 0, let first = addrList else { return nil } defer { freeifaddrs(addrList) } return sequence(first: first, next: { $0.pointee.ifa_next }) .compactMap { addr in guard let nameC = addr.pointee.ifa_name, name == String(cString: nameC), let sa = addr.pointee.ifa_addr, sa.pointee.sa_family == AF_LINK, let data = addr.pointee.ifa_data else { return nil } return data.assumingMemoryBound(to: if_data.self).pointee.ifi_type } .first } The values are defined in <net/if_types.h>, starting with IFT_OTHER. However, this value is rarely useful because many interfaces ‘look like’ Ethernet and thus have a type of IFT_ETHER. Network framework has the concept of an interface’s functional type. This is an indication of how the interface fits into the system. There are two ways to get an interface’s functional type: If you’re using Network framework and have an NWInterface value, get the type property. If not, call ioctl with a SIOCGIFFUNCTIONALTYPE request. The return values are defined in <net/if.h>, starting with IFRTYPE_FUNCTIONAL_UNKNOWN. Swift does not import SIOCGIFFUNCTIONALTYPE, so it’s best to write this code in a C: extern uint32_t functionalTypeForInterfaceNamed(const char * name) { int fd = socket(AF_INET, SOCK_DGRAM, 0); if (fd < 0) { return IFRTYPE_FUNCTIONAL_UNKNOWN; } struct ifreq ifr = {}; strlcpy(ifr.ifr_name, name, sizeof(ifr.ifr_name)); bool success = ioctl(fd, SIOCGIFFUNCTIONALTYPE, &ifr) >= 0; int junk = close(fd); assert(junk == 0); if ( ! success ) { return IFRTYPE_FUNCTIONAL_UNKNOWN; } return ifr.ifr_ifru.ifru_functional_type; } Finally, TN3158 Resolving Xcode 15 device connection issues documents the SIOCGIFDIRECTLINK flag as a specific way to identify the network interfaces uses by Xcode for device connection traffic. Revision History 2025-12-10 Added info about SIOCGIFDIRECTLINK. 2023-07-19 First posted.

Hi Team, We have a requirement for device-to-device communication using the Multipeer Connectivity framework without requiring Wi- Fi connectivity. Current Status: Multipeer communication works successfully when Wi-Fi is enabled Connection fails when using Bluetooth-only (Wi-Fi disabled, in Airplane Mode) Concern: We've found forum suggesting that Multipeer Connectivity over Bluetooth-only has been restricted since iOS 11, despite Apple's documentation stating support for both Wi-Fi and Bluetooth transports. Request: Could you please confirm: Whether Bluetooth-only Multipeer Connectivity is officially supported in current iOS versions( iOS 18.0+)? If there are specific configurations or entitlements required for Bluetooth-only operation? Any known limitations or alternative approaches for offline device-to-device communication? This clarification will help us determine the appropriate implementation strategy for our offline communication requirements. Thank you.

Hi there, I'm trying to work on an architecture where one app exposes an API (Extension Host) that other apps can plugin to. I've been reading all I can from the docs and whatever I can find online. It seemed like iOS26 added the ability to do such a thing (at least in early builds). Is that the case? Has the functionality been walked back such that extensions can only be loaded in iOS from within the single app bundle? My use case is the following: I'm working on an agent app that desires to have 3rd party developers add functionality (think how MCP servers add functionality to LLMs). The 3rd party plugins would be provided in their own app bundles vetted by the AppStore review team, of course, and would only provide hooks, basically, the main app can use to execute functions or get state. This is the best thread I found on the topic, and the subtext is that it needs to be in the same bundle. https://developer.apple.com/forums/thread/803896?answerId=865314022#865314022 Let's say for the moment that this isn't possible using ExtensionKit. What's the best way to achieve this? Our current best alternative idea is a hidded WebKit window that runs JS/WASM but that's so hackish. Please let me know, thanks!

Summary NetworkConnection<WebSocket> in iOS 26 Network framework throws POSIXErrorCode(rawValue: 22): Invalid argument when receiving WebSocket ping (opcode 9) or pong (opcode 10) control frames. This prevents proper WebSocket keep-alive functionality. Environment iOS 26.0 (Simulator) macOS 26.1 Xcode 26.0 Note: This issue was initially discovered on iOS 26 Simulator. The same behavior was confirmed on macOS 26, suggesting a shared bug in the Network framework. The attached sample code is for macOS for easier reproduction. Description When using the new NetworkConnection<WebSocket> API introduced in iOS 26 or macOS 26, the receive() method throws EINVAL error whenever a ping or pong control frame is received from the server. This is a critical issue because: WebSocket servers commonly send ping frames to keep connections alive Clients send ping frames to verify connection health The receive callback never receives the ping/pong frame - the error occurs before the frame reaches user code Steps to Reproduce Create a WebSocket connection to any server that supports ping/pong (e.g., wss://echo.websocket.org): import Foundation import Network // MARK: - WebSocket Ping/Pong EINVAL Bug Reproduction // This sample demonstrates that NetworkConnection<WebSocket> throws EINVAL // when receiving ping or pong control frames. @main struct WebSocketPingPongBug { static func main() async { print("=== WebSocket Ping/Pong EINVAL Bug Reproduction ===\n") do { try await testPingPong() } catch { print("Test failed with error: \(error)") } } static func testPingPong() async throws { let host = "echo.websocket.org" let port: UInt16 = 443 print("Connecting to wss://\(host)...") let endpoint = NWEndpoint.hostPort( host: NWEndpoint.Host(host), port: NWEndpoint.Port(rawValue: port)! ) try await withNetworkConnection(to: endpoint, using: { WebSocket { TLS { TCP() } } }) { connection in print("Connected!\n") // Start receive loop in background let receiveTask = Task { var messageCount = 0 while !Task.isCancelled { do { let (data, metadata) = try await connection.receive() messageCount += 1 print("[\(messageCount)] Received frame - opcode: \(metadata.opcode)") if let text = String(data: data, encoding: .utf8) { print("[\(messageCount)] Content: \(text)") } else { print("[\(messageCount)] Binary data: \(data.count) bytes") } } catch let error as NWError { if case .posix(let code) = error, code == .EINVAL { print("❌ EINVAL error occurred! (POSIXErrorCode 22: Invalid argument)") print(" This is the bug - ping/pong frame caused EINVAL") // Continue to demonstrate workaround continue } print("Receive error: \(error)") break } catch { print("Receive error: \(error)") break } } } // Wait for initial message from server try await Task.sleep(for: .seconds(2)) // Test 1: Send text message (should work) print("\n--- Test 1: Sending text message ---") try await connection.send("Hello, WebSocket!") print("✅ Text message sent") try await Task.sleep(for: .seconds(1)) // Test 2: Send ping (pong response will cause EINVAL) print("\n--- Test 2: Sending ping frame ---") print("Expecting EINVAL when pong is received...") let pingMetadata = NWProtocolWebSocket.Metadata(opcode: .ping) try await connection.ping(Data()) { pingMetadata } print("✅ Ping sent, waiting for pong...") // Wait for pong response try await Task.sleep(for: .seconds(2)) // Cleanup receiveTask.cancel() print("\n=== Test Complete ===") print("If you saw 'EINVAL error occurred!' above, the bug is reproduced.") } } } The receive() call fails with error when pong arrives: ❌ EINVAL error occurred! (POSIXErrorCode 22: Invalid argument) Test Results Scenario Result Send/receive text (opcode 1) ✅ OK Client sends ping, receives pong ❌ EINVAL on pong receive Expected Behavior The receive() method should successfully return ping and pong frames, or at minimum, handle them internally without throwing an error. The autoReplyPing option should allow automatic pong responses without disrupting the receive loop. Actual Behavior When a ping or pong control frame is received: The receive() method throws NWError.posix(.EINVAL) The frame never reaches user code (no opcode check is possible) The connection remains valid, but the receive loop is interrupted Workaround Catch the EINVAL error and restart the receive loop: while !Task.isCancelled { do { let received = try await connection.receive() // Process message } catch let error as NWError { if case .posix(let code) = error, code == .EINVAL { // Control frame caused EINVAL, continue receiving continue } throw error } } This workaround allows continued operation but: Cannot distinguish between ping-related EINVAL and other EINVAL errors Cannot access the ping/pong frame content Cannot implement custom ping/pong handling Impact WebSocket connections to servers that send periodic pings will experience repeated EINVAL errors Applications must implement workarounds that may mask other legitimate errors Additional Information Packet capture confirms ping/pong frames are correctly transmitted at the network level The error occurs in the Network framework's internal processing, before reaching user code

Recent our APP performance online has revealed significant degradation in cellular network SRTT (Smoothed Round-Trip Time) on the latest iPhone models (iPhone 18.1, 18.2, and 18.3) relative to previous generation devices. IDC network transmission SRTT P50 increased by 10.64%, P95 increased by 103.41%; CDN network transmission SRTT P50 increased by 12.66%, P95 increased by 81.08%. Detailed Performance Metrics: 1. Network Transmission SRTT Degradation Following optimization of our APP's network library, iOS network transmission SRTT showed improvement from mid-August through mid-September. However, starting September 16, cellular network SRTT metrics began to degrade (SRTT increased). This degradation affects both IDC and CDN routes. WiFi network performance remains unaffected. 2. Excluding iOS 26.x Version Data After data filtering, we discovered that the increase in iOS cellular network transmission SRTT was caused by data samples from iOS 26.x versions. When excluding iOS 26.x version data, network transmission SRTT shows no growth. 3. Comparative Analysis: iOS 26.x vs. iOS < 26.0 network transmission SRTT shows： IDC (Internet Data Center) Links: P50 latency: 10.64% increase / P95 latency: 103.41% increase CDN (Content Delivery Network) Links: P50 latency: 12.66% increase / P95 latency: 81.08% increase 4. Device-Model Analysis: iOS 26.x SRTT Degradation Scope Granular analysis of iOS 26.x samples across different device models reveals that network SRTT degradation is not universal but rather specific to certain iPhone models. These measurements indicate a substantial regression in network performance across both data center and content delivery pathways.

In iOS AP-mode onboarding for IOT devices, why does the iPhone sometimes stay stuck on the device Wi-Fi (no internet) and fail to route packets to the device’s local IP, even though SSID is correct? Sub-questions to include: • Is this an iOS Wi-Fi auto-join priority issue? • Can AP networks become “sticky” after multiple joins? • How does iOS choose the active routing interface when Wi-Fi has no gateway? • Why does the packet never reach the device even though NWPath shows WiFi = satisfied?

We are facing a DNS resolution issue with a specific ISP, where our domain name does not resolve correctly using the system DNS. However, the same domain works as expected when a custom DNS resolver is used. On Android, this is straightforward to handle by configuring a custom DNS implementation using OkHttp / Retrofit. I am trying to implement a functionally equivalent solution in native iOS (Swift / SwiftUI). Android Reference (Working Behavior) : val dns = DnsOverHttps.Builder() .client(OkHttpClient()) .url("https://cloudflare-dns.com/dns-query".toHttpUrl()) .bootstrapDnsHosts(InetAddress.getByName("1.1.1.1")) .build() OkHttpClient.Builder() .dns(dns) .build() Attempted iOS Approach I attempted the following approach : Resolve the domain to an IP address programmatically (using DNS over HTTPS) Connect directly to the resolved IP address Set the original domain in the Host HTTP header DNS Resolution via DoH : func resolveDomain(domain: String) async throws -> String {     guard let url = URL(         string: "https://cloudflare-dns.com/dns-query?name=\(domain)&type=A"     ) else {         throw URLError(.badURL)     }     var request = URLRequest(url: url)     request.setValue("application/dns-json", forHTTPHeaderField: "accept")     let (data, _) = try await URLSession.shared.data(for: request)     let response = try JSONDecoder().decode(DNSResponse.self, from: data)     guard let ip = response.Answer?.first?.data else {         throw URLError(.cannotFindHost)     }     return ip } API Call Using Resolved IP :  func callAPIUsingCustomDNS() async throws {     let ip = try await resolveDomain(domain: "example.com")     guard let url = URL(string: "https://(ip)") else {         throw URLError(.badURL)     }     let configuration = URLSessionConfiguration.ephemeral     let session = URLSession(         configuration: configuration,         delegate: CustomURLSessionDelegate(originalHost: "example.com"),         delegateQueue: .main     )     var request = URLRequest(url: url)     request.setValue("example.com", forHTTPHeaderField: "Host")     let (_, response) = try await session.data(for: request)     print("Success: (response)") } Problem Encountered When connecting via the IP address, the TLS handshake fails with the following error: Error Domain=NSURLErrorDomain Code=-1200 "A TLS error caused the secure connection to fail." This appears to happen because iOS sends the IP address as the Server Name Indication (SNI) during the TLS handshake, while the server’s certificate is issued for the domain name. Custom URLSessionDelegate Attempt :  class CustomURLSessionDelegate: NSObject, URLSessionDelegate {     let originalHost: String     init(originalHost: String) {         self.originalHost = originalHost     }     func urlSession(         _ session: URLSession,         didReceive challenge: URLAuthenticationChallenge,         completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void     ) {         guard challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodServerTrust,               let serverTrust = challenge.protectionSpace.serverTrust else {             completionHandler(.performDefaultHandling, nil)             return         }         let sslPolicy = SecPolicyCreateSSL(true, originalHost as CFString)         let basicPolicy = SecPolicyCreateBasicX509()         SecTrustSetPolicies(serverTrust, [sslPolicy, basicPolicy] as CFArray)         var error: CFError?         if SecTrustEvaluateWithError(serverTrust, &error) {             completionHandler(.useCredential, URLCredential(trust: serverTrust))         } else {             completionHandler(.cancelAuthenticationChallenge, nil)         }     } } However, TLS validation still fails because the SNI remains the IP address, not the domain. I would appreciate guidance on the supported and App Store–compliant way to handle ISP-specific DNS resolution issues on iOS. If custom DNS or SNI configuration is not supported, what alternative architectural approaches are recommended by Apple?