Dear All, I am developing a watchOS app for Apple Watch Ultra that needs to use the Apple depth / water submersion APIs with the entitlement. The app is configured with the shallow depth and pressure entitlement right now, and I have verified that the entitlement is present both in the signed Watch app and in the embedded provisioning profile. App configuration: Platform: watchOS Device: Apple Watch Ultra Entitlement used: com.apple.developer.submerged-shallow-depth-and-pressure = true Info.plist contains: WKSupportsAutomaticDepthLaunch = true WKBackgroundModes includes underwater-depth I verified the built Watch app with: codesign -d --entitlements :- /path/to/WatchApp.app The output contains: com.apple.developer.submerged-shallow-depth-and-pressure I also verified the embedded provisioning profile with: security cms -D -i /path/to/WatchApp.app/embedded.mobileprovision The embedded profile also contains: com.apple.developer.submerged-shallow-depth-and-pressure The built Watch app Info.plist also confirms: WKSupportsAutomaticDepthLaunch = true WKBackgroundModes includes underwater-depth At runtime, my diagnostics show: Requested source: Automatic or Apple Sensor Runtime source: Automatic / Apple Sensor Capability resolved by the app: Shallow Resolved provider: Apple Sensor — Shallow Sample source: Apple Shallow CMWaterSubmersionManager.waterSubmersionAvailable: true Depth automation: available Provider start is called First provider event is received Submersion state: unknown No submersion event is received No depth measurement is received No temperature sample is received Provider state: error Raw error: Domain: CMErrorDomain Code: 105 Description: The operation couldn’t be completed. The relevant runtime failure is: CMErrorDomain 105 The app also does not appear in: Apple Watch Settings → General → Auto-Launch → When Submerged This is the key point that I cannot clarify from the documentation. My questions are: Is the entitlement com.apple.developer.submerged-shallow-depth-and-pressure sufficient for a watchOS app to appear in: Apple Watch Settings → General → Auto-Launch → When Submerged? Is the shallow depth entitlement sufficient to receive runtime events from CMWaterSubmersionManager, including submersion and depth measurements? Or is the full submerged depth entitlement required for: appearing in the “When Submerged” auto-launch list; receiving CMWaterSubmersionManager submersion events; receiving CMWaterSubmersionManager depth measurements? What does CMErrorDomain code 105 mean in the context of CMWaterSubmersionManager? If the shallow entitlement is sufficient, what other conditions could cause CMWaterSubmersionManager to return CMErrorDomain 105 before delivering any submersion or depth samples? To summarize: The shallow entitlement is present in the source entitlements file. The shallow entitlement is present in the signed Watch app. The shallow entitlement is present in the embedded provisioning profile. The built Info.plist contains WKSupportsAutomaticDepthLaunch = true. The built Info.plist contains WKBackgroundModes = underwater-depth. CMWaterSubmersionManager.waterSubmersionAvailable returns true. The app does not appear in the Watch “When Submerged” list. CMWaterSubmersionManager fails with CMErrorDomain 105 before delivering submersion/depth samples. Any help will be strongly appreciated. Thank you.

These days, we live our lives completely surrounded by and immersed in smartphones. It seems there isn't a single person among us who isn't. This is because we can find all kinds of information, meet friends, and enjoy our leisure time on our smartphones. However, there is one thing we are overlooking. It is the emotion you will feel toward the people around you as you die on the day you come to pass away. What is that emotion? It is regret. That regret is likely the longing to enjoy physical intimacy, conversation, travel, and everyday life more. That is why I am developing an app with a special feature. I am developing an app that helps users self-regulate and maintain moderation in their smartphone usage—something we are addicted to and love so much, yet often fail to realize that it is poison. This app is designed to encourage mutual moderation and provide rewards. Ironically, this app is designed to operate on the smartphone itself. The reason is that if the smartphone is a tiger's den, then to catch the tiger, one must enter the tiger's den. While conceptualizing and proceeding with development, I encountered a completely insurmountable wall. This is because the iPhone cannot accurately measure the screen-off time. I earnestly hope that if there is a team or developer working on the iPhone framework, you can resolve this issue. If you can extend the extension or take measures to allow access to that data within the SDK, I believe I will be able to complete this app. I look forward to your help.

