“file uri scheme”

That message corresponds to errSecCSInvalidObjectRef (-67071). That’s an obscure one. I’ve been supporting Mac coded signing for almost a decade and I’ve never seen it before. Well done! [quote='818406021, hasii2021, /thread/818406, /profile/hasii2021'] Can't figure out how to post the log file. [/quote] You can post log files as text attachments. I have info on how to do that in Posting a Crash Report. Its focus is on crash reports, but the process for posting a text attachment is the same in both cases. However, the notary log is unlikely to help here because, as you say, the app notarises successfully. Rather, this is a code signing error on your local Mac. [quote='818406021, hasii2021, /thread/818406, /profile/hasii2021'] when I try to verify the signature I get the above error. [/quote] How are you doing that? Normally I’d verify a signature like so: % codesign -v --deep --strict /path/to/my.app Is that what you’re doing? As to the potential causes of errSecCSInvalidObjectRef, there are

My general approach for problems like this is to set up a VM that’s never seen my product before and then use that VM to test various user-level sequences. For example, I might install version N of the app, check that screen capture works, then install version N+1, and then check that it continues to work. The advantage of doing this on a VM is that you’re starting from a fresh machine and you can save and restore snapshots for your various tests. If your product passes those tests, and thus works in general, this becomes a question of what’s happening on specific user machines to cause the reported issue? That’s a much harder question to answer. macOS has lots of flexibility — with the user able to install and remove apps at will, install multiple copies of your app, and so on — and that flexibility causes serious challenges for TCC. There’s no easy way to map from specific symptoms back to the root cause. However, it’s unlikely to be your app’s issue. I mean, there’s nothing you can do at the code level to

Hello SuneethaR, Apologies, the tintColor of a view controller's tab bar item refers to the color of its title and image, not the grey background that appears when an item is highlighted through selection. There's no supported way for you to customize it with the APIs currently available. If you'd like us to consider adding the necessary functionality, please file an enhancement request using Feedback Assistant. Once you file the request, please post the FB number here. If you're not familiar with how to file enhancement requests, take a look at Bug Reporting: How and Why? We also recommend you move away from the Appearance APIs and reduce your use of custom backgrounds when customizing navigation elements. Let me know if you'd like to know more, Richard Yeh  Developer Technical Support

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