App Store publishing: everything you asked at our Reddit AMA

We get this question a lot, so we looked at our own support cases from the last 18 months. The most common rejection reasons are less dramatic than people expect:

• Incomplete or inaccurate App Store metadata — missing or misleading information, screenshots, descriptions.
• An incorrectly configured App Privacy form.
• Apps that Apple considers incomplete or not fully functional during review.

Beyond that, we regularly see rejections tied to content rights (especially audio or video), apps in regulated industries that don't meet Apple's expectations, or apps judged too close to something that already exists.

For a first-time submission, it starts with the metadata: highlight your app's real value instead of generic promotion, and follow Apple's guidelines — they're the baseline for everything else. And if you do get rejected, don't panic. A rejection isn't a dead end, it's usually just part of the process. Read Apple's feedback carefully, address each point, and resubmit — we've seen plenty of apps get approved after one, or several, rounds of review.

If you're convinced a reviewer got it wrong, stay factual. Explain clearly why you believe your app complies with the guideline in question, and back it up with whatever helps — screenshots, a screen recording, test credentials, step-by-step instructions if a feature isn't obvious. If the discussion stalls, you can request a call with an Apple representative through the App Resolution Center in App Store Connect — a direct conversation often clears up misunderstandings faster than a written back-and-forth. As a last resort, you can appeal to the App Review Board, where a senior member of Apple's team reviews the case. Either way, the goal isn't to prove Apple wrong — it's to make it as easy as possible for the reviewer to see why your app complies.

Screenshots do two jobs at once: they convince someone to download your app, and they help Apple understand what the app does during review. Highlight your main features and the value they bring rather than showing random screens — if something makes your app different, a unique workflow, a community feature, a specific use case, make sure it's visible.

One detail that trips people up more than you'd expect: your screenshots have to match the version of the app you're actually submitting. It's surprisingly common to redesign part of an app, submit a new build, and forget to update the App Store screenshots — and a significant mismatch between what's shown and what's being reviewed can raise questions during App Review. Apple also provides official product bezels to present your screenshots cleanly and consistently, worth using if you haven't already. One more thing our iOS engineers flagged: screenshots that feature a competitor's product or service have caused review issues before, so it's best avoided entirely.

You only need a D-U-N-S Number if you want to enroll in the Apple Developer Program as an Organization. If you're publishing as an individual, you don't need one at all.

To get an Organization account, you first register with Dun & Bradstreet (or a local partner) — getting the D-U-N-S Number typically takes around two weeks, and Apple may ask for additional information during enrollment. In exchange, an Organization account brings a few real advantages: your organization appears as the developer on the App Store instead of your personal name, it's generally a better fit for businesses and teams (especially if ownership changes over time), it makes it easier to demonstrate ownership of your brand and content during review, and in some countries it can make you eligible for a waiver of the Apple Developer Program fee. If you're an indie developer publishing your own apps, though, an Individual account is perfectly valid and skips the D-U-N-S requirement entirely.

A recurring source of confusion: cryptic Transporter errors when uploading a build. Three of the most common, decoded:

• "No suitable application records were found" → the app record probably doesn't exist yet in App Store Connect.
• "Potential loss of keychain" → usually just a warning, triggered when the app was transferred between Apple Developer accounts.
• "Redundant binary upload" → you're likely uploading a build with the same version or build number as one that's already there.

One of the questions we get asked the most. Based on what we see helping customers publish, most reviews are completed within 24 to 48 hours, though it can take longer depending on the app and Apple's review workload.

If you're working against a deadline — a launch event, a release date — submit as soon as possible rather than waiting until the last minute. That way, if Apple asks for changes before approving, you still have time to address them. And if your timeline gets genuinely tight, Apple offers an expedited review request for time-sensitive situations. It's not guaranteed, but it's worth trying whenever you have a fixed date to hit.

The best time to leave beta isn't when your app is perfect — it's when it's ready for real users. In practice: the core experience is solid, the app already has meaningful content, and your beta users keep coming back because it genuinely solves a problem for them.

The second part matters just as much: don't publish without a launch plan. A common mistake is pouring all your energy into getting the app approved, only to realize afterward that nobody knows it exists. A clear target audience and a clear answer to "why would someone choose this app instead of another one" has a much bigger impact on traction than shipping a few days earlier. That answer doesn't just help your marketing, either — it tends to align with what Apple looks for during App Review too. Apps that bring something genuinely useful or distinctive usually have a smoother path than apps that read as another variation of something that already exists.

Both platforms can be tricky, just in different ways. From what we see, first submissions tend to get rejected more often on Apple's side than on Google Play's — but that doesn't mean Google Play is easier. It has its own constraints, and can create just as much friction depending on your developer account type and app configuration. For app updates, the rejection rate is usually much closer between the two.

One long-time GoodBarber user summed up the trade-off well in the thread: publishing on Apple is a whole process, and there's always some reason an app gets flagged — but having GoodBarber's documentation and support to walk through it removes most of the stress, and guarantees the app stays compliant with store policies over time. They also pointed out that Google Play, once the easier of the two, has gotten stricter as well: apps now need regular updates, or the developer account risks getting flagged. Reliable support on both fronts, they said, is worth a lot.

There's genuinely a lot to say about Google Play specifically — enough that we're planning a dedicated AMA on that topic rather than mixing it in here.

Everything covered above is what our support team deals with day in, day out — which is also why the service exists as a dedicated offer: GoodBarber Takes Care (GBTC). Instead of navigating App Review yourself, the GBTC team submits the app to the App Store and Google Play on your behalf, start to finish. Apple rejects roughly 42% of first submissions on average — often for reasons that are hard to anticipate — but over the last 12 months, the GBTC team has gotten 91% of those rejected first submissions ultimately accepted. On updates, proactive prevention work brings the rejection rate down to just 5%. If you'd rather leave App Review to a team that lives in it daily, that's exactly what GBTC is for.

That's the recap, but the thread itself is still worth a read for the full detail on each answer — and it stays open, so if you have a question we haven't covered, you can still post it there: App Store publishing AMA on r/GoodBarber.

This was our second live AMA. Tell us in the comments what topic you'd like us to tackle next.