`get` fails for PL App Store; `install` succeeds (macOS 26.5, mas 7.0.0)

[wojteksbt]

Configuration

mas    7.0.0  (rev 7c70ffdfd9f71a654300a78b3b627782e6abe1b4)
slice  arm64
swift  6.3 (swiftlang-6.3.0.123.5 clang-2100.0.123.102)
driver 1.148.6
store  PL
region PL
macos  26.5 (25F71)
mac    MacBookAir10,1 / Apple M1
arch   arm64

Bug description

For an app that the Apple ID already owns but which is not present on disk, mas get <id> exits non-zero with Error: No downloads initiated for ADAM ID <id>. mas install <id> against the same id in the same session succeeds.

The unified log shows mas get routing through SSPurchase / StorePurchaseBatchOperation / PurchaseOperation with bagType 1 <buyProduct> and isUpdate=NO, isRedownload=NO — i.e. the buy-product pathway, not a redownload. The store responds with the dialog Purchase of this item is not currently available. and the batch is cancelled; mas translates that into Error: No downloads initiated. mas install apparently exercises a different (redownload) path which the store does allow for owned items.

This was first surfaced against brew bundle in Homebrew/brew#22270, fixed by Homebrew/brew#22271 with a mas install → mas get fallback. The Homebrew maintainers (@rgoldberg) asked for log stream evidence to be filed upstream here.

Log evidence (key lines, full capture available on request)

Captured with:

$ /usr/bin/log stream --level debug \
    --predicate 'process == "mas" OR process == "storedownloadd" OR process == "appstoreagent" OR process == "storeagent" OR process == "commerce" OR subsystem == "com.apple.commerce" OR subsystem == "com.apple.storekit" OR subsystem == "com.apple.AppStoreDaemon" OR subsystem == "com.apple.commerce.client"'

High-signal lines during the failing mas get (kbsync / DSID / account ID redacted):

SSPurchase: purchasesGroupedByAccountIdentifierWithPurchases is returning 0:(null):1544743900
StorePurchaseBatchOperation: Operation requires bag 0
SSPurchase: needsAuthentication because appleID is nil
    (<SSPurchase: 0x… - itemIdentifier=1544743900,
     buyParams=productType=C&price=0&pg=default&appExtVrsId=0
              &pricingParameters=STDQ&macappinstalledconfirmed=1
              &salableAdamId=1544743900,
     isUpdate=NO, isRedownload=NO, isVPP=NO, …>)
StorePurchaseBatchOperation: Running 1 purchase operations
PurchaseOperation: Operation requires bag 1
PurchaseOperation: Loaded required bag type 1 successfully
PurchaseOperation: Issuing purchase request:
    kbsync=<REDACTED>&productType=C&pricingParameters=STDQ
   &salableAdamId=1544743900&pg=default&price=0&appExtVrsId=0
   &macappinstalledconfirmed=1
    for storeClient <ISStoreClient: …> (bagType 1 <buyProduct>)
PurchaseOperation: didAuthenticateWithDSID: adding touchID headers { … }
    "/inApps/v1/inAppRegrantPurchaseHistory",
    inAppRegrantPurchaseHistory
PurchaseOperation: Purchase (kbsync=<REDACTED>&…&salableAdamId=1544743900&…) failed, but had dialog: {
    message = "Purchase of this item is not currently available.";
}
PurchaseOperation: User selected (OK)
StorePurchaseBatchOperation: Cancelling 1 purchases from batch after error: (null)
StorePurchaseBatchOperation: Message tracing com.apple.MacAppStore.purchase - {
    "dialog_message" = "Purchase of this item is not currently available.";
    …
}

Note isUpdate=NO, isRedownload=NO and bagType 1 <buyProduct> — mas get is going through the buy bag, not the redownload bag. For an already-owned free app on the PL store, the store responds Purchase of this item is not currently available and cancels the batch.

Hypothesis (mechanism)

