Hello, After being in the AppStore for more than a year with the app working perfectly, yesterday I started seeing that WeatherKit requests failed with Failed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Encountered an error when fetching weather data subset; location=<+41.40217108,+2.20023642> +/- 0.00m (speed -1.00 mps / course -1.00) @ 13/12/25, 12:20:35 Central European Standard Time, error=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors 2 Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" I checked on developer.apple.com and we still have everything turned on and No changes were made from an already deployed app; and we pay 200$ a month for WeatherKit, this is unacceptable since it's not the first time WeatherKit randomly decides to stop working. More fun facts: the widget works fine...

For other permission prompts in the iOS ecosystem, we have the option to configure the text shown in the prompt via keys in the Info.plist. This does not appear to be the case with regards to the age range permission prompt. The text of the prompt implies the app includes a differentiated experience for child or teen content and that confirming age unlocks more features (making it seem optional for using the app). Is there a plan for app developers to be able to update that permission prompt similarly to how we can configure others? If so, is there any timeline we can expect that on?

My app updates are repeatedly rejected under Guideline 2.3.6 – Accurate Metadata, with a request to remove “Age Assurance” unless the feature can be located. However, the app does include age assurance. During onboarding, users must enter their date of birth, and users under 16 are blocked from completing registration and using the app. The app contains a women’s health blog and a community Q&A feature (similar to Reddit), where users can ask and answer health-related questions. For this reason, I am considering restricting access to users 18 and older. Each time I explain this to the review team and provide a screenshot of the DOB screen, the app is approved. What is the correct way to document or surface this in App Store Connect so reviewers can easily find it and avoid repeated rejections? Is a DOB gate sufficient for Apple’s definition of Age Assurance?

Share Age Range Permission is set to 'Ask First'. Application requested for AgeRange via requestAgeRange API. System presented a consent window where user has to make a choice. User did not acted. Application was pushed to background. Our Application supports PushToTalk Framework and we have successfully joined the channel already. User tapped on the blue-pill , SystemUI will get presented. User tapped on the SystemUI, A New Full Screen SystemUI will get presented. User chosen 'Leave' option and our application left the active channel. 10 User brought the application to foreground and the previous "Share Age Range" system window disappeared. 11. After Step 10, We need to terminate and launch our application in order to get the "Share Age Range" system window. Is "Share Age Range" system window getting disappear is expected here or a BUG

Hey all, Running into an issue with a WeatherKit. Whenever I make a WeatherKit API call, I get this error: Details: { domain: WeatherDaemon.WDSClientErrors, localizedDescription: invalidAuthorization: 401, underlyingError: Unknown, code: 3 } This only happens when calling via the Swift package: swift WeatherService.shared.weather(for: location).currentWeather When I was calling the WeatherKit REST API directly from Dart, everything worked fine. So far I’ve: Enabled WeatherKit in the Apple Developer account Added the WeatherKit capability to the app Refreshed provisioning profiles Installed the app fresh on device/simulator Has anyone seen this specific invalidAuthorization: 401 from WeatherDaemon.WDSClientErrors when using WeatherService in Swift, and know what might be missing or misconfigured?

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.

I recently submitted an Advanced App Clip Experience, and the status currently shows as "Received." My default App Clip Experience is already working well, but I need the advanced experience to go live as soon as possible. Does anyone know the typical timeframe for this to be published? Also, will the status change from "Received" to something else when it is fully active? Any insight would be appreciated. Thanks!

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.

When syncing an Office 365 (Exchange) account on an M1 Max machine running the latest macOS (e.g., Sonoma), the native contactsd and AddressBookManager processes enter a severe, persistent failure loop. The CPU usage spikes from 0.0% to over 80% (observed at 81%) and repeats every 60-90 seconds. This occurs even when the account is entirely empty of contacts and after performing a clean macOS installation, strongly indicating a systemic bug in the framework's Exchange protocol handler on the M1 architecture. System Information Affected Hardware: Apple M1 Max Affected macOS Version: Tahoe 26.1 Affected Processes: contactsd, AddressBookManager Account Type: Microsoft Exchange / Office 365 Steps to Reproduce System Setup: Perform a clean installation of macOS on the M1 Max machine (USB boot, NO Migration Assistant or data restoration). Account Preparation: Ensure the target Exchange account's contacts folder is entirely empty on the server (via Outlook Web Access). Trigger: Go to System Settings > Internet Accounts and add the Exchange account. Ensure ONLY Contacts is toggled ON. Observation: Open Activity Monitor and sort by % CPU. Expected Behavior The contactsd and AddressBookManager processes should spike briefly (under 5%) to establish the empty sync, then settle to a persistent idle state (0.0% to 0.5% CPU). Actual Behavior The processes never settle: CPU Spikes: Usage repeatedly jumps from 0.0% to 81% for AddressBookManager and 22-59% for contactsd. Pattern: This extreme spike lasts for a few seconds before the thread crashes/restarts, and the process immediately re-initiates the loop, consuming massive CPU cycles continuously. Diagnostic Proof The runaway CPU is not caused by corrupt data: Data Neutralization: The account's contacts folder was emptied on the server, yet the high CPU loop persisted when syncing. Clean System: The issue is reproducible on a clean, from-scratch macOS installation, ruling out corrupted user preferences or system files. Cross-Architecture: The exact same account syncs perfectly on iOS and newer M4 Macs, confirming the data is valid and the issue is specific to the M1 Max's implementation of the Exchange protocol handler. Workaround (For Visibility) To restore system performance, the user must DELETE the entire Exchange account from System Settings > Internet Accounts and use a third-party client (e.g., Outlook for Mac) for synchronization, as it bypasses the buggy native framework.

