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.

Since iOS 18.4 and macOS 15.4 updating the calendar of an (ek)event (to another accounts calendar) or detaching an repeating event throws an error while saving: "Access denied" EKEventStore.save(event, span: .thisEvent, commit: true) catch { "Access denied" }

I’m hitting a WeatherKit JWT failure (WDSJWTAuthenticatorServiceListener Code = 2) at runtime even though the entitlement is present in both the signed binary and the embedded provisioning profile. Environment Team ID 5SZLQLQ9MD Bundle ID ParkProfessor.ParkProfessorDisneyland Device / OS iPhone 15 Pro · iOS 17.4.1 (hardware, not simulator) Xcode 15.3 (15E204a) Console output Failed to generate jwt token for: com.apple.weatherkit.authservice Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Entitlement & profile snippets codesign -d --entitlements :- WeatherKitTest.app | grep -A2 weatherkit com.apple.developer.weatherkit security cms -D -i embedded.mobileprovision | grep -A2 weatherkit com.apple.developer.weatherkit What I’ve already tried Regenerated a new development certificate and a new iOS App Development provisioning profile with WeatherKit enabled. Confirmed the capability is selected in Certificates ▸ Identifiers ▸ Profiles and added in Xcode target settings. WeatherKit Terms of Service accepted in the portal. Deleted the app, removed any device management profiles, rebooted the phone, clean-built & ran again. Reproduced the issue in a minimal SwiftUI app that calls: WeatherService.shared.weather(for: CLLocation(latitude: 33.8121, longitude: -117.9190), including: .current) – same Code 2 error. Request It looks like the App ID may need a backend entitlement sync. Could someone from the WeatherKit team please check the status for Team 5SZLQLQ9MD, Bundle ID ParkProfessor.ParkProfessorDisneyland and enable WeatherKit token generation? Thanks!

All of my apps stopped working with WeatherKit this morning. They all return an "Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2" error. I am certain that the WeatherKit capability added (in project) and enabled as a Capability & App Service (on developer portal for the identifier). All other iCloud features of my apps are working as expected. I have also done all the normal troubleshooting using codesign / security cms, etc. to verify entitlements. I created the following simple project to verify the integration. import WeatherKit import CoreLocation struct ContentView: View { @State private var temp: Measurement<UnitTemperature>? = nil var body: some View { VStack { if let t = temp { Text("\(t.value.rounded())°\(t.unit.symbol)") } else { Text("Fetching…") .task { let service = WeatherService() do { let location = CLLocation(latitude: 50.318668, longitude: -114.917710) let weather = try await service.weather(for: location, including: .current) temp = weather.temperature } catch { print("Error:", error) } } } } } } Any ideas what may be happening?

We persist ApplicationTokens in a storage container that ShieldConfigurationExtension has access to. In rare, cases all the ApplicationTokens for a user seem to change. We know this because the Application parameter passed into configuration(shielding application: Application) -> ShieldConfiguration function has a Token that does not match (using == ) any of the ones we are persisting in storage. Interestingly, the persisted ones still work, so I don't believe storage has gotten corrupted or anything. We can use them to add or remove shields, we can use them to display labels of the apps they represent, etc. But they don’t match what’s passed into the ShieldConfiguration extension. If the user goes into the FamilyPicker at this point and selects an app of a token that we are already persisting, the FamilyPickerSelection will have a token matching the new one that is passed into ShieldConfigurationExtension, not the one we persisted when they last selected that app. This leads me to believe the tokens are updated/rotated in some cases. When and why does this happen, and how can we handle it gracefully?

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! Sms reporting is no longer available in iOS beta 26 builds. I can set my app as the SMS/Call Reporting Extensions but the report button is missing for sms messages in the messages app. Xcode 26 beta 7 build the app without errors. This is a breaking change. Same extension was previously broken for calls but has been fixed in beta 7 build, as reported here. It is however still missing for sms messages in the messages app (beta 9 build).

We are developing a parental control application in SwiftUI with features like app blocking and screen time management. We are using the Family Control API along with Apple Family Sharing, allowing parents to add multiple children to the family group. We have followed the apple documentation still we are facing following issues: App Blocking Issue: The family picker does not display each child's name separately or their apps individually. Instead, it shows all children's apps together, making it difficult to block apps for a specific child. Screen Time Data Issue: We receive the total screen time usage for all children combined rather than separate screen time data for each child. Syncing Delay: When a new child is added to the Family Sharing group, we are unsure how long it takes for their apps to sync and appear on the parent’s device.

