Annotated File Examples: .p8, service-account JSON, ExportOptions.plist

All examples below are synthetic. Real key material is randomized and the emails / IDs are made up. Never paste your actual private keys into any third-party site, including this one.

1. AuthKey_ABC123XYZ0.p8

The private key Apple hands you once when you create an App Store Connect API key. Used to sign JWTs that authenticate against the App Store Connect API. Apple's side stores only the matching public key.

PEM framing. The -----BEGIN PRIVATE KEY----- / -----END PRIVATE KEY----- lines mark this as a PEM-encoded key file. Everything in between is one big base64 blob.

Algorithm. App Store Connect API keys are ES256 — ECDSA on the P-256 curve. The encoded bytes include an OID that identifies this, so the library reading the file doesn't have to guess.

Filename carries the Key ID. The 10 characters between AuthKey_ and .p8 are your Key ID. xcrun altool relies on this convention to find the right file when you pass --apiKey <KeyID>.

Downloadable once. Apple only serves the .p8 at creation time. Lose it → revoke the key and generate a new one. This is on purpose: if Apple kept a copy, its servers would be a tempting target.

2. service-account.json

What Google Cloud hands you when you generate a key for a service account. Used to sign JWTs that you exchange for OAuth 2.0 access tokens against the Play Developer API.

{
  "type": "service_account",
  "project_id": "my-company-deploy",
  "private_key_id": "a1b2c3d4e5f6...",
  "private_key": "-----BEGIN PRIVATE KEY-----\nMIIE...\n-----END PRIVATE KEY-----\n",
  "client_email": "lingcode-deploy@my-company-deploy.iam.gserviceaccount.com",
  "client_id": "102938475610293847561",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/lingcode-deploy%40..."
}

type Always "service_account" for this flow. Google also issues user-account keys in a similar JSON format; the type string is how LingCode distinguishes them.

private_key An RS256 (RSA-2048) private key, inline as an escaped PEM string. LingCode strips the header/footer lines and decodes the base64 body to pull out the raw RSA key material.

private_key_id Identifies this specific key within the service account (the account can have multiple). Rotating? Create a new key, deploy the new JSON, then delete the old private_key_id in Cloud Console.

client_email The service account's identity. LingCode puts this in the JWT's iss (issuer) claim so Google's token server knows who's asking. Also the email address you paste into Play Console → API access → App permissions to grant upload rights.

token_uri The OAuth 2.0 endpoint LingCode POSTs the signed JWT to, receiving a 1-hour access token in return.

Other fields are metadata Google Cloud uses for its own reference. LingCode only needs client_email + private_key + (indirectly) token_uri.

3. ExportOptions.plist

LingCode writes this file to build/ExportOptions.plist on the fly, then hands it to xcodebuild -exportArchive. It's what tells Xcode how to turn an .xcarchive into a distributable .ipa or .app.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>method</key>
  <string>app-store</string>
  <key>teamID</key>
  <string>HPTTZS5J27</string>
  <key>signingStyle</key>
  <string>automatic</string>
</dict>
</plist>

method = app-store Tells Xcode which of its four distribution modes to use. Others: ad-hoc (limited device list), enterprise (internal distribution), development (dev builds). LingCode only ships App Store uploads, so this is always app-store.

teamID = HPTTZS5J27 Your Team ID, copied from the App Store pane in Magic Deploy. Must match the team that owns the Apple Distribution certificate in your keychain — if it doesn't, exportArchive fails with "no signing certificate matching team ID."

signingStyle = automatic Tells Xcode to auto-generate / refresh the provisioning profile using the team's cert. The alternative, manual, requires you to specify profile UUIDs and signing identities explicitly. LingCode assumes automatic — don't flip your Xcode target to manual signing or this export will fail.

Missing keys. No bundle ID, no profile UUID, no provisioning-profile specifier dictionary. Those are all Xcode's job to figure out at export time from your project's settings. LingCode keeps the plist minimal on purpose — simpler plists fail in more predictable ways.

How these three files talk to each other

Worth seeing the chain end-to-end, for iOS/macOS:

You configure your Apple Developer team → this gets you a Team ID.
The Team ID lands in ExportOptions.plist, which xcodebuild uses to find your signing cert and create/refresh a profile.
Your API key's Key ID, Issuer ID, and .p8 authenticate the upload call to App Store Connect — separate from the signing that happened during export.

For Android, the service-account JSON is the only credential you need: it authenticates the entire flow (OAuth token fetch → edit creation → AAB upload → commit).

Where to see the real files on your machine

Your .p8 — wherever you saved it when Apple offered the one-time download (~/Downloads/AuthKey_ABC123XYZ0.p8 by default).
Your service-account JSON — wherever you saved it from Cloud Console → IAM → Service accounts → Keys → Create new key.
The generated ExportOptions.plist — at <your project>/build/ExportOptions.plist after a LingCode deploy attempt. Open it in a text editor to confirm the Team ID matches what you typed in.

More reference material:

Glossary · How code signing works · JWT auth · Service accounts

Pick a deploy target →

Annotated deploy files

1. AuthKey_ABC123XYZ0.p8

2. service-account.json

3. ExportOptions.plist

How these three files talk to each other

Where to see the real files on your machine