The documentation explains that the NEPacketTunnelProvider's sleepWithCompletionHandler: and wake methods are called when the device is going to sleep or waking up. The expectation is that the device will enter and remain in a sleep state for some extended period of time. On iOS 17 we're seeing the PacketTunnelProvider receive wake calls almost immediately. Is there a known issue where the PacketTunnelProvider does Not remain in a sleep state? In our logging, we see the PacketTunnelProvider is constantly alternating between sleep/wake states. On iOS 16, these methods are called on an average of 42 seconds apart from each other. In some cases, we do see the device in a sleep state for 2 to 3 minutes. On iOS 17, these methods are called on an average of 6 seconds apart from each other. The device only sleeps for a few seconds and Not for minutes. This will drain the battery. Will the app be charged for battery usage if the OS decides Not to remain in sleep mode? Is there a bug where the an iOS 17 device running a VPN will not stay in sleep mode? Also, we do Not modify the NEVPNProtocol's disconnectOnSleep field. ie Should be defaulting to NO On a device running iOS 16.3.1, with the screen locked and un-plugged from a power source PID 4574: across 9.6 minutes (576 seconds) Connected to Wi-Fi. 10 calls (5 sleep / 5 wake) Avg frequency of 57.6 seconds apart. PID 4581: across 10.3 minutes (616 seconds) Wi-Fi disabled, Connected to Cellular. 22 calls (11 sleep / 11 wake) Avg frequency of 28 seconds apart. PID 4600: across 10.6 minutes (635 seconds) Connected to Wi-Fi. 12 calls (6 sleep / 6 wake) Avg frequency of 52.92 seconds apart. (576 + 616 + 635) = 1827 seconds. (10 + 22 + 12) = 44 calls. 1827 / 44 = 41.52 seconds. On a device running iOS 17.0 (Build 21A5326a), connected to Wi-Fi: PID 14357: across 94.7 minutes (5682 seconds) 1034 calls (517 sleep / 517 wake) Avg frequency of 5.5 seconds apart. PID 14412: across 92.5 minutes (5547 seconds) 508 calls (254 sleep / 254 wake) Avg frequency of 10.9 seconds apart. PID 14721: across 92.5 minutes (5547 seconds) 1248 calls (624 sleep / 624 wake) Avg frequency of 4.4 seconds apart. (5682 + 5547 + 5547) = 16776 seconds. (1034 + 508 + 1248) = 2790 calls. 16776 / 2790 = 6.01 seconds.

How to code in the main app to call AppProxyProvider startProxy? The NEAppProxyProviderManager cannot be obtained in the main app, and there is no NEAppProxyProviderProtocol. What should I do

This post is part of the Local Network Privacy FAQ. Why does local network privacy get confused when I install two variants of my app? Local network privacy relies on NECP, a subsystem on Apple platforms that controls which programs have access to which network interfaces. For a brief introduction to this, see A Peek Behind the NECP Curtain. Internally, NECP uses a program’s main executable Mach-O UUID (LC_UUID) to track the identity of that program. If you have two programs with the same UUID, NECP might get confused (r. 30421029). This most commonly happens when you have two variants of the same app that you build from the same source code. For example, you might have a Pro and a Lite version of your app that use the same code. Or you might a core app implementation that you ‘skin’ for different customers by changing just the resources. If you encounter weird local network privacy interactions between two apps, check their LC_UUID values. To do this, run dwarfdump against the app’s main executable. For example: % dwarfdump --uuid Test725715-A.app/Test725715-A UUID: 2406B68D-B76A-3D70-8264-16F4A8E07DC0 (arm64) Test725715-A.app/Test725715-A % dwarfdump --uuid Test725715-B.app/Test725715-B UUID: D4D74EA8-FC68-3925-92AB-7B279DA095F9 (arm64) Test725715-B.app/Test725715-B Note While macOS doesn’t support local network privacy, duplicate UUIDs can cause weird problems with other NECP-based systems. macOS apps have a slightly different bundle structure, so insert Contents/MacOS/ in the path you pass to dwarfdump. For example, if you have a macOS app called Test725715-A, use the path Test725715-A.app/Contents/MacOS/Test725715. In this example the UUIDs are different, which is what you’d expect. If you see the same UUID for both apps, take steps to fix that. If you’re using Xcode, the easiest way to ensure that you have different UUIDs is to build your app from different source code. Here’s one approach that works: Create two source files, Unique-A.m and Unique-B.m. Add each file to its corresponding target. In each file define a string constant with the same name and a different value. For example, Unique-A.m might have: const char * gUnique = "Hello from app A!"; while Unique-B.m has: const char * gUnique = "Hello from app B!"; In your main function, add code to print that value: extern char * gUnique int main(…) { … printf("%s\n", gUnique); … } IMPORTANT Printing gUnique ensures that it’s not dead stripped. Now rebuild your apps and run the dwarfdump test again to confirm that each variant has a different UUID. Note This example is in Objective-C because this issue is less common with Swift code. That’s because in Swift the app’s name becomes the module name. This is reflected in the Swift runtime metadata, which is linked into the app, causing each app to have a different UUID. If you’re building your app with third-party tooling, consult the tool’s vendor as to how best to resolve this issue with their tools. Back to the FAQ

