Aug 18

We need to submit our app to the store before it closes for the weekend—what time does the app store close on Friday nights?

I found that quote on the very funny site ClientsFromHell.net. Reportedly it’s an actual quote from a real client.

Of course the App Store is not shut down for customers during weekends. But we have recently found out that the app review team no longer works on weekends. Back in the days when it seemed like the app reviewers were constantly having trouble keeping up with the ever increasing flood of app submissions, you would see apps get approved at all hours of the day and on weekends. No longer.

In a previous life when I was building large scale web sites and server systems we learned to never deploy new code on a Friday, unless you wanted to work on weekends to fix bugs or deal with launch jitters.

The same thing applies to iOS apps now. Don’t set the release date of an app to fall on a Friday. Should there be a problem with the new version of the app and you want to push through an emergency update, then nobody will act on your request until the following Monday.

But, you don’t have control over when an app will be approved, you say. That is true, but you can set the date when the app will be released. And you should always, always use this feature.

Look at the current App Store Review Status and add some margin to allow for delays. For example, today the status says that 99% of all new app submissions and 99% of all app updates are reviewed within 7 days. I would set the release date to around 2 weeks for an app update. Make sure that the date is not a Friday, and that it’s a day when you’re available and ready to handle new customer support issues.

For a new app submission I would set the release date even further into the future to allow your marketing campaign to ramp up and steam forward towards a known date. But that’s a different topic.

written by Nick \\ tags: ,

Feb 15

This post is a follow-up to my prior post about selling content on the App Store with new information from today’s press release from Apple and the updated App Store Review Guidelines.

First of all, kudos to Apple for updating the guidelines. The paragraphs you should look at for this discussion are 11.12 – 11.14. Based on my reading (and keep in mind that I’m an iOS developer, not a lawyer) these are your options:

1. Use IAP only for selling content

This is the most straightforward approach for most smaller developers. Just let Apple handle all the headaches of credit cards, payments, recurring billing, etc. For this convenience you pay 30% to Apple.

2. Use a combination of IAP and your own ecommerce

Most existing publishers who also want to sell content on iOS devices fall into this category. If you want to make content available on the iOS device that a customer has purchased on your ecommerce website, then you have some serious integration work to do, but that’s nothing new.

What’s new is that now you also have to offer the option of purchasing the same content using IAP. And the big, but not surprising, stipulation is that there has to be price parity between the two options. Your customer will pay the same amount in both cases, but you will have to pay 30% to Apple if the customer elects to purchase via IAP, compared to the 5-10% you typically pay to your ecommerce or credit card merchant. (11.13)

Furthermore, you cannot have a “buy” button in your app to direct a customer to your website. In order to purchase from your ecommerce website your customer will have to manually launch Safari, and type in the URL of your website, and complete the purchase there, before returning back to your app. Inconvenient, yes. But still a viable scenario for people who prefer to purchase things online from their desktop. (11.14)

3. Only rely on your ecommerce website

If you have a really well-known brand (Amazon comes to mind) you could remove all buy buttons, website links and purchase capabilities from your app. To buy content, your customers will have to know that they need to go to your website.

The advantage is that you don’t have to fork over 30% to Apple. The disadvantage is that you don’t get the convenience of IAP and you don’t get to ride on the coattails of Apple’s mighty iTunes machine.

Subscriptions

Subscriptions have their own paragraph (11.12) in the guidelines, which basically says: “Apps offering subscriptions must do so using IAP”. That clearly eliminates option 3 above. But is option 2 allowed? Steve Jobs quote in the press release seems to indicate that this option will be allowed: “Our philosophy is simple—when Apple brings a new subscriber to the app, Apple earns a 30 percent share; when the publisher brings an existing or new subscriber to the app, the publisher keeps 100 percent and Apple earns nothing.” A big-name example that seems like a good test case is The Economist which provides print subscribers free access to all content in their iPad app.

If this is not complicated enough yet, what about publishers who sell both subscriptions and single issues? And combinations of print and electronic subscriptions?

What will publishers do?

I believe that most companies will complain and grumble about this for a while. But in the end they will come to the conclusion that 150 million iOS customers is just too big of a market to walk away from.

Some companies do not have the margins to pay Apple 30% for the content they sell. Just like some companies don’t have the margins for sales reps or TV advertising. They will have to look to other channels for selling their content.

What will consumers do?

First of all, Apple will continue to allow you access to content you have purchased elsewhere. So your Kindle books are safe.

People’s habits are difficult to change, and I don’t think these new rules will have a significant impact on how consumers will purchase their content. If you’re used to buying ebooks on Amazon, then you will probably continue to do so (even with a few extra clicks). If pushing the IAP button in apps is second nature to you, then that’s probably not going to change either.

written by Nick \\ tags:

Sep 09

One of the most popular pages on this blog is App Store Rejection Reasons. Since Apple refused to tell us what the “real” rules for the App Store approval process were, I shared my experiences in the hope that other developers could avoid making the same mistakes. The page ends with call to Apple to release all the hidden rules. Today Apple finally listened. :-)

