UPDATE May 13, 2021: The super nice team at OGS has decided to implement Sign In with Apple on their site so I can avoid this issue in the future.
UPDATE April 07, 2021: Shortly after this article was published, Apple sent me a message saying they will review the app again, then they approved it 6 days later. The app is now available on the App Store, and the source code is available on GitHub.
--
For the last year, I have been able to set out some time to work on a personal project: an iOS app to play Go online with other players on the Online Go Server (OGS). The app has been in beta testing for more than five months with very positive feedbacks, so I have been really looking forward to releasing it on the App Store.
In order to release an app on the App Store, it is pretty well known that there is a final boss you have to beat: the App Review process. I had done dozens of app submissions before, so I am quite familiar with the process, the rejections, and how to navigate around them. However, this time, it was different, the boss has evolved, and I was unprepared for it.
Since my app is a client for OGS, to use most features in the app, you need to sign in to an OGS account, and the sign in process in my app looks like this:
Tapping on the "Sign in" button on the first screen opens a web view to the sign in page on OGS, where you can sign in to an OGS account. When you are signed in, the app will then save the necessary information, close the web view, and open up other features.
The rejection came with a screenshot of the second screen in the process above, the literal sign in page on OGS website:
UPDATE April 07, 2021: Shortly after this article was published, Apple sent me a message saying they will review the app again, then they approved it 6 days later. The app is now available on the App Store, and the source code is available on GitHub.
--
For the last year, I have been able to set out some time to work on a personal project: an iOS app to play Go online with other players on the Online Go Server (OGS). The app has been in beta testing for more than five months with very positive feedbacks, so I have been really looking forward to releasing it on the App Store.
In order to release an app on the App Store, it is pretty well known that there is a final boss you have to beat: the App Review process. I had done dozens of app submissions before, so I am quite familiar with the process, the rejections, and how to navigate around them. However, this time, it was different, the boss has evolved, and I was unprepared for it.
Since my app is a client for OGS, to use most features in the app, you need to sign in to an OGS account, and the sign in process in my app looks like this:
Tapping on the "Sign in" button on the first screen opens a web view to the sign in page on OGS, where you can sign in to an OGS account. When you are signed in, the app will then save the necessary information, close the web view, and open up other features.
The rejection came with a screenshot of the second screen in the process above, the literal sign in page on OGS website:
I was completely caught off guard by this rejection. With a sign in process like above, where could I offer the Sign in with Apple option? Even Apple's own App Review Guidelines seem to agree with me, the guideline on Sign in with Apple says that:
Sign in with Apple is not required if [...] Your app is a client for a specific third-party service and users are required to sign in to their mail, social media, or other third-party account directly to access their content.
The rejection must be a mistake, right?
...
It doesn't look like it was a mistake.
For the last 10 days, I have revised my app three times, sent many messages to the reviewer (or reviewers) to clarify the situation, and even sent two appeals to the App Review Board. All replies I have received so far have been some form of doubling down on the rejection. The full text of the last appeal I sent is as below:
Hi,
After my previous appeal, I have revised the app to make it clear that my app only supports one sign in option, that is users have to be signed in to an account on Online-Go.com (OGS). Since my app is a client for OGS, that is a hard requirement.
In the main screen of my app, you can see that there are only two buttons to either sign in to an OGS account, or to register a new OGS account. The buttons open a web view to the correspondence page on Online-Go.com (https://online-go.com/sign-in and https://online-go.com/register, respectively), the app only checks that user is signed in to Online-Go.com after the process, then save the account information and close the web view when that happens.
The fact that Online-Go.com themselves offer other sign in and register options to their account on their web pages is totally outside of my control. From the perspective of the app, user is signed in when and only when they are signed in on Online-Go.com in the web view.
With a sign in flow like that, I don't see any way for me to introduce Sign in with Apple to the process. I understand how Sign in with Apple works, as well as the benefits it brings, and I would be happy to offer Sign in with Apple whenever possible. However, in this case it is technically not possible for me to implement Sign in with Apple in my app.
I believe that when Apple created Guideline 4.8, your team have already foreseen my situation, where it is not possible to implement the feature. That is why there is a clause that Sign in with Apple is not required if "Your app is a client for a specific third-party service and users are required to sign in to their mail, social media, or other third-party account directly to access their content." As I understand the clause, it describes my situation perfectly: my app is a client for Online-Go.com, and users are required (by Online-Go.com) to sign in to an Online-Go.com account, or other third-party account that Online-Go.com supports, to access their content on Online-Go.com.
I hope that this helps clarify my situation. Let me know if you need any more information or have any suggestion.
Thank you,
Khoa
To which, Apple replied:
So, the options that Apple presented for me are:
- Just implement Sign in with Apple somehow: technically, I can still implement Sign in with Apple by introducing my own account system, then generate some username/password and use that to create an OGS account. However, this is a terrible user experience: later on if users want to use OGS on a web browser, either they will be unable to sign in (since there is no Sign in with Apple on OGS website), or I will have to create some confusing (and potentially unsecured) process to send them their username/password for OGS.
It can even get worse from there: with the way Sign in with Apple works, if some time in the future OGS decide to offer Sign in with Apple on their website, the Sign in with Apple in my app and on OGS website will sign a user in to two different accounts because I and OGS are two different developers. - Remove the third party social media login options: since the options are on OGS website, I will need to interfere with their page in the web view to do that, and if I do that then existing OGS users who created their accounts with those options will not be able to use my app.
With that, I think I have run out of options and will have to put this project on hold.
What's next
I am still fortunate that my livelihood does not depend on this, and I have ways to salvage the works I have done for something else. However, I am reconsidering all my plans for Apple platforms in the future. If I cannot have a reasonable conversation with Apple on something as simple as this, how can I ever be sure that any of my work on their platforms will ever see the light of day? The guideline on Sign in with Apple did not even exist just two years ago and has been modified a few times already, which means that any work I do on Apple platforms today might already be dead in the water because of rules that have not even been written yet.
One frustrating thing is that I know for sure there are people in Apple who understand the absurdity of this rejection, they were able to create a reasonable exception in the guideline that perfectly describes my situation. However, I have not been able to reach them via Apple's official means. So if you know anyone at Apple who can help or have any suggestion on how I can move this forward, please let me know. I would really appreciate any help.