We gets NEPacket during packetFlow.readPacketObjects. Each packet contains src ip as packet tunnel utun virtual interface address. for example if packet tunnel utun address is 10.10.10.10, then src ip of every packet is 10.10.10.10. Can we configure packet tunnel in such a way that it gives src ip as ip assigned to system via dhcp/static (primary Ethernet interface en0) instead of 10.10.10.10? I want to do this because tunnel server uses this src ip to perform some business logic. What if we assigns primary Ethernet interface en0 address to packet tunnel utun address?

I have a content filter hosted as system extension. Once you go through initial approvals for system extension & network filter everything seems fine. But if I navigate to System Settings --> Network --> Filters & disable the network filter, I am not able to enable it back again. It just stays in yellow, it does not go back to green. Reboot does not help, in fact the network extension process does not even get spawned. This is not desirable at all Has anyone ran into this ? Workarounds : Uninstall the app & perform the installation again by approving prompts.

We're looking at taking a Network Extension VPN implemented as an App Extension, and porting it to a System Extension. We still intend to distribute through the app store as well, but have requests for out-of-store distribution. I remember seeing a thread about this some time back, but I haven't been able to locate it. If someone has a link to that thread please point me that way :-) We have some questions about bundle IDs, APIs, and entitlements, because we're looking to minimize customer disruption. Can we just add the SystemExtension entitlement to the current App ID for the network extension, update the profile, and continue with the same ID, or will we need to define a new ID? What will happen if someone installs the application from a package outside the app store, and then goes to the app store page for the application? Will the App Store recognize that the app is already installed? What about version differences? It looks like our management app can still use sendProviderMessage to communicate with the extension, and that we don't need XPC unless we want to give other applications the ability to talk with the extension. Is this correct? Can a System Extension use the NSWorkspace openURL API? It looks like a System Extension doesn't have the option of writing to a file, because it's not running as a logged in user and doesn't have access to a user's file systems. Is this correct? For certificate-based authentication the SystemExtension needs to be able to access and use a client certificate. Is there a recommended way for the extension to access the client certificate, e.g, if the extension starts without the GUI because of an on-demand VPN configuration? In that case it doesn't seem like it would have keychain access.

Hi, I have an app that implements the Cycling Power Service 1.1, https://www.bluetooth.com/de/specifications/specs/cycling-power-service-1-1/ As expected, I can select this app as a Health Device in the Bluetooth settings of my Apple Watch. However, when I run the BLE app on the paired iPhone, the Apple Watch does not detect the BLE Service as a Health Device! Is this a bug, or is it designed this way? If so, is there another API where I can send power meter data from iOS to a running Watch Workout?

