`outdated --accurate*` opens an error dialog for each undownloadable app & each app purchased by an Apple Account other than the current Account

[bevanjkay]

Configuration

mas ▁▁▁▁ 3.0.0
arch ▁▁▁ arm64
from ▁▁▁ homebrew/core/mas
origin ▁ https://github.com/mas-cli/mas.git
rev ▁▁▁▁ e8993b7de5256074f2fd069d80e60fbc9e4dfaad
swift ▁▁ 6.2.1 (swiftlang-6.2.1.4.8 clang-1700.4.4.1)
driver ▁ 1.127.14.1
region ▁ AU
macos ▁▁ 26.1 (25B78)
mac ▁▁▁▁ MacBookPro18,2
cpu ▁▁▁▁ Apple M1 Max

Bug description

When running mas outdated I receive a couple of popups regarding "Redownload Unavailable with This Apple Account" I do have a couple of applications installed that are owned by a different Apple ID than the one I am currently logged in with, however this popup only used to show on mas upgrade which was expected.

Steps to reproduce

[rgoldberg]

The new outdated logic resolves tons of problems for detecting which apps are outdated.

Since most users will not have apps installed by multiple accounts, I do not want to remove the new logic unless it is supplanted by something that works better in every circumstance, though mas could offer the old logic or new alternate logic as an option to handle installed apps having been purchased by Apple Accounts other than the current one.

Apple makes if exceedingly difficult, if not impossible, to determine which account purchased an app.

For now, can you either:

• Call outdated with app ID arguments, like mas outdated 123 987 456, which will limit the apps checked to those with the given app IDs?
• Call outdated with app ID arguments supplied by a script that you'd write that obtains all installed app IDs from mas list, then filters out app IDs that you know are from another user? If you write such a script, could you post it here to share with others?
• Revert to mas 2.3.0?

If anyone can help with investigation / implementation of any of the below, please let me know.

mas can either:

1. Suppress the dialogs
2. Determine which Apple Account purchased an app, determine which Apple Account is associated with the current macOS user (preferably mas would determine which Apple Account is signed into the App Store, but there are difficulties there, too), then filter the apps it checks
3. Use a newer Apple private (or public) framework (or other mechanism) that provides a list of the outdated apps, which might require granting entitlements, calling commands that require root privileges, etc.
4. Provide a way to ignore specific apps for various commands, including for outdated. it could be implemented via options or via a persistent config (the latter could include pinning).
   • Apple recently released a Swift config library that requires Swift 6.2, which mas cannot use until it needn't build on macOS 14 anymore, which would be the case once:
     1. Homebrew no longer supports macOS 14
     2. Homebrew supports cross building (e.g., supports building bottles for macOS 14 on macOS 26)
     3. mas migrates from a formula to a cask
     4. The Homebrew core mas formula stops supporting macOS 14, forcing macOS 14 users to use the mas custom tap, which does cross build bottles
5. Reinstate the old outdated code as an alternate methodology, enabled by a flag (maybe --handle-multiple-purchasers, or maybe --alternate)
6. Leave as is. mas

[HugeIRL]

@rgoldberg I also have this issue on my work machine. I noticed that mas outdated seems to attempt to download apps? And it fails on TestFlight apps that have ID: 0 since they're not in the Mac App Store.

Note: I don't have multiple Apple IDs or apps with different Apple IDs from my primary Apple ID.

[ctrlcmdshft]

This fails as well when u have apps installed via TestFlight, It give the error The product is not available in the U.S. Store

[HugeIRL]

@rgoldberg I'm going to crack another issue and reference this one as it's the "same problem" but in a different way.

[HugeIRL]

Reported as new issue here as it's technically a new problem but with existing issue that was mentioned here: https://github.com/mas-cli/mas/issues/1053

[rgoldberg]

@HugeIRL @ctrlcmdshft #1053 is fixed and will be released in 3.0.1 later tonight. Some problems are incredibly easy to fix (#1053, because ADAM IDs are readily available for installed apps), while seemingly similar other problems are exceedingly difficult to fix (this issue, because the purchasing Apple Account for an app isn't readily available).

[bevanjkay]

@rgoldberg Thank you for the detailed response, and I appreciate you taking the time to look into this. Some interesting pain points here for sure.

I think suppressing the dialogs would be helpful, I'm not sure if you are able to collect any more information to present alongside the "No downloads began". Having it mention the mismatched Apple ID could be helpful alongside the error, as well as the name of the application that failed.

Perhaps being able to suppress the "Error: No downloads began", even behind a --quiet flag or similar would help here too.

[rgoldberg]

@bevanjkay "No downloads began" is an internal error message to which the ADAM ID & app name can easily be appended.

I just released 3.0.1, so appending the ADAM ID will wait for the forthcoming 4.0.0 with the installd/PackageKit fix.

It would probably be bad to silence the error, though, unless mas can determine if the cause was an app purchased by a different account.

I don't think that's possible, but I can investigate, though it would make more sense to investigate avoiding this issue in the first place, rather than avoiding a stdout message while a dialog is still shown.

