Spotify Mac app with Intune: what actually deploys

The request usually arrives as a one line ticket. Put Spotify on the managed Macs. The admin opens the Intune admin center, picks the macOS platform, looks at the list of app types, and finds nothing that matches what Spotify hands out. There is no Mac App Store option. The download from Spotify is not a PKG. It is not even a disk image. At that point the ticket stops being about music and starts being about packaging, and the packaging question has a very specific shape that is worth understanding before spending an afternoon on a wrapper script.

What Intune will actually take on macOS

Intune groups apps into store apps, line of business apps, built in apps, web links, and apps sourced from other Microsoft services. For the macOS platform specifically, the list of app specific types is short. There is macOS app (DMG), macOS app (PKG) for an unmanaged package, line of business app for a managed PKG, macOS web clip, plus the first party entries for Microsoft 365 apps, Microsoft Edge, and Microsoft Defender for Endpoint.

Notice what is missing. There is an iOS store app type and a Microsoft store app type, but there is no Mac App Store type. Intune cannot point at an App Store listing on macOS and let Apple handle the install and the updates the way it can on iPhone. Anything that is not a Microsoft first party product has to arrive as a file you upload, or as a shortcut to a URL.

That distinction matters because the update behavior follows from it. Microsoft's own table is blunt about who owns updates for each category. Store apps and web links update themselves. Line of business apps do not.

The consequence for a music client is easy to predict. Spotify ships new builds constantly. If the app enters the fleet as an uploaded file, every one of those builds is either an update the admin re-uploads, or a self update the app performs outside of Intune's view. Neither is wrong, but they are different operational commitments, and picking one by accident is how a deployment quietly rots.

The Spotify download is not the app

Here is the part that catches people. The Mac download served from Spotify's own content host is a file named SpotifyInstaller.zip. It is 1,868,156 bytes, roughly 1.8 MB. Inside is a single bundle called Install Spotify.app, and its identifier is com.spotify.client.installer. The real client is not in there. The stub is a universal binary for Intel and Apple silicon, and it declares macOS 11.0 as its minimum, but all it does is fetch the actual application at run time.

Now read the DMG requirement next to that. Microsoft states the rule directly.

The DMG file must contain one or more files with .app extensions. DMG files containing other types of installer files will not be installed.

A zip is not a DMG, so the file cannot be uploaded as it stands. Repackaging the zip into a DMG technically satisfies the extension rule, because the stub really is an .app bundle. It also produces a deployment that is wrong in a way that will not show up until later. Intune identifies a DMG app by the bundle identifiers listed under Included apps, and the identifier it would find is the installer stub, not the client. The install reports success the moment the stub lands in the Applications folder, whether or not the download it was supposed to trigger ever completed.

There are also the ordinary prerequisites to clear. The device has to be managed by Intune, the package has to be smaller than 8 GB, and the Microsoft Intune management agent for macOS has to be installed. On macOS 13 and later, full disk access is requested automatically when a DMG app policy is assigned, because updating or deleting a DMG app needs it.

The honest summary is that packaging this particular application for Intune means building your own DMG from an already installed copy, taking ownership of the bundle identifier and the version detection, and revisiting it whenever the vendor changes the shape of the download. That is a real option. It is just not a small one.

The web clip route, and the ceiling it hits

Every admin eventually finds the other entry in the list. Under Other types there is Web link, with platform specific variants including macOS web clip. Enter a URL, assign it, done. No file, no agent dependency, no version detection.

Read what it produces before assuming it solves the problem. Microsoft describes the outcome per platform.

Intune creates a shortcut to the web app on the user's device. For iOS/iPadOS devices, a shortcut to the web app is added to the home screen. For macOS devices, end users can pin web apps to the dock on their macOS device. Source: learn.microsoft.com

A shortcut the user can pin to the Dock. Not an application. The Full screen switch, the one that launches a web clip as a standalone window with no URL bar and no bookmarks, is labeled iOS and iPadOS only. So is Ignore manifest scope. On macOS the click opens a browser, the site becomes another tab among thirty, and the original complaint that someone wanted a real app in the Dock is untouched.