I have a network system extension that sends flow records to my GUI app, and I saw an unusual string (%awdl0) appended to the local and remote IPv6 addresses in flow records from the UniversalControl program on my Intel iMac Pro. fe80::f42d:14ff:fe38:7db7%awdl0 fe80::18d7:9bff:feae:2e32%awdl0 Any idea why the suffix is appended to the IPv6 address and what it means? Here are more details about the event: { "localPort" : "56604", "socketProtocol" : 6, "version" : 0, "programLastComponent" : "UniversalControl", "localName" : "fe80::f42d:14ff:fe38:7db7%awdl0", "time" : 716847716.50096297, "socketType" : 1, "remotePort" : "57968", "socketFamily" : 30, "procInfo" : { "path" : "\/System\/Library\/CoreServices\/UniversalControl.app\/Contents\/MacOS\/UniversalControl", "lastComponent" : "UniversalControl", "teamId" : "", "signingId" : "" }, "timeStr" : "2023-09-19T20:21:56Z", "remoteName" : "fe80::18d7:9bff:feae:2e32%awdl0", "pid" : 667, "webHost" : "", "webUrl" : "" } And here is the flurry of flows reported including their ports:

I Found I can use Per App VPN without MDM using Test Per App VPN. I created a profile which contains VPNUUID, PayloadType, VPNTYPE, VPNSubType etc (profile attached & it is created manually ). when I sent profile using air drop to my iPhone (from my Mac). profile appears in settings to install. 2A. after this installation failed with the message: THE VPN SERVICE "VPN" could not be installed. Here is my info.plist of my source app <key>NETestAppMapping</key> <dict> <key>825886EA-BB00-4805-ADD6-1616161616</key> <array> <string>added the app ids for which I want to implement per App VPN like chrome and Firefox bundle identifier</string> </array> </dict> Here is my profile <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>PayloadContent</key> <array> <dict> <key>PayloadUUID</key> <string>E6671FFB-66C2-49F7-AB1B-CD5A0CD5A0</string> <key>PayloadType</key> <string>com.apple.vpn.managed.applayer</string> <key>PayloadIdentifier</key> <string>com.apple.vpn.managed.applayer.388257C2-7902-42B5-BDAE-6E69A441C3A2</string> <key>VPNType</key> <string>VPN</string> <key>VPNSubType</key> <string>Here bundle identifier of my source app Main target</string> <key>UserDefinedName</key> <string>VPN_CONFIG</string> <key>PayloadDescription</key> <string>VPN Configuring</string> <key>PayloadDisplayName</key> <string>VPN_Config</string> <key>PayloadVersion</key> <integer>1</integer> <key>VPNUUID</key> <string>825886EA-BB00-4805-ADD6-1616161616</string> </dict> </array> <key>PayloadDisplayName</key> <string>Name not set</string> <key>PayloadIdentifier</key> <string>Ignored</string> <key>PayloadRemovalDisallowed</key> <false /> <key>PayloadType</key> <string>Configuration</string> <key>PayloadUUID</key> <string>Ignored</string> <key>PayloadVersion</key> <integer>1</integer> </dict> </plist>