[jabenninghoff]

FYI, I've discovered a related issue: when running mas outdated, a dialog will appear for each app that is present in /Applications, but no longer on the app store.

it also appears to trigger a download error:

Error: No downloads began

Here is some additional detail: (excerpt of mas list, mas info for that ID)

% mas list
 520411565  Crow                        (1.1.0)
% mas info 520411565
Error: Failed to lookup app for ADAM ID 520411565
No apps found in the Mac App Store for ADAM ID 520411565

I agree that suppressing the dialog boxes would be helpful, and it would be nice to have an option to ignore "missing" ADAM IDs, or to just always ignore them, which is what the official App Store does.

[rgoldberg]

@jabenninghoff Thanks for the report.

I rushed pending 3.0.0 changes out to get them out before the workaround for #1029 (which I'm working on now), so I didn't have all the other changes I had planned to go along with them. I wanted people to be able to get these updates without #1029 changes, and mas has so far had a linear development.

The new outdated logic solves tons of intractable longstanding issues, but has the new issues reported here, but they should be fixable (see https://github.com/mas-cli/mas/issues/1052#issuecomment-3542131635) once I get past #1029.

While a longterm fix for this is pending, you can workaround the problem by either:

• Calling outdated with app ID arguments, like mas outdated 123 987 456, which will limit the apps checked to those with the given app IDs.
• Calling outdated with app ID arguments supplied by a script that you'd write that obtains all installed app IDs from mas list, then filters out app IDs that you know are from no longer available in the App Store. If you write such a script, could you post it here to share with others?
• Reverting to mas 2.3.0

Thanks.

[jabenninghoff]

Thanks and understood! I did put together a quick script that fixes the issue (at least for me). I wouldn't call it robust, but it should work for now and for others.

MISSING_ADAM_IDS=$(mas list | awk '{print $1}' | xargs mas info 2>&1 | grep ^Error | awk '{print $9}' | xargs | sed 's/ /|/g')
mas list | grep -Ev "$MISSING_ADAM_IDS" | awk '{print $1}' | xargs mas outdated

[rgoldberg]

@jabenninghoff Thanks for the script.

I myself would have written a script for people if I weren't busy trying to deal with the #1029 fix (I have a working fix, but I'm redoing how it handles obtaining the now requisite root permissions).

[jabenninghoff]

@rgoldberg no worries! I appreciate all your work keeping mas functional.

[rgoldberg]

FYI, I've discovered a related issue: when running mas outdated, a dialog will appear for each app that is present in /Applications, but no longer on the app store.

I have some App Store apps that are no longer in the App Store but I don't get any dialog boxes for any of them when running outdated on mas 3.0.0+.

$ mas list
…
 715768417  Microsoft Remote Desktop 8  (8.0.30030)
…
$ mas info 715768417
Error: Failed to lookup app for ADAM ID 715768417
No apps found in the Mac App Store for ADAM ID 715768417
$ mas outdated
## no. dialogs

My vestigial App Store apps are both for Intel, though, I haven't installed Rosetta, and I think I installed them by just copying them from my old Intel Mac, so maybe they are ignored by the Apple code before the dialog would be displayed.

[jabenninghoff]

OK, I've done some additional checking. Most of my apps are Intel-based, but I did find one that wasn't. I kept that one in /Applications and move the rest to a different folder. After doing that, here's what I get in the Terminal, and I also get the error dialog.

% mas list | grep -E "$(mas list | awk '{print $1}' | xargs mas info 2>&1 | grep ^Error | awk '{print $9}' | xargs | sed 's/ /|/g')"
 911974149  Transcriptions              (1.4)
% mas outdated
Error: No downloads began

Update: after checking all apps, I found that ReadKit is also Universal, but somehow it's not triggering the error.

% mas list | grep -E "$(mas list | awk '{print $1}' | xargs mas info 2>&1 | grep ^Error | awk '{print $9}' | xargs | sed 's/ /|/g')"
 588726889  ReadKit
% mas outdated

So it doesn't seem to be related to Rosetta. What can I do to help troubleshoot or reproduce the issue?

[rgoldberg]

@jabenninghoff Thanks for the info.

We know that a non-Intel vestigial app gets the dialog for you, while 2 Intel vestigial apps do not get the dialog for me (I do not have Rosetta installed).

Can you run:

mas outdated <Intel vestigial app adam id>

Or you can run without the argument ID, just move all the other vestigial apps out of /Applications.

Also, is Rosetta installed on your Mac?

If that doesn't open a dialog & you don't have Rosetta installed, I think we've likely narrowed it down to vestigial apps that either are arm64 or that can currently run on an Apple Silicon Mac (Rosetta must be installed for Intel apps). If you do have Rosetta installed, and if it doesn't open a dialog, then it looks like the dialog is only for arm64 apps. Maybe it's something else, but that's my first guess about slicing up the problem space.

Thanks.

I'm reincorporating the old logic into mas as we speak.

[jabenninghoff]

