I'm trying to distribute a sandboxed macOS app with a PacketTunnelProvider (system extension) via direct distribution (outside of AppStore). The app and the extension both use the same app group, using the new group.com.XXXX.YYYY format detailed here for 10.15+ https://developer.apple.com/forums/thread/721701 I've also followed the instructions below to get around the quirk of not being able to directly process it via XCode: https://developer.apple.com/forums/thread/737894 I've re-signed with Developer ID certificate, all that is smooth and successfully notarized. However upon running the app I get: "My.app" would like to access data from other apps. Checking ~/Library/Containers ~/Library/Group Containers I see the correct files folders have been created before I select Don't Allow and Allow. My app does not access any files or folders outside of the sandboxed directories. How can I prevent this from happening? In order to diagnose further, how to diagnose exactly which files/folder the app is trying to access that is causing this problem?

Hello, We're exploring the new URL Filter capability and we managed change the SimpleURLFilter so that it could work on macOS. However, on macOS it won't work as even when signed for debugging it tries to use Apple's OHTTP Relay. Failed to fetch Token Issuer Directory. <NSHTTPURLResponse: 0xca10ca580> { URL: https://gateway.icloud.com/pat-issuer-directory?issuer=localhost } { Status Code: 503 So I have two questions: Will it be possible to debug URL Filter locally on macOS? Even more important: how can I send a capability request so that our OHTTP Gateway could be used? I checked everywhere, but it seems there's simply no way to request this capability at this moment.

We are experiencing a large number of crashes in our production environment, mainly occurring on iOS 16 systems and iPhone 8 and iPhone X devices. The crash log and stack trace are as follows: Error: Assertion failed: (false) function _onqueue_rdar53306264_addWaiter file TubeManager.cpp line 1042 Crashed: com.apple.CFNetwork.LoaderQ 0 libsystem_kernel.dylib 0x7198 __pthread_kill + 8 1 libsystem_pthread.dylib 0xd5f8 pthread_kill + 208 2 libsystem_c.dylib 0x1c4b8 abort + 124 3 libsystem_c.dylib 0x70d8c err + 266 4 CFNetwork 0x1eb80 CFURLRequestSetMainDocumentURL + 6288 5 CFNetwork 0x44fd8 CFURLCacheRemoveAllCachedResponses + 22624 6 CFNetwork 0x39460 _CFHostIsDomainTopLevel + 968 7 CFNetwork 0x1f754 CFURLRequestSetMainDocumentURL + 9316 8 CFNetwork 0x233e0 CFURLRequestSetRequestPriority + 8792 9 CFNetwork 0x20d38 CFURLRequestCopyHTTPRequestBodyStream + 1612 10 CFNetwork 0x4f950 CFHTTPCookieStorageCopyCookies + 16276 11 CFNetwork 0x15878 CFURLRequestSetURL + 7600 12 libdispatch.dylib 0x637a8 _dispatch_call_block_and_release + 24 13 libdispatch.dylib 0x64780 _dispatch_client_callout + 16 14 libdispatch.dylib 0x3f6fc _dispatch_lane_serial_drain$VARIANT$armv81 + 600 15 libdispatch.dylib 0x401e4 _dispatch_lane_invoke$VARIANT$armv81 + 432 16 libdispatch.dylib 0x41304 _dispatch_workloop_invoke$VARIANT$armv81 + 1620 17 libdispatch.dylib 0x49f14 _dispatch_workloop_worker_thread + 608 18 libsystem_pthread.dylib 0x1bd0 _pthread_wqthread + 284 19 libsystem_pthread.dylib 0x1720 start_wqthread + 8 Have you encountered a similar issue before?

Hi everyone, I’m currently developing a macOS app that is distributed via a DMG file on our website. The app includes an App Extension (appex) for Network Extension functionality. I’m wondering if distributing via DMG on the web requires the app extension to be implemented as a System Extension instead of an App Extension. Is it necessary to migrate to System Extension for web-based DMG distribution, or can I continue using App Extension as is? Any insights or recommendations would be greatly appreciated. Thank you!

