Hello, Our team submitted a request for Family Controls entitlements for our main app and four related extensions. It has now been a little over two weeks since submission, and the request is still pending review. We wanted to check if there are any recommended steps we can take on our end to help move the process forward. Any guidance or tips from anyone who have recently gone through this process would be greatly appreciated. Thank you.

Hi everyone, I am attempting to generate an Ad Hoc provisioning profile for my iOS app that includes MusicKit capabilities, but the generated .mobileprovision file consistently lacks the required entitlement, despite the configuration appearing correct in the developer portal. The Issue: I have enabled MusicKit under the "App Services" tab for my App ID. I have saved this configuration, verified it is checked in the UI, and then regenerated and downloaded my provisioning profile. However, when I inspect the internal contents of the .mobileprovision file, the Entitlements dictionary does not contain the com.apple.developer.music-kit key. It only contains the standard keys (Team ID, App ID, etc.). Steps Taken: Created a brand new App ID to rule out legacy data issues. Explicitly enabled "MusicKit" under the App Services tab for this new identifier. Created a fresh Ad Hoc Distribution profile linked to this new ID. Downloaded the profile and inspected the file structure: the MusicKit entitlement is completely absent. Attempted toggling the service off and on, saving, and regenerating the profile multiple times. Has anyone experienced a specific bug where "App Services" (like MusicKit) fail to propagate to the Provisioning Profile generator? Is there a secondary "Capability" (e.g., Media Library) that must also be enabled to trigger the inclusion of the MusicKit entitlement? Any guidance would be appreciated.

This is a question as I don't found any related documents or posts anywhere about this. Does anyone know how and when will this "pop up" shown?

Issue Description: On non-Dynamic Island devices, when the screen is on, tapping the alarm banner does not open the app or trigger any action. Steps to Reproduce: Set a regular alarm. Wait until the alarm goes off. Keep the screen on. A banner appears with options (e.g., dismiss or a secondary action). Tap anywhere on the banner area that would normally open the app. Expected Behavior: Tapping the banner should open the app. Actual Behavior: Tapping the banner has no response.

Hello, In production, a large number of users experience outgoing call reporting fails with the following error: com.apple.CallKit.error.requesttransaction Code=2 The iOS version doesn't matter, errors are present in v15-26 Details My CXProvider held as a global singleton, so it’s unlikely to be deinited. There is no explicit call to CXProvider.invalidate() in the app. If I manually invalidate the CXProvider, I observe the expected failure when trying to create an outgoing call (com.apple.CallKit.error.requesttransaction error 2). However, If I recreate the CXProvider after the error, outgoing calls are reported correctly. Many users trigger the providerDidReset delegate method (CXProviderDelegate) before this error. According to the documentation, providerDidReset can be called by the system, and we are supposed to end all active calls, but the documentation doesn't suggest recreating the CXProvider. Question Should I recreate CXProvider after providerDidReset and forget about that, or could this error be caused by something else?

On and off I've been trying to figure out how to do hang detection in-application (at least from the user's point of view). Qualitatively what I'd like to do is have a process which runs sample(1) on the application after it's been unresponsive for more than a second or so. Basically, an in-app replacement for Spin Control. The problem I've been stuck on is: how do I tell? There used to be Core Graphics SPI (CGSRegisterNotifyProc with a value of kCGSEventNotificationAppIsUnresponsive) for doing this, but it doesn't work anymore (either due to sandboxing or system-wide security changes, I can't tell which but it doesn't matter). One thought I had was to have an XPC service which would expect to receive a checkin once per second from the host (via a timer set up by the host). If it didn't, it would start sample(1). This seems pretty heavyweight to me, since it means that once per second, I'm going to be consuming cycles to check in with the service. But I haven't been able to come up with a scheme that doesn't include some kind of check-in by the target process. Are there any APIs or strategies that I could use to accomplish this? Or is there some entitlement which would allow the application to request "application became unresponsive"/"application became responsive" notifications from the window server?

Hi, As a company, we have several apps in the AppStore that contain AppClips. With the latest iOS18 it works without any problems. With all iOS26 betas so far, however, there is always the problem “ASDErrorDomain- Error 507” and the AppClip cannot be opened. You can easily test this by scanning the following QR code with the system camera: You only ever get this error instead of the option to open the AppClip. As the iOS26 beta phase is already at an advanced stage, we are naturally concerned as to whether the problem will be solved.

In iOS 18, when a contact with multiple phone numbers called, the system clearly indicated which specific number was used—often by highlighting it in red for missed calls or tagging it as 'recent.' However, in iOS 26, this distinction is missing, and there is no way to determine which of the contact's numbers the call originated from.

Hey, I am just about to prepare my app for Swift 6, and facing the issue that UserDefaults is not Sendable. The documentation states that its thread safe, so I am wondering, why is it not marked as Sendable? Was it just forgotten? Is it safe to mark it as nonisolated(unsafe) or @unchecked Sendable?

The documentation specifies that when Contacts framework returns unified contacts that each fetched unified contact object (CNContact) has its own unique identifier that’s different from any individual contact’s identifier in the set of linked contacts and that when refetching a unified contact, that this identifier should be used. There is also an analogous identifier within the list of contactRelations, but each of these don't seem to corespondent to the unified contacts. For example, is a new contact (Sheryl Zakroff) is created in the simulator Contacts and their spouse is set to Hank Zakroff. However, the GUID created for the contactRelations identifier does not correlate to the original Hank Zakroff GUID and cannot be searched. Is this a bug or what is the indent of the contactRelations identifier? Here's a debug output of walking the unifiedContacts: Name: Hank Zakroff 2E73EE73-C03F-4D5F-B1E8-44E85A70F170 - Other : (555) 766-4823 - Other : (707) 555-1854 Name: David Taylor E94CD15C-7964-4A9B-8AC4-10D7CFB791FD - Other : 555-610-6679 Name: Sheryl Zakroff DE783BC8-7917-4138-93F6-3AF0FD4CE083 - Other : (707) 555-1854 - Spouse: <CNContactRelation: 0x60000000dd60: name=Hank M. Zakroff> - 534B467D-CA00-46D3-897C-16EEA782C9CF - Looking for ["534B467D-CA00-46D3-897C-16EEA782C9CF"] []

I'll try to ask a question that makes sense this time :) . I'm using the following method on NSFileManager: (BOOL) getRelationship:(NSURLRelationship *) outRelationship ofDirectoryAtURL:(NSURL *) directoryURL toItemAtURL:(NSURL *) otherURL error:(NSError * *) error; Sets 'outRelationship' to NSURLRelationshipContains if the directory at 'directoryURL' directly or indirectly contains the item at 'otherURL', meaning 'directoryURL' is found while enumerating parent URLs starting from 'otherURL'. Sets 'outRelationship' to NSURLRelationshipSame if 'directoryURL' and 'otherURL' locate the same item, meaning they have the same NSURLFileResourceIdentifierKey value. If 'directoryURL' is not a directory, or does not contain 'otherURL' and they do not locate the same file, then sets 'outRelationship' to NSURLRelationshipOther. If an error occurs, returns NO and sets 'error'. So this method falsely returns NSURLRelationshipSame for different directories. One is empty, one is not. Really weird behavior. Two file path urls pointing to two different file paths have the same NSURLFileResourceIdentifierKey? Could it be related to https://developer.apple.com/forums/thread/813641 ? One url in the check lived at the same file path as the other url at one time (but no longer does). No symlinks or anything going on. Just plain directory urls. And YES calling -removeCachedResourceValueForKey: with NSURLFileResourceIdentifierKey causes proper result of NSURLRelationshipOther to be returned. And I'm doing the check on a background queue.

Hello. We are facing very silent and hardly replicable issue. All UserDefaults.standard data the application saved and was using to determine the state of app is lost and app behaves as if it was freshly installed. The issue always occurs only if we leave app on background for long time or if we manually swipe the app from the background apps. In case we swipe, this issue can occur in minutes, hours or up to 2 days by our latest testing. One important factor is that the app was developed using iOS18 in which issue never occured. Next it was being tested on iOS26 and it did everytime. Any currently available version of iOS26 reported this issue, all the way up to 26.2.1 (23C71). Our application is going through major upgrade of its whole lifecycle and services so it is possible this issue is caused by a bug in development as the production version does not report this issue neither on iOS26 of any version. The following list contains how we tried to fix this issue but none of which helped. App prewarming in the background (postpone all initialization including searching UserDefaults.standard for when isProtectedDataAvailable) Calling UserDefaults.standard.synchronize() everytime after saving data despite it is not recomended Built app using different SDK's (tested on iOS18 and iOS26 SDK) Distributed the app from local machine aswell as on TestFlight itself We searched through currently opened and closed issues for third-party libraries app uses regarding 'iOS26' and 'UserDefaults', especially those who were added recently with no success. The structure using which we save data into UserDefaults.standard did not change, we have only added few more settings to save through the lifecycle of the app after update. We estimate the overall increase is merely 30% more of what it used to be in previous version. Any ideas are much appreciated. We are considering to use different or fully custom ways to store app's settings.

Do we need to take approval for any entitlement for the extension Unwanted Communication because currently I do not see my app in the Settings under SMS/Call Reporting extensions.

Currently, I have implemented Unwanted Communication Extension, But I wanted to send the reported call or message to my backed server. How can I achieve this and can I send message body to the server ?

I'm experiencing a contradictory validation issue with DeviceActivityReportExtension that creates an impossible situation: The Problem: Without NSExtensionPrincipalClass in Info.plist → App Store Connect rejects upload with: "Missing Info.plist values. No values for NSExtensionMainStoryboard or NSExtensionPrincipalClass found" With NSExtensionPrincipalClass → Local install fails with: "defines either an NSExtensionMainStoryboard or NSExtensionPrincipalClass key, which is not allowed for the extension point com.apple.deviceactivityui.report-extension" Setup: Extension point: com.apple.deviceactivityui.report-extension Using SwiftUI with @main attribute and DeviceActivityReportExtension protocol Xcode 16.2, iOS 17.6 deployment target Code structure: @main struct SpoolReport: DeviceActivityReportExtension { var body: some DeviceActivityReportScene { // Report scenes here } } The extension builds and runs perfectly without NSExtensionPrincipalClass, but cannot be uploaded to App Store Connect. Adding the key allows upload but breaks local installation. Is this a known issue? Is there a workaround or correct Info.plist configuration for DeviceActivityReportExtension? Thank you!

Hello, I’m using the Screen Time API / Family Controls in my iOS app Sobre and I’m having an issue submitting a new build to TestFlight. My app setup is as follows: Main app ID: com.balthazar.sobre App extensions: Device Activity Monitor: com.balthazar.sobre.deviceactivitymonitor Shield Configuration: com.balthazar.sobre.shieldconfiguration Shield Action: com.balthazar.sobre.shieldaction On the Apple Developer portal: Family Controls (Distribution) is enabled for: the main app ID com.balthazar.sobre and all 3 extension App IDs above. App Groups are also configured for the app and the extensions. New App Store provisioning profiles have been generated for the app and all 3 extensions and are used in the latest build. When I submit the build through App Store Connect (via Fastlane / EAS), validation fails only for the Shield Action extension with this error: Invalid Info.plist value. The value of the NSExtensionPointIdentifier key, com.apple.ManagedSettingsUI.shield-action-service, in the Info.plist of “Sobre.app/PlugIns/ShieldActionExtension.appex” is invalid. DeviceActivityMonitorExtension and ShieldConfigurationExtension are accepted without any issue. My questions: What is the correct expected value for NSExtensionPointIdentifier for a Shield Action extension using the Screen Time / ManagedSettings APIs? Are there any additional entitlements or capabilities (for example, related to Managed Settings) that must be explicitly enabled for the app or the Shield Action extension in order for this extension point to be accepted by App Store Connect? Given that Family Controls (Distribution) is already granted for the main app and all extensions, is there anything else that needs to be requested or configured on my account or App IDs to use a Shield Action extension? My goal is to use Screen Time / Family Controls properly to block distracting apps and present a custom Shield UI + actions for my users, while respecting all Apple policies. Thank you in advance for your help and guidance

Hi Team, We've been developing our application with the fairly new AlarmKit. We are using the stopIntent to run some quick logic when the user stops the alarms. The stopIntent is a LiveActivityIntent and works well when the user presses the button the dismiss button on the alarm. But unfortunately we've realized some interesting behavior in the following two cases: In case the alarm fires while the user has unlocked their screen and they do things on the screen, the alarm is dismissed (and stopped), but the stopIntent is not executed. In case the alarm fires while the user has unlocked their screen and they swipe up the Live Activity banner, the alarm is also dismissed (and stopped), but again the stopIntent is not executed. I've tried to look up for some information, but could not find anything meaningful for this specific case. We're wondering if that is something that is planned to get fixed in the future, or maybe there's a workaround. We've tried also alternative - listening to alarm updates via the AlarmManager, but we are not very eager to create listener task for it, also the alarm state does not provide updates for dismissed. Thanks!

App out of memory and killed by Jetsam event seems not report to MetricKit diagnostic, it only contains crash or watch dog kill (scene create or scene update). So I want to ask to report these issues to MetricKit

Reference: FB21797091 / Related to thread 807695 Hello, I have already submitted a report regarding this issue via Feedback Assistant (FB21797091), but I would like to share the technical details here to seek further insights or potential workarounds. We are experiencing a technical regression where Universal Links and Shared Web Credentials fail to resolve for Internationalized Domain Names (IDN) specifically on iOS 16 and later. This issue appears to be identical to the one discussed in thread 807695 (https://developer.apple.com/forums/thread/807695). Technical Contrast: What works vs. What fails On the exact same app build and iOS 16+ devices, we observe a clear distinction: Standard ASCII Domain (onelink.me): Works perfectly. (Proves App ID and Entitlements are correct) Internal Development Domain (Standard ASCII): Works perfectly. (Proves our server-side AASA hosting and HTTPS configuration are correct) Japanese IDN Domain (xn--[punycode].com): Fails completely. (Status: "unspecified") Note: This IDN setup was last confirmed to work correctly on iOS 15 in April 2025. Currently, we are unable to install the app on iOS 15 devices for live comparison, but the regression starting from iOS 16 is consistent. This "Triple Proof" clearly isolates the issue: the failure is strictly tied to the swcd daemon's handling of IDN/Punycode domains. Validation & Diagnostics: Validation: Our Punycode domain passes all technical checks on the http://Branch.io AASA Validator (Valid HTTPS, valid JSON structure, and Content-Type: application/json). sysdiagnose: Running swcutil on affected iOS 16+ devices shows the status as "unspecified" for the IDN domain. Symptoms: Universal Links consistently open in Safari instead of the app, the Smart App Banner is not displayed, and Shared Web Credentials for AutoFill do not function. Request for Resolution: We request a fix for this regression in the swcd daemon. If this behavior is a specification for security reasons, please provide developers with a supported method or workaround to ensure IDN domains function correctly. We have sysdiagnose logs available for further investigation. Thank you.

I am building an app for iOS and MacCatalyst that indexes files by storing their local paths. Because the app relies on the file remaining at its original location, I only want to accept items that can be opened in place. I am struggling to determine if an item is "Open In Place" compatible early in the drag-and-drop lifecycle. Specifically: In dropInteraction(_:canHandle:) and dropInteraction(_:sessionDidUpdate:), calling itemProvider.registeredTypeIdentifiers(fileOptions: [.openInPlace]) returns an empty array. Only once the drop is actually committed in dropInteraction(_:performDrop:) does that same call return the expected type identifiers. This creates a poor user experience. I want to validate the "In Place" capability at the very start of the session so the drop target only activates for valid files. If an item is ephemeral (like a dragged photo from the Photos app or a temporary export), the drop zone should not react at all. How can I reliably detect if an NSItemProvider supports .openInPlace before the performDrop delegate method is called?