Guideline 2.1 rejections: App Completeness

Guideline 2.1 covers everything that stopped the reviewer from reviewing: a crash, a demo account that does not work, an error screen, placeholder content, or a backend that was off. For a Ruby Native app the fix is almost always on the server side, and it ships with a deploy and a reply, not a new build.

#What Apple says

From the App Store Review Guidelines:

Submissions to App Review, including apps you make available for pre-order, should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission. Make sure your app has been tested on-device for bugs and stability before you submit it, and include demo account info (and turn on your back-end service!) if your app includes a login.

#What the rejection says

In substance, one of: the app crashed on launch or during use, with a crash log attached; the demo account credentials did not work, or none were provided; the app displayed an error or a blank screen; the app contained placeholder content; or a link in the app or the metadata did not resolve.

#Why it happens to Ruby Native apps

The app loads its configuration and every page from your Rails app at launch. If the site is unreachable, in maintenance mode, behind a staging password, or returning an error, the reviewer sees the error screen instead of your app. A demo account that works on staging but not on production, or a demo account whose data was reset, is the other common cause. Crashes are rare, since the native layer is the same for every app, and the dashboard reports the configuration errors real devices hit.

#The fix

1. Check what devices are reporting. The dashboard's configuration errors, or ruby_native status and the config_errors tool for your agent, show whether the config failed to load in the last 48 hours and why. Debugging.
2. Make the demo account real. It lives on production, it signs in with the credentials you gave Apple, and it has seeded data that shows the product. Set it with ruby_native demo_account set or on the Submit screen, and sign in with it yourself on the TestFlight build before you reply. Submission.
3. Keep the backend on for the whole review. No maintenance window, no deploy that breaks sign-in, no rate limiter that blocks a reviewer signing in repeatedly from one IP. Authentication covers the sign-in cases Ruby Native handles.
4. Scrub placeholders. Lorem ipsum in a seeded account, "coming soon" pages, a privacy policy URL that 404s, a support URL that is a parked domain.
5. Test the exact build on a device. Install the TestFlight build Apple reviewed, not a preview, and walk the first five screens signed out and signed in.
6. Reply with what you changed. If the fix was on the server, no new build is needed; say so, and ask them to try again with the same build.

#When the reviewer is wrong

If you cannot reproduce it:

Thank you for the review. We tested build [number] on [device, iOS version] signed out and signed in with the demo account [email] and could not reproduce the issue. Could you share the device and iOS version used, and the crash log or a screenshot of the error? The demo account is active and the backend is up.

Attach a short screen recording of the flow working. The crash log, when there is one, is in the Resolution Center.

From Joe: TODO one line on what actually got an app through 2.1.