“eskimo”

[quote='820631021, Pavel, /thread/820631, /profile/Pavel'] Is it possible for a Network Extension … to act as a client for an XPC service hosted by a Launch Daemon … ? [/quote] Yes. The trick is to use an app group. Sign your client with an app group ID and then, in the MachServices property of the launchd daemon, set the XPC endpoint name to be a ‘child’ of that app group ID. See the discussion in App Groups Entitlement. App groups are a bit tricky on the Mac. See App Groups: macOS vs iOS: Working Towards Harmony for the full backstory. Given that your client is sandboxed, it must claim access to that app group ID. And in that case I strongly recommend that you authorise that claim via a provisioning profile. Your launchd daemon is (presumably) not sandboxed so it doesn’t need to claim access to the app group ID. However, if you decide to make that claim then my recommendation applies there as well: Authorise the claim with a provisioning profile. If you claim access to an app group and don’t authorise that

[quote='820695021, blackson, /thread/820695, /profile/blackson'] when NetworkExtension Activiate. [/quote] What do you mean by “NetworkExtension Activiate”? The Network Extension framework has many different subsystems, many of which can affect the Wi-Fi join process, so I need to understand which one is involved before I can offer any guidance. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Please share the URL of the thread in question. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

There are two parts to this: Technical — What APIs are involved? And what TCC privileges do they need? App Review — What is or isn’t allowed on the App Store? I work for DTS, not App Review, so I’m only able to comment on the first part. I’ll come back to the second part at the end. From a technical standpoint, there are three TCC privileges involved: PostEvent — This controls the ability to post UI events, for example, by calling the CGEvent.post(tap:) method that you mentioned. ListenEvent — This controls the ability to monitor UI events on a system-wide basis, for example, with a CG event tap [1]. Accessibility — This is aimed at accessibility products, and controls a wide variety of things, including the ability to example the UI state of other apps. Note I’m using the service names that you would pass to tccutil, as explained in this post. These privileges are represented in System Settings > Privacy & Security, but in a non-obvious way: Both PostEvent and Accessibility map to Accessibility. Liste

No, at least from the Apple perspective. As I mentioned above, the sticking point is reproducing the problem. If you have a way to reproduce the problem reliably, I encourage you to file a bug with that info. And also post your bug number here, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for all the updates. I’m researching this more and I hope to have another update in the next day or two. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='881565022, amepatil, /thread/769640?answerId=881565022#881565022, /profile/amepatil'] I see these issues still happening in iOS 26. [/quote] Sadly, that doesn’t surprise me. None of the bugs mentioned above (FB16052660, FB16058654, FB16058772, FB16060769) are marked as resolved. Regarding ExtensionKit, AFAIK the situation there hasn’t changed in iOS 26, that is, things are still as I described them on this thread. However, I don’t understand how that is related to CryptoTokenKit extensions. ExtensionKit was designed so that third-party apps can expose their own extension points, allowing other third-party developers to create extensions that attach to those points (and, indeed, that’s how things are working on macOS today). System frameworks, like CryptoTokenKit, generally hide this underlying mechanism from third-party developers. That is, third-party developers can extend the system without dealing with the underlying extension infrastructure, be that ExtensionKit or the older mechanism [1]. So: [qu

Glad to hear you’re making progress. [quote='881521022, balunist, /thread/820402?answerId=881521022#881521022, /profile/balunist'] Was this triggered when I installed the xcode update? [/quote] That seems likely. It’s not uncommon for new versions of Xcode to include a new licence agreement. However, it’s hard to be 100% sure without knowing the exact sequences of steps you took to get into this situation. One little-known gem is that xcodebuild has a command that checks whether the installation is copacetic: % xcodebuild -checkFirstLaunchStatus ; echo $? 0 See the xcodebuild man page for details. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='881663022, adriangm20, /thread/818603?answerId=881663022#881663022, /profile/adriangm20'] I've identified and submitted [FB22295165 and FB22295685] [/quote] Thanks. [quote='881663022, adriangm20, /thread/818603?answerId=881663022#881663022, /profile/adriangm20'] the ability to capture Wi-Fi traffic and use apps that rely on it is one of the reasons many WLAN and IT professionals choose Macs. [/quote] Understood. I can’t make any promises here, but I have passed these comments on to the folks looking at this issue. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='820543021, mhenke, /thread/820543, /profile/mhenke'] I filed an issue in the Feedback Assistant [/quote] What was that bug number? Oh, and do you hit this when you choose Validate App in the Xcode organiser? Or only after you’ve uploaded to App Store Connect? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

First up, have a read of TN3134 Network Extension provider deployment. This explains your deployment options for this technology. Specifically, for an app proxy on iOS the device must be managed. That’s because the MDM system is used to associate your app proxy with the apps that it proxies, by matching up the VPNUUID properties on both. During development you can use NETestAppMapping to establish this mapping. You’ll still need a configuration profile to enable your app proxy, because of the requirement to provide a VPNUUID property with the configuration. [quote='820572021, Davidbaraff2, /thread/820572, /profile/Davidbaraff2'] Is an app proxy the right tool for this? [/quote] Before you can answer that you have to first see if an app proxy will actually work. That is, in production: Are the target devices managed? Is the target app installed via MDM? If either of those is false, an app proxy won’t work and thus it’s definitely not the right tool (-: Share and Enjoy — Quinn “The Eskimo!” @ Developer

[quote='820585021, faisalIkwal, /thread/820585, /profile/faisalIkwal'] We don't apply rules in these methods [/quote] So what do you do in those methods? In many cases a transparent proxy can get away without implementing those methods at all. If you do implement them: Make sure they return promptly. In the case of the sleep(…) method: Implement the async version and have it return promptly. Implement the completion handler version and have it call the completion handler promptly. [quote='820585021, faisalIkwal, /thread/820585, /profile/faisalIkwal'] com.apple.developer.endpoint-security.client is not present in .entitlement file. [/quote] Network Extension and Endpoint Security are separate subsystems. It’s fine to implement an NE sysex without any ES bits in it. In fact, it’s more than fine, it’s very common. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

It sounds like you’re using Developer ID signing for day-to-day development. That’s a mistake on multiple levels. I talk about this in general in The Care and Feeding of Developer ID, but there are extra issues with system extensions, where system policy requires that Developer ID signed sysexen be notarised. So my advice in this case. Use Apple Development code signing for day-to-day development. Use Developer ID for pre-release testing and distribution. There are a couple of key benefits with this approach: It lets you build and debug without enabling development mode, which is a big win IMO. Xcode’s automatic code signing works well with Apple Development signing. Even if you’re not using Xcode, you can create a small test project in Xcode, get it working, and then follow the same path it took. See Debugging a Network Extension Provider for specific advice on how to bring up a provider in Xcode. One thing that Xcode doesn’t handle is the -systemextension suffix )-: To learn more about that, read Exporting

Right. When dealing with JSON it’s best to use a JSON parser rather than trying to treat it as text. And modern versions of macOS have (at least) one such parser built in, that is, jq. For example: % system_profiler -json SPHardwareDataType > tmp.json % jq -r '.SPHardwareDataType.[0].platform_UUID' tmp.json FCBBB6FF-E6F4-5372-87C0-1944DA936938 Read the jq man page for more on how it works. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

alam333, I don’t see any relationship between your issue and the one being reported by DarrenHan. And regarding your issue, let’s focus that discussion on this thread, which you’ve already posted on. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com