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.

When updating an existing advanced app clip experience, the change doesn't actually apply. It shows the correct image in the UI, but when you use the app clip it shows the old image. Looking into it more, the status has "UPDATE_SUBMITTED". Seems related to this issue (https://developer.apple.com/forums/thread/810544) and this issue (https://developer.apple.com/forums/thread/810351).

We recently released an update to our app to prepare for TX SB2420. Almost immediately on release, we started getting crash reports of crashes when calling isEligibleForAgeFeatures. Crashed: com.apple.root.user-initiated-qos.cooperative EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000004 Is it possible that these are beta users that have IOS 26.2 RC or is there a bug in the release version of IOS 26.2? Note: The crash reports are coming from Crashlytics so we are not getting OS build identifiers other than version "26.2"

I'm reading the "Testing Age Assurance in Sandbox" doc, but I couldn't figure out the step: 2. Tap Sandbox Testing from the main menu Where is the "main menu"?

While preparing my app for Declared Age Range capability usage, I've noticed a weird behaviour: the same code works for iOS, but not for macOS. My project uses same target for both platforms, so the capability is enabled for both platforms. The business logic layer is also shared across between platforms. Both UI layers are writter in SwiftUI. The iCloud account used for testing on iOS and macOS devices is the same, so even the consent is shared across both devices. While requestAgeRange(ageGates:) seems to work just fine for iOS app, for macOS app it always throws Not available error (DeclaredAgeRange.AgeRangeService.Error.notAvailable) Am I missing something? Could the API be somehow unavailable for macOS? Should I use AgeRangeService.shared.requestAgeRange(ageGates:in:) for macOS instead of SwiftUI's @Environment-based approach? Also, after giving permission, is there a way to actually revoke it? In Age Range for Apps menu I can only view the list of apps that have my consent to share my age range, but not the ability to revoke it.

Hello, Recently we got a question about the keyboard sensor data collection in our research project: "For the typing statistics, was any typing included or only messaging and notes? E.g., typing in the browser, phone search, calendar, etc?" While I believe it should be any typing included, I was not able to find a document explicitly stating that. Could you help to confirm it or guide me to any documentation explaining it? Thanks!

I'm encountering a strange behavior with one of my home's on Home app while I'm off network. When I launch the app it indicates that the hub is not responding and all of my devices are unavailable. However, on the menu bar at the bottom if I switch to "Automation" and back to "Home" the pop-up goes away and my devices are accessible again (sometimes this take a few attempts). Siri is also able to consistently control my devices without an issue. The same behavior occurs with Home app on other devices (e.g. Mac) and with other members that have access to the household. 3rd party HomeKit app like "Controller" does not have an issue. This issue began with iOS 26 and I haven't had much luck resolving the issue. I already tried rebooting everything, including removing and re-adding an Apple TV (home hub). I have other homes shared with me in Home App with similar network/environment that are still working. The home I'm having issues has the most number of devices though (over 100+).

Hey Im currently trying to use the weatherkit API and Im seeing the following returned: {"reason": "OVER_QUOTA"} Im using the correct service, key and bundle ID. Ive generated a private key too.

