Open GoogleCodeExporter opened 9 years ago
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
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
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
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
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
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
@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
[deleted comment]
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
[deleted comment]
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
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
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
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
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
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
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
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
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
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
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
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
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
my app was rejected because of that - any surefire solution?
Original comment by nur...@gmail.com
on 8 Mar 2015 at 12:02
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
[deleted comment]
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
@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
Open since July 2014 and still no solution. Nice...
Original comment by dort...@gmail.com
on 25 Mar 2015 at 8:53
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
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
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
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
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
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
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
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
Google. Please wake up and work!
Original comment by kaiyang...@gmail.com
on 6 Apr 2015 at 1:23
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
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
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
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
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
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
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
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
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
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
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
[deleted comment]
Original issue reported on code.google.com by
peter.pa...@gmail.com
on 4 Jul 2014 at 8:56