Title: WeatherKit REST API returns 401 NOT_ENABLED although App ID and WeatherKit key are enabled Body: I am integrating WeatherKit REST API for an iOS app, but every request returns: HTTP 401 {"reason":"NOT_ENABLED"} Configuration summary: The App ID has WeatherKit enabled in App Services. The App ID also has WeatherKit enabled in Capabilities. The WeatherKit key shows WeatherKit enabled in the Keys page. A Service ID has been created. The backend generates an ES256 JWT using the .p8 private key. The decoded JWT header and payload have been verified. I have redacted the actual Team ID, Key ID, Bundle ID, and Service ID here for security reasons. Test A: JWT header.id = TEAM_ID.SERVICE_ID JWT payload.iss = TEAM_ID JWT payload.sub = SERVICE_ID kid = WEATHERKIT_KEY_ID exp - iat = 3600 seconds Result: HTTP 401 {"reason":"NOT_ENABLED"} Test B: JWT header.id = TEAM_ID.BUNDLE_ID JWT payload.iss = TEAM_ID JWT payload.sub = BUNDLE_ID kid = WEATHERKIT_KEY_ID exp - iat = 3600 seconds Result: HTTP 401 {"reason":"NOT_ENABLED"} Since Apple returns NOT_ENABLED instead of INVALID_AUTH_TOKEN, the JWT appears to be structurally accepted, but WeatherKit is not enabled for the authenticated identifier/key combination. Questions: For WeatherKit REST API, should the JWT sub claim use the Service ID or the App Bundle ID? What exactly causes HTTP 401 NOT_ENABLED? Is there any additional WeatherKit REST API enablement required besides enabling WeatherKit on the App ID and creating a WeatherKit key? Could this be an account-side entitlement propagation issue?

I'm working on a suite of apps supporting macOS, iOS and iPadOS (potentially tvOS, watchOS and visionOS in the future). Each of these App targets contain minimal code to only load the framework dynamically instead of the recommended load-time imports for Apple platforms. The rationales for runtime loading of framework (using dlopen and dlsym) is expressed in earlier post - fyi. Each app can load multiple frameworks at runtime. Instead of naming the frameworks like this - AppName_purpose1.framework, AppName_purpose2.framework, AppName_purpose3.framework, can it be named as AppName.purpose1, AppName.purpose2, AppName.purpose3 etc? Basically, change the Framework bundle extension name from .framework to a custom name based on purpose. The folder's extension name is changed, but it's still a framework bundle. The advantage of this approach is, in my project, Frameworks belonging to each of the apps cleanly distinguish themselves with a concise name. While this post is about Apple platforms, I'm also checking if other platforms allow to change the names of dynamic libraries (windows allows change). Using my custom extension can standardize the dynamic library's extension name across all platforms. Easy framework name construction - The Framework name is now the same as the App bundle name, which can be queried and this string can be appended with an appropriate extension to load all the Frameworks. Is it possible to change the extension name of the Framework bundle from the default .framework? If yes, how?

Hi everyone, I've been working on an application that provides different subdomains for different customers, so we need to support app linking with all of them. However, using wildcard notation like applinks:*.domain.com doesn't work, while hardcoding applinks:subdomain.domain.com works fine. The association file is being served from both the main domain and subdomains. It used to work fine about a month ago, and I can't find any recent breaking changes on Apple's side . Any ideas why this could happen. ?

My Entitlements file contains the following (removed some non related entries): <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.associated-domains</key> <array> <string>webcredentials:app.mydomain.org</string> <string>applinks:*.mydomain.org</string> </array> </dict> </plist> Now when I tap on a link such as abc.mydomain.org, the app is not opened. If I change the generic applinks key from *.mydomain.org to a specific domain, this works correctly and it opens the app as expected. (This makes me think the website part of the AASA file is correct). Since I need to support a lot of subdomains (think about hundreds in the near future), I really need the wildcard to work. Do you have any tips on how to make this work?

