Q: Log in flow that is acceptable on the iOS App Store

Avatar image for jesalrajdev
JesalRajdev

21

Forum Posts

0

Wiki Points

0

Followers

Reviews: 0

User Lists: 0

#1  Edited By JesalRajdev

Hi

I've recently submitted a Giant Bomb video app to the app store, that has been constantly rejected because it provides a way of making an in app purchase.

It seems that in the log in flow, it is possible to get to the sign up page and pay for a subscription, and so they keep rejecting my app.

I use the first method detailed in https://www.giantbomb.com/forums/api-developers-3017/how-to-authenticate-a-gb-app-1807094/ by directing the user to a web view inside the app, but have also been rejected with the second method too for a "direct callout to a page where users can purchase a subscription via card/paypal"

I understand that there are a few other GB video apps on iOS, but they all use the flow that I've been rejected for.

Is there another way I can log in

I've also been told I must support sign in with Apple if the app supports other Social logins

Thanks

Avatar image for ev77
ev77

151

Forum Posts

0

Wiki Points

0

Followers

Reviews: 0

User Lists: 0

I assume you are talking about paying for a giant bomb premium subscription? Because otherwise you'd be breaking the TOS for using the public APIs.

Also, if they (Apple) are concerned about being able to get to the signup page, you will probably need to whitelist only the pages needed to sign in so the user can't navigate to the signup pages.

Avatar image for conmulligan
conmulligan

2215

Forum Posts

11722

Wiki Points

0

Followers

Reviews: 0

User Lists: 10

#3  Edited By conmulligan

Man, that's a bummer. I didn't run into the subscription issue, but app review did flag one of my updates shortly after they started requiring Sign in with Apple for apps that use other social auth flows. I was able to get the update approved by making it clear that the app is a client for a third-party service which is explicitly exempt from the Sign in with Apple requirement:

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.

That may also get you around the subscription issue — if they're aware that you don't have any control over the login screen, they might not invoke that particular clause.

Avatar image for jesalrajdev
JesalRajdev

21

Forum Posts

0

Wiki Points

0

Followers

Reviews: 0

User Lists: 0

Yeah, I've been trying to push back a bit, but they've been pretty persistent. Even with Sign-In With Apple, they've been incredibly insistent. My flow is exactly the same as yours is with Bomb Cyclone, but I didn't want to draw any attention to it on the off chance that impacted you.

I'm going to try the whitelist (thanks @ev77) and also use some injected CSS to hide the links to other parts of the GB website

Avatar image for conmulligan
conmulligan

2215

Forum Posts

11722

Wiki Points

0

Followers

Reviews: 0

User Lists: 10

#5  Edited By conmulligan

Hmm, there is one other thing you could try. I checked out the latest TestFlight build and it looks like you're embedding the login page in a WKWebView instance — it might be worth replacing this with SFSafariViewController and seeing if that gets through review.

The reason I bring this up is because I had an issue with another app that requires users to sign in through a third-party OIDC server. The OIDC login page was embedded in a WKWebView so it would blend in better with the native UI. After being rejected for not supporting Sign in with Apple, I swapped out WKWebView for SFSafariViewController in order to make it clearer that the user was getting bounced out to a web page; this subsequently made it through review. I'm not 100% sure why, but my hunch is that Apple are a little less dogmatic about auth flows when it's obvious that the user is navigating to an external web page. SFSafariViewController won't support @ev77's suggestion though, so if you need to manipulate the page for any reason you'll have to stick with WKWebView.

Avatar image for jesalrajdev
JesalRajdev

21

Forum Posts

0

Wiki Points

0

Followers

Reviews: 0

User Lists: 0

My first build used SFSafariViewController and was rejected on TestFlight. It all just seems so inconsistent.

Avatar image for conmulligan
conmulligan

2215

Forum Posts

11722

Wiki Points

0

Followers

Reviews: 0

User Lists: 10

#7  Edited By conmulligan

Oh, wow, I'm not sure that I've ever had a TestFlight rejection that wasn't some egregious issue. Was the TestFlight build rejected for the same reason or something else? Also, are you supplying them with login credentials or having them create an account?

Avatar image for jesalrajdev
JesalRajdev

21

Forum Posts

0

Wiki Points

0

Followers

Reviews: 0

User Lists: 0

#8  Edited By JesalRajdev

Same login issues. I gave them my login details, but they said they were able to access a way to pay, so it was a no go. Weird thing is that changing to the WKWebView got it through for some reason, and they've not rejected in TF since.

I've resubmitted with a lot of custom CSS injected to hide any links to signup/the rest of the site, as well as some JS - Swift bridging to automate the process a bit. Hopefully that's enough for them

Avatar image for conmulligan
conmulligan

2215

Forum Posts

11722

Wiki Points

0

Followers

Reviews: 0

User Lists: 10

#9  Edited By conmulligan

Cool, hopefully that does the trick!

Avatar image for jesalrajdev
JesalRajdev

21

Forum Posts

0

Wiki Points

0

Followers

Reviews: 0

User Lists: 0

Did the trick, hopefully they're less eagle eyed in the future