mas get in 7.0.0 (commit 7c70ffd) drives the buy-product path even for apps already in the account's purchase history. The store rejects the no-op "purchase" with Purchase of this item is not currently available and the cancel surfaces as No downloads initiated. mas install apparently exercises the redownload path (isRedownload=YES / a different bag) which the store allows for owned items — which is why it succeeds against the same ID in the same session.

If accurate, candidate fixes:

• have get first check purchasesGroupedByAccountIdentifierWithPurchases membership and route to the redownload path when the item is already owned, or
• treat the Purchase of this item is not currently available cancel as a hint to retry via the redownload path, or
• merge the get and install code paths (or document the difference and have get fall back to install internally).

Hypothesis (regional — EU Digital Markets Act?)

The asymmetry between @rgoldberg's US-store success (per Homebrew/brew#22271) and the PL-store failure on the same mas 7.0.0 / macOS 26.5 versions is suggestive. EU storefronts have been re-architected for DMA compliance over 2024–2025 (alternative-distribution support, purchase-flow changes, anti-steering rules). It is plausible — but unverified — that the buy-product path now returns Purchase of this item is not currently available for already-owned free apps on EU-region accounts as part of those changes, whereas the US store still permits the no-op "purchase" and routes it into a redownload internally.

Testable: if the reproducer fails on other EU storefronts (DE, FR, IT, ES, …) on the same versions, regional store policy is the most likely driver. If it passes on UK (post-Brexit, outside the DMA) or fails uniformly across non-EU storefronts as well, region/regulation isn't the cause and the bug is elsewhere (per-app metadata, regional bag contents, account flags, …). Would also explain why this regression didn't surface during pre-release testing on a US-store account.

References

• bundle: mas get regression — fails for purchase-history apps not on disk Homebrew/brew#22270 — brew bundle fails for purchase-history apps on macOS 26.5 / mas 7.0.0
• bundle: try mas install before falling back to mas get Homebrew/brew#22271 — merged fix: brew bundle tries mas install before falling back to mas get
• mas commit 738ab965ce — bundle: use 'mas get' instead of 'mas install' (introduced the asymmetry that brew bundle exposed)

Steps to reproduce

## App is in the Apple ID's purchase history and currently installed on disk
$ mas list 1544743900
1544743900  Hush  (1.0.18)
## Uninstall (moves /Applications/Hush.app to Trash)
$ mas uninstall 1544743900
Uninstalled '/Applications/Hush.app' to '/Users/<user>/.Trash/Hush.app …'
## Confirm not installed
$ mas list 1544743900
Error: No installed apps with ADAM ID 1544743900
Warning: No installed apps found
## `mas get` against an owned app that is not on disk — fails
$ mas get 1544743900
Error: No downloads initiated for ADAM ID 1544743900
$ echo $?
1
## `mas install` against the same ID in the same session — succeeds
$ mas install 1544743900
==> Downloading Hush Nag Blocker (1.0.18)
==> Downloaded Hush Nag Blocker (1.0.18)
==> Installing Hush Nag Blocker (1.0.18)
==> Installed Hush Nag Blocker (1.0.18) in /Applications/Hush.app

@rgoldberg's test on macOS 26.5 / mas 7.0.0 US-store with PiPifier (1160374471) passes (per Homebrew/brew#22271). The reproducer above is the same shape (uninstall → get → install) on a PL-store account and still fails at the get step — so the delta isn't "session-fresh vs old purchase".

[rgoldberg]

Do you know anyone else with a PL App Store account, or some other EU App Store account, who hasn't ever gotten one of the apps that fails for a subsequent get for you?

If so, can you have them get one of the problem apps, uninstall it, then get it again?

Can you try get for some app that you've never gotten before? I cannot remember if you've tried that already.

The more regions we test, the better. I might be able to get a friend to test the UK App Store, but if you know UK people, they'd be useful, too.

Thanks for all the detail, and for future help.

[rgoldberg]

@wojteksbt At some point, I accidentally locked this issue from the GitHub app. I don't know how it happened, but it's unlocked now.

[wojteksbt]

Re: #issuecomment-4464242502 — "Can you try get for some app that you've never gotten before?"

