A rejection message points at your app, but the cause is often somewhere else: a third-party binary with a deprecated API, a build setting, or the metadata. Send us the rejection and a build. We read the clause, trace the cause, fix it, and run the submission again in your own developer account.
An automated check: if the binary references UIWebView anywhere, the build is rejected. One came from a third-party .framework with no source code. We traced the reference to that SDK, worked out a compliant path with the client (upgrade, replace or isolate it), and documented it so it would not recur.
The upload was rejected outright because MinimumOSVersion was not accepted, so the build never entered the review queue. Local archive, export and validation had all passed; only the real upload failed. We now cross-check the target against Apple's current minimum before a build goes up.
The 1024-pixel marketing icon has to be exported without an alpha channel. It is a one-flag fix, but it tends to surface last, after the bigger problems are solved, and every resubmission costs another wait in the queue.
Purpose strings, the App Privacy answers, account deletion, Sign in with Apple and current agreements are checked before a build is uploaded.
We match the exact clause to the real artefact — your code, a linked binary, a build setting or the metadata — and separate an automated upload check from a human review decision. The two are fixed in different places.
A rejection rarely names the file that caused it. We follow the reference back to its origin, which is often a third-party SDK or a build setting, instead of patching the symptom where the message happened to appear.
We reproduce the failing check locally, fix it, re-run the pre-submission checks, and write down what changed so the same rejection does not come back in your next version.
A live-streaming app operator
Took an existing Objective-C live-streaming app through App Store submission and release. A publishing engagement, not a rebuild.
Objective-C · App Store Connect
Full write-up (Chinese)
An overseas social video start-up
A native Swift app, from version 1.0 in 2024 through a full 2.0 rebuild, together with a Python model service for image-to-text, video and music generation. Released on the US and UK App Stores in 2026 and still being updated.
Swift · Firebase · Python
An overseas social app operator
Voice chat rooms on native iOS (Swift) and Android, plus a web front end, localised into more than 70 languages with in-app purchases on Google Play. Live on both stores since 2022 and still updated regularly.
Swift · Android · Firebase
A Hong Kong marketplace operator
A customer app, a merchant app and a web front end from one cross-platform codebase, on a Java microservice back end. Traditional Chinese and English interfaces with Facebook sign-in; released to the App Store in several regions and to Google Play.
uni-app · Java microservices
A written diagnosis that names the clause and its real cause; the fix itself, in the code, the build settings or the metadata; a rebuilt and re-signed package; the reply to App Review written on your behalf; and a short note of what changed, so your next release does not repeat the rejection.
Once we have the exact rejection message and a build or archive, our initial diagnosis is delivered within one business day.
It depends on the cause, and we do not promise a number of days before we have read the rejection. An upload-time check can be cleared the same day; replacing a third-party SDK or rewriting metadata takes longer and depends on the vendor or on the next review round. Once the cause is confirmed we give you a dated estimate.
Yes. The app stays in your account and under your name, and we work with the access you grant. Nothing is submitted under our identity.
The exact rejection text — a screenshot or the email from App Review — a build or archive of the rejected version, and App Store Connect access for the account the app belongs to. If the cause turns out to be a third-party SDK, its name and version help.
We look at what is genuinely possible: a newer SDK release, a compatible replacement, or isolating the SDK behind our own interface while the permanent fix is planned. Where the workaround is temporary, we say so and document the permanent fix rather than leaving it implicit.
What the product does, which platforms or devices are involved, and your timing. We reply within three working days, in English, with questions or a short written proposal.