Last week our Universal Links stopped working. We made some changes and uploaded a new AASA file, but https://app-site-association.cdn-apple.com/a/v1/(domain) still returns 404 Not Found for all our domains. When I query directly from our server like domain/.well-known/apple-app-site-association, it returns 200 and the file is accessible. Could you help us resolve this issue? Our app relies on working Universal Links (deep links). Thank you!

Hello, While reviewing the latest FAQ and documentation for the Declared Age Range API, we have some questions regarding the behavior of checkEligibility()—specifically how it relates to user eligibility, geographic jurisdiction, and regulatory requirements. Context From the documentation, it appears that checkEligibility() indicates whether a user is eligible to share their declared age range. However, it is unclear whether this eligibility also incorporates jurisdiction-specific requirements (e.g., certain U.S. states with age assurance regulations). We would appreciate clarification on the following points: Eligibility vs Region: Does checkEligibility() return true based on the user’s eligibility to share age information only, or does it also depend on the user’s geographic region (e.g., specific U.S. states like Texas)? Region-Specific Laws (Texas Example): In scenarios where certain jurisdictions (such as Texas) require age assurance features, while other U.S. states may not, how does checkEligibility() behave? User Consent vs Regulatory Requirement: If a user denies age sharing, but they are located in a region where age-related regulatory features are mandated, how does checkEligibility() behave? Will it return false because the user denied consent? Or will it still return true due to regulatory requirements overriding user preference? Source of Region Determination: Does the Declared Age Range API internally determine the user’s applicable region (e.g., based on IP address, Apple ID region, or device settings) when evaluating checkEligibility()? Should developers independently determine jurisdiction (e.g., using IP-based geolocation) to apply region-specific rules, or is checkEligibility() intended to fully abstract both eligibility and jurisdiction requirements?

I've a question for you maybe you can help me. My watchOS app has: WKSupportsAutomaticDepthLaunch = true WKBackgroundModes = underwater-depth com.apple.developer.submerged-shallow-depth-and-pressure = true entitlement present in codesign and embedded provisioning profile The app uses the shallow depth entitlement, but it does not appear in: Settings → General → Auto-Launch → When Submerged. Is the shallow depth entitlement sufficient for appearing in the system underwater auto-launch app list, or is the full submerged depth entitlement required?

Hi! I have a few questions about the lifecycle and capabilities of the Crash Reporter Extension. Besides using the corpsePort to inspect the crashed process through Mach APIs, is it safe/supported/recommended for the extension to access files in a shared App Group container? Are there any caveats or exceptions we should be aware of, for example around memory-mapped files, file coordination, or filesystem access after the host app has crashed? Shall we use some particular APIs for this kind of shared resource or not? While debugging the extension, I noticed that when I trigger a crash in the app I am debugging, LLDB does not stop inside the extension (it also ends up stopping the debugging session). However, I can observe that the extension does run, because it writes data into a shared App Group directory related to the crash. Is this expected behavior? Is there a recommended way to debug the Crash Reporter Extension reliably (with lldb, or other way)? More generally, I would like to better understand the extension lifecycle: When exactly does the extension start running? How long can it live after the app crashes? Is there a time limit for operating on the corpse process? Is the extension subject to resource limits similar to other app extensions, such as memory, disk, CPU, watchdog, or jetsam constraints? If the Crash Reporter Extension itself crashes, how can we detect that? Would those crashes appear in Xcode Organizer, or is there another recommended way to observe them? Any clarification around the supported lifecycle, debugging model, and resource limits would be very useful.

