iOS, submitted once and approved.

An app that is a wrapper around a website, or that offers little a mobile browser could not, gets rejected. If your core value is web content, the app has to earn its place with something native — offline access, push, hardware use, or a genuinely different interaction model. We raise this before the first line of code, because it decides whether the project should exist as an app at all.

Digital goods and subscriptions consumed in the app must go through in-app purchase, and the app may not point users to an outside payment route. Physical goods and services consumed outside the app must not. Getting this boundary wrong is the most expensive mistake in an iOS launch, so we map it against your business model at the start.

Any app that lets a user create an account must let them delete it from inside the app, not by emailing support. It is a small feature that stops a submission dead when it is missing.

Every permission needs a usage string that explains the actual reason, the app must work sensibly when a permission is refused, and the nutrition labels must match the binary. Vague or copied permission strings are a routine rejection.

An app offering third-party social login generally has to offer Sign in with Apple as an equivalent option. It is straightforward to add early and awkward to retrofit into an existing account model.

Cross-platform makes sense when the same app goes to both stores and the interface is largely standard — one codebase, roughly half the cost. Native Swift is worth it for interface-heavy products, anything leaning on the newest platform features, or where performance and battery use are part of the product. We build both and will tell you honestly which your case justifies.

You need the Apple Developer Program membership in your company’s name — it should be your account, not ours, so ownership of the listing never depends on the agency. The Mac is our problem, not yours. We can manage the account and certificates for you under an agreed access arrangement.

Usually it is a specific, fixable point in the reviewer’s note. We respond in Resolution Center the same day — often the resolution is a clarification rather than a code change — and resubmit. Rejections are part of the process, not a failure; what matters is that they cost a day rather than a fortnight, which comes from having designed around the common ones already.

Once the build is ready: a day or two for external TestFlight, then typically one to three days for App Review. Budget a week for a first submission, because the store listing, privacy declarations, screenshots and export compliance are all first-time work.

Yes. We audit the Swift and dependency versions, the deployment target, the certificate and provisioning state, the privacy declarations against the current requirements, and the crash-free rate. Apps that have not shipped in a year usually need SDK and API updates before any feature work is realistic.