What do you need these metadata files for? More specifically, do you need these metadata files or do your users? I deal with the same thing with GIS files. In my case, I have some open-source libraries that want to automatically write those metadata files. Obviously that fails in the sandbox. But what I've been able to do is define an alternate location for these sidecar files. In my case, the library already supports a "PROXY_DIR" environment variable for read-only locations. So I just used that. I could have also hacked up the source, but I got lucky. What this means is what when various legacy software bits want to write a sidecar file, it always succeeds. It writes the sidecar file in an appropriate location inside my app's sandbox container. Then when other bits of the legacy software look for the sidecar data, it's there and always available. If I needed to export the sidecar files (which I won't), I could do that by allowing the user to specify an entire output directory and write all necessary files under a pre-determined name.

Has anyone else had this happen to them? I see at least 2-3 identical questions every day. If so what was the resolution? No one ever knows. You would think that with 700-1000 identical questions per year, at least one person would follow up with what happened, but I haven't seen it.

It looks like that was a Google thing originally. After Google abandoned it, Apple didn't want to take it up. Have you tried the standard signature verification APIs? Or various command-line looks like pkgutil, codesign, or spctl?

This is what you would use File Coordination for.

Please help. What would you like us to do? The best that other random developers, who aren't in the EU and/or aren't using the App Store, can do is point you to documentation provided by Apple and make random guesses. From what I understand regarding alternative payment options on the App Store in the European Union, there are two different entitlements. You seem to be trying to avoid one entitlement because you don't like the user experience dictated by the other entitlement. While these two entitlements are related to the same general idea, they aren't both required. You can use just one, the other, or both. The technical documentation on how to use these entitlements seems pretty clear.

They have the same problem on the Apple Support Community. Maybe Apple should test from outside the internal network.

I think that the system doesn't consider an app an actual app until it's launched for the first time. That first launch triggers the verification process and integrates the app with launch services. If you modify the app before then, it would invalidate the signature anyway. See the WWDC 2022 reference in this post. It sounds like apps that use the same developer signature can update each other. They can also allow a specific bundle ID to update via an Info.plist entry. I can't say for sure which method Google is using. I didn't dig into it that much. I despise those auto-updaters. I only keep Chrome around because it makes it easy to change one specific request field for testing multi-language websites. I keep the auto-updater disabled at all times. If I used Brave, I would do the same.

Maybe try to repost your code. It looks like you could be putting the #include behind a comment. When I reformat what you've posted, and remove the pcount() function that was deprecated in the previous century, it works fine.

Maybe you need to do something like "import Supabase" in your SupabaseManager.swift file? I don't think the AI is really helping you. I've never heard of Supabase. Apparently, it's an open source alternative to Firebase. OK, so what's Firebase? Who! That's Google. Full reverse! Is that what's causing that long list of external dependencies in your app? You aren't going to be able to actually learn how to write apps this way. It's too far beyond your current capabilities. It's like trying to teach brain surgery to a toddler. All brain surgeons were once toddlers, but that doesn't mean they did their surgical residencies in preschool.

You'll need to access the main screen via NSScreen and then check the top safeAreaInsets. This will be in screen coordinates, of course.

The FSEvent create flag kFSEventStreamCreateFlagWatchRoot was specifically designed to handle this event. I haven't used this event yet. It doesn't sound like you need to recreate the event stream. The documentation for kFSEventStreamCreateFlagWatchRoot describes how to handle it. It specifically says to open the directory before creating the stream so you have the file descriptor handy.

I'm pretty sure that if Apple thinks your app would be useful in Apple's marketing, they'll be sure to reach out to you.

Are you sure Xcode isn't just locked up? When you hit a breakpoint, or sometimes even step to the next line, it can take a long time before the debug inspector pane is useable. I assume that any operation you do in Xcode during this time is likely to fail. You just have to wait for it. Once the debug inspector pane has its data and is useable, then I expect everything should work. But this can take anywhere from 3 to 30+ seconds, even on a fast machine.

I've heard that these kinds of images encoded into smart cards use a jpeg2000 code stream, which apparently Apple's built-in JPEG2000 logic either doesn't support or doesn't expose in existing image-based and PDF APIs. You will probably have to use a 3rd party framework like OpenJPEG to get access to lower-level decoding routines.

I think my biggest bottleneck is needing to process a ProRAW image immediately after capture which seems a few seconds to even start the image processing. That doesn't sound like it has anything to do with Core Image. That sounds like more of a threading or concurrency problem. When I talked about Core Image hitting the CPU resulting in "horribly slow" performance, I was talking about a reduction in frames per second, not seconds per frame.