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]

Popular apps live in the App Store that exhibit current Google sign-in 
behaviour  

- The Guardian (https://itunes.apple.com/gb/app/the-guardian/id409128287)
- Soundcloud 
(https://itunes.apple.com/gb/app/soundcloud-music-audio/id336353151)
- Flixter 
(https://itunes.apple.com/gb/app/movies-by-flixster-rotten/id284235722)
- MTV Trax 
(https://itunes.apple.com/gb/app/mtv-trax-free-music-player/id925265172)

Original comment by alasdair...@musicqubed.com on 30 Jan 2015 at 11:20

[GoogleCodeExporter]

Our app has also been denied a few times now for this same reason. Google we 
really need a permanent solution for this. Thank you.

Original comment by davt...@gmail.com on 2 Feb 2015 at 5:36

[GoogleCodeExporter]

After submitting an update to Apple for our app, we too got rejected for the 
reasons listed here. 

Original comment by rashaad....@cumuluspoint.com on 8 Feb 2015 at 4:31

[GoogleCodeExporter]

Just for record, our app also rejected for this reason. Any update on this fix? 
Does anyone used any hacks to get approval? Please help us with suggestion.

Original comment by girinamb...@gmail.com on 17 Feb 2015 at 3:23

[GoogleCodeExporter]

And if this issue is not fixable, I think better to update documentation with 
NOTE saying, please don't use for Sign-In purpose. That saves app developers 
time. 
https://developers.google.com/+/mobile/ios/sign-in

Original comment by girinamb...@gmail.com on 17 Feb 2015 at 3:47

[GoogleCodeExporter]

Regarding hacks and workarounds, I have this hack that allows to pass review 
and keep the SignIn.  Basically you hide the button for the time while app is 
in review.
The downside is that immediately after release your users will ask you how to 
log in, but once cutoff time passed, it will be back to normal, with sign in 
button visible.

Here it is:

// Check if Google Plus app is installed
    BOOL isAppInstalled=[[UIApplication sharedApplication] canOpenURL: [NSURL URLWithString:@"gplus://"]];
    if(!isAppInstalled ) {

        //hide before this date, show after this date. Change the date before submitting the app for review.
// Should be current date plus about 10 days. See http://appreviewtimes.com
        NSDateComponents *comps = [[NSDateComponents alloc] init];
        [comps setDay:26];
        [comps setMonth:2];
        [comps setYear:2015];

        //If date have not passed then hide the button. App store review will not see the google Sign in button.
        if ([[NSDate date] compare:[[NSCalendar currentCalendar] dateFromComponents:comps]] == NSOrderedAscending){
            googleSignInButton.hidden=YES;
     }

Original comment by roman.r...@gmail.com on 17 Feb 2015 at 4:01

[GoogleCodeExporter]

@56 - If Apple catches you doing this you can be banned for life from the App 
store. 

Original comment by karlgood...@gmail.com on 17 Feb 2015 at 2:18

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

If you have come here from Google search looking for solution for app store 
rejection, please Star this issue (at the top of the page). It signifies 
people's interest in this issue. Issues with more stars will be more visible in 
overall list of issues.  
While it has been more than 6 months waiting for solution form Google SDK team. 
Commenting or adding stars seems be the only way that we can influence the 
Google's decision to prioritise this issue.

Original comment by roman.r...@gmail.com on 20 Feb 2015 at 8:35

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

First off, Google is 100% right about this. It's a matter of security and that 
trumps minor UX hoops like (gasp) having to jump into Safari for a minute.  I 
hope Google doesn't "undig" their heals on the matter - they shouldn't.

We submitted a rather lengthly, reasoned, and civil appeal on this same issue 
today, and just got rejected.  We pointed out the fact that the Facebook login 
button in the same app has the exact same flow as well, but we just got a 
pretty generic response (that didn't address the security implications or 
double standard whatsoever):

"Specifically, it is not appropriate to redirect users to Safari for Google+ 
authentication. Users should be able to sign in to Google+ directly in the app 
without being redirected to Safari."

The message is pretty clear: UX > Security (but just for Google+). We're 
pushing back, but not expecting much. Would love for someone with more weight 
to throw it around on this. :\

Original comment by jeremy.m...@stre.am on 20 Feb 2015 at 11:23

[GoogleCodeExporter]

Thanks Jeremy, and everyone else here. We're as dug in as we can be on the 
point of security, while putting finishing touches on our integrations of 
Consent handling into additional Google apps, as noted in @49.

We will be partnering this with an updated SDK that among other things 
implements best-known practices acceptable to review, which still hold security 
(and usability: embedded WebViews mandate repeated entry of credentials) 
paramount.

Original comment by fa...@google.com on 20 Feb 2015 at 11:27

[GoogleCodeExporter]

Is there a timeline for the new SDK?  We have been holding off resubmitting our 
latest app updates in the hopes a new SDK will come out that addresses the 
issue.  We are entering a crossroads and need to decide if we go without 
Google+ logins for the time being.  Any perspective on a timeline for a fix 
would really help.

Original comment by rashaad....@cumuluspoint.com on 21 Feb 2015 at 12:31

[GoogleCodeExporter]

Our app got rejected for this same reason. We developed the in-app web view 
workaround and got approved.
We know that this is subject to security concerns by the users, but still find 
it as the best approach. If you need to offer Google+ login functionality to 
your users and want to get your app approved, you should consider doing the 
same...

Original comment by sebastia...@gmail.com on 21 Feb 2015 at 1:59

[GoogleCodeExporter]

While preparing our case for another round with Apple, I found a couple 
interesting points:

- The actual OAuth RFC specifically calls out embedded user-agents as a 
security challenge: 

    An embedded user-agent poses a security challenge because resource
    owners are authenticating in an unidentified window without access
    to the visual protections found in most external user-agents.  An
    embedded user-agent educates end-users to trust unidentified
    requests for authentication (making phishing attacks easier to
    execute).

    [source: https://tools.ietf.org/html/rfc6749#section-9]

- Given that the Google+ SDK does not expose a supported WebView solution, and 
that forcing it into a WebView constitutes a "hack" that Google ha expressly 
advised against, one could make a very strong argument that it's actually a 
violation of App Store Review Guideline 2.5:

    2.5 Apps that use non-public APIs will be rejected

    [source: https://developer.apple.com/app-store/review/guidelines/]

So, feel free to add these to your laundry list of compelling reasons that will 
be summarily ignored and countered with a canned response on your next appeal.

Original comment by jeremy.m...@stre.am on 23 Feb 2015 at 2:14

[GoogleCodeExporter]

Apple called my company to talk about our rejection for this same issue.  We 
told them that this is how other services that provide authentication work, 
namely Facebook, and that the redirect to Safari outweighs the user having to 
re-enter their credentials.

They told us to file a radar if we want this review policy changed.  So I did:

http://openradar.appspot.com/radar?id=5744622710030336

If more developers file bug reports about this issue it might compel them to 
change the policy:
https://bugreport.apple.com

Original comment by ScottBos...@gmail.com on 24 Feb 2015 at 11:14

[GoogleCodeExporter]

One of our apps has been rejected as well for the same reasons explained by 
others in this thread. We tried to explain that other apps do exactly the same, 
but to no avail. They kept rejecting it. In the end we had to remove Google+ 
sign in to make sure the app would be approved. 

The best would be for someone at Google to talk to whoever is in charge of app 
reviews at Apple and figure out a solution, either by engineering or by 
amending the chapter that makes apps exposing this behavior being rejected.

Original comment by santine...@altralogica.it on 27 Feb 2015 at 2:13

[GoogleCodeExporter]

My app got rejected three times till now and apple review team does not look 
like to be willing to approve it in any case: no matter what you write or how 
much you complain... It is such a pain! Google please do something!

Original comment by rambodra...@gmail.com on 1 Mar 2015 at 3:22

[GoogleCodeExporter]

Hi Guys,

I am having the same issues with the app rejection. I have gone through this 
thread and through lot of others threads and I would like your comments or 
experience with the following questions:

1. If you show the G+ SignIn button only when the G+ app is installed on the 
device, does this works and it is approved? The rejection is only because the 
app redirects to Safari? Or it will be rejected anyways since there is a switch 
to the G+ app?

2. I know that Google does not recommend the approach using UIWebView and 
GTMOAuth2ViewControllerTouch. But, is this approach accepted by Apple? I have 
read some threads about people being rejected for another reason regarding the 
WebView having a link to "Create an account" and they stated the rejection was 
for violating:

 "11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the App, such as a "buy" button that goes to a web site to purchase a digital book, will be rejected"

Have anyone submitted an app with this approach and got approved?

I am really looking to find a way of not having to remove the G+ Sign In, so 
any input or experiences will be appreciated.

Thanks!

Original comment by cho...@gmail.com on 2 Mar 2015 at 7:03

[GoogleCodeExporter]

What about the Stack Exchange iOS app?
https://itunes.apple.com/app/stack-exchange/id871299723
It has G+ login through Safari

Original comment by dnt.l...@gmail.com on 2 Mar 2015 at 8:34

[GoogleCodeExporter]

Hi

I created the webview workaround from this thread and also opened this issue

Yes, it is confirmed that you will pass the review implementing the webview
solution (didnt came across anybody who done the webview approach and got
rejected)

The only problem is, that you can as a developer intercept the login
credentials (email, password), therefore Google doesnt like it, but they
have no other chance, as this is the only approach passing the review

Nice chess game Apple

Original comment by peter.pa...@gmail.com on 2 Mar 2015 at 8:43

[GoogleCodeExporter]

And I can confirm that if you detect the app and only show the login button if 
the Google App exists that you will pass review.

Original comment by karlgood...@gmail.com on 2 Mar 2015 at 8:54

[GoogleCodeExporter]

My app was rejected for the same reason. I'm absolutelly impressed that 8 
months ago from the initial post there is no Google solution for this problem. 

UIWebView is not a solution. As an user I won't trust an application who embeds 
Google+ sign in in a UIWebView.

The only solution is disable Google+ sign in

Original comment by hyde....@gmail.com on 6 Mar 2015 at 7:19

[GoogleCodeExporter]

my app was rejected because of that - any surefire solution?

Original comment by nur...@gmail.com on 8 Mar 2015 at 12:02

[GoogleCodeExporter]

Our app update was rejected because of this. However, providing the information 
from #46 and #65 seemed to be enough for approval the second time around. I 
doubt we'll have as much luck next time though. Hopefully we can get an update 
soon. 

Original comment by ja...@iruleathome.com on 8 Mar 2015 at 2:30

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Our app has been a half of a month switching between Review and Rejection 
state. I've provided three attempts to reply in Resolution center, last one 
with the arguments mentioned above, got rejected three times. Then I've made an 
appeal on a Review Board – same result, got a reply 3 minutes after 
automatic message arrived, so I have some doubts somebody even went through the 
issue. So they forced us to implement the signing in via presented webview.

Because of this, Google+ SDK comes totally useless in our case as we use in for 
signing in only – so we got rid of this closed source binary blob with lots 
of useless dependencies. However, I still find the Review process as one big 
failure by stating that Apple with their rules along with the Review team is 
just full of false-noble, pseudo-innovative and likely-to-be-elegant idiots.

Original comment by n3weRm0re.ewer on 21 Mar 2015 at 4:25

[GoogleCodeExporter]

@70 -- We at Stack Exchange just got a notice about this and have two weeks to 
fix it, looks like this thread is being monitored ;) I doubt Google can do much 
to respond to this but I sincerely hope something is added to the Google+ SDK 
to allow the ability to do WebView login (like Facebook supports, but isn't 
required to do) since every user having to implement their own WebView login is 
an easy road towards phishing.

Original comment by krahjerdi on 24 Mar 2015 at 10:28

[GoogleCodeExporter]

Open since July 2014 and still no solution. Nice... 

Original comment by dort...@gmail.com on 25 Mar 2015 at 8:53

[GoogleCodeExporter]

Thought I'd chime in and say that I got an app update rejected too, but not for 
Google+ per se, but for ANY service that uses Safari for login, if the app 
isn't installed. Sigh.

Original comment by dida...@gmail.com on 31 Mar 2015 at 7:30

[GoogleCodeExporter]

Pushed another update, but no such luck this time. Even with the statement that 
got us approved last time, the reviewer still rejected the app. I'm going to 
have to create an embedded web view to get this out, which is something I 
really don't want to do due to the obvious security concerns. Can we get some 
kind of update on whether or not this is still being worked on? 

Original comment by ja...@iruleathome.com on 1 Apr 2015 at 3:08

[GoogleCodeExporter]

My app was rejected today for the same reason. Take it there's still no 
particular consensus on a workaround?

Original comment by richard....@googlemail.com on 1 Apr 2015 at 7:26

[GoogleCodeExporter]

And... Stack Exchange got rejected.  Talked with WWDR and they aren't budging.  
I get that security concerns are what they are (I'm certainly not happy with 
the idea of in-app auth), but having everyone roll their own web view because 
... reasons ... isn't helping anyone.

Original comment by brian.ni...@gmail.com on 2 Apr 2015 at 6:04

[GoogleCodeExporter]

echo "We were rejected as well.  Appealed with the suggested text, rejected 
again. I guess we will be rolling a webview ourselves too." > /dev/null

Original comment by i...@ephemeronindustries.com on 2 Apr 2015 at 6:31

[GoogleCodeExporter]

Has anyone implemented the webview in Swift?
I have Google+ working in Swift (thanks to this: 
https://medium.com/swift-programming/google-in-swift-a0943352dfe9) but now want 
to implement the webview thing, so Apple will not reject my app.

Still learning Swift, so not sure what to do.
Thanks

Original comment by patr...@coxall.ca on 3 Apr 2015 at 12:52

[GoogleCodeExporter]

Actually, I believe there is a 'consensus' - from apple side.

After 2 unspecific feedbacks, I've managed to extract third one from them:

During further review, we found when logging in with Google, it launches Safari 
for login. Currently, Facebook login is in compliance. It would be appropriate 
to have a web view within the app for Google login, since users are can to log 
in without opening Safari first.

Original comment by vladimir...@codesynapses.com on 3 Apr 2015 at 1:59

[GoogleCodeExporter]

Also rejected for auto-renewable subscriptions along with this issue. I argued 
that Facebook SSO is the same flow and they came back and still rejected our 
auto-renewable service, but said and I quote "Also, please have the Google+ 
login mechanism stay present in the app."  

I got on the phone and won the auto-renewable subscription battle.  However, 
they re-iterated that the Google SSO was still a problem.  I told Apple on the 
phone that they explicitly said in our thread in iTunesConnect that it was okay 
and I didn't need to be change.  They replied "That was a mistake on our side, 
you still need to change it...".  Very inconsistent.

Facebook must be paying $$$ to have Apple reject Google+ SSO, that is all.

Original comment by d...@team.shoeboxed.com on 3 Apr 2015 at 2:36

[GoogleCodeExporter]

Google. Please wake up and work!

Original comment by kaiyang...@gmail.com on 6 Apr 2015 at 1:23

[GoogleCodeExporter]

Our also got rejected for this and we had to hackily work around it. FYI, when 
you intercept the success URL to forward to the G+ library, it will only call 
your sign in delegate if you lie about the sourceApplication and claim its 
"com.apple.mobilesafari" This is a super crappy hack and it'd be great to have 
a more officially supported solution if people are going to have to do this 
anyway, even if no one thinks it's the right approach.

Original comment by ak...@edx.org on 9 Apr 2015 at 7:33

[GoogleCodeExporter]

Can you elaborate on this hack? Perhaps post a link with source?

Original comment by alasdair...@musicqubed.com on 10 Apr 2015 at 7:58

[GoogleCodeExporter]

The official iOS Playstation App behavior is exactly as Google Plus SDK. When 
you try to log in Playstation Network, the app opens Safari browser to perform 
the auth and then returns to the Playstation App. 

Original comment by hyde....@gmail.com on 10 Apr 2015 at 11:46

[GoogleCodeExporter]

We got the new version of our game "The Grumpy Granny" rejected for the same 
reason. The first version has the login through google and was accepted, 
probably they did not notice it.

We are using libgdx and robovm... and we are trying to integrate the webview 
(the only available solution to keep google game service), the problem is that 
we have difficulties to subclass UIApplication and therefore  override 
OpenURL(NSURL url). Anyone got a solution using libgdx and robovm? We are 
losing so much work time because of that!

Help would be greatly appreciated!

Original comment by carlo.b1...@gmail.com on 13 Apr 2015 at 9:22

[GoogleCodeExporter]

I was wondering if anyone has instructions, to add the above in, that are 
detailed and have pictures, just like on the Google website?
(https://developers.google.com/+/mobile/ios/sign-in)

I am still new to Objective-C and got the standard Google part working, but 
cannot figure out from the thread above how to get the webview working.

Thanks

Original comment by patr...@coxall.ca on 14 Apr 2015 at 1:51

[GoogleCodeExporter]

hi i wrote this tutorial 
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 14 Apr 2015 at 11:35

[GoogleCodeExporter]

We managed to do it for our game "The Grumpy Granny" using Libgdx!
This is how:
-Subclass UIApplication and override openURL
public class MyUIApplication extends UIApplication{
    public boolean openURL(NSURL url)
    {
        //System.out.println(url.getAbsoluteString());
        if (url.getAbsoluteString().startsWith("googlechrome-x-callback:"))
        {
            return false;
        } else
        {
            if (url.getAbsoluteString().startsWith("https://accounts.google.com/o/oauth2/auth"))
            {
                IOSLauncher.ShowWebView(url);
                return false;
            }
        }

        return false;
    }
}

in IOSLauncher change main method like this:
 public static void main(String[] argv) {
        NSAutoreleasePool pool = new NSAutoreleasePool();
        //UIApplication.main(argv, null, IOSLauncher.class);
        MyUIApplication.main(argv, MyUIApplication.class, IOSLauncher.class);
        pool.close();
 }
- Add the webview after super.didFinishLaunching(application, launchOptions);
        CGRect webFrame = gdxApp.getUIViewController().getView().getFrame();
        myWebView = new UIWebView(webFrame);
        myWebView.setBackgroundColor(UIColor.white());
        myWebView.setScalesPageToFit(true);
        myWebView.setAutoresizingMask(UIViewAutoresizing.FlexibleWidth);
        myWebView.setDelegate(new WebViewDelegate());

create webview delegate class

    private class WebViewDelegate extends UIWebViewDelegateAdapter {
        @Override
        public void didStartLoad (UIWebView webView) {
            UIApplication.getSharedApplication().setNetworkActivityIndicatorVisible(true);
        }

        @Override
        public void didFinishLoad (UIWebView webView) {

            UIApplication.getSharedApplication().setNetworkActivityIndicatorVisible(false);
        }
        @Override
        public boolean shouldStartLoad(UIWebView webView, NSURLRequest request, UIWebViewNavigationType navigationType)
        {
            if (request.getURL().getAbsoluteString().startsWith("com.yourcompany.yourgame:/oauth2callback"))
            {
                GPPURLHandler.handleURL(request.getURL(), "com.apple.mobilesafari", null);
                return false;
            }
            return true;
        }

    }   

remove the webview when user signed in:
    public void didFinishGamesSignInWithError(NSError error)
    {

        if (error == null) {
            myWebView.removeFromSuperview();
......................................
        }

Hope it can help people using libgdx

Original comment by carlo.b1...@gmail.com on 15 Apr 2015 at 8:31

[GoogleCodeExporter]

Why hasn't someone at Google updated the documentation for the SDK to recognize 
this issue? I think it's understandable that Google doesn't want to encourage 
developers to do something insecure, but encouraging them to do something that 
will probably lead to their app being rejected without warning isn't the right 
thing to do either.

Original comment by jus...@contactually.com on 20 Apr 2015 at 1:59

[GoogleCodeExporter]

Wondering if anyone can help?

I have followed the instructions from Google 
(https://developers.google.com/+/mobile/ios/sign-in) and got my test app 
working. You click on the "login" button and it opens Safari and you can login 
and you get back the email address.

I then tried to integrate the fix, so that the webview opens up inside the app 
(from: 
http://stackoverflow.com/questions/15281386/google-iphone-api-sign-in-and-share-
without-leaving-app). I got steps 1, 2 & 3 working. I have a notification 
working and it is catching it and I have a webview opening up that lets you log 
in.

My problem is that once logged in, the webview returns to the standard Google 
page and I am not receiving any notification in finishedWithAuth. Not sure what 
I am doing wrong.

I have placed my code on Github 
(https://github.com/Mr-Coxall/Google-Plus-Login-for-iOS).
I am using Google's kClientId, so anyone should be able to run it.
Any help would be wonderful.
Thanks

Original comment by patr...@coxall.ca on 5 May 2015 at 3:39

[GoogleCodeExporter]

My app also reject because of G+ sign in. following replay

We noticed an issue in your app that contributes to a lower quality user 
experience than Apple users expect.

Specifically, the app opens a web page in mobile Safari for Google+ 
authentication, then returns the user to the app. The user should be able to 
sign in to Google+ without opening Safari.

Next Steps

It would be appropriate to revise your app to provide a Google+ web view or 
native login to authenticate users within your app.

Original comment by arkaya...@gmail.com on 8 May 2015 at 11:13

[GoogleCodeExporter]

I just had my app rejected a second time. The first time it was because I was 
opening Safari. I implemented the fix recommended above. Now they are saying 
this: 

Your app includes an account registration feature, which is considered an 
access to external mechanisms for purchases or subscriptions to be used in the 
app. Specifically, Google "Create Account" feature. This feature does not 
comply with the App Store Review Guidelines.

This is unbelievable!!! 

Am I missing something here? Is there a way to redirect people to a google sign 
in page that does not have Create Account? (I actually think that would be the 
wrong experience)

Original comment by cmaier...@gmail.com on 10 May 2015 at 9:06

[GoogleCodeExporter]

[deleted comment]