Rejected for something that wasn't in the docs
The rejection points at a guideline clause that takes a paragraph to unpick. You fix that one issue, resubmit, and get knocked back for something else. Every round of this costs two to seven days.
App Store Deployment
Live on both stores, handled end to end.
Getting an app onto the App Store and Google Play trips up plenty of development teams. Certificate errors, metadata rejections, a binary that fails validation. Each round of that can cost two to seven days. We run the whole process so your launch date holds.
- Setup and configuration for App Store Connect and Google Play Console
- Store listings, screenshots, and preview assets produced for both stores
- Binary signing, provisioning profiles, and release builds taken care of
- CI/CD set up so post-launch updates don't mean a full resubmission
The deployment tools we run releases through.
Why
Store submission fails more often than teams expect.
A lot of first submissions get rejected. It might be a gap in the privacy policy, a screenshot that's the wrong size, a metadata rule you didn't know about, or a binary entitlement error. Apple and Google both have long lists of requirements, and learning them one rejection at a time gets expensive when there's a launch date on the calendar.
Certificate and provisioning profile confusion
Distribution certificates, push notification entitlements, app identifiers, provisioning profiles. All of it stays murky until something breaks, and most teams find out what they didn't know right at submission time.
Screenshot and metadata rules that keep moving
The App Store wants specific screenshot sizes for each device family. Google Play wants a feature graphic, an 80-character short description, and a privacy policy URL. These requirements change with no warning.
No CI/CD for updates after launch
The first submission was done by hand and took a week. Every update after that needs the same manual slog, so bug fixes go out once a quarter when they could go out weekly.
The Process
How the work actually runs.
Each step has a clear deliverable and a written handoff, and we get your sign-off before moving to the next one.
01
Account and certificate setup
We configure App Store Connect and Google Play Console, create the app identifiers, and set up the distribution certificates and provisioning profiles. All of it is documented so future releases don't turn into detective work.
02
Store listing production
We write the store copy (name, subtitle, description, and keywords for the App Store; short and long descriptions for Play) and produce screenshots and preview videos at every required device size, written to help people actually find the app.
03
Release build and signing
Production builds with the signing configuration set up correctly, entitlements checked, and the privacy manifest filled in, which iOS 17 and up require. We validate the binary with the store's own tools before uploading it.
04
Submission and the review process
We submit, keep an eye on review, and handle it through. If a rejection comes back, we work out the cause, fix it, and resubmit, and we'll usually still hit the planned launch date.
05
CI/CD for life after launch
We set up CI/CD with Fastlane or EAS Build. A developer pushes a tag and the pipeline builds, signs, uploads to TestFlight or an internal track, and submits for review. After that, releases take minutes.
The Result
What you walk away with.
Real deliverables you can point to and outcomes you can measure. Not a slide deck.
Both storesday one
iOS and Android live on launch day
We plan the timeline backwards from your launch date so both stores go live together.
Zerosurprise rejections
Rejections dealt with before they hold you up
We check the build against Apple's and Google's guidelines before submitting. If a rejection still happens, it lands on us to sort out rather than on you.
Automatedfuture releases
A release pipeline you can run without us
CI/CD with Fastlane or EAS means a future update is just a tag push. The pipeline and the store accounts are yours.
Store listings that turn browsers into installs
Screenshots, descriptions, and keywords are written to win installs, not merely to clear the minimum bar for submission.
FAQ
Common questions.
Do we need developer accounts already, or can you set them up?
Either way works. We can create new accounts or use the ones you have. The Apple Developer Program costs $99 a year and Google Play is a one-time $25. We walk through setup with you and confirm billing and team access before the work begins.
How long does App Store review take?
For most submissions Apple reviews within 24 to 48 hours, though a first submission from a new account can take 2 to 5 days. Google Play usually reviews within a few hours to a couple of days. We build both windows into the launch timeline.
What happens if the app gets rejected?
We work out what triggered the rejection, fix it, and resubmit. Because we check against the guidelines before the first submission, rejections are uncommon. When one does land, what counts is fixing it quickly.
Who owns the App Store and Google Play accounts?
You do. The accounts are registered under your company and your billing, and you stay the owner with full admin access. We work inside your accounts with the access you grant, so there is no risk of your app being tied to an agency account you cannot control later.
How do you handle signing certificates and provisioning?
We set up the iOS distribution certificate, app identifiers, provisioning profiles, and push entitlements, and the Android signing key (or Play App Signing). Everything is documented and stored securely so future releases are repeatable. You keep ownership of the keys, which matters because a lost Android signing key cannot be replaced for an existing app.
Can you push updates without a full store resubmission?
For JavaScript and asset changes in React Native or Expo, yes: over-the-air (OTA) updates with EAS Update or CodePush let you ship fixes without a new store review, within the stores' rules. Anything that changes native code still needs a normal store submission, which the CI/CD pipeline makes quick.
What does it cost to publish on both stores?
Apple charges $99 per year for the Apple Developer Program and Google charges a one-time $25 for a Play Console account. Those are paid to Apple and Google directly under your accounts. Our deployment work is separate and scoped up front, so there are no surprise platform fees from us.
How long does the whole submission process take?
Account and certificate setup plus store listings typically takes a few days, then Apple review usually runs 24 to 48 hours (longer for a brand-new account) and Google Play a few hours to a couple of days. We plan the timeline backwards from your launch date and build the review windows in so both stores can go live together.
Can you publish under our existing accounts and brand?
Yes. We publish under your developer accounts, your app name, and your branding, so the listing shows you as the developer. If you do not have accounts yet, we set them up in your name and hand over full ownership.
Do you handle beta testing before the public release?
Yes. We set up TestFlight for iOS and an internal or closed track on Google Play so your team and selected users can test the real signed build before it goes public. This catches store-specific issues and lets you sign off on the exact build that will ship.
Contact UsEmail
[email protected]
Have a project in mind? Let's build it.
Tell us where the project stands right now. Within one working day we'll come back with a straight read on scope, timeline, and cost. There's no commitment in asking.
Office
Surabaya, Indonesia
Starting price
From USD 4,000
Typical projects: USD 4,000–25,000