iPhone devsugar: 9 ways Apple can improve App Store

Apple has been working hard to make the App Store a better experience for both customers and developers. Recently, they introduced in-app purchases, scheduled sale prices for apps, provided review status indicators in iTunes Connect, and introduced other new features. Despite that, they still have a long way to go.

Through talking with developers, I've assembled a list of items that Apple might yet look into and implement. They range from issues arising from iPad development and deployment, to longer-standing items that would benefit the entire store. Here, then, is a list of nine suggestions for improving the App Store experience for iPhone OS developers.

1. Offer In-App Purchase Promo Codes

Although iTunes Connect allows developers to generate promo codes for reviews and other marketing purposes, they have yet to introduce a way to create freebies for in-app purchases. When your application revolves around those purchases, reviewers either have to skip those features during product testing, or pay out of their own pocket.

Since the introduction of in-app purchases, many developers had reverted to gifting iTunes credits to reviewers, and that quickly proved to be a problem. Between taxes and left over money, it's been an accounting nightmare. What's more, revised iTunes terms and conditions make it clear that you cannot gift in-app purchases directly, and you cannot apply iTunes credits to IAP items outside the United States. Introducing promo codes for in-app purchases would help both developers and reviewers to this end.

For that matter, extending regular promo codes outside the United States (not just for IAP) would help developers outside of the United States. At this time, reviewers and testers must create US accounts in order to use promo codes. Think about developers outside the US, who make applications localized to the surrounding language and culture. They cannot offer promo codes to local testers or reviewers unless those people open a second US account with all the associated clerical and legal problems. Extending promo codes to the world (even if to specific stores around the world, as Apple would likely require) would solve that problem.

2. Offer device-specific iPhone archive files (.ipafiles)

You've been there. I've been there. You're at an airport or on the road, trying to download an app, and you get the message about needing a Wi-Fi connection because the app exceeds the 20MB (formerly 10MB) over-the-air download limit. What do you do? I know what I do. I find something else to download.

It's just going to get worse with the iPad. Developers from major game brands have been complaining that building universal resources, that is to say, apps with graphics that are optimized for both smaller and larger iPhone OS devices, might tip them over that 20MB over-the-air limit.

If Apple allowed devs to split up their apps into non-universal builds specifically targeted to install-devices, they could decrease the size of those over-the-air ipas, take up less space on each device, and provide only those resources immediately needed. Also, should Apple allow those separate builds to share a single unique application identifier, it would become easier for each device to maintain just a single slot for each device-specific version of the application. Let iTunes decide which ipa to install on each device. It would make things smaller and simpler.

3. Create application families and introduce "Complete My App"

Many developers are currently struggling with the need to build separate iPhone and iPad applications. Many iPad adaptations include significant changes and development costs that cannot be covered with a single universal application upgrade (let alone the issues about over-the-air media limitations). They're also worried that their new "for iPad" applications will be listed separately in the App Store, and that customers will struggle to find them.

Introducing App Store application "families" would work to solve these concerns. Creating a family of apps (an iPhone version, an iPad version, a universal version, and so on) that shared common application ids and was presented on a unified App Store page would allow developers to meaningfully group new product entries along side of existing applications. Instead of writing separate marketing text, shooting separate screen shots, gathering separate reviews, and otherwise dealing with divided resources, a single application family page could bring all of those materials together into one place. Apps in the same family could share the same branding and the same SKU.

Application families would also allow developers to price their device-specific products separately, and open the door to a "Complete My App" purchase. Although most iPhone app purchases will run on the iPad using pixel doubling, using "Complete My App" would allow developers to sell iPhone-only versions at a lower cost, and also allow those users to upgrade for a lesser cost when they finally do buy an iPad. Think of it as a "preowned discount" for loyal users.

Even with separate entries in an application family, developers may still want to update each member of that family to provide for in-app cross promotion in order to better unite those products. At the same time, building those applications into a family structure will make that task easier (and more user friendly!), especially if StoreKit calls could report back as to what items each user has already purchased, and which items remain outstanding.

4. Offer Paid Upgrades

The "buy once, own forever" App Store model is not sustainable. At some point, developers need to recoup costs for continued development and improvement. It's clear that Apple is exploring the paid upgrade arena (as previous leaks have shown), but developers have yet to see that upgrade path become real.

In that scenario, users will be given the choice of paying a nominal fee to upgrade from an existing purchase, or to buy into the upgraded product at full price. Paid upgrades fit with the application family scenario as well, where over time, users can opt in for device and feature upgrades from the same App Store page.

A paid upgrade path isn't limited to feature enhancements though. Another App Store feature that would be welcomed by many developers is "TryWare", full featured software that times out after a certain amount of time. Once the application times out, a paid upgrade/in-app purchase path would restore full functionality to that application. As one developer imagined it, "Apps would grey out in Springboard. When users try to open them, a dialog would explain the timed-out state, giving them the option to unlock the app by buying it now."

This approach would offer an alternative to the "lite" feature-limited application. Users would get to experience the full application feature set before deciding whether to make their purchase. Developers could opt to distribute their software using this model or continue with the existing alternatives. Until Apple green lights this idea, though, it's a no go. Under current App Store submission criteria, a timed-out application, whose functionality stops after a given date, is unacceptable.

