I'm running into a contradictory requirement involving the DeviceActivity Report extension (com.apple.deviceactivityui.report-extension) that makes it impossible to both: upload the app to App Store Connect, and install the app on a physical device. This creates a complete catch-22. 📌 Overview My extension: Path: Runner.app/PlugIns/LoADeviceActivityReport.appex Extension point: com.apple.deviceactivityui.report-extension Implementation (SwiftUI): import SwiftUI import DeviceActivity @main struct LoADeviceActivityReport: DeviceActivityReportExtension { var body: some DeviceActivityReportScene { // ... } } This is the standard SwiftUI @main DeviceActivityReportExtension template. 🟥 Side A — iOS runtime behavior (device installer) If I add either of these keys to the extension's Info.plist: NSExtensionPrincipalClass NSExtensionMainStoryboard then the app cannot be installed on a real iPhone/iPad. The device installer fails with: Error 3002 AppexBundleContainsClassOrStoryboard NSExtensionPrincipalClass and NSExtensionMainStoryboard are not allowed for extension point com.apple.deviceactivityui.report-extension. To make the app install and run, I must remove both keys completely. This leaves the extension Info.plist like: NSExtension NSExtensionPointIdentifier com.apple.deviceactivityui.report-extension With this, the app installs and runs correctly. 🟥 Side B — App Store Connect upload validator However, when I upload the IPA with the runtime-correct Info.plist, App Store Connect rejects it: State: STATE_ERROR.VALIDATION_ERROR (HTTP 409) Missing Info.plist values. No values for NSExtensionMainStoryboard or NSExtensionPrincipalClass found in extension Info.plist for Runner.app/PlugIns/LoADeviceActivityReport.appex. So ASC requires that at least one of those keys be present. 💥 The catch-22 If I add PrincipalClass / MainStoryboard: ✔ App Store Connect validation passes ❌ But the app can NOT be installed on any device (Error 3002) If I remove PrincipalClass / MainStoryboard: ✔ The app installs and runs correctly ❌ ASC rejects the upload with “Missing Info.plist values” There is currently NO Info.plist configuration that satisfies both: Runtime: "NSExtensionPrincipalClass and NSExtensionMainStoryboard are not allowed." App Store Connect: "You must include NSExtensionPrincipalClass or NSExtensionMainStoryboard." 📌 Expected behavior For SwiftUI @main DeviceActivityReportExtension, the documentation and examples suggest the correct configuration is: NSExtensionPointIdentifier com.apple.deviceactivityui.report-extension with no principal class or storyboard at all. If that is correct for runtime, ASC seems to need updated validation rules for this extension type. ❓My Questions What is the officially correct Info.plist configuration for a SwiftUI DeviceActivityReportExtension? Should principal class / storyboard not be required for this extension type? Is this a known issue with App Store Connect validation? Is there currently a workaround that allows: installation on device and successful App Store Connect upload, without violating runtime restrictions?

Problem Description: After upgrading to iOS 26, I discovered that the ExtendedDistanceMeasurement feature in the Nearby Interaction framework is not working as expected. On the same device model, the issue did not occur on iOS 18, but it is present on iOS 26 (including the latest iOS 26.2), and it has started affecting the functionality of my app. I hope this issue can be resolved as soon as possible. Problem Details: On iOS 26 and later versions (including iOS 26.2), when using an iPhone and an Apple Watch both equipped with second-generation UWB chips, enabling isExtendedDistanceMeasurementEnabled initiates the distance measurement process successfully, but the distance information fails to update. The real-time distance between the devices does not display within the app. Affected Devices and Versions: iPhone Model: iPhone 15 Pro Max iOS Version: iOS 26.2 Apple Watch Model: Apple Watch 10 watchOS Version: 26.2 Example Code: The issue can be reproduced by adding the following code from the official sample code: Nearby Interaction Framework Sample Code