I'm currently using Swift to write an independent Apple Watch app for watchOS 7+. My app uses Location Services, and in case the user doesn't allow that at first, I'd like to have a button inside my watchOS app to send my user to the part of the Settings app (inside watchOS) where he can give the appropriate permissions for the app. I know that in iOS/macOS you can use the openSettingsURLString string from UIApplication to do what I want, but it's not available in watchOS and I haven't found any equivalent resource inside the WKExtension class (normally the equivalent for UIApplication in the watchOS environment). Does anyone know if there's any way to programatically open the Apple Watch Settings app from my watchOS app? I'm asking since as far as I understand asking for Location permissions again would not work since the user has already refused to allow the permissions before, making the authorization status "denied". I understand as well that there's the possibility of showing a modal and directing the user to go to Settings and allow the use of location services (as in "Please go to Settings > Privacy > Location Services > [AppName] to allow the use of location services") but I'd like if I could direct the user there instead as one might do in iOS. The code below is what I'm trying to do - but (of course) it crashes since I'm not actually passing any system URL. .alert(isPresented: $alertVisible) { Alert (title: Text("Please allow our app to use location services in order to get Weather Data"), message: Text("Go to Settings?"), primaryButton: .default(Text("Settings"), action: { WKExtension.shared().openSystemURL(URL(string: "")!) //UIApplication.shared.open(URL(string: UIApplication.openSettingsURLString)!) }),

I'm reaching out to see if anyone else is experiencing issues with the Live Caller ID feature on iOS. We recently encountered a problem where the feature stopped working entirely. Here's a brief overview of the situation: We were monitoring test traffic on our backend and noticed everything came to a halt around 1:00 AM UTC on November 15th. After this time, any attempts to reach our backend through calls failed completely. I tested this across multiple devices running iOS 18.2 and iOS 18.0. I used both TestFlight builds and development builds via Xcode, which should communicate directly with our backend. I experienced the problem on our main application as well as a dedicated test app. To troubleshoot further, I even set up a local server on localhost and tried directing requests there, but the requests did not reach the local server when a call was received. Further debugging in Console.app revealed the following error: identity request returned error: Error Domain=com.apple.CipherML Code=400 "Error Domain=com.apple.CipherML Code=401 "Unable to request data by keywords batch: failed to fetch token issuer directory" However, when I manually tried to hit our server endpoint using curl, the request successfully reached the server: curl https://our_server/something hb_method=GET hb_uri=/something [Hummingbird] Request -- log on backend This suggests that while our backend is responsive, the requests from the iOS client side are simply not being initiated.

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 am trying to set up a message filter extension that will use shared web credentials for basic auth when calling to its ILMessageFilterExtensionNetworkURL. I have associated domains set up for both "messagefilter:" and "webcredentials:" and the message filter IS correctly calling the ILMessageFilterExtensionNetworkURL with each message - so that part is working. As detailed here, I have set up Shared Web Credentials and my view controller is using SecAddSharedWebCredential() to save the creds to the correct domain. Using Authorization services, the creds are auto-filled into my app's login screen. When I go under Settings > Passwords, I see the creds are saved and they are the correct creds to the corrent website that matches ILMessageFilterExtensionNetworkURL. Regardless of all of this, the deferQueryRequestToNetwork() refuses to use the creds and implement Basic Auth in its URL call. It makes the call to the correct URL, it just won't use the Shared Web Creds for basic auth. Any help would be greatly appreciated.

Hi there, My app uses all the Screen Time API's with individual FamilyControls authorization. I've been using the API's for over 2 years (since they came out). In iOS 18 Beta (maybe started in Beta 3?), I've been experiencing random issues. I tracked it down to where it seems like DeviceActivityMonitor extension is more likely to deadlock in iOS 18. To reproduce: when DeviceActivityMonitorExtension.intervalDidEnd gets called, IF you call DeviceActivityCenter.startMonitoring for that SAME DeviceActivityName from the DeviceActivityMonitorExtension , the startMonitoring call deadlocks (if I pause debugger, it does not advance past DeviceActivityCenter.startMonitoring). The bug is reported in FB14664238. It also contains a sample project where you can reproduce this. I also note in the comment section that this is not the only way to encounter this problem. My application code (which is a lot more complicated) seems to deadlock on calling DeviceActivityCenter.activities. As a result, there seems to be an "overall trend" where, due to some changes, DeviceActivityMonitor extension is more likely to deadlock. The steps are not reproducible on iOS 17.6. This is built using Xcode 17.4. Thank you! 🙏

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"?

PDFKit PDFPage.characterBounds(at: Int) is returning incorrect coordinates with iOS 18 beta 4 and later / Xcode 16 beta 4. It worked fine in iOS 17 and earlier (after showing the same issue during the early iOS 17 beta cycle) It breaks critical functionality that my app relies on. I have filed feedback (FB14843671). So far no changes in the latest betas. iOS release date is approaching fast! Anybody having the same issue? Any workaround available?

