Show IH: I built a free check for mobile app submission evidence gaps
If you're preparing an iOS or Android store submission, the hard part often isn't writing the app. It's noticing which review evidence and operational details are still missing before you submit.
I built ReadyTo's free Evidence Gap Check to turn a short set of answers into a list of likely gaps and next actions. It runs in your browser. It doesn't submit your app, review your app manually, or guarantee Apple or Google approval.
It is most relevant if you work on an active mobile app and are submitting within 90 days or addressing a current rejection. You can try it here: https://readyto.app/mobile-app-launch-readiness-audit?utm_source=indiehackers&utm_medium=community&utm_campaign=readyto_q25_01.
I'd value feedback on what the check misses for real submissions, especially where it identifies the wrong next action.
Have early users changed what they submit after running the check, or is the main signal so far that people find the identified gaps useful?
I don't have evidence yet that someone changed their submission after using the check, so I wouldn't claim that outcome. The feedback here is useful, but the stronger signal would be someone with an active submission identifying a gap, fixing it, and telling us what changed. That's what I'm trying to learn from this test.
That fix-after-check behavior is the signal I’d want to follow. Could be useful to keep comparing notes by email as you get that evidence.
From the marketplace side (not Apple, but a plugin marketplace with human review): the instant rejection I got was never about the code. It was a missing support link and a license field that did not match what the listing said. Fixing both took minutes, but finding out cost a full review cycle. So one gap I would test for is the boring metadata, like support and privacy URLs that actually resolve and fields that contradict each other. Does the check look at listing metadata, or only the app itself?
That is a useful example. The check does ask whether privacy and support URLs are live and whether listing assets are drafted, so it covers some listing metadata. It relies on the user's answers, though: it doesn't visit those URLs or compare listing fields for contradictions. Your license-field mismatch is exactly the kind of gap that could slip through today. Was the contradiction between the listing and a document you submitted, or between fields in the listing itself?
This is exactly the kind of measurement tool that founders need before submission - instead of finding out evidence gaps during review (when rejection becomes expensive), you're making it visible upfront. The insight here is that the checklist is less valuable than the ordering of gaps: which ones block approval vs. which ones are just nice-to-have? That changes what a founder prioritizes in their final 90 days. Have you found patterns in which evidence gaps appear most frequently across submissions, or do they vary wildly by app category?
That's a useful distinction. I don't have a reliable cross-category sample yet, so I wouldn't claim a most-common gap. The check is meant to help identify what needs attention before submission, but the priority depends on the app and the specific issue: a likely review blocker should come before a nice-to-have improvement. If you've run into a gap it would rank incorrectly, I'd be interested in that example.
This resonates a lot — how long did it take before you saw any real signal on it?
It's too early to claim a real demand signal from this post. I'm tracking whether people with an active app and an upcoming submission or current rejection actually complete the check, and then whether that leads to checkout or a purchase. Likes and comments are useful feedback, but I wouldn't count them as validation on their own.