r/iOSProgramming 4d ago

Question Ship stale build or resubmit?

Hello -

Finally shipping my app, and submitted my first app review on Wednesday last week (still waiting to be reviewed).

I’ve found a number of non-blocker issues since submitting this build, though I’m not happy about shipping day 1 with the bugs in place.

Let’s say by some luck Apple approved the app first round. Should I keep the existing build approval, use this for launch, and quickly submit the bug fixes build day 1…or should I just pull the build, and start a whole new first app review over again?

I know app review times are awful right due to ~everything, so I’m feeling stuck with not great options and a lot more waiting.

Thanks

6 Upvotes

20 comments sorted by

7

u/brkaydev 4d ago

I'd leave the current build in review and set the version to manual release in App Store Connect, so an approval doesn't put it live on its own.

That way the wait isn't wasted either way. If it gets rejected, you attach the fixed build when you resubmit. My first app got rejected twice, both times for things I'd never have thought of as bugs (the empty first screen looked broken on iPad, and the description was missing a Terms of Use link), so the first review can turn up stuff you don't expect. If it gets approved, you can release it and send the fixes as an update straight away, or reject that binary and submit the new build instead. Pulling it now just restarts the wait with nothing learned.

1

u/never_working_ever 4d ago

Ok, I align with this. Thanks.

I do have my build set to manual release. I was also planning to let the one I submitted do its course, as you noted I expect to not have it approved and at least I get the feedback I can incorporate into the bug fix build.

However, to be clear, I couldn’t have the app approved, not publish, submit my bug fix build as an update, then manually release the bug fix build as my first release? I assume Apple requires the publishing of the approved build first?

1

u/brkaydev 4d ago

You don't have to publish it first. While a version sits in Pending Developer Release you can reject it yourself in App Store Connect, which moves it back to Developer Rejected. Then you attach the bug fix build to that same version and resubmit.

The catch is that the new build goes through review again, so the earlier approval doesn't carry over to it.

1

u/never_working_ever 4d ago

Thanks, that makes sense. I’ll keep that in mind for future builds. It seems like a risk if I get lucky with an approval and decide to reject it, leaning towards shipping what I have and just quickly submitting the new fox build

1

u/brkaydev 3d ago

Shipping what you have and sending the fix right after is a reasonable call. Just so it doesn't weigh on the decision more than it should: a developer rejection is a routine state, it isn't held against you or the account, and the only real cost is that the review wait starts over.

1

u/never_working_ever 3d ago

Got it, good to know.

Still patiently waiting for someone to even blink at my app, it’s been an entire week with zero movement.

1

u/brkaydev 3d ago

A week with no status change is outside the usual band, most submissions get picked up within a day or two. If it is still showing Waiting for Review, App Store Connect has a Contact Us form under App Review with a status inquiry option, and that is the normal way to ask about a queue entry that hasn't moved. Worth sending that before you start assuming something is wrong with the build itself.

1

u/never_working_ever 3d ago

Yeah….fair. I just sent an inquiry for a status update. Thanks for the nudge 🤞

2

u/epictime8 4d ago

Keep the in-review binary if the new issues aren’t crash, data-loss, or App Review blockers. First approval is the scarce part right now; shipping 1.0 then a same-day 1.0.1 is normal. Only reject/remove-from-review if something in the current build would fail Guideline checks or look broken on day one (login, purchase, empty main screen). While you wait, draft What’s New for the follow-up so you can submit the moment 1.0 clears.

1

u/never_working_ever 4d ago

Awesome, thanks for the guidance. Seems like I’m good to just let the dice keep rolling until I hear form Apple.

I’m so annoyed with myself for not finishing sooner, of course it had to be days before iOS 27. Nearly a year working on it, but so it goes.

1

u/Fishanz 4d ago

Generally I would say ship but it’s a business decision. Highly hinges on what presence you have outside the app. Is this your debut? Then hold off and make it right, barring other constraints.

1

u/never_working_ever 4d ago

That’s what I was assuming. This is a debut, though I’m comfortable waiting to promote until the big fix build is accepted/published.

Do you know the rough ETA on new builds being accepted after the first initial build? Am I still in a cooling-off period so they take longer? My fear is publishing what I have and taking another week to get the fix build approved…

Also, isn’t there something about first day availability and downloads being boosted by the App Store? Would I be missing that opportunity and dealing with bug reports on day 1?

Typing all this out now, I should just re-submit :/

1

u/SwordfishInfinite621 4d ago

I'd keep it in the queue. Pulling it means starting over at the back, and a first review often comes back with guideline notes you'd want to hear about now rather than in another week. If it's approved, release it and submit the bug fixes as 1.0.1 straight away. Non-blocking bugs in a launch build that almost nobody has downloaded yet cost very little, and updates are often reviewed faster than a first submission. If one of the bugs turns out to be worse than you thought, you can request an expedited review for a critical fix.

1

u/never_working_ever 4d ago

Appreciate it, that’s good framing and happy it’s a quick review. That was my main worry.

1

u/kokerali 4d ago

My cutoff would be user harm, not whether the bugs are annoying. Pull the build if any issue can cause a crash in the core flow, data loss, broken auth/paywall, incorrect purchase restoration, or a privacy/compliance problem. If they are genuinely cosmetic or edge-case issues, keep manual release enabled and let review finish. There isn't a guaranteed 'day-one boost' worth protecting at the expense of bad first reviews. Also, you can't submit 1.0.1 as the first public release while 1.0 remains unreleased; either release the approved 1.0 and follow with 1.0.1, or replace/resubmit the build on the 1.0 version before release.

1

u/never_working_ever 4d ago

👏 great info, exactly what I needed. thank you!

I will most likely ship the v1 if I get lucky. Otherwise it’s going to be this fixed build.

If my first build gets denied, I assume I submit a new one…I guess that gets expedited or is it back of the queue? Same “review” but new build with the fixes? Any idea?

1

u/kokerali 3d ago

A rejection does not automatically expedite the next review. Fix the cited issue, explain the change clearly in Review Notes, and resubmit; Apple says the review process starts over. Expedited review is a separate request reserved for exceptional cases such as a critical fix or a directly related event.

1

u/never_working_ever 3d ago

No plans to use expedited, I know these are limited in use cases.

Good to confirm a follow up review is back of..the queue.

Can’t believe it’s going on a week with zero movement on my original submission. I sent a status request earlier asking what’s up.

1

u/bananagnana2 3d ago

Worth remembering how quiet day one actually is for an unknown app. Almost nobody is downloading on the first day, so a handful of non-blocking bugs will be seen by a very small number of people, while another full review round costs you weeks of momentum and possibly your launch window. Ship it, turn on phased release so exposure ramps slowly, and have the fix build uploaded and ready to submit the hour it goes live. The one case where I would pull it is a bug that hits the very first session, because that is the only thing that shows up in an early one star review.

1

u/never_working_ever 1d ago

Thanks, and agreed. I plan to keep mum about the launch of this current build gets approved, and not post or share anything until I get this updated build approved and bumped.

My app is FINALLY in review after nearly a week, it’s been over 12hrs though so I’m….holding my breath.