Your App Got Rejected for Requiring WhatsApp — Surviving App Store Guideline 4.2.3(i)
The rejection, the fix that wasn't enough, and the first-launch change that finally cleared Apple's minimum-functionality bar.
You open the email from App Review and there's the line that stops you cold:
"We were required to install WhatsApp before we could use the app. Apps should be able to run on launch, without requiring additional apps to be installed."
That's Guideline 4.2.3(i) — Design, Minimum Functionality — and if you're reading this because you just got the same email, you already know the particular sick feeling underneath it. This isn't a bug report you can triage. For an app built around a specific companion service, this rejection reads like it's questioning whether the app should exist at all.
That's ClickPing, my click-to-chat and scheduling utility for WhatsApp. And that quote above is the actual rejection text, word for word.
What a rejection cycle costs you
Before the how, the cost — because it's the reason you shouldn't just resubmit and hope.
Every day your app sits in "Rejected" is a day your launch slips, and the slip is invisible to everyone but you. There's no dashboard for it; there's just the date you told people and the date it's actually going to happen, drifting further apart. The expensive mistake isn't the rejection itself — it's guessing at the fix, resubmitting, and having the reviewer see, functionally, the same app they already turned down. That doesn't just cost you the review queue's turnaround time. It costs you a cycle you'll never get evidence from, because you changed the wrong thing and won't find out until the next rejection lands.
I made that exact mistake on this app.
What 4.2.3(i) is actually testing
Arguing against the wrong thing is the fastest way to lose an appeal, so it's worth knowing what this guideline checks.
Everything in that rejection text points to a clean-device test: the app opened on a phone with nothing else installed — the rejection record for my build names an iPhone 17 Pro Max. Assume that's the entire test surface: does the app do something real on launch, with what's already on the phone? If the first thing it can offer you is "go install this other app first," you've told the reviewer your app isn't a product on its own — it's a shortcut to one, and shortcuts don't need a listing in the App Store.
That's a defensible thing to check for. ClickPing's whole premise is resolving a phone number and getting you into a chat, and for that action it genuinely depends on WhatsApp. Depending on a third-party service is fine — plenty of approved apps do. What isn't fine, and what 4.2.3(i) is built to catch, is a launch experience with no path forward at all when that third-party app isn't there.
The fix that wasn't enough
Given that, the fix I reached for first seemed obvious: give the app a complete path that has nothing to do with WhatsApp. I added "Send via Messages" — enter or paste a phone number, compose a message, and send it straight through Apple's own Messages app. No WhatsApp installed, no WhatsApp required, nothing else on the phone at all. On a clean build with nothing WhatsApp-related present, that whole loop worked end to end.
I resubmitted treating that as the fix. It wasn't. Build 1.0(10) went back to review on July 17, 2026, on that iPhone 17 Pro Max — and came back rejected again, same guideline.
That one stung, because I had genuinely built and shipped a real standalone path. I'd made "the app works without WhatsApp installed" true and assumed that closed the guideline. It's worth naming plainly: shipping a working alternate path isn't the same thing as making sure that path is what a first-time user actually sees first. I'd fixed the app. I hadn't checked what the app showed you before you did anything at all.
The real culprit was the first screen
So I went back to the build a reviewer would have opened — nothing WhatsApp-related on the device — and paid attention to what rendered before any of my new logic ever came into play.
The very first thing on screen, before a number had been entered or anything tapped, was a notice reading "WhatsApp isn't available," followed by a "Get WhatsApp" link straight to the App Store. My new Messages path was there. It just wasn't what a person saw first. An empty launch that leads with an install prompt for another app looks, to anyone opening it cold, exactly like an app that needs that other app to function.
I can't tell you that's the screen the reviewer's eyes landed on — Apple's rejection text doesn't say that, and I'm not going to claim more than it does. What I can tell you is that it's the only screen on that build capable of producing precisely the experience the rejection describes, and it's the thing I changed. The principle I took from it: the reviewer's first screen is your app. Not your best screen or your most capable one — whatever renders before any input, because on a clean device that's the entire evaluation surface there is.
The fix, shipped in build 1.0(12): the empty first-launch state no longer mentions WhatsApp at all. "Send via Messages" is now a permanent action present in every state, WhatsApp installed or not. The unavailable notice and the "Get WhatsApp" link only appear later, after a number has actually been entered — once there's something real for them to attach to. Nothing about the app's real dependence on WhatsApp for its named purpose changed. What changed is what the first five seconds show someone with a clean phone.
The appeal is evidence, not argument
With that fix in hand, I didn't just resubmit and hope for the best. I wrote to the Resolution Center clarifying what the app actually did, rather than arguing the rejection was wrong:
"ClickPing is fully usable on launch with no other apps installed. A user can enter or paste a phone number, compose a message, and send it directly through Apple Messages — a complete, standalone path that never depends on WhatsApp. WhatsApp is only one optional destination among the send options; it is never required."
I named the exact build — 1.0(12) — and attached screenshots of the fixed flow: the empty launch state with no WhatsApp installed, and the Messages compose flow actually firing with a number entered. Evidence, not argument. A reviewer working through a queue doesn't need persuading that I'm right about my own app; they need two screenshots that let them see the fix land in ten seconds.
What I'd check before you resubmit
If you're in the middle of a 4.2.3(i) rejection right now, this is the order I'd work through:
- A standalone path exists that has nothing to do with the companion app — and it completes end to end, not just partway.
- The empty first-launch screen does something useful and shows zero install prompts — nothing that reads as "go get this other app" before any input has happened.
- The companion app is framed as one optional destination, not the default and not the only path.
- The appeal carries visual evidence — before/after screenshots and the exact build number, not a paragraph of argument.
- One defensible fix per cycle. Resubmit only when you can point to the specific thing you changed and say exactly why it answers the guideline — never a guess dressed up as a fix.
It's live
ClickPing was approved and live on the App Store by July 20, 2026: apps.apple.com/us/app/clickping-click-to-chat/id6786285130. Same core idea as the day I started — resolve a number, get you into a chat — just with a first screen that finally does something on its own.
If you're staring at a 4.2.3(i) rejection right now, don't start with the feature you assume caused it. Start with what renders before anything else does.
Ramiz Raja is a senior mobile developer and technical lead with 12+ years shipping and rescuing production apps on Android, iOS, and Flutter. More at codebyramiz.com.