If you are having problems with Catalina, you should probably post a question in Apple Support Communities. This is a developer forum. The rules and expectations are different here.

I'm not sure about Apple policies for restricted apps like that. It may not fly with Apple just due to that.However, it would be trivial to setup a "new user" group that a reviewer would initially join. It would have only publicly-available contact information for corporate HR. Maybe spin it as an HR gateway. Once you get hired, you have more access. I don't know how much detail App Review would go, but again, I think you could have problems. Your distribution choice is irrelevent. Apple will treat it as a public app. So if there is any user-generated content, like messages or blog posts, for example, you will need to demonstrate a complete moderation system for it. And if there are any other app review critiera that apply to public apps that would not be applicable in your private one, you get rejected.

So why not just manually call your cleanup code when you close the channel? Then let the cleanup handle anything that is remaining for the file descriptor. I got confused not when it was working, but when it came time to deal with errors.

Am I doing something wrong here?I can't answer that. All I can do is relate my own experiences with this API. To make a long story short, I found that there were so many different possible flows of execution that I felt that I had no real understanding of how to use the API. The documentation is very light and contradictory. For example, you found that you could only get the cleanup handler to execute if you called close() on the underlying file description. But one thing the documentation explicity says is "it is an error for your application to modify the file descriptor directly."One thing I suggest is to look at the headers. There is often much better documentation there. My dispatch IO code kept spiraling more and more out of control, getting more and more complicated. My ultimate decision was to abandon dispatch IO completely. Instead, I use old-school select(). It is conceptually a very small and simple API. I'm confident that I am able to handle all potential flows of execution. I have complete control over the data stream and the underlying file description. No, it's not pretty. No, it's not fancy. Maybe it is not very efficient. But it works reliably.

A sandboxed app can definitely control another app. However, the other app has to be designed for that. What framework are you using? What does the developer of the framework say when you ask them about this problem?On a more fundamental level, why are you even sandboxing? Do you plan to release this app in the Mac App Store? It requires Accessibility and Full Disk Access? Sorry, but that's dead on arrival.On an even more fundamental level, why are you doing this at all? Have you been following macOS developments over the past few years? I suggest coming up with a different idea for an app that would work on iOS. Such an app would be easy to port to macOS in the Mac App Store.

Yes, my first post that you replied to contained excerpts from all of the relevant parts of Console's output that I could find. Unfortunately it didn't give me any clues.It's just a suggestion. I tried it once on a problem virtually identicaly to what you describe in this same forum. I found the problem right away in Console. Did I mention how messed up Console is. I'm used to dealing with it. If you aren't familiar with it, you might miss that one significant line in the 10,000 irrelevent ones generated during that 6 second test.I'm using those tools as documented by Apple and they're failing to produce software that works in macOS 10.15.5Someone should come up with an aphorism about a worker blaming his tools...You know Xcode works. If you don't, then I'm telling you it does. You can build a demo app and notarize it yourself to confirm. For extra fidelity, embed some random framework. Say, why not Qt? You don't have to do anything fancy. There has go to be some simple function to print out the version or something. Maybe even give your app the same bundle ID as your real app. Xcode gives you a comprehensive log file of everything it does. It's not like Console. It's useable. Compare that to what your own toolchain is doing. Change anything that is different than what Xcode does. Compare the structure of your demo app with your real app. Change the real app to match. Check the dylib paths and the rpath in the executable and compare those, fixing anything that is different.It's still unclear if the problem with my app is about dylib loading. At least there's no clear output in Console about an issue with dynamic libraries. And all of the dylibs required by Qt are signed, notarized, and in the proper place in the app's bundle.Hey, it's an idea. That's something isn't it. You have a better idea? Great! Run with it! It has been the right answer in 93% of the other cases of people with crazy Qt projects that won't notarize. Have I mentioned that this is ALWAYS Qt? Because if I haven't pointed that out yet, you should really be aware of it.burden of having to notarizeIt's not a burden. It's drop-dead, fall-of-a-log, do-it-in-my-sleep easy.Notarization hasn't stopped piracy at all.How do you know? And what do you care? Notarization is the single easiest part of the entire process. There is absolutely nothing about making an app that is easier than Notarization. Not a single thing!macOS is not iOS.macOS has been nothing but ports of iOS for years.I think it would be very short-sighted of Apple to continue along these lines.You better go back into quarantine because you sure aren't going to like the next few weeks.

