Bundle IDs seem to uniquely identify an app (unlike app names, but like app IDs).

mas commands should accept bundle IDs anywhere app IDs are currently accepted (command-line arguments, Brewfile).

Bundle IDs are more descriptive of apps than app IDs, so if a user copies & pastes the wrong bundle ID, or makes a typo in one, it's much more obvious.

The App Store lookup web endpoint (https://itunes.apple.com/lookup) supports using bundleId instead of id, and the apps listed in CKSoftwareMap.shared() can be looked up via bundle ID instead of via app ID, so there shouldn't really be any problems supporting bundle IDs.

If everyone agrees that bundle IDs should be allowed to be used as much as possible, I can investigate all the code to ensure there are no places where app IDs are much better or the only workable option (neither should be the case).

Should we also switch to displaying bundle IDs instead of app IDs in output?

This would be implemented by changing all current app ID command-line arguments from being read as integers to being read as Strings. If the String can be parsed as a UInt64, it will be considered an app ID. Otherwise, it will be considered a bundle ID. I assume that no bundle IDs are unsigned integers, so there shouldn't be any naming collisions. Any optional arguments would have their default value set to an empty string as a marker.

For some reason, mas upgrade can accept either app IDs or app names (it's the only command that accepts both). Since app IDs aren't guaranteed to be unique, it's not that great to accept them. I would propose changing text values here to also be bundle IDs. No one should need to match by app name. Moreover, we can have tab completion search through app names, bundle IDs, and app IDs to complete to either bundle IDs or app IDs.

Change SoftwareMapAppLibrary.installedApp(forBundleID:) to return [SoftwareProduct].