Apple Maps Guides

Doing what you’re suggesting on iOS isn’t really feasible. There are two potential sticking points: Running in the background Inter-process communication (IPC) I talk about the first in general terms in iOS Background Execution Limits. However, in your case this might not be a showstopper because you’re interacting with a Bluetooth LE accessory, and Core Bluetooth does have background execution facilities [1]. The second point is much more problematic. In general, iOS doesn’t allow unmediated IPC between apps from different teams. This isn’t a limitation, but a deliberate design decision based on security and privacy policy. The only path forward I see here is for you to ship an SDK that interacts with the Bluetooth accessory directly, that is, from within the process of the app that adopts the SDK. However, that presents other challenges: Each app will need to request the Bluetooth privilege from the user. You have to find a way to mediate access from multiple apps. You can’t do that on the iOS side because

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

This seems to be a widespread issue. My app has been in Waiting for Review since Jan 27 (technically, I submitted the app on Jan 23, but I thought resubmitting it after no movement for 4 days would nudge it, but in hindsight, that likely made it worse), and I've submitted two requests to Apple support with no response.

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

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