I have a watch only app that display an open/close park status and the current temperature with a current condition icon. That's it. On second submission the watch app was rejected due to no WeatherKit attribution. I have a lack of clarity of what's needed. With my single view that display my content I don't want WeatherKit attribution to overwhelm what's being presented to the user. I've tried looking for watch apps in the store that provide attribution and I'm not finding any. Looking for advice on how to meet this requirement without attribution overpowering my content.

Our team is in the process of updating our apps to comply with Texas's new state law. In order to minimize user confusion and provide the most ideal flow to access the app as possible, we have a few questions we would like answered. Summary of questions: Is isEligibleForAgeFeatures intended to be accurate and accessible before the user has accepted the Age Range permissions prompt? As other US states and/or other countries adopt a similar law going forward, will this instance variable cover those locations? Will the runtime crashes on isEligibleForAgeFeatures and other symbols in the DeclaredAgeRange framework be addressed in a future RC or in the official release? Details and Investigations: With regards to isEligibleForAgeFeatures, our team has noticed that this value is always false before the age range prompt has been accepted. This has been tested on the XCode RC 26.2 (17C48). Assuming the request needs to be accepted first, isEligibleForAgeFeatures does not get updated immediately when the user chooses to share their age range (updated to true, when our sandbox test account is a Texas resident). Only upon subsequent relaunches of the app does this return a value that reflects the sandbox user's location. Is isEligibleForAgeFeatures intended to be accurate and accessible before the user has accepted the Age Range permissions prompt? This leads to our follow-up question to clarify whether isEligibleForAgeFeatures explicitly correlates to a user in an affected legal jurisdiction–if future US states and/or other countries adopt a similar law going forward, will this instance variable cover those locations? Can we also get confirmation about whether the runtime crash on isEligibleForAgeFeatures and other symbols in the DeclaredAgeRange framework will be addressed in a future RC or in the official release? Thank you.

Hi everyone, I have a question regarding the intended privacy limits of the DeviceActivityReportExtension. According to the documentation and the WWDC21 session "Meet the Screen Time API", this extension was created specifically to prevent the host application from accessing the user's underlying activity data (websites visited, app usage, screen time, etc). But I have found that my host app is actually able to reconstruct this raw activity data from the activity report. I am able to extract specific visited websites and app usage durations back into the main app. I reported this to Apple Security (Case ID: OE1100504480881 ), assuming it was a sandbox bypass. However, they closed the ticket stating that this is "expected behavior" and requires no fix. My question for Screen Time Engineers: Is the documentation incorrect? If my host app is expected to be able to read this data, is there a formal API we should be using instead of extracting it from the report extension? The current behavior contradicts the privacy limits described in the documentation, so I am confused if I should rely on this data access for my app features or if it will be patched later. Thanks.

After reading the news below, we are currently working on updating our app in preparation for the enforcement of Texas SB 2420. https://developer.apple.com/news/?id=2ezb6jhj Based on the information in the announcement, we understand that parents will be able to revoke their consent for apps. However, we are unsure how an app is supposed to obtain or verify the parent’s consent status in the first place. We reviewed the Declared Age Range API and PermissionKit’s Significant Change API, but could not find any functionality related to this. If anyone with expertise on this topic has insight, we would greatly appreciate your guidance. Thank you in advance.