Our App is starting to crash (SIGABRT) with the following semaphore failure: _dispatch_semaphore_wait_slow + 132 that´s the stack trace of the affected threads: CrashReporter Key: 682241501eca714a73bcfc32a9fc72f3697580c2 Hardware Model: iPad8,3 Process: TapestryPRO [590] Path: /private/var/containers/Bundle/Application/19755567-CB9E-49C2-9506-C3087BB86227/TapestryPRO.app/TapestryPRO Identifier: com.t-mobile.Tapestry-PRO Version: 1.900.8 (1.900.8) Code Type: ARM-64 (Native) Role: Foreground Parent Process: launchd [1] Coalition: com.t-mobile.Tapestry-PRO [529] Date/Time: 2023-09-12 14:18:50.2918 -0400 Launch Time: 2023-09-12 14:17:34.2497 -0400 OS Version: iPhone OS 16.6.1 (20G81) Release Type: User Baseband Version: 5.03.01 Report Version: 104 Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: FRONTBOARD 2343432205 <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:scene-update watchdog transgression: application<com.t-mobile.Tapestry-PRO>:590 exhausted real (wall clock) time allowance of 10.00 seconds ProcessVisibility: Foreground ProcessState: Running WatchdogEvent: scene-update WatchdogVisibility: Foreground WatchdogCPUStatistics: ( "Elapsed total CPU time (seconds): 40.950 (user 40.950, system 0.000), 47% CPU", "Elapsed application CPU time (seconds): 0.300, 0% CPU" ) reportType:CrashLog maxTerminationResistance:Interactive> Triggered by Thread: 0 Kernel Triage: VM - (arg = 0x0) pmap_enter retried due to resource shortage Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libsystem_kernel.dylib 0x1ebc52c20 semaphore_wait_trap + 8 1 libdispatch.dylib 0x1b4a64448 _dispatch_sema4_wait + 28 2 libdispatch.dylib 0x1b4a64afc _dispatch_semaphore_wait_slow + 132 3 TapestryPRO 0x104fc70a8 -[TapestryServices serviceCallUsingRequest:] + 632 4 TapestryPRO 0x104fc6e18 -[TapestryServices serviceCallUsingMutableRequest:] + 232 5 TapestryPRO 0x104fc6c6c -[TapestryServices serviceCallUsingMutableRequestReturnData:] + 180 6 TapestryPRO 0x104fdf370 -[TapestrySSOAccess getStoreId:error:] + 948 7 TapestryPRO 0x104f2efcc -[TapestrySSO getStoreId:] + 416 8 TapestryPRO 0x104f34794 -[LoginViewController getStoreId] + 132 9 TapestryPRO 0x104f33fa4 __39-[LoginViewController handleSSOHandoff]_block_invoke_3 + 116 10 libdispatch.dylib 0x1b4a62320 _dispatch_call_block_and_release + 32 11 libdispatch.dylib 0x1b4a63eac _dispatch_client_callout + 20 12 libdispatch.dylib 0x1b4a726a4 _dispatch_main_queue_drain + 928 13 libdispatch.dylib 0x1b4a722f4 _dispatch_main_queue_callback_4CF + 44 14 CoreFoundation 0x1ad62fc28 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16 15 CoreFoundation 0x1ad611560 __CFRunLoopRun + 1992 16 CoreFoundation 0x1ad6163ec CFRunLoopRunSpecific + 612 17 GraphicsServices 0x1e822435c GSEventRunModal + 164 18 UIKitCore 0x1af9a2f58 -[UIApplication _run] + 888 19 UIKitCore 0x1af9a2bbc UIApplicationMain + 340 20 TapestryPRO 0x104fc8b3c main + 112 21 dyld 0x1ccb38dec start + 2220 Thread 1 name: Dispatch queue: com.apple.UIKit.KeyboardManagement Thread 1: 0 libsystem_kernel.dylib 0x1ebc537dc __ulock_wait + 8 1 libdispatch.dylib 0x1b4a6489c _dlock_wait + 56 2 libdispatch.dylib 0x1b4a64650 _dispatch_thread_event_wait_slow + 56 3 libdispatch.dylib 0x1b4a73714 __DISPATCH_WAIT_FOR_QUEUE__ + 368 4 libdispatch.dylib 0x1b4a732c0 _dispatch_sync_f_slow + 148 5 UIKitCore 0x1af9a322c __37-[_UIRemoteKeyboards startConnection]_block_invoke_3 + 156 6 CoreFoundation 0x1ad609c04 __invoking___ + 148 7 CoreFoundation 0x1ad5b7cb4 -[NSInvocation invoke] + 428 8 Foundation 0x1a79626f8 __NSXPCCONNECTION_IS_CALLING_OUT_TO_REPLY_BLOCK__ + 16 9 Foundation 0x1a7933a5c -[NSXPCConnection _decodeAndInvokeReplyBlockWithEvent:sequence:replyInfo:] + 520 10 Foundation 0x1a7ea4a00 __88-[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:]_block_invoke_5 + 188 11 libxpc.dylib 0x20c9baee4 _xpc_connection_reply_callout + 124 12 libxpc.dylib 0x20c9adee8 _xpc_connection_call_reply_async + 88 13 libdispatch.dylib 0x1b4a63f2c _dispatch_client_callout3 + 20 14 libdispatch.dylib 0x1b4a81e38 _dispatch_mach_msg_async_reply_invoke + 344 15 libdispatch.dylib 0x1b4a6b40c _dispatch_lane_serial_drain + 372 16 libdispatch.dylib 0x1b4a6c0d8 _dispatch_lane_invoke + 436 17 libdispatch.dylib 0x1b4a76cdc _dispatch_workloop_worker_thread + 648 18 libsystem_pthread.dylib 0x20c95addc _pthread_wqthread + 288 19 libsystem_pthread.dylib 0x20c95ab7c start_wqthread + 8

