> ## Documentation Index > Fetch the complete documentation index at: https://docs.hiveku.com/llms.txt > Use this file to discover all available pages before exploring further. # Mobile Credentials > Connect your Apple Developer and Google Play accounts so Hiveku can build and submit your app on your behalf To ship a native binary to the App Store or Google Play, Hiveku needs credentials that let it act on your behalf — sign iOS builds, upload to TestFlight, push Android releases to Play Console. These are **your** credentials, owned by your developer accounts, stored encrypted in AWS Secrets Manager. Hiveku never owns the apps it ships for you; you do. ## Where credentials live The Mobile Credentials page lives at `/dashboard//mobile-credentials`. It's an Expo-only tab that appears in the project nav. Each platform (iOS and Android) is a separate card with three states: * **Not connected** — shows the inline 5-step setup guide and an upload form * **Connected** — shows non-secret metadata (Apple Team ID, Apple ID, Last verified time) plus inline toggles for auto-submit and Play track * **Connected but verification failed** — same as Connected with a red banner explaining the specific error Credentials are stored encrypted (KMS) in AWS Secrets Manager keyed by your Hiveku project ID. They're never written to disk in plaintext, never sent to third parties, and never visible in the Hiveku UI after upload. ## Connecting Apple Developer **Prerequisite:** an active [Apple Developer Program](https://developer.apple.com/programs/enroll/) membership (\$99/year). Allow \~24 hours after enrolling for Apple to verify your account before generating API keys. ### What you upload | Field | What it is | | -------------- | ---------------------------------------------------------------------------------------------------------------------------- | | `.p8` file | App Store Connect API private key. One-time download. | | Apple Team ID | 10-character alphanumeric. Found at [developer.apple.com/account](https://developer.apple.com/account) → Membership Details. | | Apple ID | The email address of the Apple ID that owns the developer account. | | ASC API Key ID | 10-character alphanumeric. Shown next to the key in App Store Connect → Users and Access → Integrations. | | ASC Issuer ID | UUID. Shown at the top of the ASC API Keys page. | ### Step-by-step Open [App Store Connect → Users and Access → Integrations → App Store Connect API](https://appstoreconnect.apple.com/access/api). Click **Generate API Key**. Name it `Hiveku`. Pick the **Admin** role (recommended for first builds — see "Why Admin?" below). Click Generate. Apple offers the `.p8` as a one-time download. **Save it now.** If you close the page without downloading, you have to revoke the key and generate a new one. Apple does not let you redownload. Note the **Issuer ID** at the top of the page (a UUID) and the **Key ID** in the row of the key you just created (10 chars). Open [developer.apple.com/account](https://developer.apple.com/account) → **Membership Details** → copy the 10-character Team ID. On the Mobile Credentials page, paste the .p8 file, Apple ID email, Apple Team ID, ASC Key ID, and ASC Issuer ID. Click **Connect Apple Developer**. After upload, Hiveku immediately runs preflight validation: signs an ES256 JWT against Apple's `/v1/users` endpoint and confirms the credentials are accepted. You'll see a green banner within 5 seconds. ### Why Admin role? The **Admin** role is required for *automatic* iOS App Store record creation on your first iOS build. Hiveku calls `POST /v1/bundleIds` and `POST /v1/apps` to register the bundle ID with Apple and create the App Store Connect app entry — saving you a manual setup step. If your key is **App Manager** role only: * Builds and submits will still work for apps that *already exist* in App Store Connect * The first iOS build will fail with a clear error: "Your ASC API key role is App Manager — auto-creating the App Store record requires Admin" * Workaround: manually create the app in App Store Connect with the bundle ID Hiveku shows you (`com.hiveku.<12-hex>`), then re-trigger the build If you're security-conscious about granting Admin access, the recommended flow is: use Admin for the first build, then **regenerate** the key as App Manager once the App Store record exists. ### Common errors | Banner says... | What it means | Fix | | ------------------------------------------------------------------------------------------ | ------------------------------------------------------ | -------------------------------------------------------------------------------------- | | "App Store Connect rejected the API key" | Wrong Key ID, Issuer ID, or .p8 file is malformed | Re-copy the IDs; if the .p8 looks corrupted, revoke and regenerate | | "API key does not have App Manager access" | Key was generated with Developer or lower role | Re-generate the key in ASC with App Manager (or Admin) role | | "Failed to sign JWT — the .p8 file is likely malformed" | The file you uploaded isn't a valid PKCS#8 or SEC1 PEM | Re-download from Apple; make sure it starts with `-----BEGIN PRIVATE KEY-----` | | "Your ASC API key role is App Manager — auto-creating the App Store record requires Admin" | First build can't auto-create the iOS App Store entry | Either upgrade the key to Admin, or manually create the app in App Store Connect first | ## Connecting Google Play **Prerequisites:** * A [Google Play Developer](https://play.google.com/console/signup) account (\$25 one-time) * A Google Cloud Console account (free; same Google login as Play Console works) * Your app entry **already created** in Play Console (Google Play API can't create the very first version of an app — only updates) ### What you upload | Field | What it is | | -------------------- | ---------------------------------------------------------------------------------------------------- | | Service Account JSON | The credentials JSON for a Google Cloud service account that has Play Console release-manager access | | Initial Play Track | Where new releases land. Default: **Internal testing** (safest — only invited testers see it). | ### Step-by-step Open [Google Cloud Console → IAM → Service Accounts](https://console.cloud.google.com/iam-admin/serviceaccounts). Click **Create Service Account**. Name it `hiveku-publisher`. **No project roles needed** at this step — Play Console grants its own permission separately. Open the service account → **Keys** → **Add Key** → **Create new key** → **JSON**. Save the downloaded file securely. Open [Play Console → Setup → API Access](https://play.google.com/console). Link your Google Cloud project. Find the `hiveku-publisher` service account in the list and grant it **Release Manager** role (must include "Release apps to production", "Manage releases", and "Manage testing tracks"). Play Console → **All apps** → **Create app**. Set the package name to the exact `com.hiveku.` value shown on the Mobile Credentials page (under "App identifier"). Once the app exists in Play Console, Google's API can update it on subsequent builds. Back on Mobile Credentials, upload the JSON file. Pick the Play track (default: Internal testing). Click **Connect Google Play**. Hiveku's preflight validation: signs an RS256 JWT with the service account's private key, exchanges it for a Google OAuth2 access token, and creates a temporary Play Console edit transaction (auto-cleaned-up to avoid leaking edit slots). Three possible outcomes: * **Green** — credentials work AND the app exists in Play Console with proper permissions * **Amber** — credentials work but the app doesn't exist in Play Console yet (loop back to Step 4) * **Red** — service account doesn't have Play Console access (verify the Release Manager role in API Access) ### Common errors | Banner says... | What it means | Fix | | -------------------------------------------------------------------- | ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | "Service account is authentic but has no Google Play Console access" | Service account exists in Google Cloud but isn't linked in Play Console | In Play Console → Setup → API Access, grant Release Manager role to this service account | | "App doesn't exist in Google Play Console yet" | Credentials work but the app entry hasn't been created | Play Console → All apps → Create app, use the bundle ID from Hiveku | | "Service account JSON is invalid or disabled" | The JSON is malformed or the service account was disabled in Google Cloud | Re-download the JSON; check that the service account is enabled | ## Auto-submit settings Each platform has an **Auto-submit** toggle. Default is on. * **Auto-submit on (default):** when a Build & Ship completes successfully, Hiveku immediately submits the binary to TestFlight (iOS) or your configured Play track (Android). The build → submit chain happens at EAS without intervention. * **Auto-submit off:** the build finishes and you get the binary URL but no submission is triggered. Useful for QA-conscious teams who want to review the build artifact before pushing to testers. The toggle changes only affect *future* builds. Builds already in flight retain whatever auto-submit setting they were enqueued with. ## Play track configuration The Android side has a **Play track** selector. Builds with auto-submit on land in this track: | Track | Audience | When to use | | -------------------------- | -------------------------- | --------------------------------------------------------------------- | | **Internal testing** | ≤100 invited testers | Default. Best for early QA. Releases are available immediately. | | **Closed testing (alpha)** | Invited testers + groups | Slightly larger circle. Releases need Google review (\~hours). | | **Open testing (beta)** | Anyone with the opt-in URL | Public beta. Releases need Google review. | | **Production** | All Play Store users | Fully public. Releases need full Google review (1-3 days first time). | Most teams stay on Internal testing through the development phase, then switch to Production when shipping a 1.0 release. ## Disconnecting credentials Click **Disconnect** in the Connected card. Hiveku immediately: 1. Deletes the encrypted credential from AWS Secrets Manager 2. Removes the platform metadata from `expo_config.ios` (or `expo_config.android`) 3. Clears the corresponding row in the credential cache Disconnecting does NOT cancel any in-flight builds — those finish using the credentials they were enqueued with. Subsequent Build & Ship attempts will fail with a "credentials missing" error until you reconnect. Disconnecting your iOS credentials does not revoke the .p8 key on Apple's side. If you suspect the key was compromised, also revoke it in App Store Connect → Users and Access → Integrations → revoke the key, then generate a new one. ## Re-verifying credentials The **Verify credentials now** button on each Connected card re-runs the preflight validation. Useful when: * You changed the app entry in Play Console and want to confirm Hiveku still has access * You suspect Apple revoked your API key and want to confirm * Your build keeps failing at submit time and you want to isolate whether it's a credential issue or a code issue Verification takes \~5 seconds. Last-verified timestamp updates on success. The original credentials are not modified. ## How Hiveku stores credentials Each credential goes through this path: 1. Customer uploads via the form (multipart POST) 2. Server-side validates format (PEM header for .p8, valid JSON for service account) 3. Encrypts via AWS KMS and writes to AWS Secrets Manager (key: `hiveku-project-secrets/`) 4. Persists non-secret metadata to `website_projects.expo_config` (Apple Team ID, Apple ID, Issuer ID, Key ID for iOS; Application ID, track for Android) 5. Build pipeline pulls the encrypted credential into a temp directory at build time, writes it as a file inside that temp dir, hands the path to `eas-cli`, then deletes the temp dir on completion The credential is in plaintext only inside the temp dir for the \~30 seconds the build is being enqueued. After that it's encrypted at rest until the next build. ## What's next Trigger your first build now that credentials are connected. Understand which package additions need a Build & Ship vs an OTA update.