`eas device:create` (Developer Portal import) broken since v18.5.0 — apple-utils pagination

[kirstilynn]

Summary

eas device:create → "Developer Portal — import devices already registered" fails on v18.5.0 and later. v18.4.0 works. The only relevant dependency change between those versions is @expo/apple-utils 2.1.13 → 2.1.16, so the regression is in apple-utils.

Confirmed still broken on the latest v19.0.4.

Likely the JWT-auth flavor of the pagination bug from #3392 (cookie-auth flavor).

Repro

eas device:create
# → use <org> account: yes
# → Developer Portal — import devices already registered

Other registration methods (Website, Input manually) succeed — they don't hit pagination. .p8 + issuer + key id are good (curl against GET /v1/devices returns 200).

Output

|■■■■■| Fetching Apple devices...
The specified resource does not exist - The path provided does not match a defined resource type.
UnexpectedAppleResponse: ...
    at l.parseResponse (.../@expo/apple-utils/build/index.js:1:785175)
    at l.requestAndParseAsync (.../@expo/apple-utils/build/index.js:1:783558)
    at async t.ConnectResponse.fetchNextPagesAsync (.../@expo/apple-utils/build/index.js:1:787305)
    at async l.fetchAllModelsAsync (.../@expo/apple-utils/build/index.js:1:783164)
    at async findUnregisteredPortalDevicesAsync (.../eas-cli/build/devices/actions/create/developerPortalMethod.js:62:27)

Environment

eas-cli/19.0.4 darwin-arm64 node-v24.14.0, ASC API key auth.

Workaround

bun install -g eas-cli@18.4.0

[mathieu-benard-tb]

Confirming this on eas-cli/19.0.8 (latest as of today). Identical stack trace, JWT/ASC API key auth, ~33 devices on the team (so pagination is guaranteed
to kick in — Apple defaults to 20 per page).

The bug surfaces during eas build as well, not just eas device:create. When the build picks an ad-hoc device, registerMissingDevicesAsync in
provisioningProfileAdhoc.js calls Device.getAsync(), which paginates GET /v1/devices and crashes on the second page:

✖ Failed to handle Apple profiles
Failed to set up credentials.
The specified resource does not exist - The path provided does not match a defined resource type.
UnexpectedAppleResponse: ...
at l.parseResponse (.../@expo/apple-utils/build/index.js:1:785175)
at l.requestAndParseAsync (.../@expo/apple-utils/build/index.js:1:783558)
at async t.ConnectResponse.fetchNextPagesAsync (.../@expo/apple-utils/build/index.js:1:787305)
at async l.fetchAllModelsAsync (.../@expo/apple-utils/build/index.js:1:783164)
at async registerMissingDevicesAsync (.../eas-cli/build/credentials/ios/appstore/provisioningProfileAdhoc.js:15:24)
at async manageAdHocProfilesAsync (.../provisioningProfileAdhoc.js:83:21)
at async createOrReuseAdhocProvisioningProfileAsync (.../provisioningProfileAdhoc.js:167:84)

Root cause looks consistent with #3392 but in reverse: the fix from #3392 made getNextUrl() return pathname + search to keep cookie-auth requests on the
right host. Under JWT auth, baseURL is https://api.appstoreconnect.apple.com/v1/ and the absolute links.next URL has a pathname starting with /v1/....
Axios' combineURLs ends up producing https://api.appstoreconnect.apple.com/v1/v1/devices?cursor=... — hence Apple's path does not match a defined resource
type.

A direct curl GET /v1/devices with the same .p8 returns 200, so credentials and key permissions are fine.

Downgrading to eas-cli@18.4.0 (which pins @expo/apple-utils@2.1.13, pre-regression) resolves the issue. Confirming the workaround from this issue works.

Side effect for anyone else hitting this: failed eas device:create / eas build runs may leave an orphan device entry in EAS (visible in eas device:list
with Name: Unknown / Apple Team Name: Unknown) that was never propagated to Apple. After downgrading, clean it up with eas device:delete + eas credentials
→ delete the broken provisioning profile, then re-run the build.

A proper fix in getNextUrl() probably needs to branch on auth mode — or simply return the absolute URL when baseURL already covers /v1/, so axios uses it
as-is and doesn't double the prefix.

[sorinc03]

I traced this against expo/eas-cli main and the published @expo/apple-utils package versions up through 2.1.21. This still looks like a pagination URL normalization regression in @expo/apple-utils, not in the EAS command call sites.

The relevant behavior changed after the cookie-auth pagination issue in #3392: ConnectResponse.getNextUrl() now normalizes an absolute links.next URL to pathname + search. That is correct for Apple ID / cookie auth because it keeps paginated requests on the configured developer-mdn.apple.com base host.

For App Store Connect API key / JWT auth, though, ConnectClientAPI.getHostnameAsync() already returns a base URL ending in /v1/:

https://api.appstoreconnect.apple.com/v1/

Apple's pagination link is also under /v1, so returning parsed.pathname + parsed.search produces a relative URL like:

/v1/devices?cursor=...

Axios then combines that with the /v1/ base URL, which results in the failing double-prefix request:

https://api.appstoreconnect.apple.com/v1/v1/devices?cursor=...

A minimal fix is to keep the path-only normalization for cookie auth, but preserve the absolute links.next URL for token auth:

getNextUrl(): string | null {
  const next = this.data?.links?.next ?? null;
  if (!next) {
    return null;
  }

  try {
    const parsed = new URL(next);

    if (this.context.token) {
      return next;
    }

    return parsed.pathname + parsed.search;
  } catch {
    return next;
  }
}

That should preserve the #3392 fix for Apple ID sessions while avoiding /v1/v1/... under ASC API key auth. It also fixes both reported EAS paths because eas device:create and ad-hoc provisioning both call Device.getAsync(context) from @expo/apple-utils.

I could not find the public source location for @expo/apple-utils in expo/eas-cli; eas-cli currently just pins the package (2.1.19 on main). If there is a public repo/path for that package, I can put this into a PR there.