`outdated` requires recent MAS launch to show updates

[glyph]

It seems like mas outdated doesn't make the request that causes information about outdated apps to get refreshed, as clicking on the "updates" tab of the app (or launching it) does. When I run mas outdated, it (sometimes?) shows me nothing until I launch the app, then it shows a list of outdated apps.

I run as a user without admin privileges, if that makes a difference; I've noticed it seems to tweak the behavior of the app store itself sometimes.

I realize this isn't the greatest bug report. Are there any diagnostics that would be useful?

[myobie]

I believe this is how mas currently works. In the source I see it is simply enumerating the apps that have updates, but it does not trigger an update scan. Can someone else verify that this is intended behavior?

[rodionovd]

@glyph thank you very much for your report! @myobie is 100% correct: currently mas outdated doesn't fetch new updates from Apple's servers, but simply prints information about known pending updates.

I agree that we need a flag that will force mas outdated to trigger an update scan. I therefore marking this issue as a pull request.

Thank you folks! 🌟

[glyph]

I therefore marking this issue as a pull request.

ITYM "feature request" :).

Thank you!

The bug report here is really that mas outdated appears to be documented to just check for outdated apps; there's no way a reader just reading its help text would realize that it would never check the server, and therefore be permanently out of date until the app is launched. If it were just documented to do this, that would be a little better.

[baarons]

having a scan for updated feature would really be beneficial. pushing this out to hundreds of computers that have automatic updates check disabled...scanning for the updates would be huge!

[brandonzylstra]

I'm a little reluctant to say this because it may be perceived as harsh, but to be completely honest I don't understand the value of a CLI tool that will only work if you also open the GUI tool. mas has the potential to be very useful, but as long as we must open the GUI tool, is there a reason not to just use the GUI tool? There might be, but it's not coming to mind at the moment.

It seems like the minimum step is including a note presented to users of the CLI that this information is only as up-to-date as the last time the App Store GUI was updated, and that they might need to actually click on the "Updates" tab of the App Store (apparently a bug in the App Store itself) to get a fresh list of outdated apps.

The next step might be—if it's very difficult or impossible to query the server directly from mas—might be to automate this with AppleScript or JavaScript to be done in the background. Worst case: it's done in the foreground, if that's the only possible way.

Ideally (if possible) mas could directly get this information (or get it through the App Store without visibly opening the App Store app). That's what I think everyone assumed was happening until they discovered otherwise through trial and error.

[glyph]

I'm a little reluctant to say this because it may be perceived as harsh, but to be completely honest I don't understand the value of a CLI tool that will only work if you also open the GUI tool. mas has the potential to be very useful, but as long as we must open the GUI tool, is there a reason not to just use the GUI tool? There might be, but it's not coming to mind at the moment.

This is a little off topic, but in the spirit of relieving some support burden on the maintainers, let me try and answer.

One way that mas-cli helps tremendously is in provisioning new machines, or keeping multiple machines in sync. It is a pain to manually search for and install dozens of applications, if you are lucky enough to have (say) a work macbook, a home macbook, maybe a desktop, or maybe a couple of dev VMs with different versions of macOS that need a group of apps installed. If you look at the "homebrew integration" section of the README, you can see one way that such a template can be applied. Sure, you still have to sign in to the GUI but a homebrew bundle can save you literally hours of interactive app re-downloading.

Another, similar way it can help is with family sharing. If I search for an app that I know I've purchased previously, but I don't know whether myself, my spouse, or our shared "family organizer" apple ID actually has it in the purchase list, and I click "buy", it actually re-buys the application, even if I already own it, unless I go through the super clunky app store "family purchases" UI to find it there. Whereas, if I use mas install, it will quickly install it using whichever apple ID is appropriate.

So it's a very helpful little tool. It would be better if Apple shipped something first-party that was completely headless, of course, but it's not useless just because it doesn't have every possible non-interactive feature.

[brandonzylstra]

Thanks @glyph that was a very helpful summary of ways that mas is still very useful, and addresses my overarching question very well.

So it's a very helpful little tool. It would be better if Apple shipped something first-party that was completely headless, of course, but it's not useless just because it doesn't have every possible non-interactive feature.

But the objection to the way mas outdated works is not simply that it's lacking a feature, but that it acts as though it has a feature which it doesn't exactly have. If mas outdated included a note warning the user that the information it is presenting is only what was last fetched by the Software Update/App Store app, then we wouldn't have bug reports complaining that mas is not working.

[phatblat]

@brandondrew your feedback is very welcome. I agree that mas should not bring up the App Store GUI (ever) because the whole reason of using a CLI tool is to not require the user to be logged in. However, the reality of this tool is that a lot of it is a giant hack leveraging private Apple APIs which may have worked as expected in the past, but as macOS evolves they are ultimately going to break at some point in the future. #164 is the worst case of this as the API behind it was removed in High Sierra (Sept 2017) and I still haven't found a replacement.

Back on the topic of this issue, it is worse than described here because #111 documents outdated not working at all. It works some of the time, but if there is an underlying Apple bug then mas is probably doomed to suffer the same fate. Hopefully, we can find workarounds to these things.

That said, if anyone does come up with a workaround for an issue using a script or manual flow, please share! This sort of information may be enough to help with tying mas into the same workaround or lead us towards a more stable solution.

And please don't hesitate to relay your expectations of the tool, as harsh as they might seem. This helps to set the bar of what you want this tool to do so that we can strive to make it great!

[glyph]

But the objection to the way mas outdated works is not simply that it's lacking a feature, but that it acts as though it has a feature which it doesn't exactly have. If mas outdated included a note warning the user that the information it is presenting is only what was last fetched by the Software Update/App Store app, then we wouldn't have bug reports complaining that mas is not working.

For what it's worth, I agree with this - that's, uh, why I filed this bug :).

I should also note however that auto-checking for outdated apps seems to happen much more reliably on Mojave, so just probabilistically speaking, mas outdated actually produces much more useful output these days. (But it also means that I am using it much less often, because I just set the app store to auto-update and it actually works now, as opposed to having to manually prod it with shell scripts and mas on my own.)

[andrewcrook]

could the following issue #92 and #249 also been caused by this?
opening Apples App Store App before made no difference.