iOS Pain Points – iTunes Connect’s “Sales and Trends”

The ‘Sales and Trends’ section is the worst dashboard/analytics platform I’ve ever seen. It’s combination of uselessness and bugginess is unmatched.

Let’s start off with a look at a few of the issues that I’m sure you’ve all seen before. Eagerly awaiting your sales numbers the morning after your app is released? Too bad.

You would think that Apple would at least do some basic QA to make sure stuff displays properly. But, they apparently don’t.

Grammar? What’s that?

The attention to detail is astounding.

But enough of the minor annoyances. The real problem with Sales and Trends is the lack of functionality.

When you select something from the dropdown above, you aren’t selecting a “week” or a “day”. You’re selecting the end period for some arbitrary, unknown date range. Why can’t I simply choose a date range to view results for? Why am I limited to viewing the results for the past X days or weeks, starting at day or week Y?

Why can I only view data for the past few weeks? Apple is one of the richest companies in the history of the universe, but they can’t even spend a few fractions of a penny on a few extra bytes of storage for historic data?

Why can’t I filter the results by product?

Why does it always show me ‘Free Apps’ by default, instead of remembering that I was previously on the ‘Paid Apps’ view, and that every single time I log in, the first thing I do is click on ‘Paid Apps’?

Why does Apple’s development ecosystem continue to frustrate and disappoint?

iOS Pain Points – the Xcode 4.3 / iOS 5.1 / Lion versioning debacle

Earlier today I wanted to test out March’s application on my iPod, which I had upgrade to iOS 5.1 a while ago. I was quite surprised to see that I was not able to, because “The version of iOS on my iPod does not match any of the versions of iOS supported for development with this installation of the iOS SDK.”

It turns out that in order to run your apps on an iOS 5.1 device, you need Xcode 4.3. Ok, fair enough; I’ll just go and downlo…. oh, wait. It requires OS X Lion.

Huh?

In order to develop for a minor revision of iOS, I need a minor revision of Xcode, which requires an entirely new operating system?

So, my options are now:

  1. Upgrade to Lion
  2. Downgrade to IOS 5
  3. Hack Xcode 4.3 to run on Snow Leapoard
Since there appears to be no officially supported way of doing #2 or #3, my only choice is to upgrade to Lion.

Thanks, Apple. Nice to see you still have no respect for your developers. At least I’m not the only one who feels this way.

iOS Pain Points: Xcode debugger failures

If you’ve ever done much iOS development, you’ve probably experienced the fun of Xcode debugger failures. One of the most popular ones is a hang at ‘Attaching to (name of your app)’, which seems to mysteriously appear once in a while. The StackOverflow post for it lists dozens of possible solutions, some or all of which may accomplish absolutely nothing. In my most recent case, none of the fixes mentioned solved the problem. I eventually rolled back my changes (thanks to ‘git reset –hard HEAD’), and things started to work again.

The sad part? My changes consisted entirely of adding icons to the project and setting up the Icons plist. I’m not sure what bizzaro world Xcode lives in where adding icons to a project is enough to completely and utterly destroy the debugger, but somehow that was apparently the case.

As if that wasn’t enough, I ran into another issue shortly thereafter. This time it was the ever-popular ‘Couldn’t register (name of your app) with the bootstrap server’. Fortunately, StackOverflow came to the rescue once again, and I was back in business after a reboot.

It’s really quite depressing that Visual Studio 6 – which is almost 15 years old at this point – offered a better overall debugging experience than even the newest version of Xcode.

iOS Pain Points: Autocomplete in Xcode is a usability disaster

