iOS SDK SignIn don't leave app [Apple appstore rejection]

[GoogleCodeExporter]

Describe in detail the new feature you would like to see added
-> the iOS SDK opens up safari app to sign in, it should allow the possibility 
to open an overlay webview sign in

Describe your use case, or some example use cases, for this feature
-> we got rejected from Apple from using the official Google supported approach

Reasons

10.6: Apple and our customers place a high value on simple, refined, creative, 
well thought through interfaces. They take more work but are worth it. Apple 
sets a high bar. If your user interface is complex or less than very good, it 
may be rejected
10.6

We found the following issues with the user interface of your app:

The app opens a web page in mobile Safari for logging in to Google plus, then 
returns the user to the app. The user should be able log in without opening 
Safari first.

These examples identify types of issues discovered in your app but may not 
represent all such issues. It would be appropriate to thoroughly evaluate your 
app to address these types of issues.

* * * *

Original issue reported on code.google.com by peter.pa...@gmail.com on 4 Jul 2014 at 8:56

[GoogleCodeExporter]

How do you use Google plus sign on IOS if using the Google plus apis to do it 
gets you rejected from the app store? 

Original comment by michael....@gmail.com on 3 Sep 2014 at 7:22

[GoogleCodeExporter]

Our app was just rejected for the same reason.

Reasons

10.6: Apple and our customers place a high value on simple, refined, creative, 
well thought through interfaces. They take more work but are worth it. Apple 
sets a high bar. If your user interface is complex or less than very good, it 
may be rejected
10.6

We found the following issues with the user interface of your app:

Google+ log-in opens a web page in mobile Safari for logging in, then returns 
the user to the app. The user should be able log in without opening Safari 
first.

These examples identify types of issues discovered in your app but may not 
represent all such issues. It would be appropriate to thoroughly evaluate your 
app to address these types of issues.

* * * *

Original comment by a...@tapshield.com on 3 Sep 2014 at 9:21

[GoogleCodeExporter]

For my application "Solar Smash", I had the exact same experience. The 
application uses FB or G+ login for authentication purposes. Even though the FB 
and G+ logins follow the same fallback procedures, Apple kept denying the 
application for the exact reasons listed above.  In order to get published, I 
made the decision to remove G+ integration from the application, leaving only 
FB. The application was then approved. I was hoping Google would soon fix the 
SDK to align with Apple's capricious rules

Original comment by matthew....@gmail.com on 4 Sep 2014 at 10:24

[GoogleCodeExporter]

We had this issue with iOS app Staffino, i did manage to code the google sign 
in by opening an internal webview

Original comment by peter.pa...@gmail.com on 4 Sep 2014 at 12:35

[GoogleCodeExporter]

i do include parts of the custom webview code

////////////////////////////////////////////////////////////////////////
#pragma mark - UIWebView
////////////////////////////////////////////////////////////////////////

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest 
*)request navigationType:(UIWebViewNavigationType)navigationType {

    if ([[[request URL] absoluteString] hasPrefix:@"com.min60.staffino:/oauth2callback"]) {
        // @"com.google.chrome.ios"
        // @"com.apple.mobilesafari"
        //NSString * bundleID = [[NSBundle mainBundle] bundleIdentifier];
        [[AuthenticationManager shared] handleOpenURL:[request URL] sourceApplication:@"com.apple.mobilesafari"  annotation:nil];
        [self.navigationController popViewControllerAnimated:YES];
        return NO;
    }
    return YES;
}

- (void)webView:(UIWebView *)webView didFailLoadWithError:(NSError *)error {

    [super webView:webView didFailLoadWithError:error];

    RIButtonItem * cancelButton = [RIButtonItem itemWithLabel:@"Ok" action:^{

        [[AuthenticationManager shared] logout];
        [self.navigationController popViewControllerAnimated:YES];

    }];

    UIAlertView * alertView = [[UIAlertView alloc] initWithTitle:AlertViewCommonErrorTitle message:AlertViewCommonErrorMessage(error) cancelButtonItem:cancelButton otherButtonItems:nil];
    [alertView show];

}

