“eskimo”

I have filed FB21917334 Thanks! however not in a Hypervisor Framework category as it does not exist Virtualization is fine. But that’s not a problem; it’ll find its way to the right place. ps 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. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

OK, cool. Well, not cool, but you know what I mean (-: Given that you can reproduce this so easily, I recommend that you file a bug about it now. When doing that: Make sure to enable additional VPN logging, per the VPN (Network Extension) instructions on our Bug Reporting > Profiles and Logs page. After reproducing the problem, grab a sysdiagnose and attach it to your bug report. Once you’re done, post your bug number here. My plan is then to grab the crash report from your sysdiagnose log and dig a bit deeper. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Entitlements and code-signing requirements are very different. See the following for more background on each: TN3125 Inside Code Signing: Provisioning Profiles TN3127 Inside Code Signing: Requirements You can use a code-signing requirement to check for an entitlement, for example: % codesign --verify -R '=entitlement [com.apple.security.app-sandbox] exists' -v /Applications/Pages.app … /Applications/Pages.app: explicit requirement satisfied % codesign --verify -R '=entitlement [com.apple.security.app-sandbox] exists' -v /usr/bin/true … test-requirement: code failed to satisfy specified code requirement(s) However, entitlements are tricky to use in this situation because: You can’t create a provisioning profile that authorises a custom requirement. Many of of the popular entitlements are either unrestricted on macOS, or only restricted in that they clear the entitlement-validate flag [1]. Given that, I think maintaining your previous approach makes sense, that is, check for the Team ID and a list of code-signi

Most of the weird keychain failures I see like this are caused by folks using the keychain API incorrectly. I talk about this a lot of in: SecItem: Fundamentals SecItem: Pitfalls and Best Practices However, your additem and readitem summaries look pretty reasonable. It’s hard to see how you could hit the symptoms you’ve described based on this setup. Are you able to reproduce this on a device that you control? Or are you investing this based solely on reports coming in from your users? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for bringing this to the Apple Developer Forums. First up, I want to double check that this is for iOS. You mentioned the “System Keychain”, which is a macOS thing [1]. On iOS there is only one keychain, known as the data protection keychain. Within that keychain, credentials exist within a keychain access group. Your app’s access to keychain access groups is moderated by entitlements, as explained in Sharing access to keychain items among a collection of apps. Note For a lot more background on keychain APIs, see: SecItem: Fundamentals SecItem: Pitfalls and Best Practices Next, let’s look at your specific questions: [quote='815135021, HSB, /thread/815135, /profile/HSB'] 1- Is there an API that allows us to create a signature without us having to pass the private key itself [/quote] No. iOS does have the ability to work with keys where the key material isn’t directly accessible to your app. We use this, for example, to allow keys to be protected by the Secure Enclave and to support keys stored on a hard

I’m generally skeptical of using Network framework for multicasts. It should work in general, but: There are a bunch of things it can’t do. And even when it can, you often hit weird edge cases. My general advice — and this makes me very sad — is to stick with BSD Sockets for broadcasts and multicasts. See Extra-ordinary Networking > Broadcasts and Multicasts, Hints and Tips. Having said that, this is weird: [quote='815127021, Anshuman1989, /thread/815127, /profile/Anshuman1989'] Reinstalling the app fixes the issue [/quote] This isn’t a standard pathology I see with Network framework’s multicast support and you are right to suspect local network privacy in that case. So let’s dig into that. First up, you’ve signed your app with the the com.apple.developer.networking.multicast entitlement, right? You didn’t mention that, and it’s very important. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You mean that the compiler crashes? If so, that’s probably something best addressed over in Swift Forums > Using Swift. And speaking generally, to improve your chances of getting traction: Be clear about what version of the compiler you’re testing with. Isolate the code into a small test project that reproduces the issue. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='875498022, dridev, /thread/814235?answerId=875498022#875498022, /profile/dridev'] Im having the exact same issue [/quote] Are you absolutely sure that this is not an Individual team? Because if it is, then the inability to access Certificates, Identifiers and Profiles is a documented limitation. This is a bit of a FAQ, so I finally got around to writing it up properly: 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

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

If your submission relies on features that are only available on device, I recommend that you built and test it using the Swift Playground app and then request that it be judged in that environment. The major drawback with that is that the current Swift Playground app doesn’t support the iOS 26 SDK )-: I don’t have anything to share about that limitation right now, but if and when I do I’ll update this other thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='815182021, backstroke, /thread/815182, /profile/backstroke'] because multicultural themes are a main point of my app, it seems unavoidable to use other languages. [/quote] Agreed. This is one of those cases where it’s important to understand the rationale for the rule. The requirement that everything be in English exists so that the judges can review your submission, both by running the app and looking at the code. So, if the goal of your submission is to show off multiple languages, then that’s your only real option. However, it’s important to put yourself in the position of the judges who review your submission. Will they be able to understand how cool it is? Keep in mind that: Folks who grew up with alphabetic script systems are notoriously bad at recognising logograms. Folks who speak non-tonal languages struggle to hear tones. So construct your submission in a way that someone who only reads and speaks English can understand how cool it is. Share and Enjoy — Quinn “The Eskimo!” @ Develop

Let’s focus this discussion on your other thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Are there any plans to introduce its system registers to HVF’s EL2 support? We can't talk about The Future™ [1], but if you'd like to see this change I encourage you to file an enhancement request describing your requirements. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] See tip 3 in Quinn's Top Ten DevForums Tips.

Thanks for that dump. Much nicer! My reading of the stuff in your latest post suggests that you’re authorised to use the entitlement but you’re not actually claiming it. Remember that a provisioning profile acts an allowlist. It tells the system what entitlements you’re allowed to claim, but it doesn’t actually claim them. You actually claim entitlements in your app’s code signature. Note To learn more about how this works, see TN3125 Inside Code Signing: Provisioning Profiles. I usually debug problems like this by first confirming the nature of the problem: Instead of sending my app directly to App Store Connect, I export an archive. For example, when using Xcode’s organiser window I click Distribute App and then follow the Custom > App Store Connect > Export workflow. I then upload that archive using Transporter. Presuming that reproduces the problem, I unpack the archive by hand. See Unpacking Apple Archives. I can then dump the profile and the entitlements in the resulting app. The profile dump comm