Apple Maps Guides

Hi, Thanks for following up. Platform: iOS (tested on iOS 17.x and iOS 18 betas). Extension type: Apple MatterSupport “Matter Add Device Extension” (Accessory Setup extension). We’re not building a Network Extension provider—our earlier “Network Extension” tag was a mistake. Our setup is a standard iOS app (com.infibrite…) plus the Matter setup extension (com.infibrite…MatterSetupExtension). Both targets need to share Matter fabric credentials via a single keychain access group (com.infibrite.matter.shared) so the extension can commission devices while the main app reuses the stored fabric. App Groups and other capabilities enable correctly, but the “Keychain Sharing” toggle never appears for either App ID in the portal. Because the provisioning profiles can’t include that entitlement, the OS returns errSecMissingEntitlement whenever we reference kSecAttrAccessGroup, so the extension can’t read the credentials. Could you enable Keychain Sharing for these iOS App IDs (main app + Matter setup extension

This is related to developing for Apple: software, accessories, and platforms.

Please consider filing a bug report about this so our engineering teams can investigate this issue. A resolution may involve changes to Apple's software. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports. Bug Reporting: How and Why? has tips on creating your bug report.

Maybe check out the Pathways pages. Those pages were created to provide some insight for developers just getting started with programming Apple devices.

We appreciate your interest in participating in the forums! These forums are for questions about developing software and accessories for Apple platforms. Your question seems related to a consumer feature like price and is better suited for the Apple Support Communities https://discussions.apple.com/welcome Hope this helps Albert Pascual
  Worldwide Developer Relations.

So, the first thing to understand is that what you're describing here: Our app receives a CallKit VoIP call. When the user taps “Answer”, the app launches and automatically connects to a real-time audio session using WebRTC or MobileRTC. ...is NOT what's actually happens on iOS. Your app doesn't receive a CallKit call, nor is CallKit something that really controls how your app works. This is how incoming voip pushes actually work: The device receives an voip push for your app. The system either launches or wakes your app (depending on whether or not your app is running). Your app receives the voip push. Your app reports a new call into CallKit. The system present the incoming call UI, sending updates back to your app about the actions the user takes in that UI. If the user answers the call, the system activates the audio session you previously configured. The critical thing to understand here is that CallKit is best understood as an interface framework (albiet a very narrowly focused one), NOT a voip calling

[1] If you're curious it was an old Apple Watch I had that got stuck in a boot loop after restarting it to try to fix some crashy app behavior, and IIRC there were low storage alerts shortly before that happened. Definitely way after the iOS 8 days. Hmm... Maybe? Turns out my memory was wrong and APFS was actually adopted in iOS 10.3, not 8.3. watchOS did adopt it before that, so it's possible you could have hit something then. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Based off that, it feels like I should NOT rely on the BGContinuedProcessingTask notifications (or whatever they are called) to communicate state. It seems like instead what I should do is do something like local notifications to communicate state and handle it more in my app, is that correct? This is one of those questions where the right answer really depends ENTIRELY on the exact details of what you're trying to do. The simple end of the spectrum here are things like short-lived, single jobs, where putting up extra” UI to manage a single task which isn't going to take very long anyway might be unnecessary. At the other end of things, I think there are lots of situations where the work the app is doing doesn't nicely map directly to the task model and you'll absolutely want to use other tools/APIs to tell the user what's going on. As one example, if an app is doing lots of small network transfers, using an individual processing task for each transfer is probably a mistake. At a technical level, the