When a user uses the "Add Name" feature on an unknown number in their Call Logs, the name appears under "Other Known Contacts" in the native iOS Contacts app. The Problem: CNContactStore completely ignores these contacts during a standard fetch/enumeration. When user gives limited permission they can search for that contact and select it, but it won't be visible in my App as it's not technically a contact. Is CNContactStore intentionally blocked from reading "Other Known Contacts" for privacy reasons or are there any future plans to expose API so that third party apps can access it?

Hi, I really need suggestion on how to get into Apple's Development Payment Department team's attention. I'm using Singaporean contact and address, but currently has to be in Indonesia for quite a while. I registered and put in my creditcard detail, and later got the email from Apple that I need to contact my card provider, which is a frustrating and expensive experience since I have to call roaming, and the line keeps dropping after few mins call. I tried emailing Apple Dev/Payment requesting different payment method, but so far have not received any feedback, and I need to import my flutter into ios apps for closed testing and presenting it early next week. Please, if anyone knows how to I should be able to get them to respond, there will be great. Thank you.

Hey, I've been banging my head against this for a few days now and genuinely can't figure out if it's something on my end or an Apple backend issue. My app has WeatherKit integrated and it works fine in the simulator, but on my physical device I consistently get this in the console: Failed to generate jwt token for: com.apple.weatherkit.authservice Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Things I've already tried and ruled out: WeatherKit capability is enabled in the App ID on developer.apple.com ✓ com.apple.developer.weatherkit = true is in the entitlements file ✓ Removed and re-added the capability in Xcode Signing & Capabilities ✓ Clean Build Folder, fresh install on device ✓ The location coordinates are valid (hardcoded lat/lon in Bavaria) ✓ The weird part is that it's not a location issue — Error Code 2 from WDSJWTAuthenticatorServiceListener suggests the JWT generation itself is failing before any location lookup even happens. I've had this App ID since early this year, WeatherKit was working at some point, and I'm not sure what changed. My fallback to Open-Meteo works fine so the app isn't broken, but I'd like to actually use the API I'm paying for. I also opened a support ticket but got redirected to the forums, so here I am. Anyone else seen this recently or know if there's something on the provisioning side I'm missing?

Hello, We are currently integrating the new Declared Age Range framework to comply with the age assurance requirements (such as the Texas regulatory rollout). We are specifically trying to test the AgeRangeService.RegulatoryFeature.significantAppChangeRequiresParentalConsent flow for minors. The Problem When testing in the Sandbox environment, the consent flow returns a mocked response immediately. While this validates our basic code logic, it does not allow us to test or see the actual end-to-end user experience/UI of the parental consent flow. When we attempt to test this outside of the Sandbox environment on a production build/device to see the true system UI, the AskCenter.ask(PermissionQuestion, in: ...) request fails immediately with the following error: Error: “The user is in a region that does not support this type of ask." UserInfo: {NSLocalizedDescription=The user is in a region that does not support this type of ask., NSLocalizedRecoverySuggestion=Please ensure the user is in an eligible region., NSLocalizedFailureReason=The user must be in a supported region to use this feature.} What We Have Tried Verified that our App Store Connect Sandbox account and test devices are configured correctly according to the "Testing Age Assurance in Sandbox" documentation. Attempted to change the region/location settings on our physical test devices to Texas/US to trigger the real flow, but the production environment still blocks it with the region error. Reviewed existing forum threads (such as 809889 and 809483) where other developers are facing the exact same roadblock without a clear solution. Our Questions Is there any supported way to trigger the full, unmocked system consent UI end-to-end during development/local testing? If changing the device's region settings isn't enough to bypass the production region check for AskCenter, how does Apple determine region eligibility for this specific API during local evaluation? Any insights, workarounds, or configuration steps to properly preview this UI before app submission would be greatly appreciated. Thank you!

It would be good if SensorKit was more available for non research related apps. For example I want to create an app that tracks light sensor values to create a mapping of bikelanes with poor lighting. This doesn’t fall under a research app, but seems like a reasonable use of this data. creating a way to opt the user into this (via clear warnings that the data Is being collected, and maybe a 24 or 1 hour time limit) might be a way to make this sensor data available. also clear warnings on the app store privacy page, or maybe even rules about running in the background or at app startup and an icon in the toolbar (similar to the mic) could make this more safe for users.