OK, I ran a quick script to run mas outdated <ID> on all apps not found by mas info (ie, Error: Failed to lookup app for ADAM ID 520411565). Out of the 17 missing apps, only 8 triggered an error (including the dialog box), and I can't find any commonality between them (other than they're all pretty old).

Rosetta is installed on my Mac, I forgot to mention that in my last comment.

% mas list | awk '{print $1}' | xargs mas info 2>&1 | grep ^Error | awk '{print $9}' >missing.txt
% for i in $(cat missing.txt); do echo $i; mas outdated $i; done     
520411565
422304217
467939042
Error: No downloads began
499190094
Error: No downloads began
475260933
Error: No downloads began
436780099
Error: No downloads began
405219581
416422471
Error: No downloads began
407963104
588726889
880001334
602589414
Error: No downloads began
411887332
1002633630
911974149
Error: No downloads began
497448794
Error: No downloads began
402359583

The apps that generate an error include both Intel and Universal, as do the apps that don't generate an error (I have one Universal app that generates an error and one that doesn't.

Perhaps there's something on the App Store back-end? I seem to recall in the past that some apps could be reinstalled but not downloaded from the App store, while others were just completely gone.

[rgoldberg]

@jabenninghoff Thanks for all the info.

I think I will pause trying to figure out exactly when this occurs or not until later.

If you can determine the cause of the different behaviors, that would help.

I doubt that we'll be able to determine it based on info available to us, however, but maybe the info would be in the Spotlight data (mdls /Applications/<app-folder.app>) or in the iTunes Search API results (used in, but not completely exposed by, mas info; will be able to get all the results from mas info in JSON format once mas 5.0.0 is released), but I don't have time to look through it now.

Instead, I'm avoiding the problem in 2 ways:

1. Default outdated & upgrade logic will be from pre-3.0.0. New logic will be available with an --accurate flag.
2. Maybe an extra flag for, or an alternate flag to, --accurate that specifies ignoring apps that are not known to be in the App Store. Would use the iTunes Search API to determine that. Maybe some apps that aren't available through that API could still be updated, but I imagine it would be rare to never. Anyway, it would still be more accurate than the old, now default again, logic. I also might make that filter default for --accurate, and have the extra / alternate flag remove the filter. Or I might always or never use that filter. Any preference?

[rgoldberg]

This issue has been mitigated in 3.1.0 by:

1. Changing the default outdated app detection logic to be the inaccurate pre-3.0.0 logic, while processing two new flags for outdated & update/upgrade for two variants of the new accurate logic.
2. One of the 2 accurate flags, --accurate-ignore-unknown-apps mitigates this issue with the 3.0.0 logic at the expense of a few extra quickly network calls to Apple that allow mas to skip checking any app whose ADAM ID is unknown to the iTunes Search API lookup endpoint. Many of those apps would open dialog because their installers are no longer available to be downloaded from the App Store. Some of those apps do have installers available, however, but the likelihood of those installers being newer than your installed version is very low, so it's theoretically possible that this flag could ignore a few apps that could under very odd circumstances have updates. --accurate won't ignore such apps, but will open dialogs for them if they exist.

I've left this issue open because more work can be done to avoid dialogs.

[jabenninghoff]

Thanks @rgoldberg! I'm late answering your question, but I think the options and defaults you implemented for 3.1.0 make sense and fully address the problem. I think there might be rare circumstances when an app not available through the Search API could be updated, but that would be the exception, not the rule, especially for mas users (who I'd expect to keep their apps up to date).

[rgoldberg]

@jabenninghoff Thanks for the reply.

If you want (or if anyone else wants) to test the fixes for the installd/PackageKit problem that were just recently merged into main and that will be released later today as mas 4.0.0, or if you want to review & comment on the code, please see https://github.com/mas-cli/mas/issues/1029#issuecomment-3568152481.

[jabenninghoff]

Also, following up on the question of "when does this occur?" ... As I hang on to App Store apps for probably longer than I need to, I've come across this before. The introduction of the --accurate flag helped me work out what's going on.

Looking through the App Store GUI, some of my old purchased apps can't be found in the App Store search, but are still listed in my Account to download. The apps that trigger the download error have been completely removed from the App Store, and don't appear in either the search or in my Account. I haven't been able to figure out the criteria for full removal, though.

If there is a way to check for an ADAM ID in a user's purchase history, then you could implement logic to skip downloading an app if it appeared in neither the Store Search API or the Account.

[rgoldberg]

@jabenninghoff Thanks for the info. That's what I expected the situation to be.

Apple seems to make it incredibly difficult to determine what apps have been purchased by what account. I will look into this sometime in the future, but doubt I'll be able to associate apps with accounts.

The most likely fix would be to prevent dialogs from opening.

If all else fails from the Apple end, once mas has a config system (probably a year from now at earliest so that mas can use the Apple swift-config library which will only build on macOS 15+), mas could implement pinning / ignoring, so each app that opens a dialog can be ignored for all future outdated / update, so dialogs would only inconvenience once per app.