“file uri scheme”

OK, I've successfully changed the app group to iOS style (group.com.myorg.MyApp)... and it hasn't fixed the problem. It's working on older versions, but still failing on Sequoia. To confirm: Both the main app and extension have an explicit app ID (com.myorg.MyApp and com.myorg.MyApp.EMPFileProvider, respectively). I have added an App Group identifier on the website for group.com.myorg.MyApp -- the website won't let me add one in the old macOS format (I understand this is normal). On the website, in the Identifier entry for each component, I've added group.com.myorg.MyApp to the existing App Group set. This has required me to re-generate the provisioning profiles. On the Profiles page, I regenerated the profiles (by choosing Edit and then Save rather than deleting and re-creating them). I downloaded and installed the new profiles. The resulting app works fine on a pre-Sequoia machine. But on the Sequoia one, the main app runs successfully (and can log to the Group Container), and the FileProvider also runs, bu

I forgot to mention that I also added TestClass as an @class in the .h file: @class SSPMasterViewController,iMag,TestClass;

Thanks for reporting the issue. The error indicates that HealthKit lost the cached data source information, which is an implementation detail inside the framework. Do you have a feedback report yet? If not, would you mind to file one with a sysdiagnose, and share your report ID here? You can following the instruction here to install the profile and capture a sysdiagnose from a device that reproduces the issue. Best, —— Ziqiao Chen  Worldwide Developer Relations.

Thanks for filing the feedback report. Is this issue the same as the one discussed here? Best, —— Ziqiao Chen  Worldwide Developer Relations.

That part of the copyfile man page is unfortunately somewhat poorly worded; further down it does clarify that: Note that recursive cloning is also supported with the COPYFILE_CLONE flag (but not the COPYFILE_CLONE_FORCE flag). A recursive clone operation invokes copyfile() with COPYFILE_CLONE on every entry found in the source file-system object. Because copyfile() does not allow the cloning of directories, a recursive clone will instead copy any directory it finds (while cloning its contents). As symbolic links may point to directories, they are not followed during recursive clones even if the source is a symbolic link. Additionally, because the COPYFILE_CLONE flag implies the COPYFILE_EXCL flag, recursive clones require a nonexistent destination. So yes, you can use copyfile(3) to recursively clone directories. You should not use clonefile(2) for that purpose.

Thanks for sharing more information. Even without SwiftUI, addRenderingAttribute + invalidateLayout doesn't refresh the text view (NSTextView) either (though the text view does refresh with the right rendering attribute after I resize the app window), which I believe is worth a feedback report, and would suggest that you file one and share your report ID here. Before the issue is addressed, a workaround I can see is to use display attributes for that purpose – When loading the the text storage, UI/NSTextView calls textContentStorage(_:textParagraphWith:), and you can implement the method to set up display attributes for the text coloring, and return an appropriate NSTextParagraph, as shown in the following code example: extension ViewController: NSTextContentStorageDelegate { func textContentStorage(_ textContentStorage: NSTextContentStorage, textParagraphWith range: NSRange) -> NSTextParagraph? { let paragraphText = textContentStorage.textStorage!.attributedSubstring(from: range) let paragraphStr

Thanks. I’ll collect the Core Device logs from both macOS and iOS, file a Feedback Assistant report with the attached logs, and post the FB number here once submitted.

I have the same issue. I reinstalled the Application, checked all Targets , Unadded and added my Dev Profil, turned Devmode on and off on my iPhone, deleted Derivated Files . cleaned the Project and tried it with Wifi Off+Cellular. I personally thing its due to a malfunction of a server. The appllications all work on the Simulator

Update: For local hosting using the Claude agent, Unsloth recommends adding CLAUDE_CODE_ATTRIBUTION_HEADER : 0 to the env section of your settings.json file. The default behavior can frequently invalidate the session KV cache, causing expensive prompt reprocessing (depending on your inference engine). Example: { promptSuggestionEnabled: false, env: { CLAUDE_CODE_ENABLE_TELEMETRY: 0, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC: 1, CLAUDE_CODE_ATTRIBUTION_HEADER : 0 }, attribution: { commit: , pr: }, plansDirectory : ./plans, prefersReducedMotion : true, terminalProgressBarEnabled : false, effortLevel : high }

Same error, for ~2hrs now. But curl returns successful, confusingly. curl -v https://ppq.apple.com Host ppq.apple.com:443 was resolved. IPv6: (none) IPv4: 17.33.192.136, 17.33.193.105, 17.33.194.109 Trying 17.33.192.136:443... Connected to ppq.apple.com (17.33.192.136) port 443 ALPN: curl offers h2,http/1.1 (304) (OUT), TLS handshake, Client hello (1): CAfile: /Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/site-packages/certifi/cacert.pem CApath: none (304) (IN), TLS handshake, Server hello (2): (304) (IN), TLS handshake, Unknown (8): (304) (IN), TLS handshake, Certificate (11): (304) (IN), TLS handshake, CERT verify (15): (304) (IN), TLS handshake, Finished (20): (304) (OUT), TLS handshake, Finished (20): SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF ALPN: server accepted h2 Server certificate: subject: CN=ppq.apple.com; O=Apple Inc.; ST=California; C=US start date: Jan 21 17:47:41 2026 GMT expire date: Feb 17 18:28:16 2027 GMT subjectAltName: host ppq.apple.com m

Perhaps I didn't explain myself well. I wasn't making assumptions about how the the APIs operate - the only thing I was claiming (well trying to) was that paths provide the concept of file location and in certain contexts that concept matters to GUI apps (with the NSBrowser example being an obvious one). Sure. And, to be clear, I don't mean that paths don't EVER have a place and/or aren't a good solution. However, I do think those use case are more limited then they seem and that most interactions with files are better handled through object references (which are tied to a specific file system object), NOT paths (which describe a location in the hierarchy). Our APIs don't do a very good job of expressing that idea, but APIs like reference URLs and bookmarks are actually object reference APIs, not just weird ways of storing paths. Very interesting. Yeah I use that (watch root) With the watch root flag set it does seem to just track whatever is at the path. Ahh... Yes, you're right. I

This has been happening an awful lot for me lately as well. Here's an example error message: + rustup show Default host: x86_64-apple-darwin rustup home: /Users/local/.rustup info: syncing channel updates for 'stable-x86_64-apple-darwin' error: failed to download file error=Reqwest(reqwest::Error { kind: Request, url: https://static.rust-lang.org/dist/channel-rust-stable.toml.sha256, source: hyper_util::client::legacy::Error(Connect, ConnectError(dns error, Custom { kind: Uncategorized, error: failed to lookup address information: nodename nor servname provided, or not known })) }) To debug I've tried hitting that same URL from Xcode Cloud using curl as well and get a similar DNS error, so it seems the error is with the Xcode Cloud DNS setup rather than rustup

Thanks for the reply Quinn. We've spent the time looking into the options you suggested. Am I right in assessing that each needs some level of code modification of the app under test? We're reluctant to add test hooks that would end up in released product, esp networking code, because this app is a medical device that already has FDA trial approval based on SBOM documentation showing no networking libraries (and thus a low cybersecurity risk rating), and no operating differences between tested and released .ipa files. Modifying the iPad's environment is kosher which is why the helper app was helpful.