- Disable Slack Auto Update
- Disabling Auto Updates On Slack For Mac Mojave
- Disabling Auto Updates On Slack For Macbook
With this setting, your Mac will Automatically download the available Updates in the background. Once the updates are downloaded, your Mac will notify you that the updates are ready to be installed. All that you need to do is click on the Install button on the notification popup to install the update on your device. Disable Automatic MacOS Updates. Oct 25, 2019 Use it to disable automatic updates, notifications and even disable Google Automatic updaters and other background apps and launch agents. #4: For third-party apps, you can also disable updates within individual app settings. Not everyone downloads apps on a Mac from the Mac App Store. Turning off automatic updates. The Microsoft Silverlight auto-update feature helps make sure that your computer is up-to-date. Disabling the auto-update feature will prevent Microsoft from providing you with the latest Silverlight functionality and security features.
For instance, if you use a Mac for work, you might like Slack to open right up for quick communications. However, if you are experiencing apps opening that you do not want, there are a couple of ways you can change this. This short tutorial shows you how to stop Mac apps from opening automatically on startup or login. Slack will also offer advanced search recommendations as you start typing. For more tips on searching in Slack, check out this resource. Bonus tip: Use the keyboard shortcut Command + G (Mac) or Control + G (Windows) to quickly pull up the search bar (and to reopen your most recent search results). Speed Things Up with Quick Commands.
Tucked into the release notes on today’s standalone download of Slack is a particularly awesome nugget that many of us have been yelling about for a long time:
Long story short, the com.tinyspeck.slackmacgap preferences domain now respects a boolean (true/false) value called SlackNoAutoUpdates instead of requiring admins to set an environmental variable. Note that this functions slightly the opposite of what you might initially expect because the preference itself is worded and used as a negative value – setting it to true (yes) disables auto-updates. You can test this with the following in your terminal:
Should you want to manage this with a configuration profile (AND WHO WOULDN’T?!) you can find an example one below.
Update: The workaround described below for disabling Squirrel updates specifically for Slack no longer works, as Slack’s Mac app as of 2.5.1 includes code to actively disable it. If you disagree (as I do), you can use the Slack /feedback command to send feedback to the developers.
Today in the Macadmins Slack #autopkg channel, my friend Ben mentioned he was seeing this update prompt for the non-Mac-App-Store version of Slack. It probably looked something like this:
Background
Dialogs like this are all too common for those who manage large numbers of computers, because of at least one of: 1) Users running the applications aren’t administrators and an application assumes they are, 2) An application assumes a user can modify files or the app bundle in /Applications, and that there may only be, in fact, one user using this application on the computer, or 3) An application has an auto-updater which is problematic to disable via a configuration profile or script.
Nearly every one of the 100+ applications we install across my org needs some additional configuration to disable a built-in auto-updater.
I use Munki to deploy all of our software, and typically one deploys apps to /Applications (when copied from disk images) using root:wheel ownership, because it’s considered a “system” install, not a user install. This can be overridden to another user, but there’s an assumption that Munki is “managing” the installation of said application on the system.
This “helper tool” dialog shown above happens when the auto-updater used by Slack knows that it’s not going to have the rights to modify the Slack app bundle (because it’s owned by root), and so it prompts for admin authorization to install a helper tool so that it can do its work with elevated privileges.
Squirrel, Slack and Sparkle
Slack recently did a big rewrite using Electron, and it looks like they also adopted Squirrel for the auto-update component on both Mac and Windows. This stands to reason, as Squirrel is a companion project to the Atom editor, out of which the Electron project was born.
Squirrel is a bit like the next generation of Sparkle, supports Windows, and works using more server-side logic than Sparkle, which uses a simple RSS feed (which can still be generated using any server-side logic one wishes). But one nice thing about Sparkle is that there are documented preference keys which can be used to control its behaviour, and while this has to be done for each individual app, the behaviour and methodology of doing this is understood and predictable.
We’ve supported Atom in our computer labs for a while, and have been deploying a supported configuration option in Atom itself to disable update checks. Atom still leverages Squirrel, but uses the configuration to decide whether it will even bother to check for updates at all. I could not easily find any such setting in the Slack Mac app.
Continuous Updates
Some of these apps get updated a lot. Atom has had sevenstable releases over a three-week period last month (November). Yesterday I could open Slack and Atom on a managed desktop and get to work, but today it looks like this within a few seconds of opening the apps:
Atom and Slack apps both prompting for admin rights to install a helper tool.
Despite having great ease of automation thanks to tools like Munki and AutoPkg, we can never match pace with the upstream updates. We might turn around very quickly to get these updates out, but we can’t predict the future.
You also can’t easily test this if you’ve only got the latest version of an app. You’ve got to go find an out-of-date version (which apparently doesn’t take long) and install that to a test machine using the same tools. For example, using an admin user to just copy that old version to /Applications and then launch it won’t necessarily trigger the dialog, because its auto-updater will already have the rights to overwrite the app bundle, provided /Applications still has the default group ownership of admin.
Use the Source
Squirrel’s open source, so that’s usually a good place to start looking. Typically in this case I’ll see if they have any open issues or pull requests that have to do with “update check” or something of that nature, and search the wiki (if there is one) or documentation. GitHub’s interface to immediately search the repo you’re currently browsing is very convenient.
In the end, I found this line - which was very easy, just searching for the word “disable.” This looks like an undocumented flag for debugging purposes. Apple’s APIs provide getenv() as part of the standard C library, so here they’re just checking for this DISABLE_UPDATE_CHECK environment variable to be set (to anything) as a master disable switch.
This is good enough for our purposes to see if we can disable the update check, at least for now.
Environment Variables and LaunchServices
Most of us are familiar with how to set an environment variable via the shell, but how do we set this on macOS so that it will be understood in the context of a GUI app? There are a few ways, although perhaps fewer ways than were possible in earlier versions of the OS, which have been removed for security reasons - and some other approaches have been documented but none of which look appealing.
LaunchServices supports adding environment variables within the context of a bundle, however. It’s possible to dig into the Slack Helper app, at:
/Applications/Slack.app/Contents/Frameworks/Slack Helper.app
and add the LSEnvironment key to its Info.plist file, like so:
I shy away from editing Info.plist files for “released” software if at possible – even though it would be trivial to do this on each install using a post-install script – mostly because I worry that it could at some point break signing, if the developers sufficiently tighten the code signature requirements for the relevant app bundle.
launchctl setenv
Another potentially more interesting option that also doesn’t require us to modify any installation files, is to set this for any user as they log into the system, using launchctl. Again, the variable only needs to be set:
/bin/launchctl setenv DISABLE_UPDATE_CHECK 1
After setting this in the terminal as the user launching the app, we can see whether it will try and initiate an update (and it doesn’t).
Disable Slack Auto Update
We can also check the state of these variables using launchctl getenv <variable> and unset them using (surprise) launchctl unsetenv <variable>.
To make this setting apply for all users (all the time), it must be done in the user’s context on every login. To manage running automatic login scripts on a system, we have tools like outset or LoginScriptPlugin. Managing login and startup scripts is such a common pattern for administering desktop computers that it’s something everyone should have in their toolkit anyway.
Setting this environment variable for a user will of course affect all apps using Squirrel (or at least this publicly-available verion), which may or may not be what you want.
Other methods?
I was hoping there might also be a way to set an environment variable as a user or managed preference in the context of the application itself, but still without modifying the bundle Info.plist, for example:
defaults write com.tinyspeck.slackmacgap.helper LSEnvironment -dict-add DISABLE_UPDATE_CHECK -string 1
But no such luck. Apple has some overview documentation about what options are available for setting an envionment variable, but it’s from 2009 and doesn’t seem to mention launchctl. The launchctl *env commands seem to be available going back at least as far as OS X Mavericks.
Get Involved
Disabling Auto Updates On Slack For Mac Mojave
What’s great about products using open-source components like Electron and Squirrel, is that someone like me can go look at the source code and learn how it works, and propose or submit my own improvements. I’ve done that here, because I don’t like the idea of relying on an undocumented flag like what I’ve shown above.
This idea about pitching in goes for any issues you find with software you want to support in your environment but something about the application’s design poses a problem. Mac installer packaging and versioning is a common problem area, and often you don’t need to know how to write code in a “real” programming language to help an open source project fix that.
Disabling Auto Updates On Slack For Macbook
I’d encourage any Mac sysadmin who’s eager to get some coding practice or learn an unfamiliar language or framework, and to participate in an open source project, to consider offering up such improvements yourself or at least begin the discussion with software developers, who often aren’t aware that these issues exist for larger environments.