apple pencil battery life

[quote='854085022, DTS Engineer, /thread/797007?answerId=854085022#854085022'] Keep in mind that appex-based VPN isn’t well aligned with macOS’s execution model. macOS supports multiple users simultaneously, which is a concern because VPN configurations affect the networking stack as a whole. [/quote] So how does that explain network app extensions in App Store apps? What is there to stop a user logged in on the same system (possibly a standard user) from accessing a VPN tunnel started by another higher privileged user via a Mac App Store app with a network app extension and gaining unauthorized access to resources via that tunnel? I would think most people assume App Store apps to be running in a far more restricted environment than apps distributed outside the App Store, but in the case of app extensions the opposite appears to be the case. By forcing Developer ID apps to use system extensions it forces admin privileges in order to install the extension and the explicit granting of Privacy and Security perm

[quote='876733022, disinghal, /thread/811887?answerId=876733022#876733022, /profile/disinghal'] URL Session is calling a public endpoint. [/quote] Right, but you’ve set up your on-demand rules to say that everything generates demand. It’d be interesting to see what happens if you configure your on-demand rules to only generate demand what you load a URL that’s behind the VPN. I suspect it’ll work consistently, but if you find that’s not the case then that’d be an interesting datapoint. [quote='876733022, disinghal, /thread/811887?answerId=876733022#876733022, /profile/disinghal'] It happens intermittently. [/quote] Fair enough. But that doesn’t really contradict the position I explained above. You’ve set yourself up for failure and that you only fail in some cases. That’s a win, right? (-: Seriously though, I don’t think I’m going to be able to help you further here. You are clearly exploring the limits of what’s possible. If you want to make the case that this should work, I recommend that you do that direct

This is not a very difficult API to use: let url: URL = … let verdict = await NEURLFilter.verdict(for: url) switch verdict { case .unknown: … you need to decide on a policy for this case … case .allow: … continue loading the URL … case .deny: … stop loading the URL … @unknown default: … you need to decide on a policy for this case … } Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Issue has been solved by requesting apple developer call

[quote='876709022, siddhant-mac, /thread/815755?answerId=876709022#876709022, /profile/siddhant-mac'] is it possible on the macOS login window? [/quote] That depends on what you mean by “it”: If you’re asking whether it’s possible to reuse infrastructure used by Platform SSO then the answer is “No.” If you’re asking whether it’s possible to create an authorisation plug-in that presents a completely passwordless experience, the answer is more nuanced. You can certainly make a lot of progress, but I don’t think there’s a complete solution. Sticking points involve FileVault, as I’ve mentioned above, and unlocking the keychain. This is especially problematic when it comes to the data protection keychain. Honestly, I don’t see a good path forward for this. The authorisation plug-in mechanism has significant issues, and I’m doubtful they’ll be addressed because of limitations in that architecture. Specifically, FileVault support is pretty critical and it’s hard to see how that can happen within the current design.

[quote='876690022, ZKK640, /thread/806582?answerId=876690022#876690022, /profile/ZKK640'] What are the consequences of using Xcode15? [/quote] There are a couple that spring to mind: Xcode 15 doesn’t include the iOS 26 SDK, so you won’t be able to use the latest iOS features. You won’t be able to test your submission properly, because it will ultimately be reviewed on Xcode 26. While Xcode is generally good about working with projects from older versions, the only way to be sure that it’ll work is to try it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='876718022, dridev, /thread/814235?answerId=876718022#876718022, /profile/dridev'] I am absolutely sure yes [/quote] OK. Then I recommend that you follow the support path laid out in the last bit of Team Member Can’t access Certificates, Identifiers, and Profiles. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I’m not an expert on the App Store Connect API, but I can speak to this part of your question: [quote='816166021, Misko_, /thread/816166, /profile/Misko_'] there is a possibility to set Entitlements, which is I understand also called as Template. [/quote] The entitlement template feature is very much an old school path. These days most access to managed entitlements is via additional capabilities. Like any other capability, you set these on your App ID and they flow through to every provisioning profile [1] you create for that App ID. These capabilities have a bunch of advantages, including Xcode integration, compatibility with automatic signing, and the ability to add any combination of the capabilities to a given profile. Given that, the template mechanism is largely deprecated. If you have existing templates you can request that they be migrated to additional capabilities. See Developer Account Help > Reference > Provisioning with capabilities > Migrating additional entitlements to capabilities. T

You can expect that most uploads will be notarised quickly. Occasionally, some uploads are held for in-depth analysis and may take longer to complete. As you notarise your apps, the system will learn how to recognise them, and you should see fewer delays. For lots of additional info about notarisation, see Notarisation Resources. Specifically, it links to a Q&A with the notary service team that’s quite instructive. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='816179021, GangOrca, /thread/816179, /profile/GangOrca'] Whereas, with conditional variables, there are no warnings. [/quote] I wouldn’t read too much into that. These warnings have to be explicitly coded, and we added that code for Dispatch semaphores because that’s the most common offender here. It wouldn’t surprise me if we added a similar warning for pthread condition variables at some point in the future. Then again, it wouldn’t surprise me if we didn’t. The pthreads API is relatively obscure. [quote='816179021, GangOrca, /thread/816179, /profile/GangOrca'] What is the recommend way? [/quote] There isn’t a supported way to block the main thread of a GUI application for long periods of time. On macOS it will SPOD, which is a terrible user experience. On other platforms the app will likely end up being killed by the watchdog. And to be clear, the issue here isn’t about the specific APIs you’re using, it’s this overall design. Speaking of iOS and friends, app termination [1] behaves very differently