My app is configured with the App Clip experiences, and a Clip App card pops up when an NFC tag is scanned—whether the host app is not launched, running in the background, or active in the foreground. I want to prevent the App Clip card from popping up when the host app is in the foreground; how can this be achieved?

General: Forums topic: Family Controls Forums tag: Family Controls Configuring Family Controls documentation Requesting the Family Controls entitlement documentation Screen Time Technology Frameworks documentation FamilyControls documentation What's new in Screen Time API video Meet the Screen Time API video

If there is this situation: A text message is sent from a sender and gets classified as junk (by a text filtering extension) with the result that it gets send to the spam folder as expected. A text message with different content is sent from the same sender and gets classified as allowed, however it also gets sent to the spam folder. If the above is repeated but after step 1 the message is deleted, then in step 2 the message doesn't get sent to the spam folder. So the presence of the message from step 1 being in the spam folder is having an effect on the behavior of step 2. Expected beahavour (if so, why?), or a defect?

We integrated DeviceCheck framework into our app to prevent fraudulent call to our app service around one year ago. Recently, we received a few cases related to this function over Christmas Eve period. Based on the logs we have, it indicated both the following two functions returned errors. But we don't have the exactly errors logged and now we cannot replicate. DCAppAttestService.shared.attestKey() DCAppAttestService.shared.generateAssertion() The other finding we have is some users reporting this issue recently upgraded their devices from iOS 18 to iOS 26. So we are suspecting it's due to either the OS upgrading, or Apple's app attest service degrading. Anyone encountered the similar issues before, or have any idea regarding the root cause? Thanks!

Hi Apple Developer Community, I'm implementing MetricKit launch performance tracking in our iOS app and need clarification on two properties: histogrammedTimeToFirstDraw histogrammedOptimizedTimeToFirstDraw The Documentation Problem: The official MetricKit documentation provides minimal explanation of these properties beyond their names. Based on naming conventions, I initially assumed: histogrammedTimeToFirstDraw = cold launches histogrammedOptimizedTimeToFirstDraw = warm/optimized launches Based on our measurements: The “optimized” metric appears only in a small fraction of launches The "optimized" metric is actually slower The naming suggests the opposite behavior Questions: What specific launch conditions does each metric measure? Why would "optimized" launches be slower and less frequent? Is histogrammedOptimizedTimeToFirstDraw related to iOS app pre-warming or prediction features? If these metrics don’t correspond to cold vs. warm launch times, is there an alternative way to measure them accurately? Any clarification from Apple or insights from developers who've tracked these metrics would be greatly appreciated.

I am trying to port my sandboxed macOS app completely over to iOS using a Catalyst target and SwiftUI. There appears to be an issue when trying to drag to the Finder in Catalyst (and in SwiftUI in General). For some reason, the Finder will not accept multiple file drops, only a single file. On my macOS (non-Catalyst AppKit target), I overcame this by dropping multiple files to a UTType of .folder, and the OS accepted the folder. This workaround is not available for iOS because .folder is a macOS-only option. I have a test app to illustrate the issue. Hopefully someone can help. Download Test App

AgeRangeService is the burning topic right now. Needless to say, Everything is so unclear. We got our app finally into the TestFlight for QA and the product to test. only to find out that AgeAssurance for sandbox testing does not work. There is no document confirming or denying whether and when age assurance for the App with the release configuration in test flight would work. There isn't any guidance from Apple on whether an app that sells physical goods, such as an e-commerce app, can continue doing business as usual. Also, there is no clarity that the Age assurance options are off, 13, unverified, 13 verified, and so on. How those should be used.

I see many anti-theft apps already released in the App Store that have a feature to immediately play a loud sound when the charger gets unplugged. I can't find an API to make it work if the app is backgrounded, which is the main point. How can I achieve this?

My CoreSpotlight extension seems to exceed the 6 MB memory limit. What’s the best way to debug this? I've tried to attach the debugger on the Simulator but the extension seems to be never launched when I trigger the reindex from Developer settings. Is this supposed to work? On device, I am able to attach the debugger. However, I can neither transfer the debug session to Instruments, nor display the memory graph. So I've no idea how the memory is used. Any recommendations how to move forward? Is there a way to temporarily disable the memory limit since even with LLDB attached, the extension is killed.