While running my application on macOS 27 today, it crashed in a strange way. The backtrace for the thread that crashed looks like it was some kind of Spotlight search indexing thread. The strange part is that my app makes no use of Spotlight and is not mentioned anywhere in the Spotlight section of System Prefs. Here is the backtrace, maybe something in here is enough of a clue as to what happened and why my App was running a Spotlight-related thread. This was on 27 beta 1 (26A5353q), and the app is a video streaming app that uses both Qt 6.11.1 and SDL 3 and was rendering some frames with Metal at the time. The most unusual thing in the backtrace is the existence of ObjC params spelled both updatingDonationProgress as well as updatingDonationProgres. Thread 8 Crashed:: Dispatch queue: com.apple.root.user-initiated-qos 0 libobjcMsgSend.dylib 0x19e7f0808 objc_msgSend + 8 1 CoreFoundation 0x1970fe300 __NSSetM_new + 368 2 CoreFoundation 0x19711cd64 -[NSSet initWithArray:range:copyItems:] + 304 3 LaunchServices 0x1976bc144 -[_LSLocalizedStringRecord _missingBundleLocsWithContext:tableID:unitID:unitBytes:] + 104 4 LaunchServices 0x197700628 objc_object* __strong __LSRECORD_GETTER__<objc_object* __strong>(LSRecord*, objc_selector*, objc_selector*) + 288 5 LaunchServices 0x1976bc854 -[_LSLocalizedStringRecord _detachFromContext:tableID:unitID:unitBytes:] + 68 6 LaunchServices 0x197701cac -[LSRecord detach] + 240 7 LaunchServices 0x197773720 -[UTTypeRecord _detachFromContext:tableID:unitID:unitBytes:] + 68 8 LaunchServices 0x1977756fc -[_UTDeclaredTypeRecord _detachFromContext:tableID:unitID:unitBytes:] + 52 9 LaunchServices 0x197701cac -[LSRecord detach] + 240 10 LaunchServices 0x197702c74 +[LSRecord(LSDetachable) resolveAllPropertiesOfRecords:count:andDetachOnQueue:] + 392 11 UniformTypeIdentifiers 0x19cd1bc80 +[UTType _typeWithTypeRecord:detachTypeRecord:findConstant:installInConstant:] + 232 12 UniformTypeIdentifiers 0x19cd19d38 _UTTypeGetForIdentifier(NSString*, bool) + 148 13 SpotlightKnowledge 0x2a7596adc -[SKGProcessor(EmbeddingsUtils) needsEmbeddingsForRecord:bundleID:] + 604 14 SpotlightKnowledge 0x2a7590bd4 -[SKGAttributeProcessor processorAttributesForRecord:bundleID:protectionClass:isUpdate:] + 500 15 CoreSpotlight 0x1a79bfa84 -[CSSearchableItemAttributeSet(CSPrivateAttributes) _standardizeProcessorAttributesForBundle:protectionClass:isUpdate:] + 292 16 CoreSpotlight 0x1a79b11a4 -[CSSearchableItem(Internal) standardizeAttributesForBundle:protectionClass:] + 780 17 CoreSpotlight 0x1a799f218 __39-[CSSearchableIndex _standardizeItems:]_block_invoke + 248 18 CoreFoundation 0x19712e56c __NSARRAY_IS_CALLING_OUT_TO_A_BLOCK__ + 24 19 CoreFoundation 0x197277604 ____NSCollectionHandleConcurrentEnumerationIfSpecified_block_invoke + 116 20 libdispatch.dylib 0x196ed45d4 _dispatch_client_callout2 + 16 21 libdispatch.dylib 0x196ecf2d4 _dispatch_apply_invoke3 + 336 22 libdispatch.dylib 0x196ed45bc _dispatch_client_callout + 16 23 libdispatch.dylib 0x196ebd624 _dispatch_once_callout + 32 24 libdispatch.dylib 0x196ecf974 _dispatch_apply_invoke_and_wait + 364 25 libdispatch.dylib 0x196ecea70 _dispatch_apply_with_attr_f + 1312 26 libdispatch.dylib 0x196ecebf4 dispatch_apply + 96 27 CoreFoundation 0x197277548 __NSCollectionHandleConcurrentEnumerationIfSpecified + 184 28 CoreFoundation 0x19712e350 -[__NSArrayM enumerateObjectsWithOptions:usingBlock:] + 188 29 CoreSpotlight 0x1a78d99b4 -[CSSearchableIndex _standardizeItems:] + 144 30 CoreSpotlight 0x1a799d4b0 -[CSSearchableIndex indexSearchableItems:deleteSearchableItemsWithIdentifiers:clientState:expectedClientState:clientStateName:updatingDonationProgress:protectionClass:forBundleID:options:reason:completionHandler:] + 824 31 CoreSpotlight 0x1a799d024 -[CSSearchableIndex indexSearchableItems:deleteSearchableItemsWithIdentifiers:clientState:expectedClientState:updatingDonationProgress:protectionClass:forBundleID:options:reason:completionHandler:] + 52 32 CoreSpotlight 0x1a799ca64 __131-[CSSearchableIndex endIndexBatchWithExpectedClientState:newClientState:critical:reason:updatingDonationProgres:completionHandler:]_block_invoke + 188 33 libsystem_trace.dylib 0x196d957e8 _os_activity_initiate_impl + 64 34 CoreSpotlight 0x1a799c91c -[CSSearchableIndex endIndexBatchWithExpectedClientState:newClientState:critical:reason:updatingDonationProgres:completionHandler:] + 448 35 AppKit 0x19c7a3568 0x19b5b6000 + 18797928 36 AppKit 0x19c4d8584 0x19b5b6000 + 15869316 37 libdispatch.dylib 0x196ebaa30 _dispatch_call_block_and_release + 32 38 libdispatch.dylib 0x196ed45bc _dispatch_client_callout + 16 39 libdispatch.dylib 0x196ec3018 _dispatch_lane_serial_drain + 744 40 libdispatch.dylib 0x196ec3b4c _dispatch_lane_invoke + 448 41 libdispatch.dylib 0x196ecdf70 _dispatch_root_queue_drain_deferred_wlh + 284 42 libdispatch.dylib 0x196ecd874 _dispatch_workloop_worker_thread + 720 43 libsystem_pthread.dylib 0x197076f78 _pthread_wqthread + 292 44 libsystem_pthread.dylib 0x197075cc4 start_wqthread + 8