I have an iOS app with ExtensionFoundation. It runs well on my local device, but when I upload on the AppStore it gets rejected with: Validation failed Invalid Info.plist value. The value of the EXExtensionPointIdentifier key, AsheKube.app.a-Shell.localWebServer, in the Info.plist of “a-Shell.app/Extensions/localWebServer.appex” is invalid. Please refer to the App Extension Programming Guide at https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/Action.html#/apple_ref/doc/uid/TP40014214-CH13-SW1. (ID: ae8dd1dd-8caf-4a48-9651-7a225faed4eb) The Info.plist in my Extension is: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>EXAppExtensionAttributes</key> <dict> <key>EXExtensionPointIdentifier</key> <string>com.example.example-extension</string> </dict> </dict> </plist> so the Info.plist that causes the issue has been automatically generated by Xcode. I can access it as well, and it says: { "BuildMachineOSBuild" => "25A354" "CFBundleDevelopmentRegion" => "en" "CFBundleDisplayName" => "localWebServerExtension" "CFBundleExecutable" => "localWebServer" "CFBundleIdentifier" => "AsheKube.app.a-Shell.localWebServerExtension" "CFBundleInfoDictionaryVersion" => "6.0" "CFBundleName" => "localWebServer" "CFBundlePackageType" => "XPC!" "CFBundleShortVersionString" => "1.0" "CFBundleSupportedPlatforms" => [ 0 => "iPhoneOS" ] "CFBundleVersion" => "1" "DTCompiler" => "com.apple.compilers.llvm.clang.1_0" "DTPlatformBuild" => "23A339" "DTPlatformName" => "iphoneos" "DTPlatformVersion" => "26.0" "DTSDKBuild" => "23A339" "DTSDKName" => "iphoneos26.0" "DTXcode" => "2601" "DTXcodeBuild" => "17A400" "EXAppExtensionAttributes" => { "EXExtensionPointIdentifier" => "AsheKube.app.a-Shell.localWebServer" } "MinimumOSVersion" => "26.0" "NSHumanReadableCopyright" => "Copyright © 2025 AsheKube. All rights reserved." "UIDeviceFamily" => [ 0 => 1 1 => 2 ] "UIRequiredDeviceCapabilities" => [ 0 => "arm64" ] } What should I do to be able to upload on the AppStore?

In IOS17 and IOS18, core spotlight can only match app contents by searching for the displayName, but cannot hit the contents by using keywords. Moreover, when matching the app content by searching for the "displayName", it requires inputting four consecutive characters to achieve a match.These issues did not occur in iOS 16. What is the reason for this? Here is my code. func addItemToIndex(_ item: QSpotlightItem) { let attributeSet = CSSearchableItemAttributeSet(contentType: .item) attributeSet.title = item.title attributeSet.displayName = item.title attributeSet.contentDescription = item.contentDescription attributeSet.keywords = item.keywords attributeSet.thumbnailData = item.thumbnailImage attributeSet.contactKeywords = item.keywords attributeSet.supportsNavigation = true let searchableItem = CSSearchableItem(uniqueIdentifier: item.id, domainIdentifier: "xxx", attributeSet: attributeSet) searchableItem.expirationDate = .distantFuture CSSearchableIndex.default().indexSearchableItems([searchableItem]) { error in if let error = error { } else { } } }

Hello, I think it is quite a common use-case to open the parent app that owns the ShieldActionDelegate when the user selects an action in the Shield. There are only three options available that we can do in response to an action: ShieldActionResponse.none ShieldActionResponse.close ShieldActionResponse.defer It would be great if this new one would be added as well: ShieldActionResponse.openParentApp While finding a workaround for now, the problem is that the ShieldActionDelegate is not a normal app extension. That means, normal tricks do not work to open the parent app from here. For example, UIApplication.shared.open(url) does not work because we can’t access UIApplication from the ShieldActionDelegate unfortunately. NSExtensionContext is also not available in the ShieldActionDelegate unfortunately, so that’s also not possible. There are apps however, that managed to find a workaround, in my research I stumbled across these two: https://apps.apple.com/de/app/applocker-passcode-lock-apps/id1132845904?l=en-GB https://apps.apple.com/us/app/app-lock/id6448239603 Please find a screen recording (gif) attached. Their workaround is 100% what I’m looking for, so there MUST be a way to do so that is compliant with the App Store guidelines (after all, the apps are available on the App Store!). I had documented my feature request more than 2 years ago in this radar as well: FB10393561

In recent versions, the increase in background abnormal exits is significant. According to monitoring data, it is closely related to the iOS 26 system. Could you please look into the reasons or provide some suggestions for troubleshooting the issue?

I’m integrating the Declared Age Range feature to tailor our app’s experience based on a user’s age range. I’m currently in the testing phase and would like to repeatedly test the consent flow and different outcomes from AgeRangeService.shared.requestAgeRange(...). However, once I go through the consent flow and choose to share, the age-range sharing sheet no longer appears on subsequent attempts—so it’s hard to validate edge cases (e.g., changed gates, declined flow, re-prompt behavior). Could you advise on the recommended way to reset or re-prompt during development? In particular: Is there a supported way to clear per-app consent so the system prompts again? Under what conditions should the “Share Age Range Again” control appear in Settings, and is there an equivalent way to trigger it for testing? Are there best practices for QA (e.g., using Ask First at the system level, testing on real devices vs. Simulator, using a separate bundle ID for dev builds, or other steps)? Any other guidance for validating different requestAgeRange results (e.g., declined/not available) would be appreciated.