One more detail deserves attention before assigning it broadly. A macOS web clip assigned as Required cannot be removed by the user. Deleting the assignment does not clear it either. The assignment has to be changed to Uninstall first, otherwise the web clip stays on the device permanently.

What the browser costs in sound quality

If the plan is to route people to the web player, the trade is not only cosmetic. Spotify publishes the bitrates, and the web player and the installed app are not the same product.

Where it plays	Free account	Premium account
Web player	AAC 128 kbit/s	AAC 256 kbit/s
Desktop, mobile, tablet	up to approximately 160 kbit/s	up to approximately 320 kbit/s, or lossless up to 24 bit / 44.1 kHz FLAC

Spotify also states plainly that quality is not adjustable in the browser and points users to the app for the extra settings. For a design studio playing background music in an open office, none of this registers. For an audio post house, a broadcast team, or anyone who bought Premium specifically for the top tier, shipping the web player as the official answer is a downgrade that the ticket did not ask for. Confirm which group is asking before choosing.

The other browser limits follow the same pattern. Downloads for offline listening live in the installed app. Local file playback lives in the installed app. If the fleet includes laptops that spend hours on aircraft or in facilities without usable wifi, that is the deciding factor, not the packaging convenience.

Turning the web player into something Intune can ship

There is a third path that sits between the two. Instead of deploying a shortcut, build a standalone Mac application around the web player and deploy that application the same way any other DMG is deployed.

A tool that turns a website into a standalone Mac app produces a real .app bundle with its own name, its own icon, its own Dock entry, and its own entry in Command Tab. That bundle is exactly the object Intune's DMG app type expects: a disk image containing an .app, with a bundle identifier you control and can list under Included apps. The web clip's ceiling disappears, because the result is not a shortcut into a browser session. It opens in its own window with no tab strip.

The practical differences against the other two routes look like this.

	Repackaged vendor installer	macOS web clip	Standalone app built from the web player
Intune app type	macOS app (DMG)	macOS web clip	macOS app (DMG)
Lands in the Dock as an app	Yes	No, opens a browser	Yes
Detection identifier	Vendor's, and the stub complicates it	None needed	Yours, stable
Offline playback and lossless	Yes	No	No
Who owns updates	You	Nobody, the site updates	The site updates itself

Read the last two rows together. The wrapper route removes the packaging problem and the update problem at the same time, and pays for it in audio ceiling and offline playback. That is a legitimate trade for a marketing team and a bad trade for an editing suite. The point is to make the trade knowingly instead of discovering it in a complaint two weeks later.

Worth noting for anyone evaluating this class of tool: some of them build on top of a Chromium browser the user already has, rather than bundling a separate runtime. That keeps the download small, and it means sign in state and extensions carry over instead of starting from an empty profile. The Features page lays out what that structure does and does not cover, and the Supported services list shows how many sites are already configured, with more than 300 presets available.

Detection rules and updates decide whether this stays quiet

Whichever route wins, the settings that determine whether the deployment ages well are on the detection rules page, not the app information page.

Ignore app version is the one to get right. Set to Yes, Intune only checks whether the bundle identifier is present, which is what you want for anything that updates itself. Microsoft's guidance says exactly that: for apps that have an auto update mechanism, select Yes. Set to No, the version number has to match as well, and every self update turns the app into a mismatch that Intune tries to correct.

The same setting changes uninstall behavior. With Ignore app version set to No, both the bundle identifier and the version number have to match before the app is removed. With it set to Yes, the identifier alone is enough. Fleets that have drifted across several versions usually want Yes here for that reason alone.

Two more behaviors are easy to forget. An app deployed as Required installs into the /Applications directory, not the user's own Applications folder, so it is shared across accounts on that Mac. And a macOS app deployed through the Intune agent is not removed automatically when a device is retired. The app and its data stay. If the device is being handed to someone outside the organization, the uninstall assignment has to happen before the retire.

What to change first

Decide who is asking before deciding what to package. If the answer is a team that needs offline playback or the top audio tier, accept the packaging work and build a proper DMG from an installed copy. If the answer is everyone else, skip the vendor installer entirely and deploy a standalone app built from the web player, so the Dock gets a real application and nobody inherits an update chore. Kagemusha documents the second route end to end.