Hi, I wanted to reach out about an issue we're seeing in PTT Framework. We have been investigating reports from some users that our app would run without issue for a day or so and then they would suddenly be unable to transmit audio but playback continued to work normally. After doing some digging and internal testing I was able to reproduce this by triggering a media services reset while PTT Framework was active (we had joined a channel). When this occurs everything appears to work correctly, all normal callbacks are received and the audio session is activated, but the data from the tap on the input node of our audio engine returns only silence regardless of whether the app is in the foreground or background. I'm able to reproduce this with 100% reliability using the following steps: Activate PTT Framework by joining a channel. Navigate to Settings -> Developer, tap Reset Media Services, and select Reset All Media Services. Return to the app and attempt to transmit. I've validated this behavior both in our app as well as in a separate minimal test app we use internally to validate interactions with the framework. Once we end up in this state it persists through tearing down and recreating our audio engine, deactivating and re-activating the audio session, killing the app and restarting it, etc. The only way we have found to recover from this state is to either reboot the device or leave the framework's channel and join again (basically toggle PTT Framework off and back on). Based on what I was able to find I believe this is the known CallKit issue (r.157725305) referenced in this forum post and does extend to PTT Framework. As mentioned above, we currently haven't found a good way to deal with this. Our current solution to this is to programmatically "toggle" PTT framework. This partially solves the problem but it has a couple issues: It causes the PTT Framework activation and deactivation sounds in quick succession. This is expected but not ideal UX. Because attempting to join a channel when the app is not in the foreground results in a failure with PTChannelError.appNotForeground we can only recover when in the foreground. The second issue is the more serious of the two as our users commonly rely on external wired or BLE devices to trigger PTT calls while the device is locked or the app is in the background. In this scenario we can't automatically recover so they won't know something is wrong until they realize they are only transmitting silence. We can identify when this occurs via the internal media services reset notification but again we only receive this while the app is active. Additionally, if the app was suspended when the reset occurred but then becomes active it is received after a 2-4 second delay so if the app wakes up to start a call, we commonly don't receive it until the user is already in the middle of a call trying to transmit. Is there anything we can do here other than posting a notification telling the user that there is an issue and they need to on-screen the app to resolve it? I've tried to provide as much information as possible but if there's anything else that would be helpful let me know.