What I don't understand is that if any of these problems are present in an app bundle, why does Apple's notary service still report success and allow me to staple a ticket to the app?Because it is likely a runtime failure. You didn't notice because you were running in whatever development environment that Qt provides. But Gatekeeper does additional runtime dylib checks.Unfortunately it also doesn't tell me anything about why it's failing to allow my app to run!Have you looked in Console? One of the times I responded to a question virtually identical to yours, I found a dylib loading problem that was causing notarization to fail. There aren't any easy-to-use error messages for this because it only affects people who aren't using Xcode. Xcode just works. But if you choose to roll your own, you have to be willing to debug the errors on your own too.I have been using this since, at up until now, it had been working fine.This is what I mean when I say, "you'll get it to work today, but it will be broken again next month."Is the alternative you recommend to individually sign all bundles, executables and dylibs from deepest to shallowest in the bundle?The "alternative" is to use Xcode which does it all correctly. Failing that, you could look to see how any other app using Xcode is built and copy that.However I had no problem getting it notarized and running in macOS 10.15 until now. See my note above.Very little of consequence has changed between my prior and current attempts!There have been tons of changes. In my previous message, I said, "there is an entire industry dedicated to breaking Apple's security." I wasn't joking. This is how it works. Apple has to patch these bugs or their authors will release them. It is legalized extortion. This is where you see the ramifications. One of those exploits used the same slightly lax dylib loading scheme that you depended on. That bug is now fixed, so your app is broken.Is @rpath still allowed?@rpath is the preferred method. However @rpath is dynamic. Qt libraries, especially if you build them yourself, may have funky rpath values that specifically cause this problem.And more importantly, I've yet to see any compelling explanation why this entire notarization system works better than, say, some kind of client-side process that scans executables to try and detect malicious code the first time it's executed. That's been a successful method of stopping malware on every other operating system.Well, no. In fact is has been the opposite. Apple's security platform has been more successful than any client-side approach. And it certainly provides a better user experience.And don't forget that I also mentioned fraud. Malware is what everyone is scared of and is what drives the Apple security and clickbait industry. But it is largely just fearmongering. Apple's security infrastructure works very well and there is very little risk. Nobody talks about fraud. Fraud is orders of magnitude bigger than malware. Most of these "security exploits" are also useful for fraud. But in this case, it is developers being defrauded. My piracy rate is around 20% for direct sales. (Mac App Store appears to be 0%.) And I do a lot of DRM. It is a free app, with in-app purchase. But in order to run the pirated version, you have to disable Apple security. I'm nobody. I can't imagine how bad it is for big developers.- Malware definitions can be updated frequently. If a novel piece of malware manages to slip through Apple's notarization checks and is notarized, it'll still appear to be legitimate, whereas as-needed scanner could detect it once the malware definitions are updated.It doesn't work that way. Apple has multiple levels of security. For all practical purposes, users have to install malware themselves by overriding Apple security.- It avoids all of the aggravating and frustrating work developers have had to go through getting their software notarizedNotarization is fall-off-a-log easy, for everyone who uses Xcode, properly signs, and avoids problematic frameworks.- It provides a better user experience because it provides just as much protection while still allowing more apps to run.Nope.- It allows the platform to remain more open.Wrong platform, Corrigan. That doesn't matter here.

Archive > Distribute > Developer ID > Upload

Is the app and/or dmg notarized? Can you explain why the data file isn't in the app bundle? You could use an installer package that would install both your app and the data file. That seems like it would solve the problem. Or you could download the file at first run.

I've just built an app, signed it with my Developer ID certificate, and had it successfully notarized. However, when I download a zipped copy of the app in macOS 10.15.5 and try to run it, I get the "“XYZ” can’t be opened because Apple cannot check it for malicious software" error message.I know this is nit-picky, but that isn't a successful notarization. A successful notarization is when you don't get that message.There are a number of things that have to happen successfully to have successful notarization. You need a correct bundle. You need embedded frameworks/dylibs that are properly signed and/or entitled. You need need the full dynamic loading layout to be in good shape. There are a number of popular, but poor practices published on the internet, flaky 3rd party libraries, and flaky 3rd party frameworks that contribute to failed notarization. Obviously I don't know which of those are afflicting you, but I know it is one of them, it always is.There are a few things you can do to help debug these problems:1) Don't use poor signing practices. Don't use "--deep" and don't use "--force". I'm sorry, but the internet is wrong on this, as it often is.2) Don't use flaky 3rd party frameworks and libraries. Yes, I'm talking directly to you, Qt. But I'm sure there are many others.3) Use sane bundle layouts. Look at any 3rd party, properly notarized app on your machine. Look at how the app bundle and frameworks are structured. Copy that structure. In many cases, the actual fault is not with the bundle structure per se, but the structure is a big Red Flag. It means you are improvising and you going to have problems. Maybe if you tweak that one entitlement, you'll get it to work today, but it will be broken again next month.4) Make sure your dynamic libraries are properly loaded. Use "otool -L" to check this. This is one of those "hidden" steps that the command-line verification tools don't check. In some cases, the app will work fine when you test it but then fail the download test, the "true" notarization. This is likely because your development build is using one set of dynamic libraries visible to your Xcode build or your account, but the release version is trying to do it in release mode, and failing. You can easily test this by running the app inside a VM. In many cases, you don't even need to bother notarizing to test this. There may be a note in the Console log when your app fails to load. Make sure to have Console running, then try to launch your downloaded app, then quickly check for messages in Console. Be careful with Console. It is a ***** that will bring your Mac down to its knees and leave it a smouldering pile of ashes.why are these security requirements, most of all notarization, even necessary? What specific security problems that were present in Mojave are they solving, and to whose benefit?Malware? Apple doesn't like to say it, but fraud and malware are HUGE. It isn't the security problems that are present, it is the security problems that aren't there. The reason you aren't aware of this problem is due to Apple's efforts to keep it at bay. Apple is doing a very good job of that. But, sometimes, 3rd party developer doing funky things with dynamic libraries are paying the cost. Apple's efforts keep most malware and fraud efforts non-viable. Smart fraudsters don't even bother. A few clueless ones try, but they are easy to deal with. But Apple's can get complacent because there is an entire industry dedicated to breaking Apple's security.

What is the best way to build a macOS app that requires 100% access to the entire file system of a user, in a way that complies with App Store policies?This is impossible. Apple does "allow" Full Drive Access, but you have to be very careful about it. You cannot show it to the under unbidden. The user must navigate to some preferences dialog on their own and enable it. In your metadata, you cannot "require" Full Drive Access. In my experience, using the word "require" or even mentioning it at all, is an automatic rejection. If your app depends on this, it may be a non-starter.And, even worse, people can be lulled into a mistaken hope based on variability between individual app reviewers. You may get version 1.0 into the store. Then you find a critical bug and need to issue an update. Reviewer #2 may reject your app and require a total redesign. Some notes about eskimo's suggestions:- Don't worry about data vaults. They are opaque and users can't access them anyway. Don't worry about that.- Don't think you can just do privilege escalation outside of the Mac App Store. It won't work. I don't know if this is a bug or a feature, but I have found that helper tools, even when running as root, cannot get Full Disk Access. There is something about the launchd user/root divide and the new permissions system that breaks the connection. I even tried explicity giving the helper Full Disk Access. It didn't work. Maybe I was doing something wrong. I don't know. Here is my advice:- Write a different app. Do something that will work on iOS. Then you can port that relatively easily to macOS if you really want to. If you do macOS only, that's 90% of the market you are leaving on the table - and the best 90%.- Stay in the Mac App Store. Don't listen to what developers on the internet tell you. - Don't attempt any "system utilities" at all. Just come up with a novel idea that will work on any platform.

The standard response is probably "file an enhancement request". The problem is that so many app developers never bother writing uninstallers at all. Dragging the app to the trash is the uninstaller.I suggest you add a launchd task that monitors the app itself. When it detects the app has been moved to the trash, have it remove the rest. You can install this as a privileged helper so it shouldn't have to ask for root again. I'm not sure what happens in the system uninstall flow. I checked it a while back but I don't remember. Can the user cancel the uninstall of the system extension after dragging to the trash? Double check that.

I think you'll be fine then. In this context, you actually are acting as an end user. It is fine to distribute scripts as an end user, with end user expectations of reliability. All too often I see people trying to start businesses or release apps using some really marginal technology. That just doesn't scale.

It may work well on your machine, but I would never recommend releasing anything using AppleScript. Sometimes I've done it myself when I have absolutely no other option, but that's a warning, not a recommendation.AppleScript is always going to be the flakiest, most fragile part of any system. And you are using UI scripting, completely with hard-coded delays and keystrokes. Good luck with that! I did check the software in question. It is built using Qt, so the Mac software is really a least-effort port. What you have is all you will ever get. Before releasing it, make sure it runs on the new operating system to be released next month. You might need to find a new project really fast.

There is no one source for macOS training. There are a patchwork of example code over the past 20 years. Some of it is still relevent. Some of it isn't. There are some 3rd party educational resources here and there on the internet. But generally speaking, if you to learn macOS development, you're on your own.I suggest you focus on the Catalyst framework. You will be more likely to find documentation for that. You are essentially using iOS APIs to write a macOS app.