macOS allows you to independently distribute a Network Extension using Developer ID signing, but with an important wrinkle. This post explains that wrinkle, its affect on Xcode, and how you get around it. If you have questions or comments, put them in a new thread here on DevForums. Tag it with Network Extension so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Exporting a Developer ID Network Extension macOS supports a variety of Network Extension (NE) provider types. Starting with macOS 10.15, it’s possible to distribute an app containing NE providers independently, using Developer ID signing. See TN3134 Network Extension provider deployment for the full list of supported provider types. For your NE provider to work when distributed independently, it must: Be packaged as a system extension. Use Developer ID specific entitlements This post is focused on that second point, because it’s common source of confusion. This post assumes that you’re building your app with Xcode; if you’re building your app outside of Xcode, you’ll have to adapt these steps to your build system. Entitlement Matters A Network Extension system extension and its container app must be signed with the Network Extension entitlement (com.apple.developer.networking.networkextension). That entitlement is an array, with a variety of different element values based on the provider type. For example, a standard NE content filter provider must include the content-filter-provider value. There are two groups of these values: the standard ones and the ones with the -systemextension suffix. During development and for App Store distribution, use the appropriate standard value. For independent distribution using Developer ID, use the corresponding value with the -systemextension suffix. For example, a Developer ID signed NE content filter must use content-filter-provider-systemextension instead of content-filter-provider. Xcode Issues Xcode is currently not aware of this requirement. If you build your NE provider container app using Xcode, you might expect to export it for independent distribution using the Direct Distribution workflow in the Xcode organiser. This does not work (r. 108838909). To get around this, manually export your app from your Xcode archive. Before attempting that, there’s a few things to confirm: By default Xcode’s Signing & Capabilities editor uses the standard values for the NE entitlement. Leave them that way. During day-to-day development it’s best to use an Apple Development signing identity [1], and the standard values work with that. Continue to use Build > Archive [2] to create an Xcode archive for your product. The steps below replace the Direct Distribution workflow, and they assume you’re starting with an Xcode archive. [1] Don’t use Developer ID for day-to-day development; see The Care and Feeding of Developer ID for more on that topic. [2] Or, if you’re automating this, the archive action in xcodebuild. Assemble Your Assets Imagine you’re working on a content filter for the Mac called WaffleFilter. You’ve used Xcode to build the app into an Xcode archive: % ls "WaffleFilter.xcarchive／Products／Applications" WaffleFilter.app That app is development signed: % codesign -d -vvv "WaffleFilter.xcarchive／Products／Applications／WaffleFilter.app" … Authority=Apple Development: … … IMPORTANT The steps in this section are based on the much more comprehensive instructions in Creating Distribution-Signed Code for Mac. If anything is unclear, read that post for clarification. To re-sign this app for independent distribution you’ll need three things: A Developer ID application signing identity. This is named Developer ID Application: TTT, where TTT identifies your team. A Developer ID provisioning profile for the app. In this example I’ve called this WaffleFilter_Dev_ID.provisionprofile. A Developer ID provisioning profile for the system extension. In this example I’ve named this WaffleFilter_WFProvider_DevID.provisionprofile. If you’re not sure how to create these things, see Developer Account Help. Re-sign the App To start, make a copy of the app: % ditto "WaffleFilter.xcarchive／Products／Applications／WaffleFilter.app" "WaffleFilter.app" Dump the entitlements of the app and its embedded system extension: % codesign -d --entitlements "WaffleFilter.entitlements" --xml "WaffleFilter.app" % codesign -d --entitlements "WaffleFilter_WFProvider.entitlements" --xml "WaffleFilter.app／Contents／Library／SystemExtensions／com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension" And reformat them to make them more readable: % plutil -convert xml1 "WaffleFilter.entitlements" % plutil -convert xml1 "WaffleFilter_WFProvider.entitlements" Now edit these files to add the -systemextension suffix. The result will look something like this: % cat "WaffleFilter.entitlements" … ＜dict＞ … ＜key＞com.apple.developer.networking.networkextension＜／key＞ ＜array＞ ＜string＞content-filter-provider-systemextension＜／string＞ ＜／array＞ … ＜／dict＞ ＜／plist＞ % cat "WaffleFilter_WFProvider.entitlements" … ＜dict＞ … ＜key＞com.apple.developer.networking.networkextension＜／key＞ ＜array＞ ＜string＞content-filter-provider-systemextension＜／string＞ ＜／array＞ … ＜／dict＞ ＜／plist＞ Before you re-sign with these entitlements, replace the embedded provisioning profiles with their Developer ID profiles variants: % cp "WaffleFilter_Dev_ID.provisionprofile" "WaffleFilter.app／Contents／embedded.provisionprofile" % cp "WaffleFilter_WFProvider_DevID.provisionprofile" "WaffleFilter.app／Contents／Library／SystemExtensions／com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension／Contents／embedded.provisionprofile" Now re-sign the app and the system extension with their new entitlements, from the inside out: % codesign -s "Developer ID Application" -f --entitlements "WaffleFilter_WFProvider.entitlements" --timestamp -o runtime "WaffleFilter.app／Contents／Library／SystemExtensions／com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension" WaffleFilter.app／Contents／Library／SystemExtensions／com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension: replacing existing signature % codesign -s "Developer ID Application" -f --entitlements "WaffleFilter.entitlements" --timestamp -o runtime "WaffleFilter.app" WaffleFilter.app: replacing existing signature If you have multiple Developer ID Application signing identities, you’ll need to replace Developer ID Application with the name of the specific identity you want to use. IMPORTANT If your app contains other code items, like frameworks or an app extension, re-sign those as well. For advice on how to manually re-sign a more complex app, see Creating Distribution-Signed Code for Mac. And you’re done! Manually Notarise Xcode’s Direct Distribution workflow also deals with notarisation. As you’re not using that workflow, manually notarise your app. For advice on how to do that, see Customizing the notarization workflow. You should also look at Packaging Mac Software for Distribution, which has a bunch of general info about packaging Mac apps.

