There are a number of really good posts floating around (try here, here, here and here for a few — courtesy of either Daring Fireball or MG Siegler) on things people would like to see added to iOS 6 and be announced at Apple’s worldwide developer conference (WWDC). I’d like to focus on an area that has been broken for four years now and could really use an upgrade and some new features, an area that would roundly be applauded by every iOS developer: App Store Tools.
The information and abilities that we get in iTunes are pathetically out-of-date, to say the least. Four areas I’d love to see improved.
In the beginning, Apple gave us four devices (first and second generation iPhone and iPod) and 100 slots for testing purposes. Now if you are supporting iOS 5 and later, there are no less than 8 devices that need to be supported. How about iOS 4.2 and later? That’s 34 devices since you should test iOS 4.2, 4.3, 5.0 and 5.1 on each device. 
Now… start adding in partner companies. We reserved no less than 20 devices for our DEWALT partners, 10 people at 2 devices each. And I had to sprout horns and ward off potential internal reviewers with a trident. I’ve got more of these deals in process and can’t figure out where I am going to come up with test slots.
Just delete a few, you say? Wish I could. Or, rather, wish this would help as the devices only refresh at renewal, which for me is January.
And don’t even start on the arduous process of getting the unique device identifiers (UDID), getting them into iTunes, changing the provisioning file, getting it into XCode (the dev environment), getting it into the app, distributing it and actually getting it correctly installed. It’s a small miracle when it works.
I’d like to see a couple of things happen here. One, I’d like to see a designation in the App Store for beta applications. This means I can post it to the Store through the standard process and have a private link that I can use to distribute the app. The app can only be downloaded by testers who have permission to access the app. This can be managed by using the iTunes email address (or similar identifier) instead of the UDID, allowing us to opt people in through a simple web portal.
Second, the app wouldn’t need to go through review, since access is restricted, making it fast and easy for developers to iterate. In exchange for abolishing the limit on the number of beta users, the app would be time restricted. In 1-3 months it would time out and the app would automatically be removed from iTunes if it isn’t submitted for review within 18 months.
This would streamline the distribution process, get us out of the business of dealing with UDIDs and provisioning files, and make distribution a snap. Apple would get well-tested, higher quality apps in the App Store as well.
What are the odds of this happening? I don’t know about the details but I wouldn’t be surprised to see a change. Just a few months ago Apple started rejecting apps for using the UDID in their code. They don’t want us to have access. But until Apple deals with the provisioning files, they still need to give us access to it. A new process — like the one I described — would do away with that necessity.
I think an honest-to-goodness beta program is a possibility. App Store Analytics, I admit, is a wing and a prayer. Given that, I’m desperate for more information about my apps then what I have now: downloads, purchases, gifts, returns, revenues. Even the basics would tell me a ton of information that would help me figure out how to promote my app. Here is a list of some analytics data I’d love to have:
- How my app was found: iTunes feature, external direct, company page, search, the “bought other products like this one” links
- If search, what term was used
- If feature, from what page
- On which version of the app store: iPad, iPhone, iPod touch, iTunes
- For which device model (i.e., iPad 1, 2 or 3)
- Did the person buy
While I’m not counting on this happening, it would make a huge difference in my ability to understand who is buying, where they are coming from and how I can attract more of them.
If they want to get even fancier, take a look at appFigures and Flurry and bring those features in-house, too.
Promotion codes are an invaluable tool. Many developers use them to give out free copies to prospective customers, others use them for the press. But these codes are a real pain to get out of the system. First, they are buried four levels deep in iTunes Connect in a place I really don’t want to go unless I am making changes to my apps. Second, they come via a downloaded file, which makes accessing them from an iPad or iPhone impossible. Third, they are a pain in the neck for a customer to enter: copy the code, go to the App Store, go to the Featured tab, scroll to the bottom, choose Redeem, paste it into the field, submit. Finally, they expire four weeks after I create them. Use them or lose them!
Let’s make this easy. When I ask for a promo code, give me an iTunes link with a special code embedded that I can copy and send to the customer — if I request 10 codes then show me 10 links — but show them to me in the browser so I can copy them and send them. The link takes the user to the app store, adds it to their account automatically and starts the download. 
Furthermore, we need promo codes for in app purchases. With so many apps going freemium, it is hard to give out free copies of the add-ons. Promo codes that work for in app purchases would make a huge difference, too. Here’s how I’d do it: after clicking the redeem link, download the app if it isn’t already downloaded. Once done it would register the purchase in your account and alert the app that a purchase has been made the same exact way it does today. From there, it is the developer’s responsibility to handle things correctly.
At the time I thought the 100 character keyword limit would be a stopgap solution but here we are three years later and it is still around. Fast forward to earlier this year when Apple bought Chomp, an app discovery web site. Here’s hoping, as my last wish for WWDC, that we get improved search, improved app discovery, and an end to the 100 character keyword limit.
 iPod second, third and fourth generation devices is 3, iPhone 3g, 3gs, 4 and 4s is 7, iPad 1, 2 and 3 is 10. The iPod second generation and iPhone 3g will not support iOS 4.3 and later. So that’s 10 devices for iOS 4.2, 8 for iOS 4.3, 8 for iOS 5.0 and 8 for iOS 5.1, or a total of 34 devices.
 I hate the four weeks restriction but it isn’t a big enough deal to care about so I didn’t address it here.