I'm building a cross-device parental-control app: separate child and parent devices in the same Family Sharing group. I want to show the child's per-app (and per-category) Screen Time usage on the parent device. After extensive testing I can only get the child's total minutes across, and I'd like to confirm the supported architecture before building further on a path the framework may intentionally forbid. Authorization / setup Child device: AuthorizationCenter.shared.requestAuthorization(for: .child) — approved. Confirmed authorized: my app appears under Settings → Screen Time on the child, and the child's own DeviceActivityReport(users: .all) renders full per-app data. Parent device: separate device in the same family. Targets: main app + DeviceActivityReport extension + DeviceActivityMonitor extension, all with com.apple.developer.family-controls and a shared App Group. Physical devices, iOS 26.4.1. Xcode ⟦version⟧. What works: only the child's total minutes reach the parent — and only via my own relay: a DeviceActivityMonitor extension on the child writes aggregate totals to the App Group, the host app syncs them through CloudKit. No Screen Time API itself delivers the child's app/category breakdown to the parent. ⸻ Finding 1 — the report extension computes correct per-app data but cannot export it. On the child, makeConfiguration(representing:) iterates the results and produces correct per-app durations: LumicoActivityReport makeConfiguration done — 1 activityData, 1 segments, 5 apps, 17 min total Writing those aggregates to the shared App Group from inside the extension is then denied by the sandbox: Couldn't write values for keys ("screen_time_per_app_json") in CFPrefsPlistSource (Domain: group.servusjon.Lumico.shared …): setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access (UserDefaults.set doesn't throw — the write silently no-ops; only this CFPrefs log reveals the denial.) Q1: Is there any supported way to surface aggregated, non-identifying per-app usage (app name + minutes + category) computed inside the DeviceActivityReport extension to the host app, given that App Group writes from the extension are denied? Or is the DeviceActivityMonitor extension (threshold events) the only supported way to get any usage signal out of the Screen Time sandbox? Finding 2 — on the parent, users: .children shows the parent's OWN data. On the parent I embed DeviceActivityReport(_:filter:) with DeviceActivityFilter(users: .children, …). The report renders, but shows the parent's own apps/categories — no child data. FamilyActivityPicker on the parent behaves the same (lists the parent's own apps). The identical code on the child (users: .all) returns the child's full data — so the pipeline works; only the cross-device delivery to the parent fails. Q2: What is required for DeviceActivityReport(users: .children) to deliver a child's activity to a third-party app on the parent device? Must the parent app hold a specific FamilyControls authorization (which FamilyControlsMember)? What conditions make FamilyActivityPicker surface a child's apps (not just categories) from the family on the parent device — authorization type, Family Sharing roles, child managed status, sync timing? ⸻ Already ruled out: physical devices (not Simulator); Screen Time data present on the child; extension correctly embedded (ExtensionKit com.apple.deviceactivityui.report-extension) and running makeConfiguration normally; family-controls + App Group present on app and both extensions; iCloud container named conventionally iCloud.. Core question: What is the supported architecture for showing a child's per-app usage on a parent's device in a third-party app? I want to build on the sanctioned path rather than a workaround. Thanks!

Incoming calls reported via reportNewIncomingCall on a CXProvider are correctly presented on the iPhone via CallKit, but are never relayed to the paired Apple Watch. Native cellular calls relay to the Watch correctly on the same devices. What does a VoIP app's CXProvider need to satisfy for callservicesd to consider it eligible for phone continuity relay to paired Apple Watch?

