How OneStore uploads your binaries: .ipa to App Store Connect, .aab to Google Play
Shipping to two stores means two separate upload workflows. You build your .ipa, open App Store Connect, navigate to the right version, wait for processing. Then you build your .aab, open Google Play Console, find the right track, upload there too. Two consoles, two sets of credentials, two places to make a mistake.
OneStore collapses that into one place. Here is exactly how the binary upload side works.
How .ipa uploads work
When you upload an .ipa through OneStore, a macOS worker delivers it to App Store Connect by running xcrun altool --upload-app— the same command-line uploader Xcode and Transporter use under the hood. That matters for one specific reason: the .ipa is never compiled or repackaged on our side. We pass the exact file you built straight to Apple's delivery infrastructure — the worker only reads the version strings out of your Info.plist, it never alters the archive.
To connect, you need a .p8 API key from App Store Connect, your Issuer ID, and your Key ID. Once those are in OneStore's credential vault, you do not touch them again. Everything is encrypted at rest with AES-256-GCM (authenticated encryption) at the application layer. Your keys never leave the vault.
From there: select the app, attach the .ipa, submit. The worker signs an App Store Connect API request with your .p8 and hands the binary to altool. Apple processes it on their end, exactly as it would if you had uploaded through Xcode or the Transporter CLI directly.
Rollout after the binary is accepted
Apple and Google handle rollout differently, and OneStore reflects that honestly rather than pretending they work the same way. Apple's phased release is automatic — a 7-day ramp from 1% to 100% that Apple itself controls. OneStore surfaces the state on the release timeline; if you want to pause or accelerate it, that adjustment lives in App Store Connect, and OneStore links you there. Google is different — see below, where you do drive the percentage from OneStore.
How .aab uploads work
For Google Play, OneStore connects via the Google Play Developer API (Android Publisher v3) using a service account JSON. You generate the service account in Google Cloud Console, grant it the right permissions in Play Console, and upload the JSON to OneStore once. After that, the connection is live.
When you upload an .aab, OneStore opens an edit, uploads the bundle, assigns it to a track, and commits — sending it directly to Google Play through the API. You choose the track — internal, alpha, beta, or production — and the binary goes where you point it.
The service account JSON is stored with the same AES-256-GCM encryption as your .p8 credentials. Same vault, same encryption, same security posture across both platforms.
Staged rollout from the dashboard
Unlike Apple's automatic ramp, Google's staged rollout is yours to drive — directly from the OneStore dashboard. Set the rollout percentage, monitor it, halt it, resume it, or push to 100% without switching back to Play Console. You can also promote a build across tracks (internal → production) without re-uploading the binary. For teams shipping frequent Android updates, that is a meaningful reduction in context-switching.
Why this fits the rest of the workflow
Binary upload is one piece. It fits cleanly into OneStore because the surrounding workflow is already there. Before you upload, you have already edited your metadata in one editor — live character counters enforcing the 30-character App Store title limit and the 30-character Google Play title limit at the same time. You have dropped one HD screenshot and let OneStore output every required format: iPhone 6.5" and 6.7", iPad, and Google Play phone and tablet sizes, all derived from that single source (Apple auto-scales the 6.7" image up to fill 6.9" device previews). Drift detection has flagged anything changed on the store side since your last edit.
By the time you upload the .ipa and .aab, the listing is ready. You are not going back to Photoshop. You are not copy-pasting descriptions between two consoles. The binary upload is the last step, not a separate workflow.
What OneStore does not do on the binary side
OneStore does not compile your app. It does not run your tests. It is not a CI/CD pipeline. If you need build automation, Codemagic and similar tools handle that upstream. OneStore picks up after the build is done: you bring the .ipa and .aab, we handle delivery and listing management.
This is intentional. Fastlane can automate builds and uploads via CLI, but it requires writing and maintaining scripts with no GUI. OneStore is the GUI layer — for developers who want to manage both store listings without touching a script.
Credentials and security
Both your .p8 and your service account JSON sit in the same encrypted vault — encrypted at rest with AES-256-GCM at the application layer. We use your credentials only for the actions you initiate inside the dashboard, and they are never used to compile anything. A Data Processing Agreement based on EU Standard Contractual Clauses is available on request at onestore.so/dpa.
Trying it without committing
The free plan covers 3 apps, both stores, no card required — and binary upload is part of the platform on the free tier, not a paid add-on. If you want to audit your existing listing before connecting credentials, the Store Listing Audit takes a store link and returns a score out of 100 — no account, no email required. When you are ready to handle the full workflow — metadata, screenshots, and binary uploads — from one place, you can start at OneStore.
FAQs
Does OneStore repackage or modify my .ipa before sending it to Apple?
No. A macOS worker delivers your .ipa to App Store Connect with xcrun altool --upload-app — the binary is not compiled, modified, or repackaged on our side. What you upload is what Apple receives.
What credentials do I need to connect my iPhone app to OneStore?
A .p8 API key from App Store Connect, your Issuer ID, and your Key ID — the same App Store Connect API credentials used by Transporter and Xcode for direct uploads.
How does OneStore connect to Google Play for .aab uploads?
Via the Google Play Developer API (Android Publisher v3) using a service account JSON. You generate the service account in Google Cloud Console, grant it the appropriate permissions in Play Console, and upload the JSON to OneStore once. After that, uploads go through the API directly.
Are my .p8 and service account JSON credentials stored securely?
Both are encrypted at rest with AES-256-GCM (authenticated encryption) at the application layer. A Data Processing Agreement based on EU Standard Contractual Clauses is available on request at onestore.so/dpa.
Can OneStore manage phased rollout after the binary is accepted?
It depends on the store. Apple's phased release is automatic and Apple-controlled — OneStore shows the state and links you to App Store Connect if you want to adjust it. For Google, yes: you set, monitor, halt, resume, or complete the staged rollout percentage directly from the OneStore dashboard, and promote across tracks without re-uploading.
Does OneStore replace Fastlane or Codemagic?
No. OneStore does not compile builds or run CI/CD pipelines. It handles delivery and listing management after the build is done. If you use Fastlane or Codemagic upstream, OneStore handles what comes after: metadata, screenshots, binary upload, and review management.