I have an app which hosts network extensions(Packet Tunnel, Filter). I am facing uninstallation issue in scenario 2. Uninstall API: OSSystemExtensionRequest.deactivationRequest Scenarion 1: app version 1.0.0.1, extension inside app bundle version 1.0.0.1 Installed extension -> version 1.0.0.1 Uninstallation works fine. Scenarion 2: app version 1.0.0.2, extension inside app bundle version 1.0.0.2 Installed extension -> version 1.0.0.1 Uninstallation fails with below error: deactivation failed for client: /Applications/Remo Security Endpoint Client/ep-client.app/Contents/MacOS/ep-client, error: Error Domain=OSSystemExtensionErrorDomain Code=4 "(null)" Question 1: is this by design or we can do something to make uninstall works in case application upgraded and tries to uninstall previous extension version. Snippet from Apple Doc for API: OSSystemExtensionRequest.deactivationRequest A deactivation request may require a restart before deactivating the extension. If the request succeeds but requires a restart to complete, the extension may still appear operational until the next restart. Question 2: How do we know if restart needed or not?

Thread 4: "*** NSExtensionPrincipalClass PacketTunnel.PacketTunnelProvider must implement at least one public protocol" warning: Module "/Users/username/Library/Developer/Xcode/tvOS DeviceSupport/AppleTV11,1 17.0 (21J354)/Symbols/usr/lib/system/libsystem_kernel.dylib" uses triple "arm64e-apple-tvos17.0.0", which is not compatible with the target triple "arm64-apple-tvos-unknown". Enabling per-module Swift scratch context. I can't run VPN. Same code IOS,MacOS are ok.

Hello, we have some custom data in SCAN_RSP, when ADV_IND's kCBAdvDataLocalName from advertisementData is different from SCAN_RSP, before iOS 16.4 we can only get SCAN_RSP,as for iOS16.4,we can get both ADV_IND and SCAN_RSP.why it act like this, is there any official support to explain this?

