Can you pls confirm your Beta version and Build number. Mine is 20A5384c This is not related to beta versions or builds.

We used first option to immediately bring up the Daemons and second option for bringing up our agents. This second option based on open command is what failing intermittently.  Why aren't you doing that for both? Also, I'm confused about this part: daemons(will be spawned whenever machine comes up by copying to /Library/LaunchDaemons) and two for agents (will be spawned whenever a user logs in by copying to /Library/LaunchAgents). This copying of plist also happens in postinstall script. You definitely should copy these plist files in the post install. But you should not "also" do that. The post install is the only time you should copy those files.

When they wipe the machine, they may just reinstall the OS that it came with.

Already flushed the stdout as stated in https://developer.apple.com/forums/thread/112444 And in that thread, you were asked to do 3 specific things. What were they?

This how it has always worked. If your app is sandboxed, all you get are directories in the container. Turn off sandboxing to get the equivalent locations in the user home directory.

Check console logs when you run the app. This can happen when you have something funky going on trying to load dylibs. And unfortunately, Electron generates such problems on a regular basis.

Sorry, there is nothing anyone can add that isn't very clearly identified in those error messages.

We are in the process of getting a developer ID authorized by our organization and hope to release a signed version soon. However we've been distributing the unsigned software for several years without issues. This is a scientific application so distributing through the App Store has not been a priority.  A developer ID is not for App Store distribution. The App Store is a totally different thing. But if you want to distribute, or perhaps even run in the future, you're going to need a signature. Ideally, the app should be notarized. We are replacing the Qt UI with an Electron app soon. Could you please explain more about what is problematic with the architecture? As far as I know, we aren't using anything that's platform specific. Hold up there! You are going in the wrong direction! First of all, if your UI interface is not that complicated and you are considering switching from Qt to Electron, then you really have no excuse not to just do it in SwiftUI. It sounds like your UI and back-end code are well-separated. Otherwise such a switch wouldn't be possible. OK. Keep the separation. Just do the UI in SwiftUI. Do the back-end with a dylib or helper tool. It doesn't matter much. Once the app is hosted in Xcode, then these problems that you have now, and the massive problems you have coming up that you don't know about yet, simply go away. Secondly, things like Electron, Qt, bash, and Python (and Xcode and SwiftUI) are most definitely platform specific. There is nothing wrong with that. The trick is, you have to use them on the appropriate platform. You are using, and switching to, tools that are not appropriate for the Mac platform. Can you get them to work? Maybe, but you are setting yourself up for so much pain - so much pain. You said you have a scientific tool. Does that come in a command-line flavour? If so, you're essentially done. Use that. Wrap it in SwiftUI. Have Xcode build it all. Archive > Export > Upload > wait 2 minutes > Notarized! (I realize I'm glossing over the bash and Python bits. If your command-line tool is Python, then that's still going to be a challenge to integrate into a Mac App. )

Can someone confirm this behaviour. Nope. It works fine here.

The transactions of StoreKit.framework are a nice absctraction, but when having to work with subscriptions they are leaky. Having to manually parse ASN.1 receipts just to get the expiry date for a subscription is cumbersome and - as you have seen -error prone. Maybe a different question and/or forum would be a good idea. I haven't used subscriptions so I can't say anything about them. I don't know what "leaky" means. It sure looks like there is a "Subscription Expiration Date" in the receipt. Apple also has some server-to-server functionality that may help.

Is there a way to use the launchctl command within swift to load and unload the daemons Sure and in doing so when the "stop" button is pressed, to prompt for user password? Maybe, but I don't like where this is headed... I am having issues running scripts with administrator privileges.  Maybe you should have lead with that. What issues are you having? If this is an in-house application, you have a whole world of possible solutions. Just pick the easiest and be done with it. However, you might want to take a step back and review how to configure these network parameters. I strongly suspect that you are taking the long way around.

I am working on a macOS app which is distributed outside of the App Store and isn't sandboxed or signed. Then you are dead in the water. Apple has said that all apps will have to be signed. From what I understand, this means just to run them. If you are distributing apps, they will have to be signed and properly notarized by Apple. My understanding is that non-sandboxed apps should have access to everything that the user can access. This is not true. As of macOS 10.15 Catalina, the end user has more privileges than any running software, even when running under the root user. The app uses several filepath inputs that the user types into a form.  Don't use file paths. Use standard file open panels. According to your logs, the app is running translocated. This is like a quasi-sandbox. I don't know if the app will be able to access the documents folder when launched translocated. And I see you are using Qt. And you are directly referencing bash. And Python! I think you should seriously review the architecture for this app. Suppose you set out to build a SwiftUI app using the iOS SDK and tried to deploy it on Windows. That is essentially what you are attempting here. You are going to have no end of problems with this.

You said:  "...If this is really a Safari problem, then my suggestion would be to add HTML to your data types. RTF is pretty ubiquitous on macOS, but isn't the future. There is no guarantee that new code is going to support RTF like it has in the past. It does still say "NeXT", after all...." Sorry for the confusion. That was my initial reply. But then I realized that I had that old Automator service where I could test the exact same thing that you are seeing. So there is clearly a bug here. Safari reports "public.rtf" but does not provide that data to the service! I agree. To be clear, this bug will never be fixed in Catalina. You have one, maybe two weeks to file a bug report in Big Sur. There is a slight possibility that an updated Safari may contain the fix and may be released on Catalina. In the future, do not wait until the final days of an operating system to test for these kinds of bugs. This is what betas are for.

You could distribute an installer instead. When it is run, it will already be properly installing in /Applications, so you won't have any translocation issues. Your installer may be able to find the file on the DMG. If not, your app should be able to find the mounted disk image. If this is a downloaded DMG anyway, maybe just have app download the data on first launch. Then you don't even need the DMG.

In the receipts we encountered, the milliseconds occurred in the original purchase date filed. Here is one of those receipts: https://www.icloud.com/iclouddrive/0dSTgclIPHq__JEvWHvi2n9OQ#AppStoreReceipt As far as I can tell, there is no "original purchase date" in that receipt. The only "original purchase date" field is an In-app purchase field, which your receipt does not have. So it is really confusing to use the same name for two different fields. Only one of them is documented, and it behaves as documented. If you are looking at some other, undocumented field, the first thing you should do is stop doing that. If you refuse to do that, at least use a different name to refer to it. And if your app breaks when you are trying to read that undocumented data, that's not a problem. That's by design.