Thanks for the answer, @eskimo! In a non-sandbox environment, there is a way to fetch processor temperature, and there are many example apps doing that already. I must build it because that is the number one missing feature based on many users' feedback. In my app, as I see it right now, that would be an additional feature tough, that is available after installing the helper tool outside of the App Store. And there are two things I'm trying to figure out: Can I install an external helper tool for the app that is installed via the App Store? How can I establish communication between the main app (from the App Store) and the helper tool (installed from my website)?

Helper basically is another app as a LaunchAgent.

The helper app is downloaded and installed outside of the Mac App Store. I've actually managed to find the working solution. XPC does work between apps within the same app group. The issue I had with configuring the mach service name. It turned out that it had to be in this format "team_id.group.your_app_domain.suffix", where suffix in my case was just "Helper".

Interestingly enough, but I experience exactly the same issue! I've spent literally the whole day debugging this problem. Quite a few users reported it to me. And it turns out to be nothing that I do wrong. I've managed to reproduce it exactly as you described on my app, and the problem just goes away when changing the wallpaper. @nickdonald, have you found any solution to this? Also, have you reported a bug to Apple?

I have experienced the same issue for months now. Extremely annoying and kills the development experience. I still have not found any fix to that, and weird that it is not fixed yet by the Xcode update! :((

I found out that the issue was not with the signing but with a missing framework dependency in the helper app. Fixed it by adding the dependency in General -> Frameworks, Libraries, and Embedded Content.

Kevin, thanks for replying! Actually, there are two helper apps, one is the menu bar app (the main app configures it), and another one is the background service app refreshing data for the main app, the menu bar, and the system widgets where the app is available too. The main app launches them with NSWorkspace.open(_ url: URL. My expectation is that when I press the "Update" button on the Mac App Store, the helper apps will be relaunched since they were updated with its parent bundle's app.

Thanks for another reply! Yes, the menu bar app is launched by the main app. Also, at the login, it adds itself by using SMAppService. The key difference between what it actually is for me, and what you describe is: When the main app is updated from the Mac App Store, while the menu bar app is running, the system DOES NOT terminate the menu bar app. It just keeps running, and some of its functionality, where it invokes an embedded command line tool stops working until the next restart. I'm not sure if it is a bug or not, but I need to find a way to relaunch it, so the correct, updated version is running.

Thanks a lot! Gives me a much better understanding of what I need to do. Is there a reliable and efficient way to observe when the app loses its own reference to the file system? Or just to observe when the app's bundle is updated?

Okay, I got it! Thanks a lot for taking the time and providing great explanations :)

Thanks for the answer! Could you elaborate more on shipping the helper daemon as an installer package? Is it shipping it with the main app's bundle somehow? How would it look technically? Sandbox is a great concept, but in many cases, it just limits basic functionality, which otherwise is available in many apps shipped outside of the Mac App Store. Those apps have a big competitive advantage, better developer experience, and no app review. Over time I become only more frustrated with the restrictions Apple imposes.

Okay, yeah, that's what I thought. Thanks for your time!

Thanks for your reply! I think I've found what is causing the issue. I still need to verify it completely, but most likely the cause is identified. So. My app consists of the main app with the user interface and a background service app which is started by the main app and is run independently. That background service app also syncs data via iCloud. When the main app is updated, the background service app keeps running, and that is when it starts getting errors from CloudKit. It basically is unable to do any cloud sync operations from then on. My fix is to periodically check in the background app if it should be restarted due to the main app being updated. That should solve it, I believe. I still could not completely validate it, as a fix like this takes time for people to update between versions.

Thanks for the answer! I would be very much interested in receiving analytics (installs, proceeds) on the campaign link via the API.

The issue seems to be only because I have custom DraggableObject. I refactored to passing NSString instead, and encoding/decoding it by myself, and it works again. Still means that passing custom object in NSItemProvider is broken.