We have six Advanced App Clip Experiences configured for our production app, each mapped to a different path under a single domain, each with its own title and image. When a user without the full app installed receives one of these links in Messages, iOS always presents the default App Clip card -- never the matching advanced experience card. The same URLs resolve the correct advanced card in Safari. What we've already verified (so this isn't a basic setup problem): Opening the exact same URL in Safari shows the correct advanced card, including the expected per-path title. A Local Experience (Settings → Developer → App Clips Testing) for the same path + bundle ID validates and launches the correct flow. Associated Domains validation is green in Settings. The AASA at app-site-association.cdn-apple.com contains the appclips component with our App Clip bundle ID, and the applinks components include all six paths. In App Store Connect, all six Advanced App Clip Experiences show "Received" with successful domain validation, and the app + App Clip are live in the App Store. Reproduced on multiple devices on iOS [version], none with the full app installed. Messages does show a card — it's just always the default card. Our questions: Is per-path Advanced App Clip Experience card selection supported in the Messages link bubble at all -- or is Messages documented to always present the default experience metadata regardless of which advanced-experience URL is shared? Apple's App Store Connect help states the default metadata is used "in the app clip link bubble in Messages," which suggests this may be by design -- can someone confirm? If advanced cards in Messages are supported, what conditions cause Messages (but not Safari) to fall back to the default card for the same URL? Does "Received" status indicate an advanced experience is fully live, or is there a later state that confirms Messages rollout? If Messages is expected to always show the default card, we'll plan around that -- we just want a definitive answer rather than continuing to chase a configuration cause. Thanks!

Hi Apple Developer Support / WeatherKit team, I’m seeing WeatherKit fail on a physical iPhone with what appears to be a JWT / permission issue, even though the app appears to be correctly configured and signed with the WeatherKit entitlement. App / project context: App name: Signals Platform: iOS Framework: SwiftUI WeatherKit usage: Native WeatherKit framework, using WeatherService.shared.weather(for:) Purpose: Showing a small morning weather summary inside the app What I have already verified: Active Apple Developer Program membership WeatherKit capability enabled for the App ID in Apple Developer Portal WeatherKit capability enabled in the App Capabilities tab WeatherKit capability added in Xcode Signing & Capabilities Automatic signing enabled Built and tested on a physical iPhone device Location permission is requested and granted The app binary appears to include the WeatherKit entitlement The embedded provisioning profile appears to include the WeatherKit entitlement Issue: WeatherKit still fails at runtime with a JWT / permission-related error. Could you please help verify whether: The WeatherKit entitlement is correctly attached to my App ID and provisioning profile My Team ID / App ID has WeatherKit access fully enabled on Apple’s backend There are any backend propagation delays or stuck entitlement states WeatherDaemon has permission to generate JWTs for this app There is anything else I need to reset or regenerate, such as provisioning profiles, certificates, or App ID capabilities I can provide: Team ID Bundle ID provisioning profile UUID entitlement output from codesign device logs / WeatherKit error logs screenshots of App ID capability settings Thank you.

WeatherService fails on every request with: WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" hourly forecast fetch failed: … Code=2 I've verified the entire setup and the error persists, which points to the App ID's WeatherKit token generation not being provisioned on Apple's backend: Team ID: 2LWCLD2636 Bundle ID: com.hoagiecorps.poppit WeatherKit capability and App Service both enabled on the App ID. com.apple.developer.weatherkit entitlement present in the signed binary and the embedded provisioning profile (verified via codesign -d --entitlements). A TestFlight build carrying the entitlement has been processed (VALID). Location authorized (When-In-Use); valid coordinates are obtained — the failure is purely the JWT auth step. Tried: device reboot, VPN off, iCloud Private Relay off, cycling the WeatherKit capability off/on plus regenerating the profile and clean rebuild, and waiting several days. Physical device, iOS 26. Could someone from the WeatherKit team please check the status for Team 2LWCLD2636, Bundle ID com.hoagiecorps.poppit, and enable WeatherKit token generation for this App ID? It looks like a backend entitlement sync is needed. Thanks!

