Objective-C is not deprecated. It has been effectively cast aside, but the operating system will be built upon it for many years. However, I have heard of better C++ and Swift interoperability on the way. WKNavigationDelegate works fine. I can't guess what problem you are having with it, but it works fine.

Go to your web browser history and find all of the web sites you have used so far. Delete them. Otherwise, I'm not sure what to tell you. There are many support pages for Notarization on the Apple developer site and in these forums. The specific forums that you tagged are absolutely full of great advice and step-by-step examples. Maybe start here? Look for practically any post by "eskimo" regarding notarization. As for what you are doing wrong, I'm afraid it is virtually everything.

I agree with ABeeThatsBusy. You definitely don't want to attempt to do anything like this with Core Data. I don't know what a FileHandleBuffer is. Are you talking about a FileHandle class? Don't ever use that class. It can throw Objective-C exceptions. If you are managing terabytes of data, those would be a regular occurrence. The lowest level C file descriptors can append data to an existing file. Many of Apple's higher-level convenience methods and classes assume that you will have all data in memory and every write will completely replace the existing file. Don't do that.

Are you specifically talking about cache files? Or something else? Apple manages the cache files. Your app wouldn't be able to directly access them. But that WKWebsiteDataStore class should do what you want. But if you are talking about something else, then you have other options. If these are your own files you want to view in a web view, then you could include them in your app's resources and access them from there. Or you could create them in a temporary directory and view them there. You can also generate them entirely in RAM without needing to have any files on disk. Note that Apple may still cache that data to cache files, even if they didn't originally exist on disk.

BBEdit can edit any text file, even text files that are wrapped other containers, like zip file. It sounds like this really isn't a text file and you simply corrupted it. Maybe try a hex editor instead. But if you don't have really good knowledge of the exact format of the file, corruption is probably going to be your only end result.

If you are building the pkg with --sign, then your package is signed. You don't need to sign again. However, you should include the "--timestamp" option. You also have to make sure that the underlying app is properly signed with the hardened runtime and timestamp options.

Both Cmake and Qt are notorious for generating scrambled bundles with novel ways of loading dynamic libraries. Also, you haven't actually said what commands you used to codesign and notarize. Strange as it may seem, people who have trouble with code signing and notarization frequently do their code signing an notarization commands incorrectly.

Apple Script used to be completely forbidden in the Mac App Store. From what I understand, there is some limited usage available with Mail and possibly 3rd party apps. You seem to be doing everything correctly according to my limited understanding of the documentation. However, your console output specifically says "com.apple.systemevents", which would definitely be a forbidden target. Maybe it would work if you tried the scripting bridge directly. Why bother with AppleScript at all anyway? There are lots more convenient ways to communicate between a parent and helper, such as XPC.

What do you mean "login at startup"? Is this for the Mac App Store? You can use a Login Item via the Service Management framework, as described here: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLoginItems.html In the App Store, you do have to give the end user a way to control this behavior.

As long as I've seen notarization problems, I've seen Apple developer support engineers say not to use "--deep". Here is a canonical example from two years ago. Maybe just work on one problem at a time. Does your package install anything other than this app? If it doesn't, then you don't need an installer package. Otherwise, these kinds of problems are endemic to PyInstaller. I recommend you complain to the people making PyInstaller.

A proper macOS app should use frameworks instead of dylibs, and they should be in the Frameworks folder. Plus, macOS already has tcl built into the operating system. I don't know why you would need another one, unless maybe PyInstaller absolutely requires some new feature in TCL 8.6 that doesn't exist in TCL 8.5. It is a bigger question of why anyone in 2022 would even be concerned about incompatibilities with minor version differences in TCL to begin with. According to Wikipedia, "The Tcl programming language was created in the spring of 1988 by John Ousterhout while working at the University of California, Berkeley. Originally 'born out of frustration'...". Do you feel yourself to be "unfrustrated" at this point? Why not just bite the bullet and starting writing real apps with Xcode? Why spend so much of your time and effort because somebody else royally screwed something up? I can guarantee that you'll get far more use and mileage about of SwiftUI running on both iOS and macOS that you will out of TCL, Python, and Qt.

The best solution to this would be one or more XPC Services. Here is Apple documentation on the topic. The XPC services work like a normal method call, but the method runs in a separate process. If it crashes, you can restart. Technically speaking, your parent app could still crash, but trying to deal with that is a path of greatest resistance. You might be able to use a helper app too, but that would involve essentially writing your own XPC architecture. I know XPC works in the Mac App Store. A helper app could add some security/privacy complications, especially for an app like you describe. I think XPC is the way to go. Also, don't forget about alternative ways to accomplish the same thing. You have a cloud backup app. I suppose you want to ensure that it runs on a given schedule. Create a notification to warn the user that the backup hasn't run and schedule it for after the backup should have run. Then, when the backup completes, delete that notification. Repeat forever. Notifications are user-controllable and, therefore, not reliable. But this is still a good fallback idea.

The Notarization is invalid. It passes the initial checks but it is failing the lower-level runtime checks when the software is executed. Usually the problem here is with dynamic libraries. Those cross-platform app-generation tools just can't ever seem to do Notarization properly. They always do unusual things with dynamic libraries. It is now your job to find out what those are. You might be able to just add one of those entitlements to make it work. But in some cases, the problems go deeper than that. You might be able to find an error message if you run Console.app. You just have to be very quick. Click the "start streaming" button and then immediately try to run your app. Don't let it sit there for more than a couple of seconds. Jump back to Console and stop streaming. Then review the log file. If you can do all of this in 10 seconds or so, then you'll only have a few thousand log entries to review. Maybe one of them will tell you where it is failing.

There aren't different lower-level runtime checks being performed between curl vs. a web browser. When you use curl, there are no checks being done at all. Gatekeeper works by having the web browser attach a quarantine flag to the downloaded file. Then, when you double-click a file to run it, the operating system looks for a quarantine flag. If it finds one, it performs a notarization check before, and somewhat during, the launch of the app. Caveat #1: If there is no quarantine flag, nothing gets checked. M1 machines have slightly different behavior. They may require a signature, but this is murky. Caveat #2: There is different behavior depending on if the app is a double-clickable app vs a command line tool. An app may give you one or more dialogs about where the app was downloaded from and whether or not Apple checked it for malware. A command line tool won't display that interface. These cross-platform tools often generate apps that are a mixture of proper apps and command line tools. I admit I am a bit unsure of exactly what transpires when notarization fails. I don't use any of those cross-platform tool builders so any notarization problems are extremely rare and when they do happen, they are extremely easy to find and fix. The problems you encounter will almost always involve dynamic libraries. Entitlement are the solution. The log messages are never going to mention entitlement (i.e. the solution). They are only going to complain about what isn't working. If all else fails, you can just go through the list Hardened Runtime Exceptions and try them one-by-one, or some combination thereof. In your case, the cause could be one or more of the items listed in the "Runtime Exceptions" list.

In what context? iOS or Mac? I think iOS requires you to use WebKit. On the Mac, you can use whatever you can get running.