5. Introduce an unreviewed beta program

Developers would certainly benefit from a way to send their applications into the wild without having to resort to the headaches and heartaches of Ad Hoc beta testing. Ad Hoc testing is labor intensive and you're limited to an audience of, at best, 100 devices. Too often, getting folks to properly install the special provisioning proves to be a recurring fail point.

Imagine, if you will, a way to produce beta builds of your applications and offer those to the entire App Store audience -- albeit with the knowledge that these are unapproved builds and that users need to use those builds at their own risk. Apple could even make this an opt-in program, strictly for people who consider themselves "power users". A public beta brings a lot to the table in terms of a wide audience with diverse equipment and firmware.

Even if Apple insisted on some kind of automated review process (I don't imagine Apple would ever allow the kinds of apps that you regularly see on Cydia or the Rock Store into their beta program), open betas would offer developers a better opportunity to produce superior debugged products than the system that is currently in-place.

6. Provide a public list of known rules and common-sense rejects

At this time, developers are scratching their heads about whether they can build applications called "XXX for iPad," or whether the use of iPad in the name will violate Apple branding issues. It would really help if Apple posted lists of noncontroversial, easy-to-follow rules (basically a technical requirements checklist) that would save developers time, and prevent them from wondering whether an app was taking a long time to come through the review process due to some issue with the marketing text or the name.The more rules published the better -- it's easier to comply with said rules when you know what rule book the other team is playing from.

I am now adding the following text to my iTunes Connect submissions: "If you think there may be any approval issues due to naming or any marketing materials, please let me know asap and I'll adjust accordingly. I'd rather change any doubtful items immediately than wait for higher-level review. Thank you in advance." To date, it hasn't done anything one way or another, but the sentiment it expresses reveals a deeper need.

It would be great if Apple could introduce "common sense" rejects, allowing reviewers discretion to say: "Would you like me to reject your application because if you change your name from "XYZ", I won't have to pass this up the chain of authority?" Just introducing that level of common sense would really help to avoid high level reviews for matters that many developers don't really care about.

I remember that my Voice Notes application, submitted the first day that the App Store accepted submissions, was caught in review for about four months because there was something that concerned Apple in the marketing text. (I had mentioned that you could use the application on the iPod touch using a third party microphone like the XtremeMac MicroMemo. This was an unauthorized device usage.)

Developers don't care about that; they care about time. Go ahead and reject the app -- we're happy to fix the stuff that doesn't matter. Common sense rejects allow both Apple and developers to work around the tricky issues by bypassing them at the start, not the end, of the review process.

For that matter, if a submission does raise a flag, a more transparent ticketing system (even more transparent than the status items recently introduced in iTunes Connect) would allow developers to know which hill their app is dying on. Most developers might simply decide to find a different hill instead of allowing the battle to be fought on the one that Apple seems to care about.

7. Offer Project Managers for the "Unannointed"

When your company has a strong working relationship with Apple, you are assigned an internal manager who acts as your personal point of contact for review issues. Apple should consider offering a paid program for small companies who have yet to achieve those exalted connections. Serious developers should be able to pay a serious fee, and in return, receive the kind of professional attention that is on par with the service offered to Apple's hand-picked partners.

Waiting to see if Apple comes knocking simply isn't a choice for many new start-ups. Introducing a paid program for higher level technical and marketing support, beyond the two code-level incidents wrapped into the basic $99 program, would alleviate a lot of developer griping about program transparency.

It would also really help if Apple's developer forums encouraged Apple's marketing and review folks, as well as their technical staff, to participate for the sake of smaller developers who would not opt in to such a paid program.

8. Add video previews as well as screen shots

Video previews play such a powerful role in explaining what an app does and how it works -- and there's no way yet to integrate them into the App Store browsing experience. So here's a last suggestion for Apple: please consider adding developer-produced, iTunes-compatible, m4v videos to an application's App Store marketing materials. They augment the buying experience and ensure that each customer better knows what he or she is buying.

Admittedly, Apple would have to safeguard copyright for video. There's a tendency for people to create videos using material they don't own, typically music. Admittedly, even adding a "no music" (or at least a "no music you don't own") rule and legal sign-off would be a hassle. At the same time, video previews could really help sell and explain applications in a way that static images cannot.

9. Allow developers to sell their applications -- to other developers

Imagine this scenario: You're a small, independent developer and you build an application that sells like wildfire. I'm thinking of Graveck's Skeeball application, was originally called 10 Balls 7 Cups. It was a fantastic application. So fantastic, that is, that it was bought out by Freeverse.

At this time, there is no way to transfer an application from one developer account to another. Applications cannot retain their original name, user base, SKUs or application identifiers. When an application changes hand, there's no process in place in App Store to facilitate that transfer. The application must be completely withdrawn and re-issued by the new owner.

For anyone who dreams big and has created something special, this missing link in App Store can prove to be a problem. And this situation arises more often than you might imagine. Apple could better facilitate these transfers so that customers do not have to buy identical or slightly upgraded applications a second time and so both the original and acquiring developers can create continuity between the original product and the new one.

Thanks, Bartosz, Joachim Bean, David Morris, Adam Martin, Matt Covery, Mare "Borked", and everyone else who offered feedback