Dealing with rejection. Apple, OpenID and my app!

So, over the past two weeks, I have submitted my new I May Be Late app to Apple twice and they have rejected my app twice. This has left me feeling rather frustrated and a little disheartened.

My app is a companion to my new web application I May Be Late which is designed to allow London Commuters to have automated messages and alerts sent should they find themselves delayed on the London Underground during their daily commute. Useful if your manager is wondering where you are first thing in the morning. It’s not too fancy, but I think it’s something that could prove very useful.

When building the web application, I took a page out of StackOverflow’s book and decided I would implement OpenID for authentication on my site. I’m a big fan of the OpenID framework so it made sense for me to implement it in my own projects. It also removes a burden on managing user’s passwords. I offer access via Google, Facebook, Yahoo and the general OpenID site. These four should, in my opinion, cover quite a large number of people making the site easily accessible.

When it came to building the iPhone app, I had to copy the same mechanism, so I implemented a simple login screen on the app and with the help of Safari, I completed a full end-to-end OpenID login mechanism for my app. It’s a simple three step process. Choose the account, login using that account, get signed into the app.

 

 

I had originally used a UIWebView to load the login page of the selected provider, but decided against that since opening Safari gives the users more confidence they are where they thing they are i.e. they know they are on Google’s signin page as they can see the address bar and the SSL padlock.

Unfortunately, Apple don’t share my sentiments of this process. They have rejected my app with the following reason:

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

The image they attached is the Login Screen. I can, in a way, see where they are coming from. I am linking to external mechanisms e.g. Google’s OpenID page, but that is not in any way related to purchases or subscriptions. Unfortunately, this is where the waters get muddy!

On the website, I do offer users the ability to sign up for a Pro account by paying a monthly subscription using PayPal. This does, in turn, allow the user to select SMS numbers from within the iOS application for particular alerts. This ability isn’t limited to the iOS application by itself as you can configure the SMS settings using the web also. So in a round-about way, I am enabling a feature in the app by paying externally, however that feature isn’t limited to the iPhone.

I’ve raised a dispute with Apple’s App Board to see if I cannot get to the bottom of this rejection.

I’m not beginning to understand the enormous frustration faced by developers each and every day when dealing with this. It’s a little soul-destroying to wait a week and then get a simple rejection without any way to defend yourself.

UPDATE – 13:30 10th Feb 2012

I got some pointers from a tip-top iPhone developer @bendodson, who suggested that even the mere mention of an external site might be grounds for rejection. This does fit the profile. On my login page, I mention the main site in some text. It’s not really a link, but a similar thing, as pointed out to me, happened to Hulu!

http://www.appleinsider.com/articles/11/06/20/hulu_plus_for_ios_complies_with_apples_subscription_rules_removes_web_link.html

This gives me an interesting choice. The ability to specify SMS as a delivery mechanism is only available when you’re have a Pro account. Since I cannot mention that in the app, I can either just turn it on silently or try to use In-App purchases to drive it. Auto-Renewing subscriptions aren’t ideal, but rather that then just drop the app completely.

UPDATE – 17:30 10th Feb 2012

Apple clarified their position. Turns out it was the simple inclusion of a web address on the login page. You simple cannot link or show a link to any external source. That’s fair enough. Here is the offending link..

You can, I’m pretty sure, change an app’s behaviour externally, but you cannot tell the users about it via the app. Seems a little silly, but I reason that a blanket ban is easier to enforce rather than treat each submission on a case by case basis. If it takes them a week to get to my app, imagine how busy they are!

I’ve asked them to clarify whether or not the login mechanism is okay, since it opens Safari to login. That will hopefully be okay.

10 + D20 experience to Mr. @bendodson who called this!