JohnnyWorks

Programming projects and sample code

Browsing Posts in Distribution

Lacking a better medium to communicate to all my users how difficult Apple is making it to provide them with the level of service I’d want to,  I’ll get my rant out here on my blog where it’s safe.

I had a bugfix version of StickWars ready the same day the buggy version 1.4 was released. That day was May 27th. Is is June 18th and I’m still waiting patiently for Apple take a look at the update. It has been two weeks since I submitted a corrected update, and I haven’t got a lick of feedback back. In the mean time, my app has dropped from #3 to #9, and my users are sitting there wondering what I’m doing when in fact I have two more full-content updates ready for release, completed in the time it took Apple to approve a bugfix release. Keep in mind that my app has been in the top 10 paid apps for months now–this is one of Apple’s moneymaking apps. I would think they would want to work quickly to approve an update which would improve the game experience for hundreds of thousands of players.

Now I am not absolving myself of the responsibility of releasing a version with some problems. The fault for that lies solely on me, and was due to a somewhat chaotic situation as I was moving homes and starting a new full-time job that led to me not having as much time as I expected to test the release. This is no excuse, however, as I should have just rejected the update and resubmitted later after more testing. But the problem was magnified greatly by the simple fact that Apple has no agreement or desire to protect the ability of developers to have control over the applications they are producing. We can’t respond directly to user complaints or support requests posted on the AppStore. Most importantly, our update schedule is 100% subject to the whims and scheduling of Apple, so an update that we kill ourselves to complete on a rapid basis could be live in 3 days, or in 30. And we never know what to expect until after the fact.

Before a couple weeks ago when Apple first started emailing me to let me know that they approved my update, do you know how I would find out my update was live? My as-it-happens google alert would send me an email that a new cracked version of StickWars was available on some blog somewhere. I also rely 100% on third-party tools to tell me how people are responding to my applications. Check out www.appfigures.com to see what I’m talking about–from that site, you can read reviews from all countries. I received a lot of valueable feedback reading through the reviews of other english-speaking nations. Apple provides no way (that I know of) for developers to see the status of their application in the AppStore (if it is featured anywhere, it’s rank in other countries, etc…).

In addition, I’ve only received two of the seven payments for April 2009 that I should have been paid by now. Granted, one of those received was from the US, and therefore was the largest one, but they are sitting there wasting interest on a lot money and I still have not recieved a single response as to why. Three weeks ago I dug through their contact form and sent a polite email asking them why I got the financial report for a few thousands but never received the deposit, but I have yet to receive even as much as an automated reply confirming receipt of my message. I have sent more inquries weekly, and just started sending them to a more broad range of email address, and will update this at some point when I get a response.

Don’t get me wrong, I think Apple has done an amazing job with the AppStore, and building a system like this from scratch is bound to be difficult, with problems like this sprouting up and slowly being fixed month by month. But right now, I seem to find myself trapped at a criticial point, where if another week goes by without Apple looking at my update and StickWars drops off the top 10, and then the many more features and improvements I’ve made in the meantime won’t matter as all the exposure in the AppStore revolves around the top 10 and top 100 lists. I understand that applications have a limited shelf life at the top of the lists, but I didn’t expect mine to be cut short at the end by random and unpredictable update approval practices by the iTunes Store.

I believe that complaining without recommending a course of action to fix the problem is a waste of words, so here are some ideas that I would love to see put into the AppStore.

  • A priority queue for update approval based on popularity. The apps that are getting constant updates pushed out to hundreds of thousands of players should have more personal attention from Apple staffers. On the other hand, it should be balanced so that even an unpopular app which has gone two weeks with an update in the queue is bumped up to the top priority.
  • A developer portal into iTunes Store “Insights” that gives you access to any information related to the status of your applications, including reviews and rankings (in all categories) from all nations, along with any places where the application is featured.
  • More analytic information, so I can see how many users download my Lite version first, and then download the Paid version.
  • Allow developers to post short ‘responses’ to user reviews. This way, when somebody complains “the game was too easy wish i could make it harder!!@#” a developer who cares can go through and add a response such as “just hit the options button and set the difficulty to hard” (real example).

Update: I did eventually get paid by Apple like 1 or 2 months late, and about 2 weeks after I got paid I got responses to my multiple emails (sent over a month before) saying “we show your account as paid in full…”. To be fair to Apple, my banking situation was a little complex and I understand that it takes time to go through all that, but I would have appreciated a brief response (or even an automated confirmation) to my inquiries long before almost 2 months have gone by.

