Peopler now approved!

After more than one rejection by Apple, Peopler has now been approved for sale. If you want to check people’s calendars in MS Exchange without needing Outlook or messing with Shared Calendars, Peopler might be what you’re looking for! It’s free to download and can be upgraded using an In-App Purchase if you like it.

Please send me any feedback you have and share it around if you do like it!

Another week, another rejection from Apple

Not a week goes by where I don’t get get a rejection from Apple Winking smile

To give you some background, I first submitted my I May Be Late app for review back in January. The 26th of January 2012 to be precise. Apple initially rejected my app for reasons I didn’t quite fully understand and I just resubmitted it, thinking it was a problem with my server side code that caused rejection. A full week later and my app was rejected again. I reached out into the developer community for advice and found the reason for the rejection. It was related to in-app purchases and external payment mechanisms.

I fixed everything, removing the offending links and submitted the app again. You can read the full story of this in this blog post.

Yesterday evening, Apple again rejected my app, citing the same reason, but this time indicating that my metadata was at fault!

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 metadata is where you provide a description of your app, including links to help, marketing and privacy pages. I immediately assumed it was because I mentioned the Pro account in this description, but I do mention the Pro account in the app too.

I quickly adjusted the metadata anyway, removing the mention of the Pro account and submitted the updated version. Thankfully this didn’t require the submission of a new binary. I’m also assuming that because of this, the binary itself is okay!

At 1.37 AM this morning, my app was again rejected for the same reason as before. This time they included a snippet of the metadata and it showed the actual web addresses that I gave. As with the app, it’s not possible to show any links to the site at all, since the site offers a PayPal payment mechanism.

With a huff and a hiss, I removed all  links to and all all email address from the description body. I then went as far as changing the links to the support, marketing and privacy pages to point to It’s worth pointing out that the links to support and privacy pages are mandatory within the metadata, so URLs must be entered. However, these links would bring you to a site that offers external payments, so rather than risk rejection again, I just changed them.

As of 8.27AM the app is again in review.

I can fully understand Apple’s stance on this matter. They make tonnes of money from content channels, pure and simple. They protect the revenue from these channels with all their might. I do, however, object to their position on external payment mechanisms, especially since they don’t provide an alternative. Sure, they have in-app purchase, but it doesn’t offer monthly payments or subscription based payments for anything except newspapers and magazines. What they are saying amounts to “we don’t offer a monthly subscription service so you can’t use anyone else’s”.

That sounds a lot like monopolistic anti-competitive behaviour to me…

Dealing with rejection. Apple, OpenID and my app!

I May Be Late_114So, 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!

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..Issue

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!