We are working on an app that uses network extension(https://developer.apple.com/documentation/networkextension) with content filter. Our app filters both browser and socket flows. The NEFilterProviderConfiguration has both ‘filterBrowsers’ and ‘filterSockets’ set to true as given below. NEFilterManager.shared().loadFromPreferences { error in if let error { NSLog("Preferences load error: \(error.localizedDescription)") return } let newFilterConfig = NEFilterProviderConfiguration() newFilterConfig.filterBrowsers = true newFilterConfig.filterSockets = true NEFilterManager.shared().providerConfiguration = newFilterConfig //enabling content filter NEFilterManager.shared().isEnabled = true //saving the preference NEFilterManager.shared().saveToPreferences { error in if let error { NSLog("Preference save error: \(error.localizedDescription)") return } } } In the context of Family Sharing, we have established a group comprising one parent and two children, aged 4 and 15, and have enabled the 'Ask to Buy' feature for both children. When attempting to install an app from the App Store on a device linked to one of the child's iCloud accounts, a pop-up appears, guiding us to initiate the app installation request. However, upon initiating the request from the child's device, we expected the app installation notification to appear on the Apple device associated with the parent's iCloud account. Unfortunately, the notification is not received on the parent's device. It's worth noting that app installation request notifications are displayed on the parent's device if we set the 'filterSockets' parameter of the NEFilterProviderConfiguration to false. NEFilterDataProvider All the flows received in the ‘NEFilterDataProvider’ are allowed. override func handleNewFlow(_ flow: NEFilterFlow) -> NEFilterNewFlowVerdict { return .allow() } Child Device details: iPad (8th generation), iPadOS 16.7

Hi, I want to write a custom NWProtocolFramerImplementation with a handshake. In the WWDC 2019 session 713 video, it is specified that the start(framer:) method must return a .willMarkReady and we must call markReady() later. Would it be possible to have an example? thanks

I'm seeing crashes within NWPathMonitor.pathUpdateHandler and in various parts of NWPath (sometimes on dealloc of NWPath). One thing I noticed is that we are using a global concurrent queue in the call to NWPathMonitor.start(queue:). Could this be the reason? The crash isn't easily reproducible, but I'll see if I can find a way to test this. It would be nice to have an authoritative answer about this, though. The documentation makes no mention that the queue must be serial. And NWPath is a struct, so it seems unexpected to require a serial queue. To be clear, I'm doing something like this: let nwPathMonitor = NWPathMonitor() nwPathMonitor.pathUpdateHandler = { [weak self] path in guard let self else { return } // do stuff with path } nwPathMonitor.start(queue: DispatchQueue.global(qos: .background))

I am trying to establish a TLS 1.3 connection to a server that only accepts the SECP256R1 and FFDHE2048 TLS key share groups using the following code but the server is failing the TLS handshake because my client is not using a supported key exchange group. How do I specify which TLS key exchange group my client should use during the handshake? let tlsOptions = NWProtocolTLS.Options() if let secIdentity = getSecIdentity(), let identity = sec_identity_create(secIdentity) { sec_protocol_options_set_min_tls_protocol_version( tlsOptions.securityProtocolOptions, .TLSv13) sec_protocol_options_set_local_identity( tlsOptions.securityProtocolOptions, identity) } let tlsParams = NWParameters(tls: tlsOptions, tcp: .init()) let endpoint = NWEndpoint.hostPort(host: NWEndpoint.Host(host), port: NWEndpoint.Port(port)) let nwConnection = NWConnection(to: endpoint, using: tlsParams) nwConnection.stateUpdateHandler = stateDidChange(to:) nwConnection.start(queue: queue) Thanks!

Is it actually usable as a fireawall in macOS? I tried (as an example) adding a rule to block port 80, and it did not seem to work. But, that's all I tried -- just added a line to /etc/pf.conf

Hi everybody, I have some questions regarding daemons and system network extensions. I’ve read here (https://developer.apple.com/forums/thread/721674): “System extensions are effectively launchd daemons”. So I have a question, can we launch system extension somehow directly via providing com.example.plist file into Library/LaunchDaemons and loading it? Or, for example, by loading it via SMAppService.daemon(). We need our network extension to run before user session. If above is not possible, and we’ll have a separate daemon, which only purpose is to start network extension, how can we listen to the lifecycle of the network extension? For example (I’ve already made some experiments): we start daemon, it starts NE, we unregister daemon (via SMAppService), but NE still lives. Is it possible to get callback/signal in the daemon, that it was unregistered and shutdown gracefully?