`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.

[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: #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.