Original comment by peter.pa...@gmail.com on 4 Sep 2014 at 12:36

[GoogleCodeExporter]

so this is the approach by recalling

1) subclass UIApplication and the - (BOOL)openURL:(NSURL*)url method
2) when the URL points to google sign in, simply reject that, and pass the url 
to a custom uiwebview
3) monitor the shouldStartLoadWithRequest and intercept the result, whic you 
pass in to

[GPPURLHandler handleURL:url sourceApplication:sourceApplication 
annotation:annotation]

//////////////

- (BOOL)openURL:(NSURL*)url {

    // this whole class is a fix, to get google aut inside the webview
    // http://stackoverflow.com/questions/15281386/google-iphone-api-sign-in-and-share-without-leaving-app/24577040#24577040

    if ([[url absoluteString] hasPrefix:@"googlechrome-x-callback:"]) {

        return NO;

    } else if ([[url absoluteString] hasPrefix:@"https://accounts.google.com/o/oauth2/auth"]) {

        [[NSNotificationCenter defaultCenter] postNotificationName:ApplicationOpenGoogleAuthNotification object:url];
        return NO;

    }

    return [super openURL:url];
}

Original comment by peter.pa...@gmail.com on 4 Sep 2014 at 12:40

[GoogleCodeExporter]

see my answer to this comment
http://stackoverflow.com/questions/15281386/google-iphone-api-sign-in-and-share-
without-leaving-app

Original comment by peter.pa...@gmail.com on 10 Sep 2014 at 2:53

[GoogleCodeExporter]

Original comment by t...@google.com on 18 Sep 2014 at 2:20

[GoogleCodeExporter]

Thanks everyone. We're well aware and working on this via a number of means.

Original comment by fa...@google.com on 4 Oct 2014 at 1:43

• Changed state: Accepted
• Added labels: Component-SignIn
• Removed labels: Component-REST-API

[GoogleCodeExporter]

Is there an update on this issue? 

We recently had our app rejected for this same reason. We tried to reason with 
Apple (over email and phone call) and explain how FB had the same exact 
fallback scenario and that in the primary scenario if the user has the Google+ 
app installed they are not taken to Safari. They were not interested in any of 
that and implied, this is fine for FB but not for Google+. I thought that was 
completely unacceptable, but the convo ended with them telling me they don't 
have to explain why they will allow FB to work this way and all they know is 
they will not allow Google+ to work this way. They also said the App Store is 
their private store and if we want to be part of it, we need to play by their 
rules and if not we can go find some other place. 

Original comment by mlesic...@gmail.com on 9 Oct 2014 at 10:10

[GoogleCodeExporter]

it can be solved, however a bit tricky (see my answer)