We are seeing a reproducible scenario on iOS 26 where incoming VoIP push notifications are never delivered when the device has been idle and screen-locked for 30+ minutes. The same failure was observed simultaneously on WhatsApp, and Microsoft Teams and our app as well, on the same device during one incident, confirming this is a platform-level issue and not specific to our implementation. We have captured full system logs across three separate incidents. Below are the exact log sequences. Incident — All VoIP apps fail simultaneously (Our app, WhatsApp, Teams) Device: iPhone 17 Pro · iOS: 18.x · Network: 5G NSA (kNRNSA) The device had been idle with the screen locked for approximately 31 minutes. An LTE cell handover caused apsd to begin an APNs reconnection. powerd entered policy 3 before apsd reached channel-flow viable, defuncting the app. 17:45:59.562 symptomsd New RRC 0 when previous 1 from pdp_ip0 ↑ Radio drops to RRC_Idle. Device has been idle since 17:14:56 (31 min). 17:46:01.206 CommCenter #I Mapping the registration state to kRegisteredHome ↑ LTE cell handover triggers RRC reconnect. 17:46:01.330 apsd [C138 IPv4#b71cac13:5223 ready parent-flow (satisfied (Path is satisfied), interface: pdp_ip0[lte], scoped, ipv4, ipv6, dns, expensive, uses cell, LQM: good)] event: path:satisfied_change @594.391s ↑ APNs path re-satisfied. Reconnection begins. channel-flow viable NOT yet reached — TLS handshake still in progress. 17:48:08.057 apsd Powerd has requested assertion activity update ↑ Warning: powerd about to change policy. ── 2 minutes 40 seconds after APNs reconnect started ── 17:48:41.248 powerd Sending com.apple.powerd.assertionpolicy 3 17:48:41.250 apsd Update assertion policy 3 17:48:41.250 powerd Activity changes from 0x1 to 0x0. UseActiveState:0 17:48:41.250 powerd hidActive:0 displayOff:1 assertionActivityValid:0 ↑ Screen off, device locked. OS enters restricted idle. apsd restricted. APNs reconnection abandoned. 17:48:42.669 kernel necp_process_defunct_list: necp_update_client abort nexus error (2) for pid 1518 Comera ↑ Kernel terminates Comera's network stack via NECP. No API available to prevent this. WhatsApp and Teams remain suspended — no DEFUNCT, but apsd in policy 3 means no push delivery for them either. ── Dead zone: VoIP pushes for all 3 apps undeliverable ── 17:50:04.028 powerd Process CommCenter.104 Created SystemIsActive "com.apple.ipTelephony.sipIncoming.cell" ↑ Incoming cellular PSTN call forces system wake. 17:50:04.494 powerd Sending com.apple.powerd.assertionpolicy 0 17:50:04.598 apsd Update assertion policy 0 ↑ Full wake. Queued VoIP pushes from Comera, WhatsApp, and Teams are delivered simultaneously. Gap between channel-flow viable needed and actual delivery: 4 minutes 3 seconds. Recovery trigger: external cellular call from carrier — not any app action. Working case (same test, different conditions) Device: iPhone 17 Pro · iOS: 26.5.1 · Screen unlocked, no hotspot 19:2x:xx apsd policy state {downgradeWhenLocked: NO, isSystemLocked: NO, isConnectedOnUltraConstrainedInterface: NO} ↑ Device unlocked. No policy 3. Comera NOT defuncted. Push delivered. Call rings normally. Our implementation PKPushRegistry is held strongly and re-registered on every applicationWillEnterForeground reportNewIncomingCall(with:update:completion:) is called synchronously within pushRegistry(_:didReceiveIncomingPushWith:) VoIP background mode entitlement is present App has com.apple.developer.pushkit.voip entitlement Questions Is there any entitlement or API to prevent NECP from defuncting a process holding an active PKPushRegistry? The VoIP push entitlement exists for exactly this background delivery scenario. Is pushDisallowed being applied to apps with VoIP push entitlements when InternetSharingActive == 1 intentional? Should VoIP entitlements exempt an app from the Internet Sharing Policy gate in dasd? Is there a documented way to know when apsd has fully completed APNs reconnection (i.e. channel-flow viable) so a server can time push retries more accurately within a call validity window? What is the recommended apns-expiration value for VoIP pushes to survive brief APNs reconnection windows without exceeding a 60-second call validity period? Full log stream captures available for all incidents.

We have a published, approved App Clip that works correctly via QR code and the Safari Smart App Banner, but URL-based invocation does not trigger the App Clip card in any context. Most notably, Apple's own default App Clip URL does not work either: https://appclip.apple.com/id?p=hazel-torus.Clip **Tapping this link in Messages or Notes does nothing. ** Long-pressing it shows a generic website link preview rather than the App Clip card, even though appclip.apple.com is Apple's domain and requires no configuration on our end. Setup details: App Clip bundle ID: hazel-torus.Clip Team ID: 2UNR2APH47 App Clip experience URL: https://passportreader.app/open AASA includes a correctly formatted appclips key with 2UNR2APH47.hazel-torus.Clip (confirmed via https://app-site-association.cdn-apple.com/a/v1/passportreader.app that AASA is correctly cached) Associated Domains entitlements (appclips:passportreader.app) are present on the App Clip target App and App Clip experience are both Approved / Ready for Sale Tested on two physical devices, neither with the full app installed Since QR and Safari banner invocation work, the App Clip itself and its entitlements appear correctly configured. The fact that even Apple's own appclip.apple.com URL fails, and is treated as an arbitrary website link, suggests this may be a backend indexing issue specific to this App Clip rather than a client-side configuration problem. Has anyone else encountered this, or know what could cause appclip.apple.com to not be recognized as an App Clip URL?