After reading the news below, we are currently working on updating our app in preparation for the enforcement of Texas SB 2420. https://developer.apple.com/news/?id=2ezb6jhj Based on the information in the announcement, we understand that parents will be able to revoke their consent for apps. However, we are unsure how an app is supposed to obtain or verify the parent’s consent status in the first place. We reviewed the Declared Age Range API and PermissionKit’s Significant Change API, but could not find any functionality related to this. If anyone with expertise on this topic has insight, we would greatly appreciate your guidance. Thank you in advance.

操作步骤：1:调用let eligible = try await AgeRangeService.shared.isEligibleForAgeFeatures，返回YES后，再次调用 let response = try await AgeRangeService.shared.requestAgeRange(ageGates:18, in: viewController) switch response { case .declinedSharing: DispatchQueue.main.async { completion(.declinedSharing, nil, nil) } case .sharing(let swiftRange): DispatchQueue.main.async { let model = ARAgeRange(swiftRange: swiftRange) completion(.sharing, model, nil) }

[MTAgeRangeService requestEligibility:^(BOOL eligible) { if (eligible) { //您应用程序的用户所在的地区，需要执行特定年龄相关义务 [MTAgeRangeService requestAgeRangeWithAgeGates:18 in:[ViewU getCurrentVC] completion:^(enum ARResponseType responseType, ARAgeRange * _Nullable ageRange, NSError * _Nullable error) { [weakself.ageRangeLoadingView dissmiss]; self->_ageRangeLoadingView = nil; if (responseType == ARResponseTypeSharing) { //用户同意并分享了年龄范围 if ([ageRange.lowerBound intValue] >= 18) { //满18岁可以注册 }else{ //不到18岁不能注册，提示一下 } }else{ //用户拒绝或者其他未知错误，需要提示 }else{ } } }] ; }else{ }];

I'm facing a problem where notification permissions are working fine in the main app, but failing in the Device Activity Report Extension on iOS 26. This issue wasn’t present in earlier iOS versions. Despite having notification permissions granted in the main app, the extension fails to get authorization. iOS 26: " Before iOS 26:

Hi everyone, I'm building a task management app that layers on top of EventKit/Reminders. I'm also moderating /r/AppleReminders. I see a confusion around the semantics of dates on both the developer side and on the user side. I'm trying to map the standard productivity mental model to the EKReminder implementation and hitting some walls. In productivity contexts, a task tends to have three distinct dates: Start Date: When the task becomes actionable — Don’t alert the user before this date. Notification: When the device should buzz/ping the user — Meaning that they can get started on the task. Due Date: Hard deadline — If the system works well, tasks are meant to rarely be past-deadline; productivity systems are about meeting deadlines rather than about missing them. The EventKit Reality Here is what I’m seeing in practice, and I’m hoping someone can correct me if I’m wrong: Field Description In Practice (Reminders App) startDateComponents Docs say "start date of the task" Seemingly unused? I can set it via API, but the Reminders app UI ignores it. It doesn't seem to trigger visibility in "Today" or Smart Lists. dueDateComponents Docs say "date by which reminder should be completed" Conflated. Acts as the "Date" you see in the list. It functions as the Start Date (shows in Today), Due Date (turns red tomorrow), AND Notification time (unless early alerts are set). alarms Inherited from EKCalendarItem seems to be used for the actual notifications, including "Early Reminders," but tightly coupled to the due date in the UI. My Questions: Is startDateComponents effectively a dead field? Is there any native behavior (Smart List filtering, sorting, visibility) that respects this field, or is it purely for metadata storage for third-party apps? Smart List Logic: I was hoping to create a Smart List that shows "Actionable" items (i.e., Start Date <= Today). However, the Smart List filters only offer a generic "Date" field, which maps to dueDateComponents. Has anyone successfully filtered by startDateComponents in a native Smart List? Conflation: Is there any "blessed" way to set a Due Date that is distinct from the Notification time without fighting the system? (e.g. Due Friday, but remind me Wednesday). Any insight into the intended semantics here would be huge. I'm trying to avoid fighting the framework, but the "One Date to Rule Them All" approach in the Reminders app is making it tricky to support separate Start/Due dates. Thanks!

Hello, We are encountering an issue where invoking our App Clip via a Safari Smart App Banner fails on certain devices, particularly those running iOS 26. When a user taps "Open" on the Smart App Banner, the App Clip card attempts to load but ultimately fails with ASDErrorDomain Error 507. The error occurs consistently on specific devices, while other devices function correctly. In some instances, the App Clip card metadata/UI appears momentarily (flashes on the screen) before the error message is displayed and the process terminates. Has anyone else experienced this specific ASDErrorDomain error? We have already submitted a report via Feedback Assistant, but any insights or workarounds from the community would be appreciated. Thanks!

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.