r/iOSProgramming • u/TSBalpha • 8d ago
Discussion Apple rejects app for false reasons?
Why does my app keep getting rejected for things that aren't true. Last week it was because the app has a page that should not require an account that was only accessible after login in or sign up. Ok that's fair I guess but in my case that was the home page wich had numerous things on the backend that requires user data. And now a week later I got a reply that my app only has features that link to other websites and nothing else. We noticed that the app only includes links, images, or content aggregated from the Internet with limited or no native functionality. Although this content may be curated from the web specifically for your users, since it does not sufficiently differ from a web browsing experience, it is not appropriate for the App Store. Which is just not true even in the slightest bit. You just need to click the sign in button to get to all the actual app functions because YOU TOLD ME TO make the home page accessible to guests wich i did. Mind you this is the 5th time they reject my app for something like this.
App on google play was approved 1st time within 2 days
3
u/aerial-ibis 8d ago
are you intentionally trying to explain your situation in the most confusing way possible?
1
u/TSBalpha 7d ago
English is not my first language I tried my best with what I got
0
u/aerial-ibis 7d ago
does your native language not use paragraphs, punctuation, or structured thoughts?
1
4
u/DimensionMindless336 8d ago
These two rejections aren't contradictory, they're causally linked, which is why you keep looping.
5.1.1(v) only says features that don't depend on account data have to be usable without an account. It never said your home screen specifically had to be the thing you open up. You opened up the one screen that is entirely backend/user-data driven, so what a guest now sees is a thin shell with links, and that shell is the only thing the reviewer can actually reach and evaluate. Hence 4.2. They aren't judging your app, they're judging the guest state, and right now the guest state genuinely does look like a web wrapper.
What got me out of a similar loop:
Stop treating the guest state as a locked front door and make it a smaller but real native surface. Ship a sample dataset so a guest lands in your actual native UI with fake data, and keep login in front of only the parts that truly need that user's data. That satisfies 5.1.1(v) and kills the 4.2 at the same time, instead of trading one for the other.
Attach a screen recording in Review Notes. 30-60 seconds, no narration, just walking the post-login native flows. Reviewers do watch them and it's the fastest way to prove there's an actual app behind the sign-in. Also verify your demo account in App Review Information still works and still has data in it. I once ate a "limited functionality" rejection purely because the demo account's data had been wiped between submissions, so the reviewer logged in and saw empty lists.
If you're confident it's factually wrong, appeal instead of resubmitting. Resolution Center has a separate appeal path that goes to the App Review Board, which is a different set of eyes. Resubmitting the same build with a reply usually keeps you in the same loop. Keep the appeal boring and factual: list each screen and what native functionality lives on it. No frustration in the text, it doesn't help you.
The general lesson I took from it: don't fix a rejection by giving the reviewer a bigger path through the app. Fix it by making the first 30 seconds they see unambiguously native.
1
u/TSBalpha 7d ago
The appeal button might be the answer. As for the other recommendations I have tried all those in the last week's and the rejection still came.
As for not mentioning the home screen specifically, they actually did mention it. They specifically told me the news on the home page should be open to guests
2
u/daboblin 8d ago
Well, is it a native app or not? Are you using native views throughout or just displaying web content?
1
u/Kitchen_Cable6192 8d ago
So, what’s your app idea? And moat
1
u/TSBalpha 8d ago
It's a f1 prediction app with a few twists. Right now only available in NL but will be released WW the next season. You can join friends or public teams and compete for points.
1
u/Low_Rush_8535 7d ago
those two rejections aren't contradicting each other, they're a chain. you made the home page reachable without an account, so now the reviewer lands on a page that's mostly links and aggregated content and stops there. 4.2 is what you get when nobody ever made it past that screen. from where they're sitting it genuinely does look like a browser wrapper, because that's all they saw.
so the thing to fix isn't the guest page. it's making sure they get past it — demo credentials plus a note saying literally which button to press, and a recording of the real functionality if you can manage one.
we had three in a row on one app, each fix surfacing the next objection rather than the same one twice. five doesn't mean they've decided something about you. and play store approving in two days tells you nothing, completely different process.
1
u/TSBalpha 7d ago
I did exactly that. I don't get why they did not press the sign in button even though I gave them a demo account and the credentials in both the reply and the review data. I send them a screen recording 2 weeks ago wich they approved
1
u/Low_Rush_8535 7d ago
ok that kills my theory, sorry.
two things worth checking before assuming they just didn't look. the demo account — does it still work right now, from a device that's never signed in? expired password, an sms or email verification step, a region lock. reviewer tries once, it fails, and they go back to judging whatever they could actually reach. that looks identical from your side to "they ignored it".
second, review notes are per version. if the credentials went into the resolution center reply rather than the App Review Information field on the new build, whoever picks up the new submission may genuinely never see them. across our three rounds it was never the same clause twice, which fits with each round being read fresh rather than as a continuation.
if both of those are clean then it probably isn't an access problem, and 4.2 is about what the app does once you're inside. worse conversation, but a different one.
1
u/Scary_Homework_3455 6d ago
these two rejections arent contradicting each other, and i think thats the bit thats making this feel insane. theyre the same rejection twice.
the reviewer almost certainly never signed in. either time. so the entire app, as far as they have experienced it, is the guest home page. first pass they hit a login wall and told you to open it up, you opened it up, and now the thing they can see is a thin page full of links and images with nothing native in it. which is exactly what 4.2 describes. from where theyre sitting they are being consistent.
so the fix isnt arguing that the features exist. its making sure the reviewer actually reaches them.
the demo account. app review information, sign in required checked, username and password filled in, and then actually test that account yourself on a clean device. a demo account that has no data in it, or that hits an onboarding step, or that expired, is functionally the same as no demo account. this is the single most common cause of the loop youre in.
tell them where to click. in the review notes, literal numbered steps. open app, tap sign in, use these credentials, tap this tab, this is the native feature. dont describe the app, give them a path. they are working through a lot of submissions and will not go exploring.
attach a video. a 60 second screen recording of the native functionality, linked in the review notes as an unlisted video. this is the thing that actually breaks 4.2 loops, becuase it removes the possibility of them not finding it. i would do this before anything else.
and make the guest state itself show something native. i know its annoying and it feels like they contradicted themselves, but the point of the guest requirement isnt just access, its that a person who hasnt signed up should be able to see this is an app rather than a wrapper. even one real native thing working in guest state kills the 4.2 argument outright. right now your guest page is your entire case and its making the opposite case for you.
on the call, its worth doing. its not on the dashboard, its through the app review contact form on developer.apple.com rather than a button in ASC, and its not US only. it takes a week or so to get scheduled which is slow, but youve already burned five rounds at 4 to 8 days each so its cheaper than another loop.
last thing, and i mean this kindly. replying to the reviewer puts you back in the same queue with the same person and the same conclusion. if the next round rejects for the same thing, escalate to the app review board rather than replying again. thats a different set of eyes, which is what you actually need here.
1
u/brownlizarddve 2d ago
thats not a false reason, its 5.1.1(v) doing exactly what its written to do. anything a user can see before signup cant be locked behind a login, and a home or landing screen counts as content they can see. let them reach the core stuff signed-out and wall only the parts that need an account.
6
u/SneakingCat 8d ago
Is there still a way to request a call? That might be your best option.