“Visual Studio Maui IOS”

Hello, Thanks for your response. Have you tested this? As I'm fairly sure that's what Numbers is doing. NSMetadataQueryUpdateRemovedItemsKey and NSMetadataQueryDidUpdateNotification which are iCloud Document API, have the following two limitations. Therefore, I believe Numbers uses other methods as well. On iOS, NSMetadataQuery cannot handle files stored in local storage. File changes can only be detected while the app is running. Also, and I should have mentioned this in my previous reply, make sure you're using file coordination for all of this. We found that it is possible to detect deletion of files in local storage while the app is running by using the NSFilePresenter API. However, these APIs unable to detect whether a file was deleted while the app was not running. If there is a better way than checking whether the URL contains “.Trash” to determine whether a file was deleted while the app was not running—like the method used by Numbers.app—we would like to adopt it in our app as well. That sai

To supplement： iOS connecting to iOS log``` default 17:49:12.767874+0800 kernel wlan0:com.apple.p2p: Availability: map 0, channel 6 (20M), timeBmap: 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 ( ff ff ff ff ff ff ff ff ) default 17:49:12.767894+0800 kernel wlan0:com.apple.p2p: Availability: map 1, channel 149 (80M), timeBmap: 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 ( ff ff ff ff ff ff ff ff )

In a threaded comment, @kambala said: right now CI (GH Actions) produces iOS builds as well as the .symbols files (which are generated from dSYM using symbols command), but I upload builds manually from my Mac (this will be changed in the future to upload from CI directly). I can of course also store dSYM as a build artifact, but wondered if it's possible to avoid that and store the minimal amount of artifacts on CI. As I said above, you should be keeping the entire Xcode archive, which includes the original dSYM file for any build that you ship to your customers. There's a few things that underpin this advice, including the ability to symbolicate any crash report coming from the field on any version of your app in active use, but also the ability to export your app for different types of distribution, which can enable some further testing and debugging workflows. I can't speak to the storage details of your particular CI system, but for Xcode Cloud, you are provided with the ability to download the

Where is your app going to be sold? If your app is supposed to be used for those who live in Italy and is sold to people inside and also outside of Italy, then the whole scenario doesn't make sense. I often give them a ZIP archive containing one or more videos because I submit a macOS application that works side by side with its iOS counterpart.

Thank you for the quick response and for the clarification on how iOS enforces AASA validation, that context is very helpful. To answer your question: our cloud-based device testing environment is a third-party device farm that runs automated UI tests against real iOS devices hosted in their infrastructure, BrowserStack. In order to install our app on their devices, their platform re-signs the app using their own provisioning profile, which is where the Associated Domains entitlement is lost. We fully understand that this is a security boundary by design, we are not looking to bypass AASA validation in production. Our concern is specifically scoped to pre-production testing: we need a way to validate our authentication flow end-to-end (including the Universal Link redirect back into the app) in an automated, cloud-hosted environment before shipping to production. Given your confirmation that there is no native provisioning flag to accommodate this, we have a follow-up question: Short of the

Same issue still present in iOS 26.3.1 and iPad OS 26.3.1