The universal links for my apps stopped working. The server where the AASA files where hosted worked on IPV4 exclusively, a few days ago i changed the configuration to IPV6 only. I´ve created new IPV6 entries, renewed all certifactes and deleted all IPV4 entries for the domains. All seemed fine, but at Saturday I realized that my universal links stopped working for new user. What i´ve done to find the issue: Example domain that was used for debugging: "https://developffw.burns.fun" I´ve verified the AASA file is hosted properly by using different browsers and Postman to retrieve it. The file can be accessed and the certificates look fine. Output of curl -v https://developffw.burns.fun/.well-known/apple-app-site-association * Host developffw.burns.fun:443 was resolved. * IPv6: 2a01:4f8:13b:340a::2 * IPv4: (none) * Trying [2a01:4f8:13b:340a::2]:443... * schannel: disabled automatic use of client certificate * ALPN: curl offers http/1.1 * ALPN: server accepted http/1.1 * Established connection to developffw.burns.fun (2a01:4f8:13b:340a::2 port 443) from 2a00:79c0:65c:8b00:80ee:175b:3e2a:1e7d port 61014 * using HTTP/1.x > GET /.well-known/apple-app-site-association HTTP/1.1 > Host: developffw.burns.fun > User-Agent: curl/8.16.0 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK < Server: nginx/1.22.1 < Date: Mon, 15 Dec 2025 11:34:22 GMT < Content-Type: application/octet-stream < Content-Length: 329 < Last-Modified: Sat, 21 Dec 2024 08:53:11 GMT < Connection: keep-alive < ETag: "676681f7-149" < Accept-Ranges: bytes < { "applinks": { "details": [ { "appIDs": [ "6LN7G8JEA5.burns.FFW-Manager-SwiftUI.Debug"], "components": [ { "/": "/onboard", "?": { "id": "*"}, "?": { "name": "*"}, "?": { "token": "*" } } ] } ] } } * Connection #0 to host developffw.burns.fun:443 left intact I took a look at the headers from the Apple CDN network response. These indicate some sort of connection error. The response code is 404 Response headers: Apple-Failure-Details: {"cause":"dial tcp [2a01:4f8:13b:340a::2]:443: connect: network is unreachable"} Apple-Failure-Reason: SWCERR00305 Network error Apple-From: https://betaffw.burns.fun/.well-known/apple-app-site-association Apple-Try-Direct: false Via: https/1.1 defra2-vp-vst-003.ts.apple.com (acdn/268.16305), https/1.1 defra2-vp-vfe-004.ts.apple.com (acdn/268.16305), http/1.1 defra2-xdc-mx-028.ts.apple.com (acdn/3.16363), https/1.1 defra1-edge-fx-021.ts.apple.com (acdn/3.16363) X-Cache: hit-stale, miss, hit-fresh, miss CDNUUID: 4321f35e-b73b-4031-a054-7c63af69e126-712221049 Took a look at the log files of the server. I can´t find any entry from the Apple servers neither in the default logs nor in the error log entries. The curl attempts are logged with response code 200. I´ve tried sudo swcutil dl -d https://developffw.burns.fun/onboard in the Terminal on my MAC. Output: The operation couldn´t be completed. (SWCErrorDomain error 8.) This indicates to me threre is an issue for the Apple servers accessing my server. But I don´t know what could be the reason. There is no firewall configuration that could block the requests. And there has been no change at all besides the IPV4 / IPV6 protocol change. This issue is the same for all the domain listed on this server. I´v even created a new app for this purpose and created a new AASA entry and associated link. Same issue. I´m pretty much lost here. Everything looks fine from my side. Google assetlinks.json seem to work fine. I would really appreciate some help on how to solve this, i´m at my wits end.

From the document https://developer.apple.com/documentation/sensorkit/srfetchrequest we know that "SensorKit places a 24-hour holding period on newly recorded data before an app can access it. This gives the user an opportunity to delete any data they don’t want to share with the app. A fetch request doesn’t return any results if its time range overlaps this holding period." Will this holding period reset each time when I called startRecording() ? Let's say I upgrade my app to a new version, do I need to call startRecording again to init the data collection process? will it be able to query the data collected from previous version's app ?

I am using the WeatherKit REST API with hourlyStart/hourlyEnd parameters to request up to 240 hours of forecast data. However, when requesting later in the day, the API returns fewer than 240 hourly forecasts — e.g., 239 at 08:00, 238 at 09:00, etc. and goes up to 224 for 23:00 It appears the returned list is contiguous but truncated at the end compared to the full 240-hour window. I have also tried getting the data after sometime, like 09:00 data at 09:45 but still was missing the same data at the end. Is this expected WeatherKit behavior or a bug? If it’s expected, is there documentation explaining how the “forecast horizon” is determined and when it is updated? Thank you.

I am facing a severe audio routing instability issue when using CallKit and the Zego Express SDK on iOS. The problem is that the audio route immediately reverts from the Speaker back to the Earpiece, effectively disabling the Speaker button functionality.📝 Observed BehaviorWhen the user taps the native CallKit Speaker Button, the audio route is correctly changed to the Speaker, but then instantly flips back to the Receiver (Earpiece), as shown in the system log captured via AVAudioSession.routeChangeNotification monitoring.🧾 Log Evidence (Flapping Occurs in 0.4 seconds)The following log snippet clearly illustrates the system overriding the user's action (reason: 4) with an unexpected CategoryChange (reason: 3) event: TimestampComponentReason CodeDescriptionRouteIs Speaker16:31:18.009[CallKitManager]4Override (CallKit/ControlCenter)Loa ngoài (Speaker)true16:31:18.411[CallKitManager]3CategoryChangeThiết bị nhận (Receiver)false

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?

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?

We are using AgeRangeService.requestAgeRange(ageGates:in:) with an age gate of 18 to verify adult users. The system prompt always displays the lower-bound wording (“17 or Younger”), even when the app’s requirement is to verify users who are 18 or older. We understand the UI is system-controlled; however, this wording causes confusion for users, QA, and product teams, as it appears to indicate a child-only flow even when requesting adult verification. Based on the demonstration video, it appears that they have another more coherent message. In Apple's example, it is different, and it is correct that we need to specify 18 years or older in the implementation. A little more context might be helpful, but we are creating a kind of wrapper with React Native that receives that value as a parameter, which is 18.

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.