Recent Beta and Dev Insider Preview builds have brought a new entry to Settings > Apps (e.g. 26220.7271). As you can see in the lead-in graphic it’s labeled “App Updates.” Quite naturally, this led me to wonder how differs from “Updates & Downloads” in the MS Store app itself. Comparing and contrasting Settings vs Store App Updates turns out to be more nuanced than I’d hoped. Indeed, the lead-in graphic also shows Settings reports all apps up-to-date at the same time as the Store is downloading an update to itself.

Digging into Settings vs. Store App Updates

Last May, MS Product Manager Angie Chen posted a blog on this topic. Entitled Introducing a unified future for app updates on Windows, it lays out new alternatives coming to  purely Store-based updates. But it wasn’t until I could see and try out the Settings alternative to the Store-based baseline that I could see some differences.

Indeed as Sergey Tkachenko puts it at WinAero: “…you can manage updates for certain Store apps that can receive new versions via Windows Update” (bold emphasis mine). As you can see in the intro screencap, the Store will happily update itself, while Apps> Update Apps apparently will not.

The Key: “Other” Update Channels Rule

The intro language in the May 27 blog post linked above states:

If you are already getting apps through the Microsoft Store (our recommended approach), there is no action needed—you will get the benefits described here by continuing to use that method.

Among other things, this means that store-managed apps — including the Store itself — continue to update through the Store Updates & Download faciliity, not through Settings > Apps > Update Apps. That showed itself immediately as soon as I went to check things out. Indeed careful reading of that blog post shows that developers must explicitly build apps to hook into Windows Update (ditto for management tools such as Intune or Autopilot) to make use of this capability.

In fact, nobody really knows how much this will change the way things work right now. As with other possible futures in Windows-World, those who build apps will have to take up this new update path before mere users — like your humble author — can walk down it. Right now, it seems limited to MS tools that don’t fall under the Store umbrella (e.g. PowerShell and Windows Terminal). So far, it looks more like a future possibility than a real, current alternative.

I’ll keep an eye on this, and let you know what happens…Stay tuned!

When I saw the news, I had to try it. A couple of weeks back, MS announced that 24H2 users for all versions of Windows 11 except the Dev and Canary Channel could move up to 25H2. So I used the Installation Assistant, and did that very thing for my X380 Yoga install. But, as I’m learning, that Beta 25H2 jump brings unexpected side effect. Namely, as MS drops new Beta Builds (e.g. 26120.6982), my jumped-up Yoga doesn’t partake of such updates. It’s on a higher track.

Why Beta 25H2 Jump Brings Unexpected Side Effect

The base build number for 24H2 Beta versions remains 26120. For Beta installs jumped to 25H2, that base build number advances to 26200, as you can see in the lead-in graphic. Thus, for my Beta Channel test PC the unexpected side effect of the jump-up is to exclude it from updates and new versions that target 24H2 instead. I should have known, but found out when I saw last week’s announcement of Build 26120.6982, visited WU, and didn’t get anything in response to clicking the “Check for updates” button.

Only slowly did it dawn on me that my install is on a different track right now. I’m not exactly sure when I’ll see the next update for this track. I’m guessing I may have put myself on the Patch Tuesday schedule with this change, along with occasional OOB updates and 4th Tuesday items as they sometimes appear.

Here in Windows-World, it can be easy to change tracks, or even to get onto the wrong track. I know I’ve done the former, and time will tell me if I’ve also done the latter. In the meantime, I’ll just keep chugging along.

One More Thing [Added 6 hrs later]

I just ran DISM /online /analyzecomponentstore on this updated PC and guess what? the 25H2 eKB restored the spurious reclaimables that I’d hand-deleted from the 24H2 image. (See this March 21 post for details.) It worked this time, too, just as recited in that earlier post (and again, thanks to ElevenForum user @Bree for figuring this out in the first place).