A developer opens App Store Connect on a Wednesday morning and sees a red banner reading 'Developer Response Required' above an app version or an in-app purchase. The phrase does not appear in Apple's documented status list, yet most third-party dashboards (Bitrise, Fastlane reporters, RevenueCat's SDK warnings, App Store Connect API wrappers) surface it word for word. The build is not in active review. The submission is paused, and the queue waits for the developer.
Short answer
'Developer Response Required' is shorthand for any App Store Connect state that pauses the review until the developer takes an action. For apps, it maps to a Rejected or Metadata Rejected status with an open thread in Resolution Center. For in-app purchases, it maps to Apple's official Developer Action Needed status, which fires when a product change is rejected. The fix in both cases is to open the message, edit the offending item or reply with context, and resubmit.
What you should know
- The label is informal. Apple's documented status names are Rejected, Metadata Rejected, Developer Rejected, and Developer Action Needed; 'Developer Response Required' is not in the list.
- The unresolved item blocks the whole submission. Under the submission model documented by Apple, any item in an Unresolved Issues state keeps the submission from moving forward.
- The Resolution Center is the response surface. Replies are capped at 4,000 characters and accept attachments such as screenshots and screen recordings.
- In-app purchases have their own version of the state. Apple labels it Developer Action Needed and shows a yellow indicator, distinct from the red Rejected state for IAPs.
- Replies require a privileged role. Account Holder, Admin, or App Manager seats can write to Resolution Center; Developer-role seats can read but not respond.
- Edits to a build are not required to reply. A metadata reply alone can satisfy a Metadata Rejected case without a new binary upload.
- Apple does not publish a hard expiration for unanswered messages. Multi-week and multi-month stales are observed on Apple Developer Forums.
Where does 'Developer Response Required' actually show up in App Store Connect?
The phrase usually appears in one of three places.
The first is the Apps overview, where a red status indicator labelled Rejected or Metadata Rejected sits next to the version row. Apple's status reference describes Metadata Rejected as a state where you read the message from App Review, edit the metadata to resolve the issue, and reply to the message from App Review. The Submissions page itself shows an alert reading 'Unresolved Issues' until the developer acts.
The second is the Submissions tab introduced in the 2024 App Store Connect redesign. A single submission can bundle the app version, custom product pages, in-app events, and in-app purchases together. When one item in the bundle is rejected, the whole submission carries the unresolved alert, and the Submit for Review button does not return until every item in the bundle is resolved or removed. The Bitrise, Fastlane, and App Store Connect API status mappings often surface this combined state with the catch-all phrase 'developer response required' rather than reproducing every individual sub-state.
The third is the In-App Purchases tab. Apple lists the official IAP status as Developer Action Needed, and many CI dashboards relabel it for parity with the app-level rejection messaging. The state behaves differently from an app rejection (more on that below) and is the one place where Apple itself uses words close to the phrase.
What does the in-app purchase 'Developer Action Needed' status mean?
The IAP product changes you submitted were rejected. Apple's in-app purchase status reference reads that the in-app purchase product changes you submitted have been rejected, and that you are required to take action to edit the detail information or cancel the request to change the detail information before this in-app purchase can be reviewed again. The indicator is yellow, not red, because the underlying product still exists in its previously approved form; only the proposed changes are blocked.
In practice this matters for a subscription or consumable that was previously live. The customer-facing IAP keeps working. Only the new metadata, new price, new screenshot, or new localized description sits in a queue waiting for you to either fix it or withdraw the change. Many developers miss this distinction and assume the IAP itself is rejected from the store; that is the red Rejected status, not Developer Action Needed.
The other catch is that an IAP in Developer Action Needed can hold up the entire submission if it is bundled with the app version. The app version row may read In Review or Waiting for Review, but the submission as a whole will not progress until the IAP item is either resolved or removed.
How do you respond through the Resolution Center?
Apple documents the response flow as a sequence of steps inside App Store Connect. From the reply to App Review messages reference, the path is:
- Open the app in Apps.
- Click the unresolved-issues banner at the top of the page.
- In the In Progress section, click Resolve next to the submission.
- Click Reply to App Review.
- Enter text in the Reply field (4,000-character cap).
- Attach screenshots or screen recordings.
- Click Reply.
A few details that experienced developers know but Apple does not state plainly. Replying does not consume the build; you can correspond with the reviewer multiple times before deciding whether to fix the metadata, fix the binary, or push a new build. Reviewers often respond within one to three business days, though the Resolution Center itself publishes no SLA, and replies can stretch into a week or more during high-volume periods such as the run-up to a major iOS release. The character cap is firm; long technical explanations should be attached as a PDF rather than truncated into the field.
Account Holder, Admin, and App Manager roles can post replies. Developer-role seats can read the thread but not reply, which is a common source of confusion in larger teams where the engineer who built the feature does not hold the seat that can answer the reviewer.
Why does the 'Submit for Review' button stay hidden after a rejection?
Because the submission already exists in an unresolved state. App Store Connect treats a submission as one unit. While at least one item inside it is Rejected, Metadata Rejected, or Developer Action Needed, the Submit for Review button does not reappear. The way to surface it again is to either reply to the rejection (which can move the item back into review without a new build) or remove the unresolved item from the submission and replace it.
If you want to push a fresh build and let it stand on its own, the cleanest path is to open the submission, remove the rejected item or the entire submission per Apple's remove-from-review reference, upload the new binary, and create a new submission that bundles the new binary with the remaining items. The previous Resolution Center thread stays accessible for context, but the new submission does not inherit the unresolved alert.
This is the cause of most 'I uploaded a new build but App Store Connect still says Developer Response Required' reports. The build did upload, the row is in Processing or Waiting for Review, and yet the page-level status still reads Rejected because the old submission was never closed. The 90-day build expiry adds a second wrinkle: a thread tied to a build older than 90 days references an artifact that can no longer be selected for a new submission, so the developer must upload a fresh binary before responding usefully.
How do app-level and IAP-level developer-response states compare?
The states behave differently across the App Store Connect surface. The table below shows where each shows up, what it blocks, and what clears it.
| State | Where it appears | Indicator | What it blocks | How to clear |
|---|---|---|---|---|
| Rejected | App version row | Red | Whole submission | Reply in Resolution Center, then resubmit or edit |
| Metadata Rejected | App version row | Red | Whole submission | Edit metadata, reply, resubmit |
| Developer Action Needed | In-app purchase row | Yellow | The IAP change (and parent submission if bundled) | Edit IAP detail or cancel the change |
| Developer Rejected | App version row | Red | Self-imposed | Resubmit the build or upload a new one |
| Unresolved Issues | Submission header | Red | Submit for Review button hidden | Resolve or remove every unresolved item |
What to watch out for
Three myths cost the most time during a Developer Response Required stall.
The first is that a new build automatically clears the state. It does not. The submission still carries the unresolved item, and the version status keeps reading Rejected or Metadata Rejected until the developer either replies or removes the submission. Builders that rely on Fastlane or Bitrise to monitor status sometimes report 'stuck' submissions for this reason; the CI did its job, the state belongs to the human-facing surface in App Store Connect.
The second is that the IAP Developer Action Needed status pulls the IAP out of the store. It does not. The previously approved IAP keeps selling; only the proposed change is blocked. Customers on existing subscriptions or consumables are not affected. Pulling the IAP from sale is a separate action under Removed from Sale.
The third is that a Developer-role seat can resolve the rejection. Apple's role matrix permits read access to Resolution Center under the Developer role but reserves reply rights for Account Holder, Admin, and App Manager. Teams that route App Store Connect through a single junior developer seat are blocked at the reply step, even though the thread is visible. The practical workaround is to grant App Manager on the specific app rather than promoting the seat to a broader role.
For builders shipping AI-coded apps that touch sign-in flows, in-app purchases, or storage of regulated data, the queue window created by a Developer Response Required state is often when a missed Privacy Manifest entry or a hardcoded credential is finally caught. PTKD.com (https://ptkd.com) is one of the platforms focused on pre-submission scanning aligned with OWASP MASVS for no-code and vibe-coded apps; an IPA or APK can be scanned for the kinds of issues that tend to compound on a second-round rejection while the first thread is open.
Key takeaways
- 'Developer Response Required' is a developer and tooling shorthand for several distinct App Store Connect states: Rejected, Metadata Rejected, the IAP Developer Action Needed status, and the submission-level Unresolved Issues alert.
- The Submissions tab treats a submission as one unit; one unresolved item blocks Submit for Review for the whole bundle.
- Reply rights belong to Account Holder, Admin, and App Manager roles. Developer-role seats can read but not write to Resolution Center.
- Apple publishes no hard expiration for an unanswered reply, but builds expire after 90 days and reviewer context degrades; respond within a week or close and re-submit cleanly.
- Some teams use the queue window between a rejection and the next submission to run an external security read on the build; PTKD.com (https://ptkd.com) is one platform focused on pre-submission scanning aligned with OWASP MASVS for no-code and vibe-coded apps.
