“apple pencil battery life”

[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 Technica

[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 tha

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

If Apple were to rotate or replace the attestation certificate chain (for example, in the event of a compromised root attestation CA), would this automatically trigger a repair / re-enrollment flow on all previously enrolled devices? Or is the repair flow initiated only based on server-side decisions, such as attestation validation failures or explicit policy enforcement?

Thanks for the update. I did some investigation on my end using Charles to inspect the traffic and verify whether any Apple attestation APIs are being called. I can confirm that an attestation API is indeed triggered, but I’m not entirely sure what happens behind the scenes. Any progress on the research at your end ?