I'm writing an application that implements a Bonjour service and browser for the purpose of connecting to Logic Pro and interacting with a MIDI Device Script. Because it's connecting to Logic Pro running on the same system as the application, the service and browser do not need to access anything else on the local network. I'm creating the service and browser with calls like this: err = DNSServiceRegister( &serviceRef, 0, kDNSServiceInterfaceIndexLocalOnly, "MyService", "_osc._udp", "local", nullptr, 52854, txtLen, txtRecord, static_cast<DNSServiceRegisterReply>(myCallback), context ); err = DNSServiceBrowse( &browserRef, 0, kDNSServiceInterfaceIndexLocalOnly, "_osc._udp", nullptr, static_cast<DNSServiceBrowseReply>(browserCallback), context ); Despite the fact that I'm passing in kDNSServiceInterfaceIndexLocalOnly for the network interface, it still triggers an "Allow 'Application' to find devices on local networks?" permissions prompt. How can I avoid that prompt? It is both a significant failure point (in case users don't notice it or click 'Don't Allow' by mistake) but it may also scare them away, since it strongly implies my application is scanning devices on the local network, even though it's doing no such thing!

Im working on ios application that works with BLE device. The device uses BLE indications to provide data to the app. The goal is to achieve 100% data retrieval. According to the hardware team device behaves like this: CCCD Persistence: Device maintains Client Characteristic Configuration Descriptor (CCCD) with indication-enabled state across reconnections Resume Point: Device resends indications starting from the last unacknowledged indication before disconnection No Custom Logic: Follows standard BLE specification for indication reliability So it is expected that the device restores the indication streams from the last acknowledged one. My connection routine is: Discover services func centralManager(_ central: CBCentralManager, didConnect peripheral: CBPeripheral) { connectedPeripherals[peripheral.identifier] = peripheral peripheral.delegate = self updatePeripheralState(peripheral.identifier, to: .connected) print("Starting service discovery...") peripheral.discoverServices(nil) } Discover characteristics: func peripheral(_ peripheral: CBPeripheral, didDiscoverCharacteristicsFor service: CBService, error: Error?) { if let error = error { print("Characteristic discovery failed for service \(service.uuid): \(error.localizedDescription)") return } guard let characteristics = service.characteristics else { return } for characteristic in characteristics { if service.uuid == targetServiceUUID && characteristic.uuid == targetCharacteristicUUID { print("Found target characteristic! Enabling indications...") peripheral.setNotifyValue(true, for: characteristic) print(characteristic.properties.description) } } } Then the data retrieval: func peripheral(_ peripheral: CBPeripheral, didUpdateValueFor characteristic: CBCharacteristic, error: Error?) { if let error = error { print("Error reading characteristic value: \(error.localizedDescription)") return } if characteristic.service?.uuid == targetServiceUUID && characteristic.uuid == targetCharacteristicUUID { if let data = characteristic.value { let formatter = DateFormatter() formatter.timeStyle = .medium formatter.dateStyle = .none // data filtering since device is sending some other events sometims if data.count >= 15 { let event = decodeBytes(bytes: data) let now = Date() let timestamp = timestampFormatter.string(from: now) print("[\(timestamp)] Auto Increment: \(event.autoIncrement) Type: \(event.type)") } } else { print("Received indication with no data") } } } Using PacketLogger from xcode toolbox i have confirmed that: The device starts sending indications right after didConnect finishes The phone is sending ACKS for those indications Indications are not reaching didUpdateValueFor until peripheral.setNotifyValue(true, for: characteristic) properly executes This mekes me drop some data data on each reconnect. I already know I can do better in terms of service and characteristics discovery: I should discover only that one which is giving me the indications. But my intuition is: discover only the service and characteristic i care about will minimize the impact, but not guarantee 100% data retrieval Is this expected and confirmed CoreBluetooth behavior?

iPhone 12 pro with iOS 26.0 (23A5276f) App: https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps We aim to use Wi-Fi Aware to establish file transfer between Android and Apple devices. Apple will act as the Publisher, and Android will act as the Subscriber. According to the pairing process outlined in the Wi-Fi Aware protocol (Figure 49 in the Wi-Fi Aware 4.0 specification), the three PASN Authentication frames have been successfully exchanged. Subsequently, Android sends the encrypted Follow-up PMF to Apple, but the Apple log shows: Failed to parse event. Please refer to the attached complete log. We request Apple to provide a solution. apple Log-20250808a.txt

Is Apple's Wi-Fi Aware certified by the Wi-Fi Alliance? Is there any non-compliance of Apple's Wi-Fi Aware with the Wi-Fi Alliance standards? Does Apple have a roadmap to switch AWDL to Wi-Fi Aware? Does Apple have plans to adopt Wi-Fi Aware in Mac computers?

I’m trying to use the TLS Session Resumption feature in TLS 1.2 and 1.3. I first tested this on iOS, but it didn’t work as expected. To investigate via packet capture, I ran the same code on macOS and saw the same issue. Using URLSession to establish a WebSocket connection, I captured packets in Wireshark to check if Session Resumption was working. The behavior differed from what I expected: 1st TLS handshake – Client Hello does not contain the session_ticket extension (required for session resumption per the TLS spec). 2nd TLS handshake – Client Hello does not contain a pre_shared_key. Test apps: https://github.com/sf-jed-kyung/tls-session-resumption-test Test environment: Xcode 16.3, macOS 15.6, OpenSSL 3.5.1 This repo contains: tls-urlsession-macos – WebSocket via URLSession (shows missing extensions). tls-openssl-macos – Manual TLS handshake via OpenSSL (shows both session_ticket and pre_shared_key). To run this, adjust Header Search Paths and Library Search Paths for your local OpenSSL install. URLSession – 1st Client Hello Transport Layer Security TLSv1.3 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 512 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 508 Version: TLS 1.2 (0x0303) Random: 0502b10cf04223658... Session ID Length: 32 Session ID: e3b276b14f2deaced... Cipher Suites Length: 42 Cipher Suites (21 suites) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 393 ... Extension: server_name (len=26) name=echo.websocket.events Extension: extended_master_secret (len=0) Extension: renegotiation_info (len=1) Extension: supported_groups (len=12) Extension: ec_point_formats (len=2) Extension: application_layer_protocol_negotiation (len=11) Extension: status_request (len=5) Extension: signature_algorithms (len=22) Extension: signed_certificate_timestamp (len=0) Extension: key_share (len=43) x25519 Extension: psk_key_exchange_modes (len=2) Extension: supported_versions (len=7) TLS 1.3, TLS 1.2 Extension: compress_certificate (len=3) ... URLSession – 2nd Client Hello Transport Layer Security TLSv1.3 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 512 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 508 Version: TLS 1.2 (0x0303) Random: 1e485f35ad66c8598... Session ID Length: 32 Session ID: 99d02000c7ed403a5... Cipher Suites Length: 42 Cipher Suites (21 suites) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 393 ... Extension: server_name (len=26) name=echo.websocket.events Extension: extended_master_secret (len=0) Extension: renegotiation_info (len=1) Extension: supported_groups (len=12) Extension: ec_point_formats (len=2) Extension: application_layer_protocol_negotiation (len=11) Extension: status_request (len=5) Extension: signature_algorithms (len=22) Extension: signed_certificate_timestamp (len=0) Extension: key_share (len=43) x25519 Extension: psk_key_exchange_modes (len=2) Extension: supported_versions (len=7) TLS 1.3, TLS 1.2 Extension: compress_certificate (len=3) ... OpenSSL – 1st Client Hello Transport Layer Security TLSv1.3 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 1564 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 1560 Version: TLS 1.2 (0x0303) Random: aec30b0aad542252... Session ID Length: 32 Session ID: f7ee7178cab8716a625... Cipher Suites Length: 60 Cipher Suites (30 suites) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 1427 Extension: renegotiation_info (len=1) Extension: server_name (len=26) name=echo.websocket.events Extension: ec_point_formats (len=4) Extension: supported_groups (len=18) Extension: session_ticket (len=0) Extension: application_layer_protocol_negotiation (len=11) Extension: encrypt_then_mac (len=0) Extension: extended_master_secret (len=0) Extension: signature_algorithms (len=54) Extension: supported_versions (len=5) TLS 1.3, TLS 1.2 Extension: psk_key_exchange_modes (len=2) Extension: key_share (len=1258) X25519MLKEM768, x25519 OpenSSL – 2nd Client Hello Transport Layer Security TLSv1.3 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 1716 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 1712 Version: TLS 1.2 (0x0303) Random: 3fb3938a88166e4eb... Session ID Length: 32 Session ID: 7f13e54a231c17ccff70... Cipher Suites Length: 60 Cipher Suites (30 suites) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 1579 Extension: renegotiation_info (len=1) Extension: server_name (len=26) name=echo.websocket.events Extension: ec_point_formats (len=4) Extension: supported_groups (len=18) Extension: session_ticket (len=0) Extension: application_layer_protocol_negotiation (len=11) Extension: encrypt_then_mac (len=0) Extension: extended_master_secret (len=0) Extension: signature_algorithms (len=54) Extension: supported_versions (len=5) TLS 1.3, TLS 1.2 Extension: psk_key_exchange_modes (len=2) Extension: key_share (len=1258) X25519MLKEM768, x25519 Extension: pre_shared_key (len=148) Since the Client Hello is generated by the client, I believe the session_ticket should be included in the first handshake regardless of server support. However, URLSession omits it entirely. Question: How can I enable TLS Session Resumption when using URLSession?

With my UDP Flow Copier working as demonstrated by the fact that it is proxying DNS traffic successfully, I am finally writing tests to verify UDP packet filtering. I'm sending packets to a public UDP echo server and reading the response successfully. In my initial testing however the TransparentProxyProvider System Extension is not intercepting my UDP traffic. handleNewUDPFlow() is being called for DNS but not for my test case UDP echo sends and receives. I've tried sending UDP with both GCDAsyncSocket and NWConnection as: connection = NWConnection(host: host, port: port, using: .udp) Is there some other criteria for UDP datagrams to be intercepted? Google search suggests this might be a known issue for connected or async UDP sockets.

Hello everyone, I'm encountering a MultipeerConnectivity connection issue while developing a visionOS app and would like to ask if other developers have experienced similar problems. Problem Description In visionOS 26.0 Beta 3 and Beta 4, when a visionOS device attempts to connect to an iPad via MultipeerConnectivity, the iPad side completely fails to receive connection requests, resulting in connection establishment failure. Specific Symptoms After executing serviceBrowser?.invitePeer(peerID, to: mcSession, withContext: nil, timeout: 10.0) on the visionOS side The iPad side shows no response and receives no connection invitation Connection request times out after 10 seconds and is automatically rejected No error logs or exception information are generated Environment Information visionOS version: 26.0 Beta 3 and Beta 4 Development environment: macOS Tahoe 26.0 Beta (25A5306g) Target device: iPad (iOS 17.x) Network environment: Same WiFi network Comparative Test Results visionOS 2.6 (22O785): Functionality completely normal visionOS 26.0 Beta 1/2: Functionality normal visionOS 26.0 Beta 3/4: Exhibits the above problems Attempted Solutions Checked network configuration and firewall settings Adjusted MultipeerConnectivity parameters Reinitialized MCSession and MCNearbyServiceBrowser Cleared app cache and reinstalled Reset network settings Temporary Workaround Currently, the only solution is to downgrade the visionOS device to version 2.6. Impact of the Problem This issue severely affects the development of cross-device collaboration features in visionOS apps, particularly scenarios requiring peer-to-peer communication with iOS/iPadOS devices. Questions for Help Have other developers encountered similar issues? Are there any known solutions or workarounds? Is this a known issue with visionOS 26.0 Beta? Are there other known issues related to MultipeerConnectivity? Relevant Code Snippet // Connection invitation code private var serviceBrowser: MCNearbyServiceBrowser? let mcSession: MCSession // Execute connection invitation serviceBrowser?.invitePeer(peerID, to: mcSession, withContext: nil, timeout: 10.0) Thank you for your help and suggestions! Development Environment: Xcode 15.x Target Platform: visionOS

I have a custom VPN app that uses NETunnelProviderManager to install a VPN Profile if one is not already installed. On previous iOS versions this would open the VPN Settings and ask for either the PIN, FaceID or TouchID and install the profile. With iOS 26 beta5 it opens the VPN Settings and stops. Is this a bug in iOS 26? Have there been changes to NETunnelProviderManager for iOS 26 that I'm not aware of? FYI we do the samething on macOS 26 beta5 and that works as expected.

On iOS 26 beta 5, it is impossible to add a VPN configuration when a passcode is set on the device. Every time, all it does is redirect to the Settings app with no prompt for passcode. The only way around this is to disable passcode on the device so adding a VPN configuration doesn’t have to open the Settings app. This issue happened intermittently in the past with previous iOS 26 betas and even on iOS 18, but the problem has worsened on iOS 26 beta 5 to the point where you have to turn off passcode to add a VPN. Feedback ID: FB17974765

Issue summary: Iphone 16 is not connecting to WiFi7 AP with MLO Suiteb encryption. Furuno AP(EW750) is sending EAPOL M1 message, but Iphone16 is not responding with EAPOL M2 message, Hence Iphone16 is unable to connect to Qualcomm based AP with MLO suiteb encryption. Issue impact: All the Iphone16 users cannot connect to WiFi7 AP with MLO suiteb encryption globally. Predominantly, Iphone users tend to connect to more secured wifi networks using WPA3 suiteb encryption, hence many of the iphone users will experience the connectivity issue significantly. Topology: AP Hardware: Furuno WiFi7 AP(EW770) The Furuno WiFi7 AP uses Miami IPQ5332 with waikiki radio QCN9274 AP software: SPF12.2 CSU3 IPhone16 software: (18.3.1 or 18.5 ) Iphone16 wifi capabilities: 802.11 b/a/g/n/ac/ax/be Radius server details: Radius server: Laptop running with Ubuntu Radius package: 3.0.26dfsggit20220223.1.00ed0241fa-0ubuntu3.4 Version: 3.0.26 Steps: Power on the Wi-Fi 7 Access Point with the Miami chipset, and flash it with the SPF 12.2 CSU3 image. Enable both 5 GHz and 6 GHz radios on the AP. Enable MLO (Multi-Link Operation) in 6Ghz &amp; 5Ghz, set MLD address different from radio address and configure Suite-B (192-bit) encryption On the Linux laptop, set up the RADIUS server with EAP-TLS authentication method. Once the above steps are completed, take the iPhone 16 and follow the steps below to install the RADIUS client certificates on the device. On the sniffer laptop, switch the Wi-Fi adapter to monitor mode, configure the required channel, and begin packet capture. Check SSID is broadcasting, then connect the iPhone 16 to . Verify if the client (iPhone 16) connects to the SSID using WPA3-Enterprise, MLO, and Suite-B encryption by checking the wireless capture on both the AP and iPhone sides. Support needed from Apple team: We would request Apple team to analyse and enable the IPhone16 users to connect to advanced security WPA3 Suiteb by resolving the issue. Below is our analysis and observation for your reference. As per IEEE, MLD mac address can be set to the same or different from radio address, Iphone16 is not accepting EAPOL M1 message if source address(MLD) is different from radio address. IPhone16 is accepting EAPOL M1 if the source address(MLD) is set to the same as the radio address and responds with M2 message IPhone16 is not accepting EAPOL M1 if source address(MLD) set to different from radio address and fails to respond with M2 message

When setting new entitlements com.apple.developer.networking.carrier-constrained.appcategory and com.apple.developer.networking.carrier-constrained.app-optimized, I have a question about how URLSession should behave. I notice we have a way to specify whether a Network connection should allow ultra-constrained paths via NWParameters allowUltraConstrainedPaths: https://developer.apple.com/documentation/network/nwparameters/allowultraconstrainedpaths There does not appear to be a similar property on URLSessionConfiguration. In an ultra-constrained (eg. satellite) network, should we expect all requests made through an URLSession to fail? Does all network activity when ultra-constrained need to go through a NWConnection or NetworkConnection specifically configured with allowUltraConstrainedPaths, or can URLSession ever be configured to allow ultra-constrained paths?

Is it possible to capture or inspect UDP traffic using iOS content filter APIs (e.g., NEFilterDataProvider)? If not, what are the current technical or policy limitations that prevent UDP inspection via these frameworks? Any insights or suggestions on these topics would be highly appreciated.

Is it possible to capture or inspect UDP traffic using iOS content filter APIs (e.g., NEFilterDataProvider)? If not, what are the current technical or policy limitations that prevent UDP inspection via these frameworks? Any insights or suggestions on these topics would be highly appreciated.

Apologies if this is not the correct topic to post under. EpochField 5.2 is our application. It's a .NET MAUI application built against XCode 16. A customer of ours uses another app, TN3270, to connect to a mainframe host. After installing our app on an iPad and restarting the device, the TN3270 app will disconnect when suspended. Uninstalling our app (EpochField) will allow the TN3270 to suspend without disconnecting. We have tried removing background services, setting UIRequiresFullScreen to false or removing it entirely, and several other ideas. The only remedy seems to be uninstalling EpochField. On an iPad device: Install MochaSoft’s TN3270 app (free version is fine). Create a connection to ssl3270.nccourts.org, port 2023, SSL/TLS turned on, keep alive turned on. Verify that you can connect. Suspend the app by swiping up or choosing another app. Go back to TN3270 and verify that the app has not disconnected. Install EpochField 5.2. Do not run or configure the app, just install it. Repeat step 2. Restart the device. Open EpochField 5.2. You do not need to configure the app or login. Sometimes it isn't necessary to ever open EpochField to get the disconnects, but this is the most reliable way to reproduce the situation. Repeat step 2. The TN3270 app will now disconnect when suspended, even if EpochField is closed. You may need to wait a few seconds after suspending. Uninstall EpochField 5.2. Repeat step 2: the TN3270 app will now remain connected when suspended.

Samsung's Quick Share uses Wi-Fi Aware to achieve one-to-many concurrent sharing. Can Apple's Wi-Fi Aware achieve one-to-many concurrent sharing? Apple's AirDrop does support one-to-many concurrent sharing.

Hello everyone, I'm developing a macOS application with an integrated Content Filter System Extension. Both the main app and the extension are signed with a Developer ID Application provisioning profile. When building in Xcode, I'm encountering an entitlement mismatch error. I've inspected the provisioning profile using the command: security cms -D -i FilterContentExtension-prod-profile.provisionprofile | grep -A 10 com.apple.developer.networking.networkextension And found that the com.apple.developer.networking.networkextension section only contains values with the -systemextension suffix, for example: content-filter-provider-systemextension. However, when I enable Network Extension → Content Filter in Xcode, the .entitlements file is generated with: content-filter-provider. This leads to the error: "Provisioning profile 'FilterContentExtension-prod-profile' doesn't match the entitlements file’s value for the com.apple.developer.networking.networkextension entitlement." My specific questions are: Why does this error occur? How can I use the content-filter-provider entitlement? If I want to use the content-filter-provider entitlement inside com.apple.developer.networking.networkextension for my Content Filter System Extension, what should I do?