We need an official answer: wrong wiring, known bug on 26.5, or unsupported? AlertConfiguration.AlertSound.default works. AlertConfiguration.AlertSound.named("lifeloop_alarm_silent") schedules successfully (Stop/Snooze UI, no API error) but playback is always system default — never our bundled CAF. OFFICIAL API WE FOLLOW Documentation: AlertConfiguration.AlertSound.named(:) https://developer.apple.com/documentation/activitykit/alertconfiguration/alertsound/named(:) "The name of the sound file to use for the alert. Choose a file that's in your app's main bundle or the Library/Sounds folder of your app's data container." WWDC25 session 230 shows: let sound = AlertConfiguration.AlertSound.named("Chime") with the file in the main bundle. We use: AlertConfiguration.AlertSound.named("lifeloop_alarm_silent") Our Swift schedules with AlarmManager.AlarmConfiguration.alarm(..., sound: alertSound). REFERENCES WE ALREADY READ AlarmConfiguration overview: https://developer.apple.com/documentation/alarmkit/alarmmanager/alarmconfiguration Albert Pascual DTS reply (Feb 2026) on this thread pointed at nested alertConfiguration with sound AlarmKit FAQ: https://developer.apple.com/forums/thread/797158 Older forum reply (~2025): claimed .named("Glass Drum.caf") worked — not verified on 26.5 today On iOS 26.5: Bundle.main finds our file with AND without ".caf" in the lookup string; playback still system default OUR WIRING (please confirm correct or tell us what to change) We schedule fixed-time dose alarms with: AlarmManager.AlarmConfiguration.alarm( schedule: .fixed(fireDate), attributes: attributes, stopIntent: stopIntent, secondaryIntent: snoozeIntent, sound: alertSound) .default on this parameter works. .named("lifeloop_alarm_silent") does not — despite Bundle.main finding the file (proof below). Question: Is sound: on .alarm(...) correct for custom AlertSound.named, or must sound go in nested AlertConfiguration(title:body:sound:) as in the overview example? WHAT WE HEAR ON DEVICE sound = .default → loud system alarm (works) sound = .named("lifeloop_alarm_silent") → same loud system/default every time No API error — silent fallback to default PROOF 1 — FILE IN SHIPPED IPA $ find Payload -name "lifeloop_alarm_*.caf" Payload/LifeLoop.app/lifeloop_alarm_silent.caf PROOF 2 — RUNTIME ON DEVICE (2026-06-30, iOS 26.5) Bundle.main.url(forResource:withExtension:): FOUND Bundle.main.url(full filename in name): FOUND Path: .../LifeLoop.app/lifeloop_alarm_silent.caf All .caf in main bundle: lifeloop_alarm_silent.caf Library/Sounds: (none) Widget .appex .caf: (none) Native log at schedule: [alarmkit] build_config · soundModeRaw=silent alertSound=named:lifeloop_alarm_silent silentCafInBundle=true [alarmkit] schedule_ok · alarmID=FBDF2082-61F1-4C93-8B20-094A60EA8626 CAF: lifeloop_alarm_silent.caf — mono, 44100 Hz, 16-bit PCM, ~0.5 s QUESTIONS FOR DTS Main app bundle only, or must CAF also be in widget .appex? Must named(_:) include ".caf" or base name only? Bundle.main FOUND at schedule time but playback is default — known bug on 26.5? Please answer: (A) wrong wiring + correct recipe, (B) known bug + fix version, or (C) not supported — please document. Thank you. Same problem as tonny00 — custom CAF never plays, always the loud system/default alarm. App: LifeLoop (com.stujacks.lifeloop) on iOS 26.5 (physical device). https://developer.apple.com/forums/thread/814732

Hello, I am developing a parental control app using FamilyControls, DeviceActivity, and DeviceActivityReport. My current setup is: The child device requests FamilyControls authorization with .child The parent device requests FamilyControls authorization with .individual The parent app displays reports through a DeviceActivityReportExtension The report filter uses users: .children and devices: .all I would like to clarify two questions: Can a third-party app use the Screen Time API to retrieve or display screen time activity per child or per child device from the parent app? For example: Child A's total screen time today Child A's iPhone screen time today Child A's iPad screen time today At the moment, I can only display an aggregated report using users: .children and devices: .all. I do not see a public API for selecting a specific child or a specific child device. Is this a current limitation of the public Screen Time API, or is there a recommended approach to implement this? Can the Screen Time API report activity data for family members aged 14-17? Specifically, if a family member is between 14 and 17 years old and their device has completed .child authorization, can the parent app still display their Screen Time data using DeviceActivityReport(users: .children)? Or are there restrictions related to Apple ID age, Family Sharing, or Screen Time permissions that prevent third-party apps from retrieving or displaying activity data for users in this age range? My goal is to understand what third-party apps can implement in a compliant way using the public APIs, without attempting to bypass any system limitations. Thank you.

