Mobile Credentials

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.

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/<projectId>/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 membership ($99/year). Allow ~24 hours after enrolling for Apple to verify your account before generating API keys.

​

What you upload

​

Step-by-step

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

​

Connecting Google Play

Prerequisites:

• A Google Play Developer 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

​

Step-by-step

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

​

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: 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.

​

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/<project-id>)
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