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.

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

I'm building a window layout manager that saves and restores window positions across Spaces when switching between display configurations (laptop / docked 3-monitor / Vision Pro). Spencer 1.4.4 handles this today but broke on Golden Gate beta with "Cannot detect number of Spaces." I built a diagnostic probe to find the root cause. FINDINGS (macOS 27.0 Build 26A5353q): CGSPrivate symbols — all intact and functional: CGSMainConnectionID, CGSCopySpaces, CGSGetWindowWorkspace, CGSMoveWindowsToManagedSpace all resolve via dlsym and work correctly. CGSCopySpaces(mask=7) returns 14 valid space IDs. This is NOT the source of the breakage. com.apple.spaces plist — structure changed in Golden Gate: The top-level 'Monitors' key is gone. It has moved to: SpacesDisplayConfiguration → Management Data → Monitors New top-level keys: [SpacesDisplayConfiguration, app-bindings, spans-displays] This IS the root cause. Spencer's parser looks for 'Monitors', finds nothing, and fails. One-line fix once confirmed stable. CGSGetWindowWorkspace returns Space ID 0 for windows set to 'all desktops'. Valid space IDs in this session are 30, 15, 14, 12, 11, 10 — so 0 appears to be a sentinel value for that condition. Full probe output: `SpacesProbe v1.0 — WWDC 2026 Developer Lab ════════════════════════════════════════════════════════ System: Version 27.0 (Build 26A5353q) Date: 2026-06-09 21:41:33 +0000 ── PUBLIC API (stable, no entitlements needed) ──────────── ✅ CGWindowListCopyWindowInfo: 17 on-screen windows found ✅ CGGetActiveDisplayList: 1 active display(s) ✅ Accessibility (AXIsProcessTrusted): GRANTED ✅ AXUIElement read: 'Cursor Pro' @ 1427,906 438×438 ✅ AXUIElement write: SUCCESS (nudged window +1px and restored — non-destructive) ── com.apple.spaces PLIST (what Spencer reads to understand Space topology) Path: /Users/csj/Library/Preferences/com.apple.spaces.plist ✅ Plist file exists ✅ Plist readable and deserializable ✅ Monitors in plist: 8 ✅ Total spaces found: 14 Top-level keys: [SpacesDisplayConfiguration, app-bindings, spans-displays] ⚡ GOLDEN GATE: 'Monitors' replaced by 'SpacesDisplayConfiguration' SpacesDisplayConfiguration sub-keys: [Management Data, Space Properties] Monitors (under Management Data): 8 Monitor 0: 14 space(s) ⚠️ 'Monitors' key gone in Golden Gate — moved to SpacesDisplayConfiguration. Spencer parser needs update to read new key. → These anomalies cause Spencer 1.4.4 to report → "Cannot detect number of Spaces" on Golden Gate beta. ── CGSPrivate BRIDGE (private API — the only path to Space assignment) Resolution via dlsym — nil = symbol removed from this OS build ✅ CGSMainConnectionID ✅ CGSCopySpaces ✅ CGSGetWindowWorkspace ✅ CGSMoveWindowsToManagedSpace Connection ID: 3175291 ✅ CGSCopySpaces(mask=7): 14 spaces → 30, 15, 14, 12, 11, 10 ✅ CGSGetWindowWorkspace(wid=99): Space ID = 0 ── SUMMARY ───────────────────────────────────────────────── ✅ Window enumeration (CGWindowListCopyWindowInfo): WORKS ✅ Window position read/write (AXUIElement): WORKS ✅ Display topology (CGGetActiveDisplayList): WORKS ❌ com.apple.spaces plist parsing: BROKEN (1 anomalies) ✅ CGSPrivate Space management symbols: ALL PRESENT Feedback: feedbackassistant.apple.com FB23017010QUESTIONS: Is the new SpacesDisplayConfiguration.Management Data.Monitors path stable and intended for use by third-party tools, or still an implementation detail subject to change? Is Space ID 0 from CGSGetWindowWorkspace the stable sentinel for 'window assigned to all desktops', or is there a proper API for detecting that condition? Is there an entitlement (com.apple.private.spaces or equivalent) that can be granted to productivity tools distributed outside the App Store for Space management? What is the intended supported mechanism for a third-party app to save and restore window Space assignments on macOS? Feedback: FB23017010

When i use the MFMailComposeViewController in visionOS, there is no cancel button for the controller. The button at the bottom closes the app. Is anyone else experiencing this? if([MFMailComposeViewController canSendMail]) { MFMailComposeViewController* controller = [[MFMailComposeViewController alloc] init]; controller.mailComposeDelegate = (id <MFMailComposeViewControllerDelegate>)view; [controller setToRecipients:toAddresses]; [controller setSubject:subject]; [controller setMessageBody:body isHTML:isHtml]; [view presentViewController:controller animated:YES completion:nil]; }

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.

Xcode’s “App Thinning Size Report” reports a size under 15MB, but very close to it like 14.9MB, and if I publish the clip it becomes unavailable for costumers (They get "App Clip Unavailable" after scanning the QR code. On the other hand, if the size on the report is 14.7MB, it works fine for everyone. Can you advice a more accurate way to determine if the size is valid for distribution? On the same topic: Are there any plans to increase the size limit beyond the 15MB?

Hello, I am exploring an iPadOS product idea for Apple Pencil users and would like to understand the current public API boundary. The user need is a temporary, user-controlled Apple Pencil annotation layer while the user is working in another app or workspace. For example, a student may be reading in Books, Safari, a PDF app, or another educational app and want to write quick Pencil notes directly over the visible material without taking a screenshot or exporting the content first. I understand that PencilKit works inside an app's own UI, and I also understand that iPadOS sandboxing prevents third-party apps from inspecting or modifying other apps. I am not trying to bypass that model. What I am trying to determine is: Is there any current public API, extension point, or entitlement that allows a user-initiated Apple Pencil overlay session across the current iPadOS workspace? If not, is Feedback Assistant the right place to request a new PencilKit / iPadOS entitlement for this use case? Are there existing Apple-recommended patterns for this workflow beyond Quick Note, Screenshot Markup, Split View, Stage Manager, or importing content into the developer's own app? The privacy model I have in mind would be strict: The overlay is user initiated only. A visible system indicator is shown while active. The developer app receives Pencil stroke data only by default. The app cannot inspect the underlying app's view hierarchy, documents, text, or private data. Screen pixels are not captured unless the user grants separate explicit permission. The user can close or clear the overlay at any time. The closest mental model is a system-mediated Pencil annotation layer, not a background screen recorder or a way to control another app. If this is not possible today with public APIs, I would appreciate confirmation so I can file a clear enhancement request through Feedback Assistant. I also filed this as Feedback Assistant report FB23067750. 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!

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?

I built an advanced app clip experience, associated it to a location, and its MATCHED. The status is marked (green) RECEIVED. However, I am unable to see the invocation on Maps. I don't see the buttons such as SUPPORT/ORDER shown for that place. The docs does not explain why. What is the exact requirement for us to surface buttons for POI? We are authorized by the businesses to add these for them. I'd love to hear in detail the exact process to add buttons for POI - how Uber Eats and Door Dash does it for restaurants and how their app clips get shown. Thank you.

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!

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!

We noticed that in older OS versions the accessory picker would consistently display a peripheral's advertised friendly name on top of displaying information from the matching display item. While in newer OS versions we would mostly only see the name from the display item. Is there a way to configure this?

The documentation specifies that when Contacts framework returns unified contacts that each fetched unified contact object (CNContact) has its own unique identifier that’s different from any individual contact’s identifier in the set of linked contacts and that when refetching a unified contact, that this identifier should be used. There is also an analogous identifier within the list of contactRelations, but each of these don't seem to corespondent to the unified contacts. For example, is a new contact (Sheryl Zakroff) is created in the simulator Contacts and their spouse is set to Hank Zakroff. However, the GUID created for the contactRelations identifier does not correlate to the original Hank Zakroff GUID and cannot be searched. Is this a bug or what is the indent of the contactRelations identifier? Here's a debug output of walking the unifiedContacts: Name: Hank Zakroff 2E73EE73-C03F-4D5F-B1E8-44E85A70F170 - Other : (555) 766-4823 - Other : (707) 555-1854 Name: David Taylor E94CD15C-7964-4A9B-8AC4-10D7CFB791FD - Other : 555-610-6679 Name: Sheryl Zakroff DE783BC8-7917-4138-93F6-3AF0FD4CE083 - Other : (707) 555-1854 - Spouse: <CNContactRelation: 0x60000000dd60: name=Hank M. Zakroff> - 534B467D-CA00-46D3-897C-16EEA782C9CF - Looking for ["534B467D-CA00-46D3-897C-16EEA782C9CF"] []

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 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 don't see upload option for the App Store connect, can only export .ipa. Also having issues with Transporter, pasting error message here. Could not create a temporary .itmsp package for the app "Redacted.ipa". Unable to determine app platform for 'Undefined' software type. Is anyone else facing the same issue? I am using Xcode 15.

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?

Hello! Our app includes a calling feature for some users, and we would like to promote to those users that they can set our app as their default calling app. If there is no way to check this state, then the risk is that we may repeatedly prompt users to enable something they have already enabled. There also doesn't appear to be a way to set the default calling app programmatically, and that the best we can do may be to direct the user to the default app section in Settings. For our app, the calling capability is only applicable to some users. For users who are not eligible to place calls, we would prefer that they not be able to set our app as the default calling app at all. Otherwise, iOS may route calling actions to our app. So my questions are: Is there any supported API or other mechanism to determine whether the user has set our app as their default calling app? Is there any supported way to enable, disable, or hide default calling app eligibility programmatically? My current understanding is that neither of these is possible, but I would appreciate confirmation or any recommended workaround. Thanks.