Summary: I'm developing an iOS audio app in Flutter that requires background audio playback for long-form content. Despite having a paid Apple Developer Program account, the "Background Modes" capability does not appear as an option when creating or editing App IDs in the Developer Portal, preventing me from enabling the required com.apple.developer.background-modes entitlement. Technical Details: In the app that I am developing, users expect uninterrupted playback when app is backgrounded or device is locked similar to Audible, Spotify, or other audio apps that continue playing in background The Problem: When building for device testing or App Store submission, Xcode shows: Provisioning profile "iOS Team Provisioning Profile: com.xxxxx-vxxx" doesn't include the com.apple.developer.background-modes entitlement. However, the "Background Modes" capability is completely missing from the Developer Portal when creating or editing any App ID. I cannot enable it because the option simply doesn't exist in the capabilities list. What I've Tried: Multiple browsers/devices: Safari, Chrome, Firefox, incognito mode, different computers Account verification: Confirmed paid Individual Developer Program membership is active New App IDs: Created multiple new App IDs - capability never appears for any of them Documentation review: Followed all Apple documentation for configuring background execution modes Different regions: Tried changing portal language to English (US) Cache clearing: Logged out, cleared cookies, tried different sessions Apple Support Response: Contacted Developer Support (Case #102633509713). Received generic documentation links and was directed to Developer Forums rather than technical escalation. Has anyone else experienced the "Background Modes" capability missing from their Developer Portal? Has anyone successfully used the App Store Connect API to add background-modes when the GUI doesn't show it? What's the proper escalation path when Developer Support provides generic responses instead of technical assistance? Things I have attempted to solve this: audio_service package: Implemented as potential workaround, but still requires the system-level entitlement Manual provisioning profiles: Cannot create profiles with required entitlement if capability isn't enabled on App ID Other perhaps important facts about the environment where I am building the app: macOS Sonoma Xcode 15.x Flutter 3.5.4+ Apple Developer Program (Individual, paid)

如下图所示，在iOS18以上，这个识别话术为“xx主叫号码”，这个如何修改？ 附：iOS18以下话术就很合理

How can I use the Screen Time API to set a restriction for a child account from my app running on the parent’s account?

I’m trying to fully understand the purpose of the ageGates parameter in the AgeRangeService.requestAgeRange API. The official documentation includes the following statement: “The system may return geo-specific age ranges that override your provided age gates based on the person’s location and applicable regulations. When geo-specific ranges are required, the returned age range reflects regulatory requirements rather than the bounds of your age gates.” Based on this, it seems that even if my app provides specific age thresholds through the ageGates parameter, the system may override those boundaries depending on regional laws or regulations, and return a completely different lowerBound / upperBound than what my age gates would suggest. My current understanding is: ageGates indicates the thresholds my app uses to define its internal feature tiers, but the actual age range returned by the OS is determined by legal or regional requirements (e.g., COPPA, GDPR-K, AADC, SB2420), meaning the returned age range may not align with the age ranges implied by my ageGates values. I’d like to confirm whether this interpretation is correct. Additionally, if different regions may produce different lowerBound / upperBound values due to regulatory requirements, then it seems that: developers shouldn’t rely on fixed age buckets, and instead must implement feature gating logic dynamically based on whatever age range the OS returns. So my questions are: Is my understanding correct that ageGates is simply a hint that describes my app’s tier thresholds, and the OS may override those boundaries to comply with local regulations? If lowerBound / upperBound can vary across regions, what is the recommended way for developers to design their feature-gating logic? Should we avoid hardcoded age buckets and instead build flexible logic that adapts to whatever range the OS returns? I’d appreciate clarification so I can design our age-based policies appropriately and in a regulation-compliant way.

We have a login flow where the user authenticates in Safari, and at the end of the process the authentication server redirects back to our app using a Universal Link. On most devices, the app opens automatically without any confirmation banner. However, on several iPads, Safari always shows the “Open App A?” banner after the redirect. The user must tap Open every time. Other devices running the same iOS version do not show this issue. Expected Flow (working devices): Start authentication Safari login Authentication server redirects using a Universal Link App A opens automatically Problematic Flow (several iPads): Start authentication Safari login Authentication server redirects using a Universal Link Safari shows “Open App A?” confirmation banner User must tap Open App A starts Questions: Is this a known issue in iOS? Or is this expected behavior under certain conditions (i.e., is there a specific Safari/iOS specification that causes this banner to appear)? Is there any way to prevent Safari from showing the “Open App A?” banner and allow automatic redirection? ＊This issue did not occur on iOS 16, but it started appearing after updating to iOS 17. Devices : iPad 9th Gen/iPad 10th Gen

Hi We have an AppleTV app that is used to continuously display information (digital signage). One of our clients reports that their AppleTV returns to the homescreen by morning. While our recommendation is to setup Mobile Device Management to lock the AppleTV into running only our app, not every client will have the IT knowledge to set this up. So we're trying to figure out possible causes for the app getting closed. We've not received any crash reports, nor does the device give any indication the app crashed. The energy saving settings are set to run continuously without sleep. The client is reporting this happens every night, so it seems unlikely to be caused by tvOS updates. Are there other things I could rule out to find the cause of this issue? Any ideas are welcome, thanks!

The published "Next steps for apps distributed in Texas" says "A parent or guardian in Texas can withdraw consent for any app, which will block launching of the app on the child or teen’s device." My question is: will this also block notifications sent to that app from showing up on that device? Or will notifications still be delivered to the notification center, even though the app can't be launched? (Specifically, notifications sent from a server via Firebase topic/token). If notifications are not blocked automatically, what is the expected flow for this scenario? My app sends notifications from a server like this. I could implement client-side code to say "if consent is revoked, unsubscribe from notifications", but if the OS blocks launching of the app, this client-side code would never run. Similarly, I could subscribe to the server notifications for when consent is revoked, but my app is free & accountless, so I'm not aware of any information in the server notification that I could use to identify the specific user whose notifications should be stopped. (For example my users won't have an appAccountToken because they never made a purchase). Guidance would be much appreciated. I'm trying to comply with the law but I don't know how.

Hello, I’m currently reviewing and implementing age assurance and parental approval flows using AgeRangeService and PermissionKit (AskCenter) in the context of Texas regulatory compliance requirements. While the high-level APIs are clear, there are several technical aspects where the intended usage patterns are not fully explicit in the documentation. Clarification on these points would help ensure our implementation aligns with system expectations and regulatory obligations. ⸻ Querying the current approval state for SignificantAppUpdateTopic AskCenter.ask(...) returns Void, and AskCenter.responses(for:) provides an AsyncSequence of approval events. Is there an official or recommended way to determine whether a SignificantAppUpdateTopic has already been approved when the app launches, or is listening for future responses events the only supported mechanism? ⸻ Behavior of AskCenter.responses(for:) regarding past approvals When subscribing to AskCenter.responses(for:): • Does the stream replay previously recorded approval or decline decisions? • Or does it only emit events that occur after subscription? This affects whether the listener must be registered early in the app lifecycle. ⸻ Recommended lifecycle timing for registering a responses(for:) listener What is the intended or recommended time to register a responses(for:) listener? • At application launch • Immediately before calling ask(...) • When entering a specific gated feature Clarification on the expected lifecycle usage would be helpful. ⸻ Repeated calls to ask(...) after approval If AskCenter.ask(...) is called again for the same SignificantAppUpdateTopic after parental approval has already been granted: • Is the request ignored? • Is a new approval request sent to the parent? • Or is the call handled idempotently by the system? ⸻ Delivery of approval results when the child app is not running If a parent approves or declines a SignificantAppUpdateTopic while the child app is not running: • Will the approval decision be delivered as a responses(for:) event on the next app launch? • Or is the app expected to persist approval state locally? ⸻ Persistence of approval state Is the approval decision for SignificantAppUpdateTopic persisted by the system at the OS level, or is the app responsible for storing approval state? Additionally, does the approval persist across: • app restarts? • app deletion and reinstallation? ⸻ Meaning of activeParentalControls.significantAppChangeApprovalRequired How is activeParentalControls.significantAppChangeApprovalRequired determined? • Is this value explicitly configured by a parent (for example via Screen Time)? • Or is it automatically determined by the system based on region, age, or regulatory requirements? ⸻ Relationship between significantAppChangeApprovalRequired and AgeRangeService When activeParentalControls contains significantAppChangeApprovalRequired, is it still expected that apps call AgeRangeService.requestAgeRange(...)? Or can the presence of this flag be treated as sufficient indication that the user is a minor for gating purposes? ⸻ Recommended interpretation of AgeRangeDeclaration Is the intended usage of AgeRangeDeclaration to handle each case individually, or is it acceptable and recommended to interpret the values as different trust levels (for example, self-declared vs. government ID or payment verified)? Clarification on these points would help ensure that implementations of age assurance and parental approval flows are consistent with system behavior while meeting regulatory compliance requirements. Thank you for your guidance.

If I run an app with a message filter extension, it's triggered for all the prepaid unknown numbers and its not triggered for all the unknown postpaid numbers. Any idea, how to trigger for postpaid unknown numbers?.

Hello Apple Developer Support Team, I am the Account Holder of my Apple Developer Program team (Team ID: T2BKUF6E93). My iOS app is using Swift WeatherKit (WeatherService) on device. Although my environment is completely configured, the system WeatherDaemon consistently fails to generate the WeatherKit JWT token. My environment: Team type: Apple Developer Program (paid) Team ID: T2BKUF6E93 Account role: Account Holder Xcode: latest version Device: iPhone (real device) Provisioning Profile: iOS Team Provisioning Profile (auto-managed) Entitlement: com.apple.developer.weatherkit included WeatherKit Key: created successfully (.p8 downloaded) Bundle ID: correct and WeatherKit capability enabled App reinstalled after each configuration change Device rebooted Even after enabling WeatherKit capability and generating a WeatherKit Key, the system still fails to generate JWT: Failed to generate jwt token for: com.apple.weatherkit.authservice Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" The error persists across: multiple device restarts full clean/rebuild in Xcode deleting and reinstalling the app pulling the latest provisioning profiles waiting more than several hours for backend propagation What I suspect My WeatherKit entitlement and/or WeatherKit Key may not be fully propagated to the provisioning server or WeatherDaemon backend, even though everything appears correctly configured on the Developer Center. I kindly request the support team to: Verify whether the WeatherKit Entitlement is correctly attached to my app ID and provisioning profile. Verify whether my WeatherKit Key is properly registered and propagated for my team. Check if there are any backend propagation delays or stuck states for my Team ID (T2BKUF6E93). Confirm whether WeatherDaemon has permission to generate JWT for my app. Thank you Please let me know if any logs, screenshots, or provisioning profile identifiers are needed. Thank you for your help! Best regards, Jiangyang

I'm currently finding it impossible to get a text filtering extension to be invoked when there's an incoming text message. There isn't a problem with the app/extension because this is the same app and code that is already developed, tested, and unchanged since I last observed it working. I know if there's any history of the incoming number being "known" then the extension won't get invoked, and I used to find this no hindrance to testing previously provided that: the incoming number isn't in contacts there's no outgoing messages to that number there's no outgoing phone calls to the number. This always used to work in the past, but not anymore. However, I've ensured the incoming text's number isn't in contacts, in fact I've deleted all the contacts. I've deleted the entire phone history, incoming and outgoing, and I've also searched in messages and made sure there's no interactions with that number. There's logging in the extension so I can see its being invoked when turned on from the settings app, but its not getting invoked when there's a message. The one difference between now and when I used to have no problem with this - the phone now has iOS 18.5 on it. Its as if in iOS 18.5 there ever was any past association with a text number, its not impossible to remove that association. Has there been some known change in 18.5 that would affect this call filtering behavior and not being able to rid of the incoming message caller as being "known" to the phone? Update I completely reset the phone and then I was able to see the the message filter extension being invoked. That's not an ideal situation though. What else needs to be done beyond what I mentioned above in order to get a phone to forget about a message's number and thus get an message filtering extension to be invoked when there's a message from that number?