Yes — tested today on PL App Store with PDFgear: PDF Editor & Reader (ADAM ID 6469021132, free, kind=mac-software, available on PL store, never installed and not in this account's purchase history). Same mas 7.0.0 / macOS 26.5 / arm64 / store=PL / region=PL setup as in the original report.

Result

$ mas list 6469021132
Error: No installed apps with ADAM ID 6469021132
Warning: No installed apps found

$ mas get 6469021132
Error: No downloads initiated for ADAM ID 6469021132
$ echo $?
1

Identical error string to the Hush 1544743900 case from the original report, despite this being a never-purchased app. mas install was not run as a control for this never-owned ID (to avoid actually installing on the test account).

Log evidence (DSID / kbsync / touchID headers redacted)

SSPurchase: purchasesGroupedByAccountIdentifierWithPurchases is returning  0:(null):6469021132
StorePurchaseBatchOperation: Operation requires bag 0
SSPurchase: needsAuthentication because appleID is nil
    (<SSPurchase: 0x… - itemIdentifier=6469021132,
     buyParams=productType=C&price=0&pg=default&appExtVrsId=0
              &pricingParameters=STDQ&macappinstalledconfirmed=1
              &salableAdamId=6469021132,
     isUpdate=NO, isRedownload=NO, isVPP=NO, isDSIDLess=NO,
     managedUUID=(null), accountIdentifier=(null), purchaseType=0>)
StorePurchaseBatchOperation: Running 1 purchase operations
PurchaseOperation: Operation requires bag 1
PurchaseOperation: Loaded required bag type 1 successfully
PurchaseOperation: Issuing purchase request:
    kbsync=<REDACTED>&productType=C&pricingParameters=STDQ
   &salableAdamId=6469021132&pg=default&price=0&appExtVrsId=0
   &macappinstalledconfirmed=1
    for storeClient <ISStoreClient: …> (bagType 1 <buyProduct>)
PurchaseOperation: didAuthenticateWithDSID: adding touchID headers { … }
PurchaseOperation: Purchase (kbsync=<REDACTED>&…&salableAdamId=6469021132&…) failed, but had dialog: {
    message = "Purchase of this item is not currently available.";
}
PurchaseOperation: User selected (OK)
StorePurchaseBatchOperation: Cancelling 1 purchases from batch after error: (null)
StorePurchaseBatchOperation: Message tracing com.apple.MacAppStore.purchase - {
    "dialog_message" = "Purchase of this item is not currently available.";
    …
}

Implication

The error path is identical whether the item is in the account's purchase history or not. The hypothesis in the issue body ("mas get drives the buy-product path even for apps already in the account's purchase history") was too narrow — on this PL-store account the buy-product path itself returns Purchase of this item is not currently available for any free Mac app, regardless of prior ownership. mas install succeeds for owned items only because it routes through the redownload path; the buy-product bag appears to be uniformly unhealthy on this storefront.

One additional observation that is not in the issue body: purchasesGroupedByAccountIdentifierWithPurchases returns 0:(null):<ADAM_ID> for both the owned and the never-owned case here. If that API is supposed to surface the calling account's purchase history for the item, it returning 0 even for an item the account demonstrably owns (Hush is still in mas list for this account when installed) is a second signal that something on the storefront's purchase-membership side is unhappy.

Remaining region testing

I've also run it on a second iCloud account so far; it's another PL-region account (so not the broader-EU coverage you asked for), and the result is the same.

[rgoldberg]

Thanks for the detail.

Can you try to get one of these apps via the App Store GUI (not via mas), providing the log stream & any other relevant data?

Does it get & install or do you also get an error? After any error, does the App Store think you now own the app?

If it doesn't get & install, then there shouldn't be anything that mas can really do except offer a command (maybe an existing one) that first attempts get then attempts install (or vice versa).

If it doesn't get and/or install, then the App Store probably uses either different arguments or a different Apple private framework function to get apps than does mas.

[rgoldberg]

@wojteksbt Any luck trying the testing from #1253 (comment)?

Thanks for any help.