Here are finally the App Store Review Guidelines. The language of the guidelines is surprisingly informal; definitely not a product of Apple’s legal department. This makes it all the more believable that this is the actual internal checklist that reviewers use.

Daring Fireball has a nice collection of extracts from the guidelines that are funny, frank or puzzling.

I hope that Apple will start referring to these guidelines in their rejection emails, instead of the more diffuse paragraphs of the Developer Program License Agreement. This would also force them to add to the list as soon as apps are rejected and there’s no matching guideline to point to.

Apple also instituted an App Review Board where you appeal any app rejections. Obviously this is not an independent third party board, so don’t set your hopes too high. But instituting a formal review board is a great move by Apple. Hopefully the result will be less randomness in the approvals and rejections.

In another good move today, Apple also updated the iOS Developer Program License Agreement. Many of the egregious paragraphs that were added this spring with the apparent intent to stifle competition, have been removed. Bravo!

Now let’s hope that the HIG rules will still keep most of the bad Flash apps at bay…

written by Nick \\ tags:

Dec 04

In a previous post I outlined some of the difficult choices developers face in deciding to embrace In App Purchase in free apps to allow users to upgrade to a full version.

The issues include:

  • No upgrade path provided by Apple for current owners of a paid version.
  • Difficulty in breaking into the free top lists on the App Store.
  • In App Purchase requires OS 3.x and wireless access to the App Store.

Some of my clients have solved these issues by offering two versions of their apps on the App Store:

  1. A free app with In App Purchase to upgrade to the full set of features.
  2. A paid app with all content or functions already enabled.

If you have already been offering your app as a paid version and a free lite version, the only difference with this approach is the addition of In App Purchase to the lite version.

While this resolves most of the developers’ issues, it doesn’t help reduce the clutter on the App Store.

Update: I just noticed that Riptide Games have come to a similar conclusion after their experiments with In App Purchase. They also detail some of their statistics on sales and conversions. Recommended reading.

written by Nick \\ tags:

Nov 19

I just noticed something in iTunes 9 which I’m sure has been there in previous versions. But since it was new to me, it might be new to a few of you as well.

At the bottom of the top-level pages in the iTunes Store there is a collection of text links. The last link in the last column is called Change Country. When you click on that link you get to select a country from a large list. After you click on a country you will now be viewing the iTunes Store for that country.

Why is this useful for iPhone developers?

  • You can see the ranking of your apps in other countries.
  • You can see which apps are most popular in other countries.
  • You can read reviews of your apps from other countries.
  • You can see which apps have localized app descriptions.

At the bottom right corner of the top-level iTunes Store pages there is a round flag icon that indicates which country store you are currently in. Clicking on this icon has the same function as clicking on the Change Country link. This can be useful to know since the Change Country link is often localized to the language of country you’re viewing. So it’s not always easy to know which text link to click to get back to a language you can read…

Some interesting observations:

  • The iTunes Store is available in 76 countries. The iPhone is available in 86 countries. Does that mean people in 10 countries do not have access to the App Store? I’m guessing that countries like French West Indies, Reunion Island and U.S. Virgin Islands where the iPhone is available, use their “parent” country’s iTunes Store. Can any of my international readers confirm this?
  • The App Store top lists, New & Noteworthy, What’s Hot and Staff Favorites are all unique to each country store.
  • The top lists in music are much more homogeneous than the App Store lists. I guess the music labels still have some global marketing clout. Who is going to take on this role for apps?
  • The iTunes Store only has 7 official languages: Dutch, English, French, German, Italian, Japanese, Spanish. So you will only see app descriptions in these languages. (The iTunes UI is localized to many more languages than these.)
  • There is an exception to the rule of app descriptions in only 7 languages. If you have an app that is only available in your own language (not English) you can write the app description in that language in the place of English in iTunes Connect, and then only make the app available in your country’s App Store.
  • You cannot login to a foreign iTunes Store with your existing iTunes account. Therefore you cannot purchase apps or write reviews. (It is possible to create an iTunes account without a credit card. This also works after you select a foreign country. But in order to purchase anything you need to have a valid billing address in that country. So the utility of this technique is limited.)

Did you know about this iTunes feature already? What have you used it for?

written by Nick \\ tags: ,

Nov 13

This week has seen the departure of two high profile iPhone developers: Joe Hewitt and Rouge Amoeba. This is a big loss to the iPhone development community.

Rouge Amoeba details the story of the rejection of their Airfoil Speakers Touch app and presumably that was the straw that broke the camels back. I think this case has some interesting aspects that are worth discussing. I will not take sides, since I don’t know all the details of what has transpired between Apple and Rouge Amoeba.

There has been an interesting exchange between Jeff LaMarche and John Gruber about this case, which to me highlights the difficult position that Apple’s App Store reviewers are in. The iPhone is a computer that is constantly connected to a network, but it happens to be disguised as a phone. The complexity of the applications that you can write for the iPhone is astounding. The Airfoil Speakers Touch app is a great example of a complex application that involves streaming audio over a network from another computer. When a very experienced iPhone developer like Jeff LaMarche is not clear on the details of where images that show up in the UI are coming from, how is an App Store reviewer (presumably without a developer background) supposed to understand how an application like this is architected?

