App Store & Google Play Publishing Support

Your build runs on your phone. The store console disagrees. A submission comes back citing a guideline number nobody has read, or pointing at a privacy answer that does not match the SDK list inside the binary. A week disappears and the launch date moves.

Releasing a mobile app is a repeating process. Every version touches developer agreements, signing credentials, listing assets, test tracks, privacy declarations, and a review queue whose rules change between releases. We run that for iOS and Android products, from a first submission to the rollout of version 4.2 on a Friday evening.

What publishing work covers

The console is only part of it. A release starts with developer accounts and agreements, tax and banking details, organisation enrolment documents, and app identifiers that match across both stores. Then the listing: name, subtitle, description, keywords, category, age rating, privacy policy URL, screenshots for every required device size, and the Play feature graphic.

Signing follows: certificates, provisioning profiles, entitlements, Play App Signing, and the pipeline that produces the artifact. TestFlight groups and Play internal or closed tracks come next, with tester lists that expire. Then release controls: phased release, staged rollout, version codes, notes, and a halt button we hope not to use.

Privacy declarations run across all of it: Apple privacy labels, the Play Data safety form, App Tracking Transparency, and account deletion.

Who it is for

Teams arrive at a few points: founders submitting a first build who have never opened the Resolution Center, companies whose release process lives on one person's laptop, businesses that inherited an app and cannot find the keystore, product teams with no spare capacity during release weeks, and groups whose AI-coded prototype now has to pass review.

Apps that store personal data or sell digital content carry a larger compliance surface, cheaper to plan than to repair after a rejection.

What we deliver

• Developer accounts opened, audited, or repaired: agreements, roles, identifiers
• Listings written and asset sets produced for every required device size on both platforms
• Signing: keystore custody, Play App Signing, certificates, provisioning, TestFlight groups, Play tracks
• Submission packages with review notes, reviewer credentials, demo data, gated-flow walkthroughs
• Privacy declarations in both consoles, mapped to the SDKs actually present in the binary
• Phased release, staged rollout, hotfix and rollback planning, plus a runbook your team can use alone

How the engagement runs

We start with an audit of the current state: console roles and agreements, the last accepted build, the live listing, the signing chain, and the privacy answers compared against the app's real behaviour. The audit lists things that would have caused a rejection, and we fix those before touching the queue.

Then we prepare the package: listing copy and assets, purpose strings for every permission prompt, declarations, review notes, demo credentials. We push a build to an internal track, walk the reviewer path on a clean device, and only then submit. The cadence stays documented, with a checklist before every upload.

Where the project starts

A plain idea, before any code exists. Publishing decisions come early because they constrain the build: bundle identifiers, account type, the permission set, and how the app will explain data collection. Settling those early avoids the scramble when the binary reaches a test device.

An existing conventional codebase. We compare what the console already declares against what the app does, then repair: rebuild signing, verify entitlements, rewrite purpose strings that read like placeholders, reconcile privacy answers with the SDK versions in use.

An AI-generated or vibe-coded prototype. The features often work and the packaging rarely does. We inventory every permission, background service, and library, remove what the app does not need, write the declarations for what remains, and add the account deletion and consent paths stores require. The aim is protecting the idea, the users, and the data while keeping the speed that got the prototype here.

Rejections we see most, and how each one is resolved

Privacy declarations that do not match observed behaviour. Both stores compare your answers with what the binary and its SDKs do. We inventory data flows, correct the privacy labels and the Data safety form, and keep a mapping for future SDK upgrades.

No way to delete an account inside the app. Apple and Google require an in-app deletion path, and Play expects a web URL for requests. We add the flow, a backend endpoint, wording about what is removed and kept, and reviewer proof.

A social sign-in without Sign in with Apple. Apple asks for its own option when an app offers a third-party login. We add it, or remove the competing option when it is not needed.

A reviewer who cannot complete the flow. Missing demo credentials, expired test accounts, a paywall the reviewer cannot pass, or region-locked content stall a review. We supply long-lived credentials, seed demo data, and describe every gated screen.

Digital goods sold outside store billing. Subscriptions and premium content have to run through in-app purchase, with restore and server-side receipt checks. We move the flow onto store billing and keep external links inside regional limits.

Purpose strings and entitlements that do not explain themselves. Camera, microphone, photo library, location, tracking, and VPN access each need a user-facing reason and the right entitlement, and VPN apps carry extra declarations about traffic. We rewrite them and drop unused permissions.

Outdated platform requirements. Google Play expects a target API level within a year of the latest Android release, plus foreground service declarations and justification for background location. We upgrade the target and declare service types before the deadline, which is where this meets our SDK and API version upgrade work.

Upload failures and signing errors. A lost keystore, a mismatched certificate, or an expired provisioning profile stops a release before review. Play App Signing enrolment, documented key custody, and expiry reminders keep that out of launch week.

What it costs

Publishing work is billed at our flat rate of $39 per hour, and most engagements are quoted as fixed scope after we see the console state and build. For an app that already runs on a device, publishing alone runs through two to four phases: audit and repairs, assets and declarations, submission and review, rollout.

That is usually one to three weeks of calendar time, most of it in the review queue. When publishing sits inside a build, it is part of the mobile MVP typical order of $4,800 to $8,500 across four to six weeks on our pricing page. Teams with several apps or monthly store updates fit better on a capacity plan from $2,699 per month. Review outcomes depend on policy compliance and reviewer judgment, so we scope and price the packaging work that influences the outcome.

Proof

Voice VPN is our in-house Flutter VPN for restricted networks, live on Google Play with native NetworkExtension and Android VpnService integrations. It proves we carry a policy-heavy category through review: VPN service declarations, a no-account and no-logs story the console answers must support, and updates that keep shipping.

CalculatorX (HideX) is a Swift iOS privacy app on the App Store, hiding a PIN-protected vault behind a calculator-style entry screen. It proves we handle subscription review, purchase restoration, photo, video, and contact permission wording, and the on-device storage claims reviewers probe.

Camera Mirrors was built for iOS and Android with custom OpenGL shaders for real-time mirror effects. Its listings are no longer live, so the proof is the documented delivery: camera permission handling, asset production for two stores, and a release-ready build.

Related services

• Mobile apps development, the parent service that produces the build reviewers see
• App store optimization for listing copy, keywords, and screenshots that convert
• Mobile app privacy compliance for GDPR, CCPA, tracking consent, and the declarations behind them
• Mobile SDK and API version upgrades for target SDK deadlines, deprecated APIs, and library updates
• API development and integration for backend endpoints behind account deletion, receipts, and demo data

Next step

If a submission is stuck, send us the rejection text and a link to the console entry. We will tell you what the reviewer is looking at and what has to change.

Contact us with the app details, or run the project through the Vasilkoff.info estimator to get a first scope and cost range.