Guideline 4.2 rejections: Minimum Functionality

Guideline 4.2 is the rejection for an app that looks like a website in a frame. Ruby Native apps are built to clear it, with a native tab bar, push notifications, and real app assets, and when one is rejected anyway the fix is to make those native parts visible to the reviewer and say so in the reply.

#What Apple says

From the App Store Review Guidelines:

Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or "app-like," it doesn't belong on the App Store.

#What the rejection says

In substance: the experience the app provides is not sufficiently different from browsing the website, and Apple asks you to add native features so the app offers more than the site. Sometimes it also says the app's usefulness is limited by how little content or functionality it includes. The reviewer saw web pages and nothing that told them this was an app.

#Why Ruby Native apps clear it

The native layer is real, not drawn in HTML. The tab bar is the system's own, push notifications go through Apple's service with a real device token, and the icon and launch screen are proper app assets. Advanced Mode adds native push and pop transitions, a native navigation bar, and swipe to go back. Navigation bar buttons and menus, menus on any element, a floating action button, haptics, and badges are all native controls the reviewer can see and feel.

A rejection under 4.2 usually means the build the reviewer opened did not show them. The most common causes: a config with fewer than two tabs, so no tab bar appears; the web header and footer left visible, so the first screen is a website header with a hamburger menu; and nothing in the review notes pointing at the native features.

#The fix

1. Make the tab bar appear. Two to five tabs under tabs: in config/ruby_native.yml, each a real destination a signed-in user returns to. Fewer than two and the bar does not draw. Tabs.
2. Hide the web navigation. Add the native-hidden class to the web header, footer, and any web menu so native users see the app's native chrome instead. Setup.
3. Turn on Advanced Mode if every page loads Turbo Drive. Native transitions and a native navigation bar are the clearest "app-like" signal a reviewer sees. Advanced Mode.
4. Register for push. Add native_push_tag where it makes sense and send at least one notification to the demo account so the reviewer can see it. Push notifications.
5. Add one or two native controls on the screens the reviewer will open first. A navigation bar button, a menu, or a floating action button on the main list.
6. Say it in the notes. In App Review Information, list the native features and where to find them: "Native tab bar with four tabs. Push notifications (send one from Settings > Notifications). Native navigation with swipe back. Camera barcode scanner on the Scan tab." Give the demo account the same way, with ruby_native demo_account set or on the Submit screen.
7. Reply, don't just resubmit. Even when you ship a new build, reply in the Resolution Center with the list from step 6 and two or three screenshots of the native features.

#When the reviewer is wrong

Reviewers judge the first few screens. If the native features are there and the app was still rejected, reply with the list and the screenshots and ask for a second look:

Thank you for the review. The app includes native functionality beyond the website: a native tab bar (four tabs), push notifications delivered through APNs (send one from Settings > Notifications with the demo account), native navigation with push and pop transitions and swipe to go back, and a native barcode scanner on the Scan tab. Screenshots attached. We'd appreciate a second look under guideline 4.2.

Keep it to the facts. A second reviewer usually reads the reply before the app.

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