Guideline 4.8 rejections: Login Services

Guideline 4.8 is the rejection for an app that offers Google, GitHub, or another social sign-in without an equivalent privacy-focused option, which in practice means Sign in with Apple. The fix is to add it, hide the social buttons from native users, or claim one of Apple's exemptions in the reply.

#What Apple says

From the App Store Review Guidelines:

Apps that use a third-party or social login service (such as Facebook Login, Google Sign-In, Log in with X, Sign In with LinkedIn, Login with Amazon, or WeChat Login) to set up or authenticate the user's primary account with the app must also offer as an equivalent option another login service with the following features:

• the login service limits data collection to the user's name and email address;
• the login service allows users to keep their email address private as part of setting up their account; and
• the login service does not collect interactions with your app for advertising purposes without consent.

#What the rejection says

In substance: the app uses a third-party login service but does not offer Sign in with Apple or another login service that meets the requirements. The reviewer opened the sign-in screen and saw "Continue with Google" with no equivalent next to it.

#Why it happens to Rails apps

OmniAuth made Google and GitHub sign-in a ten-minute addition, so a lot of Rails apps offer them next to email and password. Apple's rule is about the primary account: if a user can create their account with Google, there has to be an equivalent. Email and password alone does not count as the equivalent, because it does not let the user hide their address.

#The fix

OAuth covers the setup. In short:

1. Check the exemptions first. You are exempt if the app exclusively uses your own account system, if it is for education or enterprise and requires an existing work or school account, or if it is a client for a specific third-party service where users sign in to that account directly. Most Rails apps with their own authentication qualify under the first one, as long as the social buttons are not the primary way in.
2. Add Sign in with Apple if the social buttons stay. The omniauth-apple strategy fits next to the others, and the native flow routes back into the app the same way Google's does. It also needs the Sign in with Apple capability on the App ID, which the next cloud build picks up.
3. Or hide the social buttons from native users with unless native_app?, leaving email and password. The web keeps its buttons. An existing Google account still signs in on the web and the session carries into the app.
4. Deploy and reply. The sign-in page comes from your site. If you added Sign in with Apple, a new build is needed for the capability; say so.

#When the reviewer is wrong

If the app uses its own account system and the social buttons are a convenience:

Thank you for the review. The app's primary account system is our own email and password sign-in; Google sign-in is an optional convenience that links to an existing account and is not required to create or use one. Under the exemption in guideline 4.8 for apps that exclusively use their own account setup, we believe Sign in with Apple is not required. [If you hid the buttons: We have also removed the third-party login buttons from the iOS app.] We'd appreciate a second look.

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