I found this post to be very informative, and possibly helped to prevent my App from being rejected the first round (I had enabled constant vibration while the player was under attack).

I spent more time trying to get Ad Hoc distribution work than any other issue that should have taken 15 minutes. There are a number of things which can go wrong, some of which are ridiculous and Apple will no doubt fix in time, but for now you should know these:

The biggest gotcha: you can not use the “Compress” option in Finder to bundle the Ad Hoc package. It adds files that cause iTunes to freak out. I wrote a quick shell script to bundle everything up and zip it together using the command line zip tool.

mkdir Payload
cp -rp MyApplication.app Payload/
zip -r MyApplication.ipa iTunesArtwork Payload

This way, you can give people the .ipa and .mobileprovision file. Tell them to drag the .mobileprovision into iTunes, and then double click the .ipa. How easy was that?

Another semi-obscure fact: iTunesArtWork is a 512×512 png, named simply ‘iTunesArtwork’ without the extension that needs to be included ONLY with Ad Hoc copies so the icon shows up in the iTunes window. You don’t need to include it, but if you do make sure you only do so when sending out Ad Hoc copies.

One more thing that caught me over and over again: don’t forget to increment the version number in your info.plist file before giving Ad Hoc users a new copy! iTunes is really sneaky about what happens here…in both cases it says the application is already installed, and asks if you want to replace it, but if you try to replace with the same or lower version number, it won’t actually do anything.


If you are getting

Application was not installed on the iPhone because it could not be verified.

then your profile isn’t valid and you should check out this post. This biggest thing to remember is

  1. Delete all the profiles stored in ~/Library/MobileDevice/Provisioning Profile.
  2. Double click your .mobileprovision file and it will get loaded into XCode.
  3. Quit XCode completely. I’m not sure why this is necessary, but often XCode refuses to build unless it starts up with the profile already ready.

Lastly, ensure not only that Entitlements.plist is included in your project (click File, New File, Code Signing, Entitlements), and that get-task-allow is unchecked, but in your “Ad Hoc” build profile (Project, Edit Active Target) expand the list to “All Settings” make sure the “Code Signing Entitlements” field is filled out with your “Entitlements.plist”.

If you are just starting out on iPhone development, or are considering starting but don’t feel like dropping $99 without getting your hands wet first, then you’ll need to jailbreak your device.

For me, this was great at first as it was far easier to set up than XCode provisioning profiles, and it let me see if I was felt confident enough playing around in Objective C to really take the dive and pay for a developer account.

In case you somehow don’t know where to jailbreak, head to Dev-Team Blog and download the appropriate torrent.

A quick note: I own one of the new Aluminum MacBooks and still have not successfully jailbroken my iPhone using it, due to some error/bug/whatever with the USB drivers failing to put the device into DFU mode. Just find a windows computer to use for 15-25 minutes and use QuickPwn on it.

After you jailbroken your device, you still need to do some tricky steps to get your own compiled iPhone app running on your device. You can find a walkthrough of how to do this here.

By far the most helpful single resource I found during the long and difficult course of properly signing my code and getting it running on my iPhone is locaded at 24100.net. And the title of the post is very helpful, because those two errors, 0xE800003A and 0xE8000001, are the curse of provisioning on iPhone development.

To sum up my own experience with XCode signing, I learned a few things which have really improved my development experience.

  • I delete provisioning profiles out of XCode as soon as I’m done with them. I will head to ~/Library/MobileDevice/Provisioning Profiles and delete everything in there, and then close XCode.
  • Drag the one .mobileprovision file you want to work with to your XCode icon in the dock, XCode loads it, renames it and puts it back in the above directory, and then I close XCode again. I know, it seems crazy, but XCode gets confused easily, and I’ve found restarting XCode helps.
  • If I’m building for AppStore or Ad Hoc, I literally just load the one provision, clean the entire build (with both checkboxes checked), build it, and then delete the provision profile out of the XCode directory.
  • I spend most of my time with my single development profile sitting in the directory. Even still, XCode spits errors at me sometimes, and a clean build + XCode restart fixes it. I’ve even had to restart my iPhone once when it was still giving me errors after the above steps.