Guideline 4.3 rejections: Spam

Guideline 4.3 is the rejection for an app that looks like one Apple already has: a second bundle ID for the same product, a per-customer or per-region copy, or an app that is indistinguishable from a template. For a Rails team it usually means a staging app, a white-label build, or a second app for a second brand. The fix is one app, with the variation inside it.

#What Apple says

From the App Store Review Guidelines, 4.3(a):

Don't create multiple Bundle IDs of the same app (for example, submitting a separate map app for every city in the world instead of a single worldwide map that allows users to search any city). This practice results in unnecessary apps, which makes it hard for users to find the apps they want. If your app has different versions for specific locations, sports teams, universities, etc., consider submitting a single app and providing the variations using in-app purchase.

And 4.3(b):

Don't submit apps that are indistinguishable from what's already widely available.

#What the rejection says

In substance: the app duplicates the content and functionality of another app submitted by you or another developer, or it is one of many similar apps, and Apple asks you to combine them or to differentiate it. Sometimes the reviewer names the other app.

#Why it happens to Rails apps

Three ways. A staging app was submitted to the store instead of kept on TestFlight. A multi-tenant product shipped one app per customer, each with the customer's name and icon on the same codebase. Or a second brand on the same Rails app got its own bundle ID and its own listing. Related: guideline 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content, which is why Ruby Native builds run under your own developer account and never from ours.

#The fix

1. Keep staging off the store. A second Ruby Native app pointed at staging is fine for TestFlight; never submit it for review. Every app is its own subscription, staging included, and previewing on your phone needs none. Pricing.
2. One app per product. For per-customer branding, ship one app that signs the user in and shows their organization's name and colors inside it. Apple's own suggestion for templates is a single binary with a picker or per-client entries inside.
3. One app per brand only when the products differ. Two brands on one Rails app with the same screens are one app to Apple. If they really are different products with different users and content, say exactly how in the review notes.
4. Differentiate in the listing and the app. Different name, icon, screenshots, description, and a first screen that is not the other app's first screen.
5. Reply with the difference, or withdraw the duplicate. If the second app should not exist, remove it from review with ruby_native withdraw or from the dashboard, and say so.

#When the reviewer is wrong

If the two apps are different products:

Thank you for the review. [App A] and [App B] are separate products for different users: [A] is [what and for whom], [B] is [what and for whom]. They share no content and no accounts, and each has its own [screens/features]. We've attached screenshots of both first screens to show the difference. We'd appreciate a second look under 4.3.

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