Skip to content

Output actual App Store name of an installed app - #1292

Open
MsfPablo wants to merge 1 commit into
mas-cli:mainfrom
MsfPablo:fix/installed-app-name-itunes-fallback
Open

Output actual App Store name of an installed app#1292
MsfPablo wants to merge 1 commit into
mas-cli:mainfrom
MsfPablo:fix/installed-app-name-itunes-fallback

Conversation

@MsfPablo

@MsfPablo MsfPablo commented Aug 3, 2026

Copy link
Copy Markdown

Summary

Fixes #784. InstalledApp derived name solely from the Spotlight attribute _kMDItemDisplayNameWithExtensions, which records an app bundle's on-disk name rather than its App Store name. Neither Spotlight nor Info.plist records the App Store name, so the output name was only an approximation — e.g. "WFMU Radio" (adamID 324175340) was output as just "WFMU".

Fix

Resolves each installed app's name via the iTunes Search API instead, reusing the existing Environment.lookupAppFromAppID abstraction that mas lookup and mas outdated already use, rather than adding a new HTTP call. Lookups run concurrently via the existing concurrentMap.

  • Apps the App Store doesn't know about (e.g. TestFlight apps) or whose lookup fails (e.g. offline) keep their approximated name — this is a best-effort upgrade, not a hard requirement.
  • InstalledApp.init(for:) has to stay synchronous, so the resolved name is applied afterward, in installedApps(matching:withFullJSON:), before apps are sorted by name.
  • concurrentMap's unused_declaration/periphery:ignore suppressions are removed since it's no longer unused.

Test plan

Added Tests/MASTests/Models/MASTests+InstalledApp.swift with 3 cases, following the existing test suite's conventions (fixture-based Environment.$current.withValue injection):

  • Uses the App Store name when the lookup succeeds
  • Falls back to the approximated name when the lookup throws (e.g. offline)
  • Keeps the approximated name when there's no ADAM ID (app not from the App Store)

swift build succeeds cleanly. I could not run swift test in my environment — it fails with error: no such module 'Testing' (the Swift Testing framework), but I confirmed this is a pre-existing environment limitation and not something this change introduced: the same error occurs on a clean checkout of main with no changes at all. I don't have a full Xcode install available, only Command Line Tools, which appears to be the gap. Happy to have CI confirm the test suite, or take pointers on getting Testing available locally.

`InstalledApp` derived `name` solely from the Spotlight attribute
`_kMDItemDisplayNameWithExtensions`, which records an app bundle's
on-disk name rather than its App Store name. Neither Spotlight nor
`Info.plist` records the App Store name, so the output name was only an
approximation; e.g., "WFMU Radio" (324175340) was output as "WFMU".

Resolve each installed app's name via the iTunes Search API instead,
reusing the existing `Environment.lookupAppFromAppID` abstraction that
`mas lookup` & `mas outdated` already use. Lookups run concurrently.
Apps that the App Store does not know about, such as TestFlight apps,
& apps whose lookup fails, such as when offline, keep their approximated
names.

`InstalledApp.init(for:)` must stay synchronous, so the resolved name is
applied afterwards, in `installedApps(matching:withFullJSON:)`, before
apps are sorted by name.

`concurrentMap(maxConcurrentTaskCount:_:)` is no longer unused, so its
`unused_declaration` & `periphery:ignore` suppressions are removed.

Fixes mas-cli#784
@sonarqubecloud

sonarqubecloud Bot commented Aug 3, 2026

Copy link
Copy Markdown

@rgoldberg

rgoldberg commented Aug 5, 2026

Copy link
Copy Markdown
Member

Thanks for submitting this.

Summary

This functionality won't be able to be added until #1226 is released (I am currently working on it), presumably in 7.2.0 (see why in Details below).

7.1.0 will be released after a few more days ensuring that the App Store remains in sync with local data.

If you want to submit PRs for other issues, I can:

  • discuss the mas roadmap so you know what might block PRs for issues from being released
  • help set up Swift Testing (I've only used it on Macs that have Xcode, but maybe I can help in some way)
  • answer questions about the existing code, standards, etc.

Details

I'm not sure if it's better to provide installed app names from iTunes Search or to use local app names. e.g., I personally prefer to see Pages (local) instead of Pages: Create Documents (iTunes Search).

Also, if you have multiple installations of the same app, local names distinguish between them.

It might be best to output the local names by default, but offer the option to fetch the iTunes Search names, too. Both could be included in the JSON output (I have ideas for—but haven't finalized—their respective keys).

iTunes Search app names should not be used until after some issues I'm currently working on have been resolved.

#1226 is required for this PR to be merged.

The other listed issues would be useful, and might also block this PR (TBD).

My relevant roadmap (small improvements & bug fixes might also be resolved, too, but the large issues are listed below):

Ignore project milestones: they're outdated & include tons of issues that will almost definitely not be released in the respective versions (they're lists of issues to think about thinking about).

#1226 allows selecting whichever name you prefer in the command line.

#1275 fetches additional data for apps more frequently, so I must cache fetched catalog apps per installed app to reuse the same results to provide multiple values.

#838 allows persistent settings, so you'll be able to persistently choose local names or iTunes Search names, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Output actual app name of an installed app, not an approximation

2 participants