Xcode, like many IDEs, gets autocomplete wrong. Compared to Visual Studio 2010, for example, autocomplete in Xcode is a frustrating experience. Here are some of the ways it is inadequate:

  • It commits the cardinal sin of autocompletion by requiring that you press enter or tab to accept an autocompletion. It should accept the current selection with any key press that makes contextual sense – such as ], ;, =, or (, instead of only accepting the current selection when you press enter or tab.

This is a pretty subtle point, but it makes a world of difference in terms of usability. Here’s an example. Suppose you want to type

self.foo = bar;

In Xcode, i have to do the following:

s[enter].f[enter][space]=[space]b[enter];

for a total of 11 keypresses.
To get the same thing in VS 2010, using C#, you have to type the following

t.f=b;

.. for a total of 6 keypresses – almost half as many as the Xcode version. And it even automatically inserts spaces around the = sign.

  • As previously discussed, it does a horrible job of offering context-sensitive help when for constants or enums, populating the list with everything in the current scope, regardless of how irrelevant it is or how many compile errors using it would cause.
  • It does not display the autocomplete list automatically when you press period. Or, for that matter, when sending a message with [foo . You have to either start typing (which isn’t very useful if you don’t know what you are looking for), or press Esc (which is a pain).
  • When you use autocomplete to insert a function call such as CGRectMake(,,,), Xcode inserts the last ), but there seems to be no way to have it automatically insert the ; or move the cursor outside of the ). This means that you have to take your hands off the keyboard and use the arrow keys to manually move the cursor over just so you can type a stupid semicolon.
  • Pressing PageUp or PageDown doesn’t scroll the autocomplete list, it hides the autocomplete list and scrolls the file you are editing.

It’s death by 1000 paper cuts, and it makes iOS development far more painful than it needs to be.

Anybody have any autocomplete frustrations that I missed?

iOS Pain Points: Renaming folders in Xcode

Xcode, in all its mind-bogglingly incomprehensible wisdom, makes the simple act of renaming a folder a chore. If you’ve ever used any IDE ever released on any other platform in the history of computing, you would think it would be as simple as right-clicking (er, command-clicking) on the folder and selecting ‘Rename’. Sadly, no. There’s no rename option. But wait – there’s a ‘Group Name’ option in the File Inspector. Just change that and… nope. That just changes the name as it appears in Xcode, not the name of the actual folder on disk. What you actually appear to have to do is rename the folder in Finder, then click on the little folder icon in the File Inspector and point the group to the new folder.

Oh, and don’t even think about renaming your project. That would just be stupid.

iOS Pain Points: $99 per year developer program

In order to distribute your work on the app store, or test your work on your device, you need to sign up for the iOS developer program at a cost of $99 per year.

What purpose does this fee serve, aside from turning away potential developers?

It’s certainly not making Apple rich. According to Apple, there are over 500,000 apps on the app store. If we make the tenuous assumption that there’s a 1 to 1 ratio of apps to app developers, we can guess that there are around 500,000 registered iOS developers, who altogether make Apple a tidy sum of $49.5 million dollars per year. Sounds great, right? Well, not when you consider that Apple took in $28 billion in revenue in the last quarter alone. That 49.5 million dollars in annual developer program fees is approximately 0.017 % of Apple’s quarterly revenue. Less than a drop in the bucket.

No, the real reason, as I see it, is to intentionally raise the bar to attract only the developers who are serious about the platform. Were there no annual fee, the app store would likely be (even more) deluged with lower quality apps, and the approvals team would be even more swamped than they already are. This is certainly a valid point, but it hurts small developers, as even the simplest apps now have to sell approximately 142 copies per year just to cover the developer program fees (and that’s not even considering the other fees associated with iOS development). As a newcomer to iOS development, this is a somewhat scary number.

Since the motivation for the annual fee is quality, not direct financial gain, I have an idea to ease this pain: refund some or all of the fee for each app that is successfully submitted to the App store. By doing this, Apple would still create its desired barrier to entry, but it would be less of a burden on small-time developers. And as the money would not be refunded until an app successfully passed the submission process, developers would have just as much incentive – if not more – to release high-quality apps.

Of course, none of this matters, because Apple would never do such a thing. But I can dream.