“file uri scheme”

I had filed FB22239913 which is still open. My eMail ticket for Developer Support also was not actioned. Eventually I ran out of patience and called developer support instead. The agent was able to identify the issue quickly (something specific about your account, nothing you can do anything about). They escalated it and it was resolved within 48h.

actually i would like to delete this post. turns out xcode always generates the file with the column before the : but a script of mine that pulls translations regenerates the file without the spaces before the : and then when i make a change in xcode, this dif happens. Im sorry for the confusion.

Update: After inspecting all provisioning profiles on our system, we found that: Profiles generated for development and Developer ID distribution contain content-filter-provider Profiles generated via Direct Distribution contain only packet-tunnel-provider-systemextension and app-proxy-provider-systemextension No profile contains content-filter-provider-systemextension When we set content-filter-provider-systemextension in the entitlements file (matching Little Snitch's configuration), Xcode rejects all available profiles with a mismatch error. This means the Developer Portal does not appear to generate provisioning profiles with content-filter-provider-systemextension for content filter system extensions. Is this a portal issue, or is there a different provisioning mechanism required?

[quote='820080021, nixx, /thread/820080, /profile/nixx'] I have submitted this via Feedback Assistant (FB22312299). [/quote] Thanks. I’m not sure what’s going on here, but it’s clearly a regression and thus warrants a bug report. Having said that, there’s a long-standing gotcha you need took out for. Using non-ASCII names for pure data should be fine, but you have to be careful when using non-ASCII names for files within a code-signed bundle. There’s a long-standing problem with that, as explained in this post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

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

I can actually reproduce that quite easily. But my biggest concern so far are other issues which makes me wondering if fskit is of production quality and should I continue making a fuse bridge with it. I got a couple of kernel panics while developing a new plugin. Can send logs if needed. With the passthrough fs: git clone which I usually use for filesystem validation and testing doesn't work: git clone https://github.com/arthenica/ffmpeg-kit.git Cloning into 'ffmpeg-kit'... remote: Enumerating objects: 11760, done. fatal: Unable to create temporary file '/Users/alexf/333/ffmpeg-kit/.git/objects/pack/tmp_pack_XXXXXX': Permission denied fatal: fetch-pack: invalid index-pack output With the passthrough fs: Recursive rm doesn't work either rm -rf ffmpeg-kit rm: ffmpeg-kit/docs/apple/html: Directory not empty rm: ffmpeg-kit/docs/apple: Directory not empty rm: ffmpeg-kit/docs/linux/html: Directory not empty rm: ffmpeg-kit/docs/linux: Directory not empty rm: ffmpeg-kit/docs/android/doc/html: Directory not

Hi Kevin, Thank you for the detailed guidance. As you suggested, I have filed a bug report via Feedback Assistant regarding the migration path from legacy KEXT power management to DriverKit. I have included our legacy initialization logic and the specific technical contradictions we encountered during the transition. Feedback ID: FB22320055 Regarding your comment on calling super: You were absolutely correct. Failing to invoke super::SetPowerState(powerFlags, SUPERDISPATCH) was indeed the cause of the missed RPC ACK, which triggered the 21-second watchdog panic. Implementing that call as the final step in my SetPowerState_Impl has resolved the immediate panic issue. We have since stabilized the driver's lifecycle and deactivation logic. We would greatly appreciate it if you could follow up on the Feedback report to help clarify the canonical resource management boundaries for complex storage drivers in DriverKit. Best Regards, Charles

Hey @drewolbrich, Thank you for filing all of these reports! Having each issue tracked separately is really helpful for our investigations. In terms of workarounds, your suggestions sound reasonable, but I don't have specific workarounds to recommend at this time. If you find anything else that helps you avoid the issue, please share it with the community here. For others encountering similar issues: Even though we're aware of this issue, we still encourage you to open a bug report, and post the FB number here once you do. The specific info you include in your bug report might help our investigation, and filing the bug report allows you to get notified when it is resolved. Bug Reporting: How and Why? Thanks, Michael

Hey @drewolbrich, Thanks for filing this feedback. I wasn't able to replicate your experience, but I'm curious if you get the same result by replacing opacity(_:) with OpacityComponent? Additionally, have you considered applying a subtle breakthrough effect on your views? This might mitigate the issue and could improve things if you expect your views to collide your content. Are you able to replicate this behavior in a sample project that we could take a look at? Feel free to link it publicly here, or you can privately share any project with us in your Feedback Request. That'll help us better understand what's going on. If you're not familiar with preparing a test project, take a look at Creating a test project. Thanks, Michael

Since adopting a newer AppStoreConnect API OpenAPI spec, the trailing '/' in the server was added back; this was something I manually patched last summer. Without the patch to remove the trailing '/', when used with the Swift OpenAPI Generator, a URL with two slashes is produced which was invalid against the SCOPE of the token evidently. Notice .com//v1 and the double slash. https://api.appstoreconnect.apple.com//v1/apps/1672441148/perfPowerMetrics There is nothing wrong with the App Store Connect API itself other than perhaps the scope should honor two slashes since the spec declares it? I submitted a feedback for this last summer to have the Apple minted OpenAPI spec remove the trailing slash in the server url. FB18389250 - AppStoreConnect API: OpenAPI spec file has a server trailing '/' which results in Swift OpenAPI Generator code to have paths with two slashes unexpectedly

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 down

I opened one last week. Case-ID: 18860388 I don't think that’s a valid bug number. Details on the bug filing process are here, and the numbers are prefixed FB. Again, please upload the full spintrace to that bug and then post the bug number back here. It definitely revised (well, APFS), that's holding the lock. Sure, but the question is why, not who. Causes this kind of hang are the interactions between multiple locks and multiple processes. It's hard to pick up unless you're looking at the full log and know what you're looking for, but the basic form is that there are two locks: The outer lock, which the blocking thread (in this case, thread 0xc0616d) is inside and holding. The inner lock, which the blocking thread (thread 0xc0616d) is stuck waiting on. You can actually see this dynamic in the traces you sent. This lock is an APFS-owned lock: *940 apfs_vnop_getattr + 312 (apfs + 604336) [0xfffffe000beacff0] *940 IORWLockRead + 144 (kernel.release.t6000 + 496568) [0xfffffe00088e53b8] And, unsurprisin

There is potentially one detail I jumped over that is relevant — are you expecting clients of your library to build from source, or to consume a pre-compiled library? I had assumed it was a pre-compiled library based on the .a file mention. I think that's accurate, but it would be good to confirm that. If the library is intended to be a pre-compiled asset, then what you'd deliver to the client is an XCFramework. This is meant to be a single container that has everything a library client needs — copies of a built binary for each platform and simulator your library supports, plus the header files. While you can hand your clients the XCFramework so they can drag-and-drop it in their Xcode project, one nice vehicle you can use for distribution is a Swift package, which will point to a compressed (zipped) copy of the XCFramework, along with a checksum for verifying its integrity. This way, it's easy to ship updates of the library to your clients. Distributing binary frameworks as Swift packages h