“eskimo”

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

Are folks still having this problem? I just tried it myself and everything worked for me, so either this was a transient thing that’s now fixed or it’s caused by an environmental thing that doesn’t apply in my case. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. We implemented your own HTTP protocol on top of NetworkConnection. OK, cool, that’s kinda what I expected but I’m glad you confirmed it. We are very eager to send HTTP requests over Wi‑Fi Aware using URLSession — is this achievable? No. I recommend that you file an enhancement request for that. Please post your bug number, just for the record. Coming back to your throughput issue, I don’t have an immediate answer to that. I’m gonna do some digging and get back to you. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='881307022, nixx, /thread/820080?answerId=881307022#881307022, /profile/nixx'] staging the package contents in an HFS volume … allows pkgbuild to succeed [/quote] I’m glad that worked but… sheesh… it’s a bit of a worry. Hopefully we’ll get a fix to FB22312299 sooner rather than later. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='881470022, GangOrca, /thread/820251?answerId=881470022#881470022, /profile/GangOrca'] dlopen and dlsym are Linux-specific C APIs [/quote] No. These are Posix APIs that are supported on most Unix-y platforms, including macOS [1]. [quote='881470022, GangOrca, /thread/820251?answerId=881470022#881470022, /profile/GangOrca'] How are they invoked in Swift directly? [/quote] Like you would any other low-level C API: import Darwin func main() { guard let dl = dlopen(/usr/lib/libSystem.B.dylib, RTLD_LAZY) else { … handle error … } … use `dl` … } main() Note that Darwin is implicitly imported by Foundation, so most Mac programs won’t need to import it explicitly. [quote='881470022, GangOrca, /thread/820251?answerId=881470022#881470022, /profile/GangOrca'] I couldn't find any swift documentation about these symbols. [/quote] Indeed. Most low-level C APIs are documented in our man pages. I’ve got a post about that somewhere… ah, OK, here we go… Availability of Low-Level APIs. Share and Enjoy — Quinn “The Eskimo