Who knows where the problem lies with this? How would anyone know? You haven't provided any context. It is pretty common for people not to provide any context in questions like this. There is a good reason for that. On the few occasions that people do supply some context, Apple's rejections seem completely reasonable.

Don't use the "comments" feature here in the forums. It hides your posts. Core Image is designed to be a black box where you don't know the implementation details. The more complex your pipeline, the greater the risk to performance. Generally speaking, think of how you would implement any given Core Image filter. If it seems like it could be implemented on the GPU in a straightforward way, then it probably was. If not, you had better investigate that filter more closely. Review Apple's Core Image documentation for Getting the Best Performance.. These suggestions are more than just general best practice suggestions. I'm sure the reflect the internal limitations of Core Image as well. These suggestions say to "Make sure images don’t exceed CPU and GPU limits", "User[sic] smaller images when possible", and "Avoid unnecessary texture transfers between the CPU and GPU". Sometimes you have to read between the lines. For example, Core Image has image tiling support that violates all of these principles - and is horribly slow as a result.

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.

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.

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'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.

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.

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

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.

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.

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.

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

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.

This is what you would use File Coordination for.

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?