By hand
- One machine, one account, metadata somewhere.
App Store release without the Mac under the desk
The build is the small part. Signing, metadata, screenshots, version numbers, two or three stores — that is the afternoon. It should sit in the same pipeline as everything else.
- App Store, Play Store, Microsoft Store from the project, not a spreadsheet
- iOS build on macOS in the cloud. The office Mac can die.
Portal or pipeline
With the commit
- Signing and upload run when the pipeline is green.
-
App StoreApple releases with prepared metadata and assets.
-
Google PlayPlay Store listings populated automatically.
Powered by Fastlane
Store releases rarely fail at compile. They fail on certificates, screenshots and the person who is on leave. Automating means putting those pieces in the pipeline that already builds the repo.
Shipping store releases by hand versus through the platform
This shows which steps a manually assembled mobile release puts on your team and how much of that the Application Platform covers.
| Task |
With the Application Platform
|
Set up manually
|
|---|---|---|
| Producing iOS and Android builds | Fully covered: The pipeline builds Flutter, Expo and native projects by the same rules | Not offered: Local builds on whichever machine is free, results hard to reproduce |
| A macOS environment for iOS | Fully covered: macOS machines in the cloud are part of the build infrastructure | Partly covered: Your own Mac or a rented runner, including Xcode upkeep |
| Managing signing material | Fully covered: Android keystores, Apple credentials and Azure artifact signing are stored in the platform | Not offered: Certificates and keystores sit with individuals, and losing one is a real risk |
| Maintaining store metadata | Fully covered: An editor with section navigation and language and platform badges inside the project | Not offered: The same copy maintained twice or three times across portals |
| Preparing screenshots | Fully covered: Screenshots are uploaded and cropped to the required formats in the editor | Not offered: Cropping in an image editor after looking up formats per store and device |
| Per-language changelogs | Fully covered: Release notes kept per language inside the project and versioned with it | Not offered: Copy and paste into store forms, with versions drifting apart |
| Google data safety declarations | Fully covered: The data safety details are part of the metadata editor | Not offered: Filled in by hand in the Play Console |
| Versioning and build numbers | Fully covered: Versioning happens in the pipeline and follows the state of the repository | Not offered: Counted up manually, with uploads rejected for duplicate build numbers |
| Submission and review status | Fully covered: Releases are triggered from the platform, with status visible per repository | Partly covered: Separate portals, different states, tracking kept in a side note |
| Serving the Microsoft Store too | Fully covered: Available as a third store from the same project | Not offered: A separate process, usually manual and rarely written down |
Green means fully covered, amber partly, grey not offered. Store review times themselves do not change; everything before them does.
As of 9 September 2026. This comparison describes typical workflows and can differ from project to project. Logos are trademarks of their owners and are used only to identify the product.
Limits
- Review stays review Apple and Google still review. Automation does not replace approval, only the scavenger hunt for artefacts.
Pricing model
You pay store accounts to Apple and Google. The platform runs the chain, not the store fees.
Pipeline for Customer App
test
build
publish
release
How an app reaches the stores
Four steps from project creation to submission.
-
Create a mobile project
Pick Flutter, Expo or a native iOS or Android project. Repository, structure and pipeline are created alongside it.
-
Add store access
Apple credentials, Play Store access, the Android keystore and, if needed, Azure artifact signing are stored in the platform.
-
Fill in the listing
Titles, descriptions, keywords, screenshots, per-language changelogs and the Google data safety details are maintained in the editor.
-
Trigger the release
The pipeline builds, signs and uploads. You track the state per repository, and the store takes over for the review.
Frequently asked questions
Which stores are supported?
The Apple App Store, Google Play Store and Microsoft Store, all three from the same project. Metadata is maintained in one place, with badges for language and platform. The review itself still sits with each provider.
Do I need my own Mac for iOS builds?
No. The platform provides macOS machines in the cloud that run iOS builds and signing in the pipeline. Interactive macOS workspaces come next; under Workspaces you currently pick Ubuntu.
How are certificates and keystores stored?
In the platform: Android keystores, Apple credentials and Azure artifact signing. The benefit is resilience, because a keystore that exists only on one laptop is a well-known Android failure mode. Access is governed by roles and project membership.
Can I adapt the pipeline?
Yes. The platform runs on GitLab CI and the pipeline configuration lives readably in your repository. You can add stages, change conditions or plug in your own scripts. The prepared configuration is a starting point rather than a closed black box.
Does this make store review faster?
No, review times at Apple, Google and Microsoft stay what they are. Everything before that is automated: build, signing, metadata, screenshots, changelogs and upload. That shortens the gap to submission and cuts rejections from inconsistent details.
Ship your next release without the manual work
Register for free, create a mobile project and see how far the pipeline gets towards a finished store listing.