I have a custom keyboard (UIInputViewController, Full Access). For a dictation feature it opens its containing app to record audio (the keyboard can't use the microphone) and then needs to return the user to the host app they were typing in. That requires knowing the host app. Through iOS 26.3 this worked, because the host bundle id was exposed on the keyboard's input-session connection. On iOS 26.4 / 26.5 it is now nil, and every route I have tried is blocked: UIInputViewController _hostApplicationBundleIdentifier -> nil _hostProcessIdentifier and the host audit token are available, but: RBSProcessHandle handleForAuditToken: / handleForIdentifier: -> "Client not entitled" SecTaskCopySigningIdentifier / SecTaskCopyValueForEntitlement -> nil (sandbox) proc_pidpath -> EPERM UIKeyboardImpl _remoteAppId / _remoteLocalizedAppName -> nil The keyboard arbiter client-change event fires in SpringBoard, not in the extension process However, at least one shipping keyboard still does this on iOS 26.5. I verified in device logs that Yandex Keyboard launches its container app with a URL containing the correct, current host bundle id, and it is live: it reported net.whatsapp.WhatsApp, then net.whatsapp.WhatsAppSMB when the host was WhatsApp Business. So the capability clearly still exists for some apps. Questions: Is there a supported API on iOS 26.4+ for a keyboard extension to identify its host app? If it requires an entitlement, can developers request it, and how? If there is no public path, is the intended approach the system "back to previous app" breadcrumb (manual) plus a containing-app round trip? I have also filed Feedback (FB#######). Thanks.

Hi everyone, I’ve been stuck on an issue with iOS Universal Links for about a week and could really use some help. The problem When tapping a Universal Link on iOS, my Flutter app opens correctly (desired behavior) — but immediately afterward, Safari opens the same link in the browser. So both the app and the browser open. This only happens on iOS. On Android everything works as expected. What works If the link is simply the domain, like: https://mydomain.com …then the app opens without triggering the browser afterward. This is the correct behavior. What doesn’t work If the link includes a path or parameters, like: https://mydomain.com/path https://mydomain.com/path?param=value …then the app opens, and then the browser opens immediately after. What I’ve tried Verified my AASA file using Branch’s validator: https://branch.io/resources/aasa-validator/ → The AASA file is valid. Universal Links do open the correct screen inside the app — the issue is the unwanted second step (Safari opening). Behavior is consistent across different iOS devices. Extra details Using Flutter. Universal Links set up with the standard configuration (associatedDomains, AASA hosted at /.well-known/apple-app-site-association, etc.). Question Has anyone encountered this issue where Universal Links with paths/params open the app and then open Safari? What could cause iOS to trigger the browser fallback even when the AASA file is valid and the app handles the link correctly? Any insights, debugging tips, or known edge cases would be incredibly appreciated!

Hello Apple Developer Support Team, We understand from the Declared Age Range documentation that, in some regulated regions, the system automatically provides the person’s age range and they can’t decline sharing it with the app. We have implemented the API as prescribed in the documentation. For certain users in Texas, the API returns: isEligibleForAgeFeatures == true declaredAgeRangeRequired == true However, in our testing we observe that these Texas users can still decline sharing their age range, either via the system prompt or later via Settings, which results in no age range being provided to the app. This behavior appears inconsistent with the documentation’s statement that, in regulated regions, the person “can’t decline” sharing their age range, and it also raises questions for us about how this aligns with the applicable legal requirements in Texas. Could you please clarify: Whether this behavior (Texas users being able to decline sharing their age range even when declaredAgeRangeRequired is true) is expected, and Under what exact conditions the “they can’t decline sharing” behavior is enforced for Texas accounts (for example, only for new Apple Accounts created in Texas after a certain date, or only for particular age categories)? Any guidance on how we should interpret isEligibleForAgeFeatures and declaredAgeRangeRequired in this scenario would be greatly appreciated. Thank you.

Environment: iOS 26.5, Message Filter app extension (IdentityLookup framework), offline filtering. Setup My Message Filter Extension performs offline string matching on the message body and returns one of: ILMessageFilterAction.allow / .junk / .transaction / .promotion In the Messages app the filtering UI shows these folders: Messages (the main/default folder), Transactions, Promotions, Junk. .allow is expected to surface a message in the main Messages folder. The documented behavior (API docs + WWDC22 "Explore SMS message filters") only describes a static mapping from action → folder. On iOS 26.5 I'm seeing what looks like a stateful, per-sender behavior that I cannot find documented anywhere, and I can't tell whether it is intended or a bug. Test methodology All messages in every sequence are sent from the same single phone number. Before each Case, I fully clear the receive history for that number, so every sequence starts from a clean slate with no prior state for that sender. The notation shows how many conversations/entries appear in each folder after each step. Case A — first message = allow allow → Messages: 1 promotion → Messages: 2 (allow + promotion), Promotions: 1 junk → everything collapses into Junk; Messages & Promotions become empty every subsequent message lands in Junk regardless of the action I return Case B — first message = allow, then transaction allow → Messages: 1 transaction → Messages: 2 (allow + transaction), Transactions: 1 junk → everything collapses into Junk; Messages & Transactions empty every subsequent message lands in Junk regardless of returned action Case C — first message = transaction transaction → Messages: 1, Transactions: 1 ← also appears in Messages allow → Messages: 2, Transactions: 1 promotion → Messages: 3, Transactions: 1, Promotions: 1 junk → Messages: 4, Transactions: 1, Promotions: 1, Junk: 1 (NOTE: here junk does NOT collapse the thread, and there is no "sticky junk") Case D — first message = promotion promotion → Promotions: 1 only (does NOT appear in Messages) allow → Messages: 2 (the earlier promotion now also appears in Messages), Promotions: 1 junk → everything collapses into Junk (sticky, same as Case A/B) every subsequent message lands in Junk regardless of returned action My core question: are the following two behaviors by design, or are they bugs? (1) "Sticky junk" after allow-first / promotion-first. In Cases A, B and D, once .junk is returned the whole sender thread collapses into Junk, and from then on every message is forced into Junk regardless of the action my extension returns. Is this expected/by-design, or a bug? If by design: is it permanent, and what resets it — does the extension have any control, or is it purely user-driven (e.g. the user moving the thread out of Junk)? What concerns me is that the system appears to ignore my returned action entirely once this state is entered. (2) .transaction-first behaving differently from .allow-first. A sender whose first message is .transaction (Case C) behaves differently: the message also appears in the main Messages folder, and a later .junk does not collapse the thread (no sticky junk). Is this .transaction-first behavior expected/by-design, or a bug? If by design, what is the underlying rule that makes .transaction-first confer this state while .allow-first does not? Since the history is cleared before each test, this is determined purely by the first action returned. Additional clarifying questions Is any of this per-sender state behavior documented beyond the static action → folder mapping in the API docs / WWDC22 "Explore SMS message filters"? If so, where? More generally, what determines whether a categorized (.transaction / .promotion) message is also mirrored into the main Messages folder? Thanks — I'd like my extension's return values to produce predictable categorization for users, and right now this first-message-dependent behavior makes that hard to reason about.

Hi, I’m developing a macOS Finder Sync extension and noticed that NSMenuItem.separator() does not appear to render as a standard separator line when used inside the menu returned from FIFinderSyncController. In a normal AppKit NSMenu, the separator renders as expected. However, when the same kind of menu is returned from the Finder Sync extension, the separator appears as a blank/full-height empty row rather than a thin dividing line. Example: override func menu(for menuKind: FIMenuKind) -> NSMenu { let menu = NSMenu(title: "") menu.addItem(NSMenuItem( title: "First Action", action: #selector(firstAction(_:)), keyEquivalent: "" )) menu.addItem(NSMenuItem.separator()) menu.addItem(NSMenuItem( title: "Second Action", action: #selector(secondAction(_:)), keyEquivalent: "" )) return menu } Expected result: The separator should render as a normal macOS menu separator line between the two menu items. Actual result: In Finder’s context menu, the separator is displayed as blank vertical space / an empty menu row. I understand that Finder Sync menus are rendered by Finder and may not support every NSMenuItem feature. However, NSMenuItem.separator() is a very standard way to visually group menu commands, so I wanted to ask: Is this a known limitation of Finder Sync extension menus? Is there a supported way to display a real separator line in Finder Sync context menus? Should this be filed as a Feedback Assistant issue against Finder Sync / AppKit? I’m trying to avoid fake separators such as disabled menu items with "────" as the title, since that does not feel native and may not behave well with different fonts, accessibility settings, or appearance modes. Thanks!

With the 27 OSes using UserDefaults.standard.integer(forKey: ) can cause a crash with EXC_BAD_ACCESS (code=1, address=0x0) It has been seen on a Multiplatform app, up to now tested on iOS/iPadOS and visionOS 27 Beta 1. In our code we use UserDefaults.standard.integer(forKey: ) from a singleton called during the SwiftUI app init(), and we don't know yet if this is the only moment there is a crash as we can't go farther. The API should return 0 if it can't get a value. There is no reason the app should crash if the API conforms to its contract. Running the same code from Xcode on iOS 26 runs it without issue. FeedBack FB23310748

Hello, Quick clarification regarding age ratings: If a user is 17 years old and wants to download a 16+ app, is parental approval required? Or is parental consent only needed if the app’s rating does not match (or exceeds) the user’s actual age? Also, is this fully enforced by Apple, or is it up to developers how to implement these checks? Thanks!

Hello there, I am trying to clarify whether iOS 26 changed the expected Phone Recents behavior for CallKit calls reported with CXHandle.generic. On iOS 18 and earlier, CallKit calls reported with: CXHandle(type: .generic, value: <stable custom identifier>) were grouped and displayed in Phone Recents based on the stable handle value. The details/history screen for a Recents entry showed calls for that same handle value. On iOS 26, the same approach no longer appears to work the same way. Observed behavior on iOS 26 I tested multiple stable CXHandle.generic values. The Recents rows are created, but when opening the details/history screen for one Recents entry, the history shows all calls, not only calls for the selected generic handle value. I also tested other handle types: CXHandle(type: .emailAddress, value: <stable email-like identifier>) works as expected: Recents grouping and the details/history screen are isolated to that handle value. CXHandle(type: .phoneNumber, value: <phone number>) also works as expected for real phone-number-style identities: Recents grouping and the details/history screen are isolated to that phone number. CXHandle(type: .generic, value: <stable custom identifier>) does not work the same way on iOS 26: the details/history screen is not isolated to that generic handle value and instead shows all calls. Questions Is CXHandle.generic still intended to be a supported identity for Phone Recents grouping and the details/history screen on iOS 26? Given that .emailAddress and .phoneNumber handles appear to isolate history correctly, is .generic intentionally treated differently by the iOS 26 Phone app, or is this a regression? Did iOS 26 change Phone Recents/details matching so that CXHandle.generic values are no longer used as isolated per-caller identities? If this behavior is intentional, what handle type should be used for stable non-phone CallKit identities? Is using CXHandle(type: .emailAddress, value: "@example.invalid") an acceptable supported approach for stable non-phone identities, if the value is not a real user email address? Is there documentation describing the iOS 26 Phone Recents identity-matching behavior for CallKit calls? Minimal repro Configure a CXProvider with calls included in Recents. Report several CallKit calls using different stable generic handles, for example: CXHandle(type: .generic, value: "app-target-1") CXHandle(type: .generic, value: "app-target-2") End the calls. Open Phone Recents on iOS 26. Open the details/history screen for one of the Recents entries. Expected result: The details/history screen shows only calls for the selected generic handle value. Actual result: The details/history screen shows all calls. Could you clarify whether this is expected behavior on iOS 26, a regression, or an unsupported use of CXHandle.generic? Thank you.