If it's GPL, then fix it. That's literally the whole idea.

Can you clarify the warning? Does it say the app was downloaded from the internet and no malware was found? Or does it say something worse? If this is an app downloaded from the internet, then it's going to say it was downloaded from the internet. No way around that unless you want to put it in the Mac App Store. If it is just an app, then there is no reason to put it inside a DMG. Just compress it into a zip file. I have no idea what you mean by "complete codesigning using the third-party app itself—not via command-line scripts". Are you saying that you didn't use Xcode to build the app? If so, then you're on your own. You are totally at the mercy of whatever tool you are using to build the app. These things are a single button click in Xcode.

Don't use the "Comments" feature. Just add a new Reply to the end. Unfortunately, everyone already assumed you were using SwiftUI. You need to show the actual code.

Does it matter? Suppose you publish app with the iOS 17 SDK and it's a big hit. But then you find a critical security bug. You have to update the SDK to iOS 18 to submit the fix. But now it won't build. So why not build and test with iOS 18 today and avoid the problem altogether?

It looks like there is a name conflict between a SQLite framework and the latest version of Swift Foundation. They both use the term "Expression", but they are radically different. It sounds like you need to write "SQLite.Expression" instead of just "Expression". That should fix it. See https://github.com/stephencelis/SQLite.swift/issues/1269

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.