Yesterday, El Capitan came out and with it came great fanfare…except if you aren’t ready to deploy it.

Maybe there is a Microsoft bug holding you back or perhaps it’s even an Apple One. Regardless, when your users now open the App Store update tab, they will see this.



Let’s dive a little deeper…


The App Store itself uses WebKit/HTML to display most of its content. Looking at the source file of the Update tab, you will see a div inserted specifically for El Capitan.

<div id="utd-os-updates" class="lockup-container installations utd-updates updates hidden">
	<table class="no-header">
		<tr class="'installation'">
			<div class="artwork"></div>
		  <td class="description">
			<h2>OS X El Capitan</h2>
			<p class="tagline">A refined experience and improved performance for your Mac.</p>
			<p class="blurb">The next big release of the world's most advanced desktop operating system. Now available as a free upgrade.</p>
			<a href='' class="learn-more">Learn More</a>
			  <span class="update">
				<span class="status"></span>
				<button class="install-button hidden"></button>
			  <div class="multi-button install-button update-button">

<span class="price">Free Upgrade</span>
<span class="left-cap"></span>
<div class="inner"><span>Free Upgrade</span></div>
<span class="right-cap"></span>


If you notice, there is a context-menu class that contains the phrase hideosupdate. This class is what allows you to disable the screen via the first method.

Method 1 - Right Click - Hide Update

Any user can simply right click on the banner and select Hide Update

Hide Update

Simple enough right? But what actually happens when you press this button?

The Island

When a user disables the banner, a SQLite database is created at the following location: ~/Library/Containers/

Upon opening this database, you will find a key called didHideUTDIsland. Apple refers to this banner as the Island and if you pay close attention, the original div also had a mention of “utd”. What exactly this means, I’m not 100% sure, but I would assume it simply stands for “update”

To test this, you can easily hide and unhide the banner by moving this database out it’s location and then moving it back in. Each time you will need to close out of the App Store or refresh the window.

Method 2 - Deploying file.

So now that we have the file, we must ensure that this database file is installed onto every user’s library. I’m a huge fan of Outset and more recently Munki-Pkg (you don’t need to be a munki user to use munki-pkg!), so this will be my preferred method of deployment.

Personally, when a script calls for a file, I place it in /usr/local/outset/custom. This folder does not exist in the default Outset installation, so my munki-pkg creates contains the logic to support this. With that said, it is still pretty straight forward.

The following Outset login-once script should be sufficient:


if [ -e ~/Library/Containers/ ]
        rm -rf ~/Library/Containers/
        cp -R /usr/local/outset/custom/ ~/Library/Containers/
        mkdir -p ~/Library/Containers/
        cp -R /usr/local/outset/custom/ ~/Library/Containers/

By simply dropping a script into /usr/local/outset/login-once, Outset will cause every user that logs in to run it, in their own context.

You will find my the script I am using, as well as the munki-pkg files at my Github

Caveat Emptor

Since we are removing this file if it exists, there is a chance that users may lose other updates that they have hidden. Some may find this an added bonus, while others will shake their heads in disapproval.

If either of these items concern you, you may want to rewrite the script to not remove the file and simply check if it exists first.


If you have never used munki-pkg before, it is a very straight forward approach to building packages. There is no UI and it is fast and easy to learn. Hopefully this is reason enough to test it out.

Sorry Apple!


Table Of Contents