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!

On the macOS platform, I am planning to use the combination of NSFileProviders Custom Action and userInfo to implement custom context menus. However, the NSExtensions FileProviders Action Activation Rule in info does not work as long as it is related to userInfo. Are there any restrictions on the use of this userInfo? keepDownloaded is bool value

I've been trying to follow Apple's testing age assurance documentation here. After following each step and setting my user as "Texas, child 16-17, significant change declined", the AgeRangeService consistently throws the notAvailable error: do { let response = try await AgeRangeService .shared.requestAgeRange(ageGates: 18, in: self) // ... } catch AgeRangeService.Error.notAvailable { // Always throws this error }

Install both Motiv Audio and Motiv Video apps from the App Store. Open and use the Motiv Audio app. Remove audio app from background. Open Motiv Video app. Observe that the Motiv Audio app crashes. Both apps are checking Free available space. Both app are using Audio Engine

How do I set a custom icon for an app control that appears in Control Shortcuts (swipe down from iOS) ? Where is the documentation for size and where to put the image, format etc? Thank you. Working Code (sfsymbol) import Foundation import AppIntents import SwiftUI import WidgetKit // MARK: - Open App Control @available(iOS 18.0, *) struct OpenAppControl: ControlWidget { let kind: String = "OpenAppControl" var body: some ControlWidgetConfiguration { StaticControlConfiguration(kind: kind, content: { ControlWidgetButton(action: OpenAppIntent()) { Label("Open The App", systemImage: "clock.fill") } } }) .displayName("Open The App") // This appears in the shortcuts view } } Sample Image These apps use their own image. How can I use my own image?

Hey there, We are being incorrectly blocked by Time Limits since the iOS 26 update released earlier this year. We are receiving complaints from parents that set a screentime limit for "All apps", and then add an exception for us, that they are still getting blocked by the OS after a certain period of time. While we originally thought this was fixed in 26.1, we have recently been made aware it still occurs. Has anyone else experienced this issue? Is there something we can do from our side to protect ourselves from this? Telling customers to remove their "All app" limit isn't really practical given our customer base, so we're looking to see if there's something on Apple's end or our end that can alleviate this.

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.

Is there any way of creating complete Shortcuts automations and bundling them with my app? Specifically, I would like the user to be able to Take a photo and open it with my app Or take a screenshot and open it with my app Of course I could offer a Share extension, but going through the Share menu and selecting my app there is time consuming for the user. I would like the user to be able to configure his or her action button such that it takes a new picture and opens it with my app right away. I can, of course, offer the respective App Shortcuts and let the user combine them into a pipeline with the Take Screenshot or Take Photo system actions. However, only power users would do this. Hence, I would like to bundle this complete pipeline with my app, such that the user just has to assign his/her Action Button to this pipeline if he/she wants to use this feature. How to go about this? I was thinking of exporting the shortcut into a file, bundling it with the app as a resource, and offering it via a Share action for the user to install it, or by sharing it on iCloud and adding the iCloud link to the UI of my app. What is the recommended approach?

Hi all, I’m trying to understand SwiftData’s runtime semantics around optional to-many relationships, especially in the context of CloudKit-backed models. I ran into behavior that surprised me, and I’d like to confirm whether this is intended design or a potential issue / undocumented behavior. Minimal example import SwiftUI import SwiftData @Model class Node { var children: [Node]? = nil var parent: Node? = nil init(children: [Node]? = nil, parent: Node? = nil) { self.children = children self.parent = parent print(self.children == nil) } } struct ContentView: View { var body: some View { Button("Create") { _ = Node(children: nil) } } } Observed behavior If @Model is not used, children == nil prints true as expected. If @Model is used, children == nil prints false. Inspecting the macro expansion, it appears SwiftData initializes relationship storage using backing data placeholders and normalizes to-many relationships into empty collections at runtime, even when declared as optional. CloudKit context From the SwiftData + CloudKit documentation: “The iCloud servers don’t guarantee atomic processing of relationship changes, so CloudKit requires all relationships to be optional.” Because of this, modeling relationships as optional is required when syncing with CloudKit, even for to-many relationships. This is why I’m hesitant to simply switch the model to a non-optional [Node] = [], even though that would match the observed runtime behavior. Questions Is it intentional that optional to-many relationships in SwiftData are never nil at runtime, and instead materialize as empty collections? If so, is Optional<[Model]> effectively treated as [Model] for runtime access, despite being required for CloudKit compatibility? Is the defaultValue: nil in the generated Schema.PropertyMetadata intended only for schema/migration purposes rather than representing a possible runtime state? Is there a recommended modeling pattern for CloudKit-backed SwiftData models where relationships must be optional, but runtime semantics behave as non-optional? I’m mainly looking to ensure I’m aligning with SwiftData’s intended design and not relying on behavior that could change or break with CloudKit sync. Thanks in advance for any clarification!

I'm having problems constructing the initial stack for the guest executable for Valgrind on macOS 12 Intel. This seemed to work OK for macOS 11 but I'm getting a bad 'apple' pointer on macOS 12. The stack (constructed by Valgrind) looks like this higher address +-----------------+ <- clstack_end | | : string table : | | +-----------------+ | NULL | +-----------------+ | executable_path | (first arg to execve()) +-----------------+ | NULL | - - | envp | +-----------------+ | NULL | - - | argv | +-----------------+ | argc | +-----------------+ | mach_header * | (dynamic only) lower address +-----------------+ <- sp | undefined | : : The problem that I'm having is with the executable path (or the apple pointer). This points to NULL. The actual pointer to the "executable=xxx" string is 16 bytes lower in memory. The code for main starts with Dump of assembler code for function main: 0x0000000100003a90 <+0>: push %rbp 0x0000000100003a91 <+1>: mov %rsp,%rbp 0x0000000100003a94 <+4>: sub $0x60,%rsp 0x0000000100003a98 <+8>: movl $0x0,-0x4(%rbp) 0x0000000100003a9f <+15>: mov %edi,-0x8(%rbp) 0x0000000100003aa2 <+18>: mov %rsi,-0x10(%rbp) 0x0000000100003aa6 <+22>: mov %rdx,-0x18(%rbp) 0x0000000100003aaa <+26>: mov %rcx,-0x20(%rbp) That's the prefix, making space for locals, setting a local variable to 0 then getting the 4 arguments from main in edi, rsi, rdx and rcx as per the SYSV amd64 ABI. I think that it is dyld that puts the apple pointer into rcx. Can anyone tall me how dyld works out the address of the apple pointer?

NWPathMonitor appears to retain itself (or is retained by some internal infrastructure) once it has been started until cancelled. This seems like it can lead to memory leaks if the references to to the monitor are dropped. Is this behavior documented anywhere? func nwpm_self_retain() { weak var weakRef: NWPathMonitor? autoreleasepool { let monitor: NWPathMonitor = NWPathMonitor() weakRef = monitor monitor.start(queue: .main) // monitor.cancel() // assertion fails unless this is called } assert(weakRef == nil) } nwpm_self_retain()

I'm building a photo editing app with a token-based subscription system using RevenueCat and StoreKit. Users purchase subscriptions that grant tokens for AI generations. There are no user accounts, the app is fully anonymous. Currently, I generate an anonymous account ID via RevenueCat SDK and store it in iCloud Keychain. This allows users on the same iCloud account to restore both their subscription and token balance across devices. However, users on a different iCloud account can restore their subscription via Apple, but their token balance is lost because there's no way to link the anonymous IDs. The problem is that if a user switches iCloud accounts or gets a new device without the same iCloud, their purchased tokens are orphaned. The subscription restores fine through Apple, but the token balance tied to the old anonymous ID becomes inaccessible. I have a few constraints: no user accounts, no email or phone sign-in, must work across devices owned by the same person, and must comply with App Store guidelines. My questions are: Is iCloud Keychain the right tool for this, or is there a better approach? Would CloudKit with an anonymous record zone be more appropriate? Are there any recommended patterns for persisting consumable balances tied to anonymous users across device migrations? Any guidance would be appreciated.

Currently, I have implemented local cache update with server data when app is killed using Push Notification and Notification Service Extension. So it works even the app is killed by the user, but I wanted to know whether this is app review safe work around or not as I am not finding any documentation for this.

Need to vent a bit before relaxing for Christmas... WatchOS IAP using Storekit 2 is such a mess...is nobody actually using this or does Apple just not care for the user experience here? Lots of users experience after the purchase confirmation double tap on the side button an instant return to the purchase screen with nothing actually happening. No error message whatsoever. There is just one remedy: users need to unpair and re-pair their watch, including restoring a backup and setting up their wallet again. Nobody really wants to do this, or doesn't believe me and think this is just typical support BS, because their watch is paired and most things just work as they expect. And it turns away a customer, often leaving a bad review. And I can't do anything about it. Other errors in the purchase process are reported, but like "process interrupted" in case the payment is not setup correctly (credit car no longer valid or sth.). How should the user know? There must be better ways of letting him know what exactly the problem is. You need to implement a "Restore Purchase" function, otherwise you're not passing the review. But it really asks every time for the AppStore password, and users with crazy passwords -- that they rightfully should have! -- have almost no chance of typing them successfully on the tiny AW keyboard. Why is it not also just a side button double tap like for purchase? At the very least you would need access to the keychain PWs or allow pasting of sth. copied on the paired iPhone. Promo Codes for IAP on AW-only apps just don't work. AW has no redemption at all, and on the iPhone the AppStore will try to talk to a companion app (which AW-only doesn't have) and the end up in a dead-end installation effort. This all feels like never really tested in the field, and people are of course blaming the 3rd party dev. for all these issues. And opening a ticket is just leading nowhere -- at best it's closed after months with the hint "duplicate" but w/o any chance for me to see that one that they then actually work on and track progress. It's all so frustratingly broken...

I'm trying to debug an issue with the Valgrind tool Helgrind. This is on masOS 11 (I've also seen it on 12, probably the same for other macOS versions). Here is the testcase. #include <pthread.h> #include <string.h> #include <assert.h> #include <errno.h> int main(void) { pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; pthread_cond_t cond = PTHREAD_COND_INITIALIZER; int res; // This time has most definitely passed already. (Epoch) struct timespec now; memset(&now, 0, sizeof(now)); res = pthread_mutex_lock(&mutex); assert(res == 0); res = pthread_cond_timedwait(&cond, &mutex, &now); assert(res == ETIMEDOUT); res = pthread_mutex_unlock(&mutex); assert(res == 0); res = pthread_mutex_destroy(&mutex); assert(res == 0); res = pthread_cond_destroy(&cond); assert(res == 0); } The error that I'm getting from Helgrind is ==56754== Thread #1 unlocked a not-locked lock at 0x1048C7A08 ==56754== at 0x10020E2F9: mutex_unlock_WRK (hg_intercepts.c:1255) ==56754== by 0x10020E278: pthread_mutex_unlock (hg_intercepts.c:1278) ==56754== by 0x7FF80F526813: _pthread_cond_wait (in /usr/lib/system/libsystem_pthread.dylib) ==56754== by 0x10020E812: pthread_cond_timedwait_WRK (hg_intercepts.c:1465) ==56754== by 0x10020E6A8: pthread_cond_timedwait (hg_intercepts.c:1512) ==56754== by 0x100003DD2: main (cond_timedwait_test.c:18) ==56754== Lock at 0x1048C7A08 was first observed ==56754== at 0x10020DE91: mutex_lock_WRK (hg_intercepts.c:1009) ==56754== by 0x10020DD68: pthread_mutex_lock (hg_intercepts.c:1031) ==56754== by 0x100003D7D: main (cond_timedwait_test.c:16) ==56754== Address 0x1048c7a08 is on thread #1's stack ==56754== in frame #5, created by main (cond_timedwait_test.c:7) If I turn on extra tracing then on FreeBSD the Helgrind pthread traces correspond to the C source. On macOS I see an extra mutex. << pthread_mxlock 0x7ff850c41 :: mxlock -> 0 >> << pthread_mxunlk 0x7ff850c41 :: mxunlk -> 0 >> ^^ I don't know what this mutex is << pthread_mxlock 0x1048c7a08 :: mxlock -> 0 >> ^^ this is the user mutex << pthread_mxlock 0x7ff850c41 :: mxlock -> 0 >> << pthread_cond_timedwait 0x1048c79d8 0x1048c7a08 0x1048c79c0<< pthread_mxunlk 0x7ff850c41 :: mxunlk -> 0 >> ^^ pthread_cond_timedwait unlocking the non-user mutex << pthread_mxlock 0x7ff850c41 :: mxlock -> 0 >> << pthread_mxunlk 0x7ff850c41 :: mxunlk -> 0 >> << pthread_mxunlk 0x1048c7a08 [error here] :: mxunlk -> 0 >> << pthread_mxlock 0x1048c7a08 :: mxlock -> 0 >> << pthread_mxlock 0x7ff850c41 :: mxlock -> 0 >> cotimedwait -> 60 >> In these traces the "-> 0" is the return code, showing that all of the calls succeeded. I need to do more debugging inside Helgrind. In the traces above I only see the user mutex being locked and then unlocked. Can anyone explain why I'm seeing an extra mutex in there? I'll have a poke around the XNU source

On macOS Tahoe, our application using the Endpoint Security Framework (ESF) observes that during file copies through finder application, DesktopServicesHelper unlinks the source file if the ESF authorization response is delayed for ~5 seconds, even though the authorization event deadline remains 15 seconds, indicating that the process does not wait for the full ESF deadline before deleting the file. Before Tahoe, we didnt see this behaviour.

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

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.

Hi, I am building an app that depends on multiple iOS devices connecting to a designated "coordinator" iOS device. I am using MPC, and it works great when the devices are connected to the same WiFi AP, with virtually 100% connection success. My definition of success is a near instant detection of available devices, >95% connection success rate, and a stable ongoing connection with no unexpected disconnects. The issue arises when the devices are not connected to the same WiFi network (or connected to no network with WiFi and bluetooth still on). Devices detect each other immediately, but when initiating a connection, both devices initiate a handshake, but the connection is not successful. In the few times where the connection succeeds, the connection quality is high, stable, and doesn't drop. Is this a known limitation of the framework? Could I be doing something wrong in my implementation?

When trying to use the MIDI Maestro app by Singular Sound, BLE peripherals experience unwanted connection-parameter renegotiation and disconnections on iOS 26, beta iOS 26.2 does not fix this issue. iOS 26 BLE communications are being sent too fast to be read correctly by the hardware device, and iOS 26.2 refuses communication altogether.