Replies: 3 comments
-
This seems a little wrong at first impression. Sparkle is for updating apps (and less commonly plug-ins). Users install and update apps (and not necessarily update through Sparkle). Launch agents and daemons associated with those apps are updated by the app through other means. I am assuming you have an app the user installs. Updating a bundle while it's already in use is not something Sparkle tries to support. If you could use a pkg update you may be able to whatever you want there, but you might not want that (it will always require user authorization) |
Beta Was this translation helpful? Give feedback.
-
I understand your concerns and while we did consider having a regular macOS app, we decided to simply install our user agent through a pkg at the moment. The reason we didn't want a regular macOS app that indeed could be updated by Sparkle normally is because we'd need to find the app bundle from within the agent which did not not work reliably in the past, also considering the user can move the app to any other location they like. At this point though, I'm starting to consider bundling our agent within a regular app whose default installation location is in the Applications folder again, just to make our flow compatible with Sparkle. |
Beta Was this translation helpful? Give feedback.
-
If you are already shipping a pkg you could serve Sparkle the pkg and do the custom needed logic there for installing/restarting your agent. However shipping a regular app bundle and not using the pkg is indeed the better thing to do for this platform. Regarding moving your app bundle you may be able to install the agent somewhere else or use an API that helps you (see SMAppService, SMJobBless (not for user agents I believe, only daemons), SMJobSubmit, in order of not deprecated to deprecated..) |
Beta Was this translation helpful? Give feedback.
-
Sandbox Enabled: No
Sparkle Version: 2.4.2
Hey Sparkle Community,
Seems like we have a special case that is not handled / supported by Sparkle. We have a user agent managed by launchd for which we'd like to use Sparkle for auto-updating. However, due to the fact that our agent's launchd plist is configured to keep the process alive at all times (KeepAlive), the auto-updating process is broken because when Sparkle terminates the app to begin its installation, the system will relaunch it immediately and therefore causing all sorts of issues.
The easiest approach to solve this in my opinion would be to allow installing updates while the app is running (is this somehow already possible?) and then on finished update, restart the process using
launchctl stop <label>
&&launchctl start <label>
. Responsibility to restart the app could be passed to the host app, if that isn't something Sparkle could easily do on its own. I'm aware of the potential issues involved with replacing a bundle of an app that is still running but I'd really like to avoid unloading and re-loading the agent during updating for 1) risk of not loading it again and therefore breaking all functionalities + update capabilities of our app and 2) because macOS will show the notification again that a background app has been installed.Note that Sparkle must not attempt to relaunch the app by simply opening it because then it won't be managed by launchd.
Thanks for any ideas and comments. We would really love to continue using this great framework!
Beta Was this translation helpful? Give feedback.
All reactions