Since Apple is unlikely to completely do away with the App Store review process, what can be done to make it better?

In Rouge Amoeba’s case maybe getting an engineer at Apple involved earlier could quickly have resolved any technical questions Apple might have, and then they can make an informed decision on merits instead of possible misunderstandings. To not overburden an already bogged down process, there should be a limit to how often you can call in engineers to review your case. Maybe you have to use one of your golden support tickets. (And they could borrow the process from American football where a team who challenges the ruling on the field does not get charged a timeout if the ruling is overturned.)

I think the bigger issue is transparency. (Regular readers know that I’ve been on this soap box several times in the past.) In the beginning Apple could be excused from being overwhelmed and making up rules as they go. But now, 15+ months later, it’s time to publish the rules. All the rules.

It’s the uncertainty and apparent randomness that is making life hazardous for iPhone developers and companies who depend on the App Store for a living.

Maybe Apple still doesn’t know all the rules and all the details. That’s ok. The American legal system works in a similar way with case law. There is a limited number of laws that have been legislated and then courts interpret those laws and apply them to real-world cases. The key here is that courts’ decisions are published for all to see and learn from. I know this is a gross simplification and a system that is not without controversy, and bad decisions. But I think there’s enough similarity for Apple to adopt a similar system.

If every App Store rejection was published by Apple, including a detailed explanation of the reasons, all developers could learn and avoid mistakes made by others. Developers would win in such a system. I think Apple would win even more with a less clogged review system and much happier developers.

written by Nick \\ tags:

Oct 23

In the last week a lot has been written about Apple’s change to allow In App Purchase in free apps. Here are some of the more informative articles I’ve found:

Thoughts on In-App-Purchasing For Free Apps
A thorough post by Jeff Scott at 148Apps describing the good news and the bad news for both developers and consumers.

In-App purchases could fundamentally change Apple’s App Store
Seth Weintraub at ComputerWorld postulates that everything will change. The (unanswered) question is how?

In-App Purchase now available for free apps
Marco Arment was one of the first iPhone developers to comment on the change.

Apple relents: in-app purchase for free apps allows demo-to-paid
Another good developer summary by Erica Sadun at TUAW.

Free In-App Purchases Will Change…. Little?
A somewhat pessimistic look at In App Purchase by Arnold Kim.

In App Purchase and the state of iPhone piracy
Much has been written about Apple’s statement that “Using In App Purchase in your app can also help combat some of the problems of software piracy by allowing you to verify In App Purchases”. Most of it has been ill-informed speculations by non-developers. In this post Dominique Bongard goes into great depth about the challenges of using In App Purchase to combat piracy. It’s not from a developers perspective, but from someone who has been involved in anti-piracy monitoring.

Do In App Purchases count towards the Top Grossing list?
This is one of the questions I asked in my original article. The answer seems to be yes. Freeverse analyzed the rankings of three of their games on the Top Paid list vs. the Top Grossing list. And Distmo discovered that several free apps have made it onto the Top Grossing list.

iTunes Connect Updated
On October 22 Apple made an update to iTunes Connect. After this update I was finally able to add In App Purchase to free apps, and it was also possible to change the price of an existing app with In App Purchase to free.

iPhone Developer Program License Agreement Updated
When you login to iPhone Dev Center you will be prompted to accept a new iPhone Developer Program License Agreement. I have not compared the entire document against the previous version, but one thing that I noticed had changed was specifically to allow for In App Purchase in free apps.

written by Nick \\ tags:

Oct 15

I just wrote a blog post on our corporate blog about Apple’s announcement that In App Purchase is now allowed for free apps. This is a huge change and you should know how it impacts you as a developer.

written by Nick \\ tags:

Sep 18

Today Apple launched the new App Store Resource Center. Calling it “new” is actually a bit of a stretch, since it seems to be mostly a collection of information that was previously scattered in several places. But we should still give Apple credit for the effort. The are moving in the right direction.

I still think my own App Store Rejection Reasons page is a good complement to Apple’s official documents. And I just updated the page with a few new items that I painfully encountered.

written by Nick \\ tags:

Aug 21

Apple posts their answers to the FCC’s questions.

One of the more interesting items posted was the statistic that “more than 40 full-time trained reviewers” review 8,500 new applications and updates per week, and at least two reviewers study each application. Some quick math reveals that each reviewer spends on average 5 minutes testing an application. That explains a lot.

People are questioning if the 40 full-time reviewers is the entire review staff, or if there is an additional group of front-line reviewers. (Would these people be part-time and/or untrained?) Also, how can 40 reviewers (or really 40 / 2) handle all the languages stemming from 77 country specific App Stores?

Now that I got my frustrations with the App Store out of my system, I promise that this will be the last post on this subject for a while. Now back to the regularly scheduled programming.

written by Nick \\ tags: