I am attempting to configure appclips, but I am getting this error in App Store Connect. I created an app clips target in my project, I have checked the XCAsset files and it is included when archived and pushed to App Store Connect. In both my parent and my app clips target I've added the associated domains capabilities, with the following associated same domains for both targets: appclips:akin-server-side-staging.onrender.com appclips:akin-server-side.onrender.com applinks:akin-server-side-staging.onrender.com applinks:akin-server-side.onrender.com My server is configured to serve the following json at all permutations of the staging endpoints and prod endpoints for both well known and aasa without well known. Here is one of them: https://akin-server-side.onrender.com/.well-known/apple-app-site-association Here is the JSON it is returning: {"applinks":{"details":[{"appIDs":["8PJ28P9ZZ8.com.ElevatedUnderdogs.akin1"],"components":[{"\/":"\/appClips\/referral\/venueToUser\/*"}]}]},"appclips":{"apps":["8PJ28P9ZZ8.com.ElevatedUnderdogs.akin1.Clip"]}} And yet I'm still getting Invalid Entitlement: Unknown ID in the store.

I have a feature that relies on Apple Universal Links, which requires the apple-app-site-association file. I made some changes to this file a week ago, but I noticed that the corresponding file still hasn’t been updated when queried via: https://app-site-association.cdn-apple.com/a/v1/x When I query directly from our server, I can see the latest file here: https://x/.well-known/assetlinks.json Could anyone please help us update the file in the CDN? Thank you.

Dear Sir/Madam, Thank you for your support. I have reviewed the documentation for Local Push Connectivity (see URL below) and, following the instruction in the "Important" section to "Request this entitlement from the Entitlement Request Page," I completed the application process for this Entitlement on March 11, 2026. [Local push connectivity] https://developer.apple.com/documentation/networkextension/local-push-connectivity?language=objc#Supporting-APNs-and-local-push-connectivity-in-one-app Subsequently, on March 13, 2026, I received the following reply from Apple: Sub : Re: Requesting Network Extension App Push Entitlement From: Local Push Review Sent: Friday, March 13, 2026 4:09 AM Hi, Thank you for your interest in the Local Push Connectivity entitlement. Your entitlement request has been approved for: Team ID: NWKYYYYYYY Technical documentation on this API is available here: -(Omission) - Best Regards, Apple Developer Relations My understanding is that upon approval of this application, an "Entitlements" field should be added to the input fields for creating provisioning profiles. However, as of today(March 18, 2026), it has not yet been added. Will the Entitlements field be added if I simply wait? My account (Apple ID), which submitted the application, belongs to three Team IDs. For convenience, I will refer to them as Team ID SV3XXXXXXX, Team ID NWKYYYYYYY, and Team ID WEJZZZZZZZ. The application status for Entitlements for each Team ID is as follows: Team ID SV3XXXXXXX Entitlements: Present. Applied for Entitlements on February 6, 2021. (Received "Re: Requesting Network Extension App Push Entitlement" email on February 6, 2021) Team ID NWKYYYYYYY Entitlements: Not present. Applied for Entitlements on March 13, 2026. (Received "Re: Requesting Network Extension App Push Entitlement" email on March 13, 2026) Team ID WEJZZZZZZZ Entitlements: Present. No record (email) of applying for Entitlements. Because of this, I am concerned that the Entitlements applied for Team ID NWKYYYYYYY may have been mistakenly granted to Team ID WEJZZZZZZZ, and I am inquiring about this. Will the Entitlements field for Team ID NWKYYYYYYY be added if I simply wait? Thank you in advance.

On iOS 26.3.1, deviceactivityd produces zero log output and never wakes a DeviceActivityMonitor extension at the scheduled time, even when the schedule is successfully registered. The extension's intervalDidStart(for:) method is never called. Steps to Reproduce: Create an app with a DeviceActivityMonitor extension subclass Add the com.apple.developer.family-controls entitlement to both the main app and extension targets Add a shared App Group entitlement to both targets In the main app, call: let center = DeviceActivityCenter() center.stopMonitoring([.myActivity]) let schedule = DeviceActivitySchedule( intervalStart: DateComponents(hour: 17, minute: 30), intervalEnd: DateComponents(hour: 17, minute: 45), repeats: true ) try center.startMonitoring(.myActivity, during: schedule) Verify registration succeeds: DeviceActivityCenter().activities.contains(.myActivity) returns true Background the app completely and wait for the intervalStart time (5:30 PM in this example) Expected Result: intervalDidStart(for:) is called in the extension process at 5:30 PM. ManagedSettings shields are applied without any user interaction. Actual Result: intervalDidStart(for:) is never called. No extension process is launched. Filtering Console.app for deviceactivityd on the device returns 0 messages — the daemon produces no logs whatsoever despite an active registered schedule. Shields are never applied. Additional Evidence: Third-party apps using DeviceActivity (e.g. Prayer Lock) successfully apply shields at scheduled times on the same device and OS version, confirming the framework is not universally broken Filtering Console.app for the app's bundle ID at the trigger time shows the main app process applying shields via a UNCalendarNotificationTrigger fallback — but no extension process activity DeviceActivityCenter().activities correctly lists the registered activity before and after the trigger time, confirming the schedule registration API is functional Environment: iOS 26.3.1 Physical device (required for FamilyControls) Development-signed build with com.apple.developer.family-controls entitlement provisioned App Group shared between main app and extension targets

Similar Issue to FB13556935: On iOS 26.3.1, deviceactivityd produces zero log output and never wakes a DeviceActivityMonitor extension at the scheduled time, even when the schedule is successfully registered. The extension's intervalDidStart(for:) method is never called. Steps to Reproduce: Create an app with a DeviceActivityMonitor extension subclass Add the com.apple.developer.family-controls entitlement to both the main app and extension targets Add a shared App Group entitlement to both targets In the main app, call: let center = DeviceActivityCenter() center.stopMonitoring([.myActivity]) let schedule = DeviceActivitySchedule( intervalStart: DateComponents(hour: 17, minute: 30), intervalEnd: DateComponents(hour: 17, minute: 45), repeats: true ) try center.startMonitoring(.myActivity, during: schedule) Verify registration succeeds: DeviceActivityCenter().activities.contains(.myActivity) returns true Background the app completely and wait for the intervalStart time (5:30 PM in this example) Expected Result: intervalDidStart(for:) is called in the extension process at 5:30 PM. ManagedSettings shields are applied without any user interaction. Actual Result: intervalDidStart(for:) is never called. No extension process is launched. Filtering Console.app for deviceactivityd on the device returns 0 messages — the daemon produces no logs whatsoever despite an active registered schedule. Shields are never applied. Additional Evidence: Third-party apps using DeviceActivity (e.g. Prayer Lock) successfully apply shields at scheduled times on the same device and OS version, confirming the framework is not universally broken Filtering Console.app for the app's bundle ID at the trigger time shows the main app process applying shields via a UNCalendarNotificationTrigger fallback — but no extension process activity DeviceActivityCenter().activities correctly lists the registered activity before and after the trigger time, confirming the schedule registration API is functional Environment: iOS 26.3.1 Physical device (required for FamilyControls) Development-signed build with com.apple.developer.family-controls entitlement provisioned App Group shared between main app and extension targets

Today is March 17th, which is the effective date for BR DECA. From what I can tell, isEligibleForAgeFeatures is still returning False for users in Brazil. Following up on https://developer.apple.com/forums/thread/816987?answerId=878188022#878188022, the API does not appear to be covering the requirements for this regulation. Could you please give some guidance on whether isEligibleForAgeFeatures will ever return True for Brazil? I'm also curious whether other apps are also seeing the same behavior (isEligibleForAgeFeatures=False) for users in BR today.

I am trying on iOS 16.1.1 the Nearby Interaction framework. I am testing it on two iPhones 14 Pro Max. The supportsDirectionMeasurement property returns false (!) and the direction property on the NINearbyObjects is nil. Has someone experienced the same issue?

Hello, my app is frequently loosing / forgetting the Screen Time Permission that had been granted previously on iOS 26. I have experienced it myself, sysdiagnose is in this radar: FB18997699 But also also my App Store users who have updated to iOS 26 already have reported this bug. It would be great if Apple could ensure that this bug is addressed before iOS 26 is released to the public.

DeviceActivityReportExtension sandbox blocks all output channels — how to export resolved Application.bundleIdentifier? Application.bundleIdentifier only resolves to a non-nil value inside a DeviceActivityReportExtension (ExtensionKit/XPC). The main app and DeviceActivityMonitor extension always return nil. However, the Report Extension's sandbox silently blocks every output channel I've tested: UserDefaults (App Group): Reads succeed, writes silently dropped File writes (App Group container): Fail silently or throw HTTP requests: Network blocked entirely Local Notifications: "Couldn't communicate with a helper application" UIPasteboard: Writes silently fail iCloud KVS: synchronize() returns false Both targets share the same com.apple.security.application-groups entitlement and group identifier. The main app reads and writes to the shared container normally — only the extension's writes fail. This means resolved bundle identifiers can only be rendered in the extension's own SwiftUI view and cannot be communicated anywhere else. My question: Is this sandbox restriction intentional? If so, what is the recommended mechanism for the host app (or a backend) to obtain the resolved bundle identifiers that only the Report Extension can access? Environment: Xcode 16.3, iOS 18.3, physical device. Sample project: https://drive.google.com/file/d/1DPyN2BCUt5p-RKEPA0zsDFFEvgZVHlS_/view?usp=sharing — a minimal two-target project that demonstrates every failing channel. Run on a physical device, grant Screen Time access, select apps, and observe that bundle ID resolution shows PASS but all write channels show FAIL.

Hello I'm using this sdk DeclaredAgeRange to get the user age range When I'm doing in debug mode using sandbox account it is working as expected and I can get the user age range But when I tried in TestFlight build using sandbox account it is not working and it is always return the age range 18+ and also isEligibleForAgeFeatures API is always returning false Any advise on this?

Hi there, Starting with iOS 26.2 RC, all my DeviceActivityMonitor.eventDidReachThreshold get activated immediately as I pick up my iPhone for the first time, two nights in a row. Feedback: FB21267341 There's always a chance something odd is happening to my device in particular (although I can't recall making any changes here and the debug logs point to the issue), but just getting this out there ASAP in case others are seeing this (or haven't tried!), and it's critical as this is the RC. DeviceActivityMonitor.eventDidReachThreshold issues also mentioned here: https://developer.apple.com/forums/thread/793747; but I believe they are different and were potentially fixed in iOS 26.1, but it points to this part of the technology having issues and maybe someone from Apple has been tweaking it.

A screen time app I'm making has started telling users that their limit was reached even when they're far below their limit for the day (sometimes even at 0 minutes for the day). This issue only started happening after upgrading my software to iOS 26.2. Is this happening to anyone else? If so how have you found any solutions or does anyone know of any changes that could be causing this? Any help would be appreciated.

Hi, I’m building an iOS app called SocialLite using Apple’s Screen Time APIs, primarily FamilyControls and ManagedSettings. My goal is to block access to the Instagram app itself, while still allowing the user to receive and see Instagram notifications. Right now, when I apply the shield/block using the Screen Time API, the Instagram app is blocked as expected, but its notifications also appear to be blocked/suppressed at the same time. What I’m trying to achieve: Block the Instagram app from being opened Still allow Instagram notifications to come through normally Current behavior: The app is blocked Notifications are also blocked or no longer visible My question: Is there any supported way with Apple’s Screen Time API / ManagedSettings to shield or block an app while still allowing that app’s notifications? Or are app access and notifications tied together by design when a shield is applied? If this behavior is expected, I’d appreciate confirmation from Apple or guidance on whether there is another supported approach. Thanks.

The Numbers.app reopens the last edited document when the app launches. If the document was moved to another folder in the Files.app while the app was not running, Numbers.app correctly tracks the file and reopens it. However, if the document was deleted in the Files.app and moved to Recently Deleted, Numbers.app does not reopen the document when the app launches. Question : How does Numbers.app detect that a document has been moved to Recently Deleted? Can third-party apps implement the same behavior? What I tested : If a file is moved while the app is not running, resolving a bookmark successfully tracks the moved file. Files that are deleted via the Files.app appear in Recently Deleted, but those files are actually moved to the following directories: iCloud Drive /var/mobile/Library/Mobile Documents/.Trash/ On My iPad /var/mobile/Containers/Shared/AppGroup/{UUID}/File Provider Storage/.Trash/ App sandbox Documents directory ([On My iPad]/[Any App]) /var/mobile/Containers/Data/Application/{UUID}/Documents/.Trash/ When resolving the bookmark after deletion, the bookmark still resolves successfully and returns the new file URL inside the .Trash directory. I tried the following checks on the resolved URL: Checking file existence Checking read/write accessibility Inspecting bookmark resolution results Using APIs related to NSTrashDirectory See https://developer.apple.com/forums/thread/813329#813329021 All of these behaved the same as when the file was moved to a normal directory. None of these checks allowed me to detect that the file had been deleted. Additional experiment: I suspected that the app might simply check whether the path contains ".Trash", so I performed the following experiment. If a .numbers file is moved to /var/mobile/Containers/Data/Application/{UUID}/Documents/.Trash/ then The file appears in Recently Deleted in Files.app Numbers.app does not reopen the document when the app launches However, if the same file is moved to Documents/Trash Documents/.Trashed Documents/Any Folder/.Trash then The file does not appear in Recently Deleted in Files Numbers does reopen the document when launched This suggests that Numbers.app is not simply checking whether the path contains ".Trash".

We are building an AI-powered smart glasses companion app, similar to Meta Ray-Ban. We want to provide true hands-free calling support. Right now, whenever the app tries to dial a native cellular call, iOS shows a confirmation screen that requires the user to tap to start the call. If the user always has to confirm/tap on the phone screen, there is no real point in using smart glasses for making calls. How can we initiate a native outgoing call without any confirmation dialog or extra tap, exactly like Siri does it, or like the Meta Ray-Ban glasses do when the user says “Hey Meta, call [name]” Please guide us on the correct APIs, entitlements, or integration path to achieve this behavior. Thank you.

We’re seeing a change in Spotlight search behavior on iOS 17 and later: Observation: User‑visible keywords we index (e.g. via Core Spotlight / CSSearchableItemAttributeSet with keywords) only start appearing in Spotlight suggestions after the user has typed more than 3 characters. With 1–3 characters, our app’s content often doesn’t show up at all, even when it clearly matches. Before iOS 17: The same indexed content could appear with fewer characters (e.g. 1–3 characters). Environment: Reproduced on multiple devices running iOS 17.x / 18.x; behavior is consistent. We’d like to confirm: Is this a documented change in iOS 17 (e.g. minimum character threshold for third‑party Spotlight results)? If yes, where is it documented? If it’s not intentional, could this be treated as a bug and considered for a fix in a future release? We’re happy to provide a sample project or more detail if that would help. Thank you.

Hello, I submitted a Family Controls (Distribution) entitlement request on February 25, 2026 for my prayer/productivity app that uses the Screen Time API to block distracting apps. I also submitted requests for two extensions on March 6, 2026: com.prayfirst.prayFirst.ShieldAction com.prayfirst.prayFirst.ShieldConfiguration All three requests still show "Submitted" status in the Certificates, Identifiers & Profiles portal with no progress. I contacted Apple Developer Support (Case #102839422791), and they mentioned I should have received a "follow-up number" after submission — but I never received one. This entitlement is the only blocker preventing me from building and distributing my app. Could a DTS engineer please assist or escalate this? Team ID: BH752TBX9L Thank you.

Hi everyone, I'm running into what appears to be a stuck Family Controls entitlement request and wanted to see if anyone has experienced something similar. Request ID: 9D7MU547QH The request is still showing a status of "Submitted". Context: • Our main app bundle ID was already approved for the Family Controls entitlement. • Two related extensions (ShieldConfiguration and DeviceActivityMonitor) were also approved within a few days. • The remaining request is for a ShieldAction extension, which handles button taps from the shield UI. This entitlement is currently blocking our business's beta testing, so we’re trying to understand whether this is just normal queue delay or if the request might be stuck. Has anyone seen a case where the main app and other extensions were approved but a ShieldAction request remained in "Submitted" for an extended period? If an Apple engineer happens to see this, I’d greatly appreciate any guidance on whether the request might be stuck in the review queue. Thank you!

Given that we can't use isEligibleForAgeFeatures property on macOS, the documentation states that In macOS, isEligibleForAgeFeatures returns false because the system doesn’t require Age Assurance for the person or device. However, you can still call requestAgeRange in macOS to get the declared age range. But in unsuitable region the requestAgeRange request always returns DeclaredAgeRange.AgeRangeService.Error.notAvailable which is vague, as it might stand for API being unavailable just as well as "You receive this error when the system prompts a person and they decide not to share their age range with your app. ", as per documentation. Unfortunately, this error fires immediately instead of showing any kind of prompt for user, so the description is definitely wrong (or incomplete) in here. Possible solutions: expand Error cases to separate not available API and not available response expand isEligibleForAgeFeatures to properly support macOS Moreover, unlike iOS, there is still no usable tool or algorithm to test given feature for macOS (mock region, mock age, mock source of approval, revoke declared range, etc). Now I get a review with rejection, stating that I don't have age verification mechanisms present in my app. Also I found out that after filling the App Information regarding Age Ratings it spreads to all fresh releases, so even though my newest macOS release doesn't contain age verification mechanisms yet, it should, as iOS release has got this functionality up and running already and I had to check this when filling Age Ratings questionnaire. Now I'm stuck between removing this capability from App Information, so the macOS release can pass and stalling macOS releases until there is a proper usable API to implement Declared Age Range verification properly (at least the same way as on iOS). How should I properly develop and test this feature for macOS before releasing it publicly?

Dear Apple, while implementing Declared Age Range API in my app, I've noticed a mistake in documentation: the isEligibleForAgeFeatures property is marked 26.0+ in documentation, but 26.2+ in Xcode, which ultimately leads to inability to use it with OS below 26.2. Moreover, I'm thoroughly confused by this quote from documentation: This flag returns true on iOS and iPadOS based on a person’s eligibility and always returns false on macOS. It leads me to two questions: Is it possible to use Declared Age Range API for macOS apps? Will it be possible to use it in future? Will there be any changes regarding this matter in a meantime (especially after Jan 1st)? If yes - when should we expect these changes? If no - why this API declares macOS 26+ support alongside iOS/iPadOS, if it simply doesn't work for macOS now? As of now, my iOS app works flawlessly with given API (on iOS 26.2) while macOS app returns isEligibleForAgeFeatures = false and requestAgeRange request always throws AgeRangeService.Error.notAvailable. Also, does it mean that one should not use isEligibleForAgeFeatures boolean while implementing Declared Age Range API for apps below iOS 26.2 (I mean 26.0+)? Or implementing given API for iOS 26.2+ is a sufficient way to go? So shouldn't the whole API be marked as 26.2+? The minimum iOS version in my app is 16.0 and minimum macOS version is 13.0 anyway, so the significant part of users is left out of these updates, but the main goal here is legal compliance.