Hey, I don't think Apple would be much of help here. I have been sitting on this problem for a long time, and I have my own apps too. What I can suggest - have a look at WinWinKit (winwinkit.com) - it is the first referral programs platform for mobile apps, supports iOS & Mac with Native SDK. They are working on a solution that is exactly what you need. And yes, it will use Apple's system for in-app purchases via subscription.

@Noblauch , @drewster , you can use this endpoint https://itunes.apple.com/lookup?id=APPID, which returns json wiith links to app icon in different sizes.

It seems like that was changed with macOS 15 because it worked perfectly fine before. Anyway, I found a fix.

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.

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

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.

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

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, I got it! Thanks a lot for taking the time and providing great explanations :)

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?

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.

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.

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.

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! :((

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?