I have a question regarding parental control features within a region with age assurance regulations. The DeclaredAgeRange docs here suggests that age range can be "set" by the user or their parent or guardian: Check the ageRangeDeclaration to understand how the person or their parent or guardian set their age range. The declaration method indicates whether the age was self-declared, guardian-declared, or verified using a payment method, government ID, or another method. Based on this, I'm assuming the parent has the ability to override the user's real age (ex: 13 year old set to 18+?). Is that a correct assumption? Or do users that belong into a regulated region always return their true age for the purposes of Texas SB2420?

I am currently experiencing a bug where everyday at 5:30pm I have to manually go into Settings and turn off Screen Time's Downtime because it automatically locks me out of almost all of my apps. I am not able to toggle the "Scheduled" option, preventing me from editing Downtime. Is there any improvements with iOS27 that will be able to fix this bug? The goal is to not use Downtime anymore (aka it is not scheduled).

When the Age Verification framework validates a user based on both regulated region and age range, which location signal will the framework use for users in regulated regions? a.          The user's current physical location b.          The location associated with the user's Apple account c.          The billing or credit card location If multiple signals are available and inconsistent, what is the expected precedence order?   2. Can you provide a list of regions where age range is specified by default and regions where it is not? My app currently requests consent to share age range information during sign-in or sign-up, and the user's session remains active until sign-out. If a user was under 18 when the app was first installed and selected “decline to share,” but later turns 18 while remaining an active user, what is the recommended in-app approach for requesting age range information at that stage? Additionally, if parental consent is used to allow access for users under 18, how should the app determine when the user turns 18 and becomes eligible for direct age range collection? What are the exact requirements and limitations for receiving real (live) responses from the Declared Age Range API? Will these Age Verification rules/checks applied only to the new Apple Accounts or for existing users too?

With the recent introduction of the unified asset pipeline and Icon Composer, managing cross-platform icon designs has become incredibly efficient. However, there is still a significant platform disparity when it comes to maintaining visual consistency and brand uniformity across paired devices. On iOS, we can dynamically change the app icon at runtime using the setAlternateIconName API. Currently, watchOS completely lacks an equivalent mechanism. If a user selects an alternative icon inside an iOS companion app, the paired Apple Watch app icon remains locked to the default primary asset. This creates a disjointed experience and directly impacts user recognition. The watchOS home screen relies entirely on instant visual cues. If a user changes their iPhone icon to a custom colorway, they instinctively look for that same colorway on their wrist. Leaving the watch icon unchanged makes it harder to quickly locate the app. I have submitted an enhancement request via Feedback Assistant to bring alternate app icon support to watchOS, ideally through an automatic system-level sync within the unified .icon pipeline, or via a native watchOS runtime API. If your app utilizes alternate icons and you would like to see this cross-device continuity brought to watchOS, please consider filing your own duplicate request to help bring visibility to this gap. Filed Feedback: FB23080617

Is there any news on Help Bundle issues from macOS 26? FB17996362 FB19414854 FB17996178 FB17460960

I have a section near the bottom of a ScrollView / LazyVStack. I want to show a popoverTip anchored to a button in that section, but only once the user has actually scrolled to it not on view load (otherwise the tip shows floating at the bottom of the screen). I tried to use onAppear but it fires as soon as the view is inserted into the hierarchy which on a LazyVStack can happen slightly before the view is truly in the viewport. I fell back to using onScrollVisibilityChange to write the @Parameter only when the section is actually visible: .onScrollVisibilityChange { isVisible in MyTip.sectionVisible = isVisible } This correctly gates visibility, but on some older devices I noticed that writing/reading @Parameter mid-scroll causes hitches. Is there a recommended TipKit pattern for this use case: showing a popoverTip only when its anchor has been scrolled into view that doesn't require a reactive write during active scroll? thanks