I haven't quite done enough research to be sure, but it sounds like there is a way to open a WKWebView sheet in a similar way to opening the mail sheet, where your app doesn't actually have access to the window that is opened. I believe this is referred to as a UIRemoteViewController. There are some posts about it here:
- http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-6/ - http://chris.cm/ios-8-remote-view-controllers/ Given the response you got, I wouldn't be surprised if UIRemoteViewController becomes an official API and they are pre-emptively rejecting apps that don't use it. I guess we'll fine out on June 8th ;-) --- Aaron http://aaronparecki.com On Mon, May 11, 2015 at 10:12 PM, Joost van Dijk <[email protected]> wrote: > I am stunned. What Apple is saying here is that we shouldn’t bother using > OAuth2. > > We might as well revert to asking for the user’s Google/LinkedIn > credentials directly. When we make the login page sufficiently familiar, > the user won’t be able to tell the difference anyway. > —Joost > > On 11 May 2015, at 18:54, Dick Hardt <[email protected]> wrote: > > Here is what I received from the Appeal Review Board: > > (highlighting is mine) > > Hello Dick, >> >> We are writing to let you know the results of your appeal for your app, >> Bubbler Mobile. >> >> The App Review Board evaluated your app and determined that the original >> rejection feedback for the current version of your app is valid. Your app >> does not comply with: >> >> 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 >> >> Upon further investigation, we found that your app takes the user out to >> Safari in order to login with Google and Linkedin, which is not in >> compliance with the App Store Review Guidelines. While we understand your >> intend to launch to Safari for login provides a better user experience, it >> is not in compliance with the App Store Review Guidelines. The user should >> be able to log into Google and Linkedin without opening Safari first within >> the app. Please provide users with a way to login with Google and >> Linkedin in the app. >> >> Therefore, your app will not be posted to the App Store at this time. >> >> We hope you will consider making the necessary changes to be in >> compliance with the App Store Review Guidelines and will resubmit your >> revised binary. >> >> Best regards, >> Nicki >> App Review Board >> > > On Fri, May 8, 2015 at 5:30 PM, Nat Sakimura <[email protected]> wrote: > >> Thanks Dick. >> OIDF is also trying to write a white paper why in-app browser for this >> purpose is a bad idea. >> >> =nat via iPhone >> >> 2015/05/09 4:28、Dick Hardt <[email protected]> のメッセージ: >> >> Glad to know I was not missing something. >> >> I explained all the logic in my first response to the reviewer. Next >> response was to comply with 10.6 >> >> I have filed an appeal. Will keep list updated. >> >> Aaron: the LinkedIn API claw back really sucks. Facebook turned down APIs >> earlier than v2 last month, and now there is little profile data from them. >> Getting data out of the silos has gotten much tougher. >> >> >> On Fri, May 8, 2015 at 7:46 PM, Joost van Dijk <[email protected]> >> wrote: >> >>> This is indeed very bad news. Not just because we are developing apps >>> that use the same approach, but also because we have declared in-app >>> browsers to be Bad Practice when used for authentication because of the >>> reasons you described. >>> >>> Furthermore, it just won't work. Our OAuth authorization server >>> authenticates to an identity federation where very diverse authentication >>> methods are used, such as TLS client authentication. An app won't have >>> access to the private key needed to authenticate when using an in-app >>> browser: you really need to open the platform browser for this to work. >>> >>> Cheers, >>> >>> -- >>> Joost >>> >>> On 08 May 2015, at 18:21, Dick Hardt <[email protected]> wrote: >>> >>> I have an app that is was submitted to TestFlight that was rejected for >>> opening up Safari for getting authorization from Google or LinkedIn. >>> >>> Apple wants me to load the Google or LinkedIn page with an in-app >>> browser to comply with >>> >>> >>> - 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 >>> - >>> >>> I'm thinking this is crazy >>> >>> The user experience is better bouncing to Safari as it: >>> >>> 1) clearly signals to the user that they are providing their credentials >>> to Google or LinkedIn >>> >>> 2) Google and LinkedIn can pre-fill the username if they have previously >>> used the browser at either site >>> >>> 3) If they Safari has their credentials, Safari can fill them in at >>> Google / LinkedIn >>> >>> From a security point of view, the in-app webview has >>> >>> 1) NO signal to the user they are providing their credentials to >>> LinkedIn or Google. >>> >>> 2) Looks like a new browser instance to LinkedIn and Google rather than >>> an already known device. >>> >>> I'm surprised Apple is taking this stance. Am I missing something? >>> >>> -- Dick >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "OAuth" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "OAuth" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OAuth" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OAuth" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "OAuth" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