we accomplished this in app called Staffino (you may want to look 
https://itunes.apple.com/app/staffino/id820618515?mt=8)

Original comment by peter.pa...@gmail.com on 10 Oct 2014 at 9:11

[GoogleCodeExporter]

I don't think using GTMOAuth2ViewControllerTouch should count as a valid 
solution. Those controllers were written before ARC and its simply unacceptable 
that we must try to integrate outdated code as a solution. I have been unable 
to get this controller working on iOS 7. One solution would be to use 
AFNetworking's OAuth Client (https://github.com/AFNetworking/AFOAuth2Client)  
and then rolling your own web view. Its what we will be doing in our future 
updates.

Original comment by danielhg...@gmail.com on 10 Oct 2014 at 9:16

[GoogleCodeExporter]

Daniel, no you don't need to use GTMOAuth2ViewControllerTouch

just a webview controller and a bit trickery will work

see answer from Peter Lapisu
http://stackoverflow.com/questions/15281386/google-iphone-api-sign-in-and-share-
without-leaving-app/24577040#24577040

Original comment by peter.pa...@gmail.com on 10 Oct 2014 at 9:49

[GoogleCodeExporter]

Hi all -- at Google, we aim to make our services available to as many users and 
developers as possible. We have heard a very small number of reports of 
problems of this type, but those app developers appear to have eventually 
gotten approval to launch by working through Apple’s standard process.

Meantime, we're continuing to work on improved mechanisms for login. I do agree 
with Daniel that direct use of GTMOauth2ViewControllerTouch, or the equivalent 
UIWebView trickery, is not recommended.

Original comment by fa...@google.com on 15 Oct 2014 at 9:44

[GoogleCodeExporter]

unless you implement the trickery, or drop Google support, you wont get pass 
the approval, we tried that for a quite long time without success :(

Original comment by peter.pa...@gmail.com on 16 Oct 2014 at 8:13

[GoogleCodeExporter]

My app got rejected 5 days ago for this reason.

Original comment by marian.o...@farlex.ie on 16 Oct 2014 at 8:28

[GoogleCodeExporter]

For me, there was no getting through. After 3 tries and a direct
conversation with Apple, we removed Google+, leaving only FB.  Only then
did we get approval.

app [Apple appstore rejection]

users and developers as possible. We have heard a very small number of
reports of problems of this type, but those app developers appear to have
eventually gotten approval to launch by working through Apple's standard
process.

agree with Daniel that direct use of GTMOauth2ViewControllerTouch, or the
equivalent UIWebView trickery, is not recommended.

Original comment by matthew....@gmail.com on 16 Oct 2014 at 10:16

[GoogleCodeExporter]

We solved the problem using a method mentioned above where you subclass 
UIApplication. http://stackoverflow.com/a/24577040/3397986

------

To the project member posting here, I think this problem is much larger than 
you're alluding to as many probably just remove the sdk or find one of these 
work arounds and never report.  Once you are flagged by Apple's review process 
for an issue you don't just eventually get through and they are clearly on the 
look out for this "issue". We were ready to just ditch Google Plus login but 
the solution I mentioned above happened to be simple enough to give it a try.

The apple reviewers clearly don't have the Google Plus app or Chrome on their 
test devices so all you would need to do is just have the standard fallback to 
safari open as a UIWebView in app. Facebook sdk already allows this as one of 
their fallback options. 

And if you really want to be clever throw in a "Chrome Lite" browser (or just a 
skinned UIWebView to look like it) into the sdk that opens in app with a link 
at the top advertising to download the full version of Chrome or Google Plus.

Original comment by a...@tapshield.com on 16 Oct 2014 at 1:25

[GoogleCodeExporter]

Like others, the only way that we got "approval to launch by working through 
Apple’s standard process" was to remove Google+ authentication from our app.

Original comment by u...@hykoo.co on 16 Oct 2014 at 7:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Is there any official follow-up by Google about this? Just got rejected for the 
same reason, and with an update for an app which already had the Google+ sign 
in feature and passed review many times with no problems at all.

Original comment by mattone...@gmail.com on 21 Oct 2014 at 9:42

[GoogleCodeExporter]

My post at #14 is unfortunately largely what we can say at the moment.

Suffice to say, we're not satisfied with the status quo, and are working on 
several fronts to build a better experience while not compromising user 
security.

We do not support hand-rolled/embedded UIWebView for reasons of security, 
though are well aware of the unsavory tradeoff currently in place.

Original comment by fa...@google.com on 21 Oct 2014 at 9:58

[GoogleCodeExporter]

We just have had a rejection for the same reason. What is the ETA for this 
fix/improved version?
Thanks in advance
BC

Original comment by bluesclu...@gmail.com on 22 Oct 2014 at 5:24

[GoogleCodeExporter]

There's a further update to this. I tried to propose to the App Review Team a 
hybrid solution, waiting for an official update by Google on its SDK. The 
solution was the following one:

- keeping the Google+ sign up/log in button in my connect screen;
- when the user taps the Google+ button, checking if the official Google+ app 
is installed on the device; if so, letting user perform the Google+ sign up/log 
in process regularly; if not, showing an alert asking to download the Google+ 
app to complete the process, with two buttons to allow the user to cancel or to 
open the App Store page for the official Google+ app.

The response from Apple was the following one:

"Hello,

Jumping to Safari and to an app is only approved for Facebook, among social 
networks. 

If the removal of the Google+ login is the solution, please update the 
screenshots to match the interface. 

If you choose to keep it in, please implement web-view for login."

Of course, I asked what's with the privilege of Facebook in this, and I'm still 
waiting for a reply. Still, it's very likely Google needs a solution to this. I 
know that other social networks already have.

Original comment by alfgrie...@gmail.com on 23 Oct 2014 at 5:44

[GoogleCodeExporter]

Anyway, in order to pass the app review (I needed to ship a crucial hot fix 
update) the only way was removing the Google+ sign in button. Just saying to 
state again that this is not a minor issue, which can be solved by trying to 
submit repeatedly the same build.

Original comment by alfgrie...@gmail.com on 23 Oct 2014 at 6:03

[GoogleCodeExporter]

Please do something google. My app got rejected as well.

Original comment by gauthamb...@gmail.com on 30 Oct 2014 at 1:02

[GoogleCodeExporter]

Our app got rejected as well. Seems that Apple is starting to reject for this 
reason all the sudden or at random. We've had Google Sign in for a while now 
and just now they are starting to complain about it.  

Original comment by imrigon...@gmail.com on 2 Nov 2014 at 3:23

[GoogleCodeExporter]

Our app got rejected for this reason as well. Previous versions was approved 
just fine. But now they seem to have different policy.

Original comment by roman.r...@gmail.com on 3 Nov 2014 at 11:07

[GoogleCodeExporter]

Same problem here... Rejected.

Original comment by brigadie...@gmail.com on 6 Nov 2014 at 6:07

[GoogleCodeExporter]

Okay, after of week of waiting and correspondence, Apple called us about this 
issue. 
Just got off the phone with actual person from App Review.

GOOD:
You CAN Sign in With Google Plus APP. That is, if the app is ALREADY installed 
on user's device.
Can NOT open Google Sign in in Safari.

BAD:
They Insist that you implement In-App Web View Sign in. That is, opening web 
view without leaving the app. (Like it was in iOS SDK 3 times with facebook and 
similar)
And yes, they know that in-app web view is a "hack" and not officially 
supported by GPlus SDK. But they still say this is the only option if user do 
not have Google Plus app installed on device.

WORSE:
And here's the worst part:
In the case that user don't have Google Plus app installed on their device - 
You CAN NOT Mention to the user that they must have this app installed in order 
to sign in.
You ca not mention the other app, not even in indirect term like "If you had 
this app on your device you could sign in with Google". 
You cannot mention this in Alert dialog, not in app description, help or 
anywhere else.

For those who's getting rejected, here's how to do a quick fix and simply 
disable function if App is not installed:

BOOL isAppInstalled=[[UIApplication sharedApplication] canOpenURL: [NSURL 
URLWithString:@"gplus://"]];
    if(isAppInstalled) {
// perform google sign in with the app.
}

Now, Google, when is new version of SDK coming out? Don't leave us hanging 
please!

And this this issue type above is "Enhancement" ?!? it's mode like a blocking 
critical bug.

Original comment by roman.r...@gmail.com on 7 Nov 2014 at 9:31

[GoogleCodeExporter]

@Roman, and everyone else on this thread, huge thanks for reporting back. It 
sounds like the community is very well aware of the factors at play. We'll 
update this thread as soon as we have more to affirmatively report.

That said, agreed that "Enhancement" is not the right categorization here. It's 
not being treated lightly, just that the other two options are "Defect" and 
"Other." You could make a fair argument that either applies, depending on your 
frame of reference.

Original comment by fa...@google.com on 7 Nov 2014 at 9:38

[GoogleCodeExporter]

Same here, our update has just been rejected for the same reason. Our app has 
been including Google+ SSO since the v1 in April 2014, and many updates have 
been approved since, but this time, they did not like it.

Original comment by woody...@gmail.com on 8 Nov 2014 at 7:31

[GoogleCodeExporter]

Our app just got rejected for testflight beta submission because of this. We 
offer Facebook and google login...now that i see so many others having this 
priblem I am fearful we're going to be rejected for our full submission into 
the appstore when they review that later this week. This is terrible and seems 
like an arbitrary 'thermonuclear' approach to sticking it to google. :(

Original comment by Bryan.La...@gmail.com on 8 Nov 2014 at 3:40

[GoogleCodeExporter]

Our App got rejected yesterday and I came across with this thread... Is Google 
even making any changes to their iOS libs? When arm64 appeared we had some 
issues updating Google Analytics because their lib didn't support the new 
architecture and now I come across this, dating from Jul 14, and almost 6 
months later there's no official solution but developing a hack to bypass the 
lib open url! Is there any ETA for a fix on G+ sign in?
Removing G+ sign in or falling back to users who have Google Plus App installed 
is not an option for our customer, so is imperative to have this working...

Original comment by flag.and...@gmail.com on 20 Nov 2014 at 1:50

[GoogleCodeExporter]

Our app got rejected too... I hide the G+ Signin button if the user don't have 
the official Google +app installed... and the app got approved.

BOOL isGpInstalled = [[UIApplication sharedApplication] canOpenURL: [NSURL URLWithString:@"gplus://"]]; self.gpSignInButton.hidden = !isGpInstalled;

We're waiting for a an update of the Google+ SDK, if no update is coming within 
the next  couple of weeks I will implement a Google+ login inside a custom 
WebView.

Original comment by pierre.l...@flayr.com on 20 Nov 2014 at 2:12

[GoogleCodeExporter]

We did like #35 and got approved. But it means a lot of existing users won't be 
able to log in anymore and won't know/understand why..

Original comment by woody...@gmail.com on 20 Nov 2014 at 2:16

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Another rejection to report. Seems Apple is being really inconsistent about 
whose lives it wants to ruin. Going with the solution from #5/6/7 and hoping 
for the best.

Original comment by bigal...@gmail.com on 3 Dec 2014 at 9:57

[GoogleCodeExporter]

Today is 3 months anniversary of this critical issue.  
Can someone from Google team tell us when the update is expected? what is the 
time frame - is it weeks, months?
As it happens when big corporation fighting the ones who are suffering are 
regular people caught in the middle of that.

Original comment by roman.r...@gmail.com on 3 Dec 2014 at 10:06

[GoogleCodeExporter]

After 3 rejections for this reason, my app was published. 

I use a webview and a class that extend UIApplication and override the openURL 
method.  I don't like this solution, but it seems to be the only method for 
pass the submission.

I don't understand why Google doesn't fix this problem. Every developer that 
include Google+ in his app and read step by step the Google guide, have to see 
his app rejected.

Original comment by antongiu...@gmail.com on 4 Dec 2014 at 9:00

[GoogleCodeExporter]

Just got the same issue. I'm really shocked to see that little feedback / 
update from Google team. This is an official SDK: has Google+ totally been 
given up by its own team or...?

Original comment by cwehr...@gmail.com on 8 Dec 2014 at 4:39

[GoogleCodeExporter]

My app also just got rejected after submitting a spelling error fix due to this 
problem. Now I am also stuck using a webview to get my fix through.

Looking for an official fix like everyone else.

Original comment by mr.cox...@mths.ca on 10 Dec 2014 at 9:10

[GoogleCodeExporter]

The latest update to our application was also recently rejected for the same 
reason. It seems that Apple reviewers act randomly as the original app was 
published only 2 weeks prior.

We're implementing the UIWebView hack but would love to see an official fix 
soon.

Original comment by rodolfoc...@gmail.com on 12 Dec 2014 at 7:02

[GoogleCodeExporter]

Is there any updates on this? Apple are still knocking back submissions with 
Google+ login.

Cheers,

Mav

Original comment by mavrick....@gmail.com on 6 Jan 2015 at 1:37

[GoogleCodeExporter]

Any updates on this issue? made a submission removing Google+ login. would like 
to get an updated SDK with official fix.

Original comment by dvn.prab...@gmail.com on 6 Jan 2015 at 8:07

[GoogleCodeExporter]

Thanks again everyone for the updates. We've been hard at work on this problem 
and hope to have a much more comprehensive set of updates soon to provide here, 
including updated SDK.

In the meantime, a brief reminder statement on rationale for our approach. 
You're welcome to adapt it for app store appeals, though YMMV on efficacy.

""
The Google Sign-In button does a fast app-switch on iOS because it is the best 
way to achieve single sign-on, where the user only needs to enter their 
password once per device.  Google believes any usability issue of the 
app-switch is greatly outweighed by the usability benefit of only needing to 
enter your Google password once per device. 

Currently, we perform sign-in using mobile Safari when Google+ is not present 
on the user’s device (in early 2015, more Google apps will support this 
capability). 

Our Sign-in SDKs do not support embedded web-views.  Web-views are unable to 
provide single sign-on, and are a security risk since they encourage users to 
enter their credentials directly into 3rd party applications which have the 
ability to collect those credentials without the user’s knowledge.

We hope you agree with our reasons for doing an app-switch, and that your app 
will be approved on appeal.
""

Original comment by fa...@google.com on 6 Jan 2015 at 9:23

[GoogleCodeExporter]

Thanks for comment #46. I think most of us agree that the current sign in 
process that you support is functionally the best solution to singing in. 
However, Apple still rejects apps that use this implementation. Have you 
(Google) explained to Apple what you just told us in your previous 
comment...explaining how the current sign in process is in fact the best 
implementation?

Also, thank you for working hard on providing us updates :)

Original comment by MatthewW...@gmail.com on 6 Jan 2015 at 9:36

[GoogleCodeExporter]

To recap this thread:

July 4, 2014: Apple started rejecting apps at random, this issue is created
September 4, 2014: rejections are almost certain.
Community members posted workaround in the thread. 

October 3, 2014: first response from Google developer. "We're well aware and 
working on this via a number of means."

November 7: "We'll update this thread as soon as we have more to affirmatively 
report."

January 6, 2015, three months later:
"We've been hard at work on this problem and hope to have a much more 
comprehensive set of updates soon to provide here, including updated SDK."

Still vague and no time frame. 

Also Google developer provided canned reply that you can send to Apple review 
board. This text can be viewed as Google's attempt to create some kind of 
outcry in hope that Apple will reconsider their position. 

Sending this reply to Apple is a complete waste of time. It will not be 
forwarded to anyone making decisions there. And will only delay your review 
until you succumb and provide app without Google Sign In.  I spent half an hour 
on the phone with actual Apple review person and they are very adamant on the 
rejecting web log ins.  Not a chance. 

Original comment by roman.r...@gmail.com on 6 Jan 2015 at 9:57

[GoogleCodeExporter]

We're frustrated as well. It's impossible to say what our efforts will yield, 
as the App Store review process is subject to policies we will never control. 

But it's things like the care and feedback on this thread from our developers 
that give heft to to, among a few other things, one of the key efforts involved 
here. Note from the prior message: "in early 2015, more Google apps will 
support this capability." That takes time, but we expect it to make a 
meaningful impact.

Original comment by fa...@google.com on 6 Jan 2015 at 11:47

[GoogleCodeExporter]

Higher up on this thread I recommended delaying the sign in with google option 
till later in the app. Meaning that login is not enforced and thus Apple would 
approve the App. I would like to retract my statement as we have been rejected 
for including Google Sign In which bounces the user into Safari.

Given that I can't see the developers at Google coming up with a solution any 
time soon, I would encourage people to integrate NXOAuthClient (found here 
https://github.com/nxtbgthng/OAuth2Client ). This library will allow you to 
sign in to google, refresh tokens and perform any API requests. It should take 
anyone approximately a day to integrate this functionality. 

There is a tutorial that can be found here 
http://www.idmworks.com/blog/entry/getting-started-with-oauth2client-on-ios

I have successfully implemented this as a solution so please feel free to 
contact me if you need assistance.

Original comment by daniel.g...@afrozaar.com on 19 Jan 2015 at 10:56