Hello, I have an AppClip technical issue I'd like to ask about: Our Xiaohongshu App (Version 9.14 & Build 9140845 & appid 741292507) was submitted to the App Store for review on December 18th and approved on December 19th, starting a phased rollout. This version was the first to support AppClip functionality, and as of today the app has been fully rolled out, but I still cannot activate the Xiaohongshu App Clip Card using the NFC tag (built-in URL: https://xhslink.com/n/22UG9jlaOfv?sourceid=911). I checked all the configurations of our project's AppClip target (Associated Domains:appclips:xhslink.com), the default experience in the ASC backend (URL: https://appclip.apple.com/id?p=com.xingin.discover.Clip), and the advanced experience (URL: https://xhslink.com/n/Arxpo4IVY9X), and all showed no abnormalities. Furthermore, the default experience URL, after being written with an NFC tag, can be successfully launched by tapping the NFC tag to open the Xiaohongshu App Clip Card, and the Card can also be opened normally in Safari on the phone. However, our advanced experience URL, after being written with an NFC tag, cannot be launched by tapping the Card. Therefore, my question is: Who please can help me check why the Xiaohongshu App Clip Card cannot be launched normally using the advanced experience URL? Thank you very much! My Expectations: My advanced experience URL configured on the ASC platform, such as https://xhslink.com/n/Arxpo4IVY9X, should be recognized and validated by the iOS system when the phone is near the NFC tag and reads https://xhslink.com/n/22UG9jlaOfv?sourceid=911, ultimately triggering the App Clip Card configured in Xiaohongshu's advanced experience settings. Additionally: We have already deployed a large number of NFC tags and other materials in many online stores, and the URL (https://xhslink.com/n/Arxpo4IVY9X) is built-in, and our 9.14 version is fully implemented. However, the newly developed App Clip feature is not working, which is very urgent and I hope Apple can help me find the cause of the problem and how to improve it as soon as possible. Thank you very much!

I’m configuring App Clip launch behavior and would appreciate some clarification. In my setup, the App Clip launch URL is the same as the deep link used to open the full app. Both are configured in the Apple App Site Association (AASA) file. Observed behavior: Scanning a QR code with this URL correctly launches the App Clip. Tapping the same URL when it’s shared (for example, via Messages) launches the full app via the deep link instead of the App Clip experience. I’m reviewing the documentation here: https://developer.apple.com/documentation/appclip/configuring-the-launch-experience-of-your-app-clip#Choose-App-Clip-experiences-you-want-to-support The table mentions that an App Clip can be invoked via “A shared link to an App Clip in the Messages app.” However, when I tap the shared link in Messages, the deep link experience is triggered instead of the App Clip. My questions are: Is this behavior expected when the App Clip URL and the app’s deep link URL are the same? Does launching an App Clip from a shared Messages link require a distinct URL or additional configuration beyond what’s in the AASA file? Are there specific constraints or priorities between universal links for the full app and App Clip invocation in this scenario? Any clarification or guidance would be greatly appreciated. Thank you.

操作步骤：1:调用let eligible = try await AgeRangeService.shared.isEligibleForAgeFeatures，返回YES后，再次调用 let response = try await AgeRangeService.shared.requestAgeRange(ageGates:18, in: viewController) switch response { case .declinedSharing: DispatchQueue.main.async { completion(.declinedSharing, nil, nil) } case .sharing(let swiftRange): DispatchQueue.main.async { let model = ARAgeRange(swiftRange: swiftRange) completion(.sharing, model, nil) }

Problem Description: After upgrading to iOS 26, I discovered that the ExtendedDistanceMeasurement feature in the Nearby Interaction framework is not working as expected. On the same device model, the issue did not occur on iOS 18, but it is present on iOS 26 (including the latest iOS 26.2), and it has started affecting the functionality of my app. I hope this issue can be resolved as soon as possible. Problem Details: On iOS 26 and later versions (including iOS 26.2), when using an iPhone and an Apple Watch both equipped with second-generation UWB chips, enabling isExtendedDistanceMeasurementEnabled initiates the distance measurement process successfully, but the distance information fails to update. The real-time distance between the devices does not display within the app. Affected Devices and Versions: iPhone Model: iPhone 15 Pro Max iOS Version: iOS 26.2 Apple Watch Model: Apple Watch 10 watchOS Version: 26.2 Example Code: The issue can be reproduced by adding the following code to the official sample code: Nearby Interaction Framework Sample Code private func didReceiveDiscoveryToken(_ token: NIDiscoveryToken) { if session == nil { initializeNISession() } if !didSendDiscoveryToken { sendDiscoveryToken() } os_log("running NISession with peer token: \(token)") let config = NINearbyPeerConfiguration(peerToken: token) // The issue can be reproduced by adding the following code to the official sample code // Enable extended distance measurement if both devices support it if NISession.deviceCapabilities.supportsExtendedDistanceMeasurement && token.deviceCapabilities.supportsExtendedDistanceMeasurement { config.isExtendedDistanceMeasurementEnabled = true } session?.run(config) } Problem Behavior: When either the iPhone or the Apple Watch does not support the second-generation UWB chip (i.e., deviceCapabilities.supportsExtendedDistanceMeasurement = false), the code works as expected. However, when both the iPhone and the Apple Watch support the second-generation UWB chip (i.e., deviceCapabilities.supportsExtendedDistanceMeasurement = true), the code fails to work, and the distance does not update — meaning the real-time distance between the devices is not displayed. Expectation: I hope this issue can be resolved soon, as it is impacting my app. The problem persists in the latest iOS 26.2, and has yet to be fixed.

I created in my Objective-c project the AgeRange check for a special function. It is working well on an iPhone. Now I used my Mac and added my app to the TestFlight on my macOS Tahoe 26.1 Here it is directly crashing. But how can I debug an Application which is created for iPhone and iPad with Xcode? I cannot use the target myMac when running a debugging mode. So how is the debugging working for such Apps?

We first discovered this issue in our own product, but we were able to reproduce it even when using Apple’s official demo: https://developer.apple.com/documentation/alarmkit/scheduling-an-alarm-with-alarmkit Reproduction Steps: Set an alarm on iOS 26.1 using AlarmKit. Upgrade the device to iOS 26.2 beta 3 or later. The alarm will no longer ring. Based on our testing, versions prior to 26.2 beta 2 do not exhibit this issue, so it appears that something introduced in beta 3 has caused the regression. The results are as follows: iOS 26.1 → iOS 26.2 beta 2 or earlier: Alarms ring normally iOS 26.1 / iOS 26.2 beta 2 → iOS 26.2 beta 3 / iOS 26.2 RC: Alarms fail to ring iOS 26.2 beta 3 → iOS 26.2 RC: Alarms ring normally This issue is critical. Users currently on iOS 26.1 may experience alarms failing to ring after updating their system, which can cause real-life disruptions (e.g., being late for work). We strongly recommend addressing this as soon as possible. Xcode Version: Version 26.1.1 (17B100) Feedback ID: FB21273655

Hi, Is there any way to make AlarmKit alarms snooze when the user presses the hardware volume buttons? Currently, pressing a volume button while an AlarmKit alarm is ringing stops/dismisses the alarm. Why this matters: Many users instinctively press the volume buttons when an alarm starts (either to react quickly while half-asleep or because they’re used to the Clock app behavior). When this stops the alarm entirely, users unintentionally dismiss the alarm, which can lead to missed wake-ups and a poor user experience. In practice, this becomes a frequent source of confusion and frustration because the behavior differs from the system Clock app.

Hi, We've noticed that this issue occurs more frequently after upgrading to iOS 18.4.1 and can result in one-way audio. Our app uses CallKit with WebRTC to establish VoIP connections. However, on iOS 18.4.1, CallKit no longer triggers: func provider(_ provider: CXProvider, didActivate audioSession: AVAudioSession) We're currently comparing the occurrence rate across different iOS versions to better understand the impact. Could you please help analyze the root cause of this issue?

I published my app clip last year in the App Store. I can successfully open my app clip in iMessage or via link URL. but scanning the QR code of the very same URL leads to the "app clip is unavailable" error, in this case, I can see my application name and banner correctly. Any Idea why?

Hi everyone, I’ve removed my App Clip completely: Deleted all Advanced App Clip Experiences Removed the App Clip target from my build Removed App Clip references from my apple-app-site-association file Deleted the meta tag from my website: But when I scan the QR code, the App Clip card still appears with: "This App Clip is not currently available in your country or region." Does anyone know why this is still showing and how to fully remove it? we need to show our website when this QRCode is scanned. Thanks!

I am requesting assistance with an issue involving my Advanced App Clip Experience, which has remained in the “Received” state for more than few months, preventing the App Clip from becoming available when invoked via QR code. App Details App Name: Yellow Label Verification App Store Bundle ID: com.acviss.demoindia App Clip Bundle ID: com.acviss.demoindia.Clip Team ID: F2RLQ4VV59 App Version (Live): 1.4 Domain: acviss.com Issue Summary My Advanced App Clip Experience is stuck in the “Received” status. The “Publish” and “Build Assignment” options never appear, even though: The updated AASA file is correctly published at: https://acviss.com/.well-known/apple-app-site-association It contains the correct appclips → appID and paths entries It is served with the correct application/json content type Domain validation in App Store Connect shows Validated The App Clip build is already approved and live on the App Store Safari-based App Clip invocation works as expected Despite this, the Advanced App Clip Experience has not transitioned from “Received” to “Processing” or “Published.” Because of this, QR-based invocation consistently shows “App Clip Unavailable”, indicating that the App Clip Experience has not yet been activated on Apple’s backend. Reproduction Steps Publish correct AASA file with appclips array and paths Validate domain (shows green “Validated” in App Store Connect) Open the Advanced App Clip Experience in App Store Connect Status stays as Received “Build Assignment” or “Publish” buttons never appear QR scanning of the App Clip URL continues to show App Clip Unavailable Request Could you please check the backend processing of my App Clip Experience and manually trigger the sync or processing It appears that the App Clip Experience is not being processed even though all configuration, AASA, and domain validations are correct. I would greatly appreciate your assistance in resolving this so the App Clip can be invoked successfully via QR. Thank you very much for your help and support.

Dear Apple, while implementing Declared Age Range API in my app, I've noticed a mistake in documentation: the isEligibleForAgeFeatures property is marked 26.0+ in documentation, but 26.2+ in Xcode, which ultimately leads to inability to use it with OS below 26.2. Moreover, I'm thoroughly confused by this quote from documentation: This flag returns true on iOS and iPadOS based on a person’s eligibility and always returns false on macOS. It leads me to two questions: Is it possible to use Declared Age Range API for macOS apps? Will it be possible to use it in future? Will there be any changes regarding this matter in a meantime (especially after Jan 1st)? If yes - when should we expect these changes? If no - why this API declares macOS 26+ support alongside iOS/iPadOS, if it simply doesn't work for macOS now? As of now, my iOS app works flawlessly with given API (on iOS 26.2) while macOS app returns isEligibleForAgeFeatures = false and requestAgeRange request always throws AgeRangeService.Error.notAvailable. Also, does it mean that one should not use isEligibleForAgeFeatures boolean while implementing Declared Age Range API for apps below iOS 26.2 (I mean 26.0+)? Or implementing given API for iOS 26.2+ is a sufficient way to go? So shouldn't the whole API be marked as 26.2+? The minimum iOS version in my app is 16.0 and minimum macOS version is 13.0 anyway, so the significant part of users is left out of these updates, but the main goal here is legal compliance.

Original discussion pre iOS 26 Our app uses Auth0 with HTTPS callback, we've found the issue where AASA file is not ready immediately when app is initially launched, which is the exact issue from the above link. The issue seems mostly fixed on later versions on iOS 18, however, we are seeing some indications of a regression on iOS 26. Here's some measurement over the last week. | Platform | iOS 18 | iOS 26 | |---------------|----------|--------| | Adoption rate | 55% | 45% | | Issue seen | 1 | 5 | | Recover? | Yes | No | This only 1 iOS 18 instance was able to recover after 1 second after the first try, however, all iOS 26 instances were not able to recover in couple tens of seconds and less than 1 minute, the user eventually gave up. Is there a way to force app to update AASA file? Are there some iOS setting (like using a VPN) that could potentially downgrade the AASA fetch? Related Auth0 discussion: https://community.auth0.com/t/ios-application-not- recognizing-auth0-associated-domain/134847/27

I'm developing a VoIP app. Currently, I'm using CallKit to control call acceptance, and end-of-call processing. When a call comes in while using the phone, CallKit appears as a banner at the top of the screen. When I click "Accept" on the banner, the app opens and the call is received. (For OEMs, clicking the "Accept" button in the banner will accept the call as is.) The reason this feature is needed is, for example, when a call comes in as a banner call while using a navigation app, accepting the call causes the navigation app to go to the back and the VoIP app to come to the foreground, causing inconvenience to customers. This needs to be improved. Please advise.

I am trying to port my sandboxed macOS app completely over to iOS using a Catalyst target and SwiftUI. There appears to be an issue when trying to drag to the Finder in Catalyst (and in SwiftUI in General). For some reason, the Finder will not accept multiple file drops, only a single file. On my macOS (non-Catalyst AppKit target), I overcame this by dropping multiple files to a UTType of .folder, and the OS accepted the folder. This workaround is not available for iOS because .folder is a macOS-only option. I have a test app to illustrate the issue. Hopefully someone can help. Download Test App

AgeRangeService is the burning topic right now. Needless to say, Everything is so unclear. We got our app finally into the TestFlight for QA and the product to test. only to find out that AgeAssurance for sandbox testing does not work. There is no document confirming or denying whether and when age assurance for the App with the release configuration in test flight would work. There isn't any guidance from Apple on whether an app that sells physical goods, such as an e-commerce app, can continue doing business as usual. Also, there is no clarity that the Age assurance options are off, 13, unverified, 13 verified, and so on. How those should be used.

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

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