I was excited to find out about Wi-Fi Aware in i[Pad]OS 26 and was eager to experiment with it. But after wiping and updating two devices (an iPhone 11 Pro and a 2018 11" iPad Pro) to Beta 1 I found out that neither of them support Wi-Fi Aware 🙁. What current and past iPhone and iPad models support Wi-Fi Aware? And is there a new UIRequiredDeviceCapabilities key for it, to indicate that an app requires a Wi-Fi Aware capable device?

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 all, WWDC 2025 introduced Wi‑Fi Aware (NAN) support on iOS 26 for peer-to-peer discovery and direct connections, but I noticed macOS Tahoe doesn’t include it. I couldn’t find any references to Wi‑Fi Aware APIs or framework support in the macOS SDK. Is Apple planning to bring Wi‑Fi Aware to macOS? If so, will this come in a future update to macOS 26 (e.g., 26.x), or is it deferred to macOS 27 or beyond? Thanks for any insights!

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?

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?

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!

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

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.

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?

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!

Hello there, I am trying to add Nearby Interaction into my project, but it is not appear into +capabilities. I have already go to my account into developer account platform to try to add it from Identifiers: Then I search into my project to activated, but Nearby Interaction was not show: So, there is anything else that i have miss? please help :c

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.

Hello, I am currently investigating if we can disable usage of QUIC on application level. I know we can set enable_quic from /Library/Preferences/com.apple.networkd.plist to false but it will have a global impact since this is a system file, all the applications on machine will stop using QUIC. I don't want that. What i am looking for is to disable QUIC only for my application. Is there any way i can modify URLSession object in my application and disable QUIC? or modify URLSessionConfiguration so system will not use QUIC?

I cannot find in the documentation and samples how exactly the Bloom filter is generated. Is there any code sample for that?

My company has a server that supports ticket-based TLS session resumption (per RFC 5077). We have done Wireshark captures that show that our iOS client app, which uses URLSession for REST and WebSocket connections to the server, is not sending the TLS "session_ticket" extension in the Client Hello package that necessary to enable ticket-based resumption with the server. Is it expected that URLSession does not support ticket-based TLS session resumption? If "yes", is there any way to tell URLSession to enable ticket-based session resumption? the lower-level API set_protocol_options_set_tls_tickets_enabled() hints that the overall TLS / HTTP stack on IOS does support ticket-based resumption, but I can't see how to use that low-level API with URLSession. I can provide (lots) more technical details if necessary, but hopefully this is enough context to determine whether ticket-based TLS resumption is supported with URLSession. Any tips / clarifications would be greatly appreciated.

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?

Our goal is to establish a Wi‑Fi Aware data path (NDP) between Apple and Android devices. Apple will act as the Publisher, and Android will act as the Subscriber. Apple-to-Android pairing has already been completed. The Android device can be normally displayed on the Apple official Wi-Fi Aware Sample. However, the indicator is not green. During pairing, the Apple log shows: state: authenticated, and the Android side triggers the callback onPairingSetupSucceeded. During pairing verification, the Apple log shows: state: authenticated, and the Android side triggers the callback onPairingVerificationSucceed. The Android side sends an NDP request to Apple (as shown in the figure 1), but Apple does not reply. Note: Qualcomm’s NDI and NMI are different. In addition, after Apple-to-Apple pairing is completed, the paired device will be recorded in “Settings → Privacy &amp; Security → Paired Devices”. However, after Android-to-Apple pairing is completed, the device is not saved to this list. My iPhone model: iPhone 13, iOS 26.0 (23A5287g).

After Apple-to-Apple pairing is completed, the paired device will be recorded in “Settings → Privacy &amp; Security → Paired Devices”. However, after Android-to-Apple pairing is completed, the device is not saved to this list. Android device can be normally displayed on the Apple official Wi-Fi Aware Sample. However, the indicator is not green. During pairing, the Apple log shows: state: authenticated, and the Android side triggers the callback onPairingSetupSucceeded. During pairing verification, the Apple log shows: state: authenticated, and the Android side triggers the callback onPairingVerificationSucceed. My iPhone is iPhone 13， iOS 26.0 （23A5287g）

I am in the middle of investigating an issue arising in the call to setsockopt syscall where it returns an undocumented and unexpected errno. As part of that, I'm looking for a way to list any socket content filters or any such extensions are in play on the system where this happens. To do that, I ran: systemextensionsctl list That retuns the following output: 0 extension(s) which seems to indicate there's no filters or extensions in play. However, when I do: netstat -s among other things, it shows: net_api: 2 interface filters currently attached 2 interface filters currently attached by OS 2 interface filters attached since boot 2 interface filters attached since boot by OS ... 4 socket filters currently attached 4 socket filters currently attached by OS 4 socket filters attached since boot 4 socket filters attached since boot by OS What would be the right command/tool/options that I could use to list all the socket filters/extensions (and their details) that are in use and applicable when a call to setsockopt is made from an application on that system? Edit: This is on a macosx-aarch64 with various different OS versions - 13.6.7, 14.3.1 and even 14.4.1.

We use as content filter in our app to monitor flows, we gather data about the flow and block flows deemed suspicious. Our content filter is activated/deactivated by a UI app but the flows are reported via XPC to a separate daemon process for analysis. As of macOS 15, we are seeing cases where flows are missing or flows are not received at all by the content filter. The behaviour is not consistent, some devices seem to receive flows normally but others don't. It appears Intel devices are much less prone to showing the problem, whereas Arm devices routinely exhibit missing flows. On macOS 14 or earlier, there is no sign of missing flows. Testing on earlier beta versions of macOS 15 did not appear to show the problem, however I can't rule out if issue was present but it wasn't spotted. Experimenting with simple examples of using a content filter (e.g. QNE2FilterMac) does not appear to reproduce the issue. Questions, What has changed between macOS 14 and 15 that could be the cause of the lack of flows? Is our approach to using an app activated content filter reporting to a daemon connected via XPC unsupported?