Guidelines read before code, not after rejection
Account deletion, privacy labels, and the minimum-functionality bar are cheap to design in and expensive to retrofit across a review cycle.
All services
Building the iOS or Android app is the half everyone plans for.
The other half is review. Two apps I worked on are live on the stores right now, and one of them started life as a Replit project. The work was the custom development on top and getting it approved. If you have a build that reviewers keep bouncing, that is the same job.
iOS and Android apps: what is included
- A read of the current build against the guidelines that actually cause rejections
- Account deletion, privacy manifest, and data declarations that match what the code does
- Custom native development on top of a prototype, or a build from scratch
- Signing, certificates, and bundle setup inside your own developer accounts
- Store listing: description, keywords, screenshots at every required size, age rating
- Submission handled end to end, including replying to a rejection if one comes back
iOS and Android apps: what gets decided first
The accounts stay yours
Apple and Google accounts registered to you, with me invited in. The account owns the listing and the ability to ship updates, and that should never sit with a contractor.
One platform properly beats two badly
Unless the audience genuinely splits, shipping one store and learning from real installs costs less than dividing the same budget across both.
iOS and Android apps in 5 steps
Read the build against the guidelines
Whatever exists now (a Replit export, a designer's prototype, or nothing yet), checked against the review guidelines that actually reject apps. This is the cheapest hour in the project and it decides how much work the rest is.
Fix what a reviewer will stop on
Account deletion, privacy manifest and labels, login handling, permission prompts that explain themselves, and enough native behaviour that the app is not a wrapped website. Before the first submission, not after the first rejection.
Build the features that are the point
The custom development the app exists for. Everything above is table stakes that gets you reviewed at all; this is the part that decides whether anyone keeps it installed.
Set up signing, accounts, and the listing
Certificates, provisioning, bundle identifiers, and the store listing: description, keywords, screenshots at every required size, age rating, and the data declarations. In your developer account, with you as the owner.
Submit, and handle the review
Including the reply if it comes back. Most rejections are a specific guideline and a fixable cause, and answering them precisely is faster than resubmitting blind and hoping for a different reviewer.
Two apps you can install rather than take my word for.
Both are published under their owners' developer accounts, which is how it should be. The links go to the live listings.
FunkyScore
iOS and Android
Live scores, tables, and results for fifteen sports in one scoreboard, with a comment section on matches. Published on both stores and paired with the web platform at funkyscore.com.
My part: Built the app for iOS and Android alongside the web platform, and took both listings through their first release.
Colla Construction
iOS
A swipe-to-match job app for the UK construction and trade sector, connecting workers and employers by location and CSCS trade profile, with chat on mutual matches.
My part: The build started as a Replit project. I did the custom development on top of it and took it through App Store Connect to approval.
Six reasons apps come back, none of them crashes.
Every one of these is knowable before you submit. That is the entire argument for reading the guidelines against the build first rather than treating review as a coin toss.
Minimum Functionality
The reviewer decides the app does nothing a mobile website could not. The most common outcome for a build that came straight out of an AI builder, and the one that needs real native behaviour added rather than an appeal.
No account deletion
If a person can create an account inside the app, they must be able to delete it inside the app. A link to email support does not satisfy it. Catches an enormous number of first submissions.
Privacy labels that do not match the code
The nutrition label and data-safety form are declarations about what the app collects. If an SDK collects an identifier the form does not mention, that is a rejection, and third-party SDKs are usually the reason the answer is wrong.
Broken demo account
Anything behind a login needs working credentials in the review notes. A reviewer who cannot get past your sign-in screen rejects the build rather than chasing you for a password.
Placeholder URLs
Support and marketing URLs that 404, or a privacy policy hosted on a link that expires. Trivially avoidable and a guaranteed round trip.
Screenshots of a build that no longer exists
Store screenshots showing screens the current binary does not have. Common when the design changed late and the listing was filled in early.
iOS and Android apps: questions
Can you finish an app I started with Replit, Lovable, or Bolt?
Yes, and it is the most common version of this job. AI builders get you to something that runs on your phone quickly, then stop being useful at exactly the point that matters: the app has no account deletion route, no privacy manifest, placeholder support and privacy URLs, and a feature set a reviewer reads as a website in a wrapper. Colla Construction, on the App Store now, started in Replit. Its bundle identifier is still app.replit.colla. The work was the custom development on top and getting it through review.
Why do apps actually get rejected?
Rarely for crashes. The two that catch most independent submissions are Minimum Functionality (the app does not do enough that a website could not, which is what sinks a lot of AI-generated builds) and Spam, for apps too close to something already on the store. After those it is process rather than code: missing privacy nutrition labels, no way to delete an account inside an app that lets you create one, demo credentials that do not work, a support URL that 404s, or screenshots showing a screen the build no longer has. Almost all of it is fixable before you ever submit.
How long does review take?
Apple reviews the large majority of submissions within 24 to 48 hours, and Google Play is usually comparable now, though a first release from a new developer account takes longer on both. The wall-clock risk is not the queue, it is the round trips: each rejection costs another cycle, so the useful work happens before the first submission, not after it.
Do I need my own developer accounts?
Yes, and you should want to. Apple's Developer Program is $99 a year, Google Play is a one-off $25. Both should be registered to you or your company, not to me. The account owns the listing, the reviews, and the ability to ship an update, and a business whose app lives in a contractor's account has a real problem the day that relationship ends. I work inside your App Store Connect and Play Console as an invited user.
Should I build for both platforms or just one?
One, usually, unless you know the split. FunkyScore is on both because sports scores are checked everywhere by everyone. Colla is iOS only because it targets UK construction and trade, and the client would rather learn from a shipped iOS app than split the same budget across two stores and launch neither properly. Shipping one platform, watching what people actually do, then porting is cheaper than guessing twice.
Who writes the privacy policy and the store listing?
The listing copy, keywords, screenshots, and the privacy and data-safety declarations are part of the work, because they are where submissions stall and they are not really a legal exercise. They describe what your app does with data, which is a question about the code. If you need actual legal review of the policy text, get it; I will tell you what the app does so that whoever writes it is describing the truth.
What happens after it is approved?
You get the repository, the signing setup, and the store assets. The part people underestimate is that approval is not permanent: Apple and Google both retire APIs and raise minimum target versions on a schedule, so an app nobody touches for two years eventually stops being updatable and then stops being installable. Budget for a release a couple of times a year even if the features never change.
Tell me what you need built.
A couple of sentences is enough to start. I reply within one business day.