Intune Enterprise App Management: Is Manual Application Packaging Becoming Obsolete?

Picture an IT admin on a Friday afternoon. Google Chrome released a new version this week. So did Zoom. So did the PDF reader half the finance team uses. Each one needs to be downloaded, wrapped into Intune's .intunewin format, given detection rules, tested, and pushed out again, the exact same routine they did last month, and the month before that.

That routine has a name: manual application packaging. And for years, it was simply the job. Now Microsoft has built something that packages a lot of that work for you: Intune Enterprise App Management (EAM). This post explains what EAM actually does, in plain language, and gives you an honest answer to the question in the title: does hand-packaging apps still have a place, or is it on its way out?

Quick Definitions Before We Start

Before anything else, here is every term this post uses, translated once so you never have to guess again.

Keep that table in mind. Everything below is really just those six ideas working together.

What Is the Enterprise App Catalog, Really?

Think of it like the difference between building your own vending machine from scratch versus renting one that already comes stocked, serviced, and restocked automatically.

Before EAM, every app you wanted to deploy through Intune, even something as ordinary as Google Chrome, was something you had to download, wrap, configure, and test yourself. It didn't matter that a thousand other IT teams around the world were doing the exact same thing with the exact same app that week.

The Enterprise App Catalog is Microsoft doing that repeated work once, centrally, so nobody has to do it a thousand times separately. It now holds several hundred common third-party applications, browsers, PDF readers, compression tools, communication apps, and other everyday software that shows up in almost every organisation's fleet. Under the hood, a catalog app is still technically a Win32 app. Microsoft has simply already done the packaging, detection logic, and installer configuration for you.

Automatic Updates: The Part That Actually Saves Time

This is the feature that changes an admin's monthly routine the most.

Supersedence: Replacing the Old with the New

Here's an everyday analogy. When a new phone model comes out, you don't keep using your old phone and your new one side by side forever, you trade the old one in and move everything over. Supersedence is Intune's version of that trade-in: it tells a device "install this new app, and get rid of that old one while you're at it," instead of leaving both versions cluttering the machine.

For a traditional Win32 app, you build that supersedence relationship by hand: open the old app's properties in Intune, go to Supersedence, and manually pick the new app that should replace it, then decide whether Intune should uninstall the old version first. You can chain up to 10 apps this way, but every link in that chain is something you built and now have to remember exists.

For a catalog app, you don't build a supersedence chain at all. Since Intune already knows it's updating the same app to a newer version rather than replacing it with a different one, there's no separate "old app" and "new app" for you to link together. The trade-in happens automatically as part of auto-update.

Traditional Win32 Packaging vs. Catalog Apps, Side by Side

Where Does Graph API Fit Into All This?

Think of the Intune admin portal like walking into a restaurant and ordering at the counter every single time. The Graph API is the delivery app: instead of a human clicking through screens, a script sends a structured request and gets a structured answer back, and it can do that for hundreds of apps in the time it takes you to click through five of them manually.

For Enterprise App Management specifically, Microsoft Graph exposes the entire catalog as data you can query. That matters once you have more than a handful of catalog apps to manage, because clicking "Add" a hundred times in a web browser is not a good use of anyone's afternoon.

Here's a beginner-friendly example. This PowerShell script simply asks Microsoft Graph for a list of every app currently sitting in the Enterprise App Catalog:

# Connect to Microsoft Graph with the permission needed to read app data
Connect-MgGraph -Scopes "DeviceManagementApps.Read.All"
 
# Ask Graph for the full Enterprise App Catalog (this is the "beta" endpoint,
# since EAM's catalog data isn't in the stable v1.0 API yet)
$catalogApps = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/beta/deviceAppManagement/mobileAppCatalogPackages"
 
# Show just the name and publisher of each app, instead of the full raw output
$catalogApps.value | Select-Object productDisplayName, publisherDisplayName

Nothing in that script clicks a single button in the admin centre. It asks a question in code, and Intune answers in code. That's the whole idea behind Graph automation: once your app estate is described as data instead of screens you click through, you can report on it, audit it, and bulk-manage it with a script instead of your mouse.

Where Custom Packaging Is Still Necessary

This is the honest part of the post. The catalog is genuinely useful, but it was never built to cover everything, and it isn't trying to.

So, Is Manual Packaging Becoming Obsolete?

Not obsolete. Smaller.

Before EAM, every single app on your fleet, whether it was Chrome or your own custom finance tool, went through the same manual packaging pipeline. That made "how do I package apps well" a huge part of an endpoint engineer's job.

Now that work splits into two very different piles. Common, everyday software increasingly belongs in the catalog pile: add it, assign it, forget it. Anything genuinely specific to your organisation still belongs in the manual pile, and that pile isn't shrinking to zero, because the catalog was never designed to hold software that only your company uses.

The actual skill shift for endpoint engineers isn't "learn to use the catalog instead of packaging apps." It's learning to correctly sort every new app request into the right pile before spending a single minute packaging anything.

A Quick Decision Checklist

Next time someone asks you to deploy a new app, run through these questions in order before opening the Win32 Content Prep Tool:

If you get through all five questions and land on "catalog app, default settings, latest version is fine," that Friday-afternoon repackaging routine just disappeared for that app, permanently.

Have you moved any apps from a hand-built Win32 package over to the Enterprise App Catalog yet? I'd like to hear which ones worked cleanly and which ones you had to pull back out of the catalog. Drop a comment below.