• Developers
• Users

Ok, not all of them, some of you are quite lovely. But I’ve been noticing a couple of trends of late that I think deserve comment, and a couple of people today really pushed me to the point of anger. If I blame everybody equally, it cancels out, right?

Firstly, universal iPhone / iPad apps, or the lack of same – particularly in the field of games.

When the iPad came out, there was a slew of seperate HD versions of apps with appropriately HD pricing. “No”, said the developers, “we’re not just price gouging because there is a shiny new device out there which we think we can make a vast profit from. Look, we need to create these lovely high resolution assets. That costs real money!”.

And that was, on the whole, entirely true.

Then the iPhone 4 came out, and a lot of iPhone games have been updated recently for free with Retina display support with lovely high resolution assets. Some strangely familiar high resolution assets in some cases.

So, you might now be paying twice for exactly the same game, with exactly the same assets. These games are crying out to be universal apps. By all means charge more money for a universal app, that’s not the problem – I like paying money for good software – but don’t charge me a second time for the same thing.

Now this doesn’t apply to all games, and certainly doesn’t apply to all apps. A complex, well thought out UI on the iPhone doesn’t always scale to the iPad, and vice versa, even if they now have a similar number of pixels. But some games are pretty much identical on both. And those, my friend, should be universal apps.

I think what bothers me most is games that start out on the iPad, and then migrate to the iPhone. They’ve already done the hard work making it look amazing on the iPad, and I gladly paid the HD price for it. But now there’s an iPhone 4 optimised version coming and you want me to pay a second time? That makes me unhappy.

A recent example that did this right was Geometry Wars – they started out as an iPad app and added a universal app in a recent update. This made me feel even happier about my original iPad purchase. Pleased to the point that I’m telling you about the game now. Go buy it, it’s great fun.

Osmos is another really great game I bought for my iPad, and it sounds as if they are about to bring out a separate iPhone version, rather than a universal one. That makes me feel worse about my original purchase. They are both great games from great developers, but making your customers feel happy is an important thing.

Angry Birds is a more complex example – they’ve been great at doing lots of free updates to their iPhone version, and have earned a hell of a lot of customer loyalty from it (and a shedload of money as a result). But they also have a separate “pay again” HD iPad version, which I’m told frequently lags in updates behind the iPhone one. Boo, and boo.

Every time I buy a new game on the app store that isn’t universal, I sigh a little bit more, knowing it’s constrained to one device for reasons which are not always purely technical. I’m informed by the always wise Neil Inglis that universal apps bought in iTunes only count in the iPhone sales charts, and that could account for one reason why developers like having two separate apps. But that seems like it could be easily fixed by Apple. But then, Apple gets 30% of all the extra sales of the other versions… CUE CONSPIRACY THEORY!

Anyway, yes, developers are just after your money. But you know who else is cheap? Users.

This week, I saw a comment about my PCalc which basically said “How come the Mac version is twice the price of the iPhone version? I think all Mac software is overpriced.”

No, no, NO.

PCalc is $19 on the Mac, $9.99 on iOS. Leaving aside the fact that buying the iOS version of PCalc gets you a code which gives you a generous $9 discount on the Mac one, a more correct conclusion that they could have come to is “Perhaps all iPhone software is underpriced, and it might not be a sustainable market in the long term”. Or perhaps “I wonder why people will pay more for something, the bigger a screen it comes on?”.

I expect Apple will bring out an App Store for Mac OS sooner rather than later. I wonder what will happen to pricing then, if it will stay the same, or be more in line with the iOS apps. And I also wonder whether Apple will be able to ask for 30% of all sales. It would be a major shake up for the Mac software market, and I’m willing to bet 59p that it will happen.

Finally, I got an email today from somebody who had been running the Mac version of PCalc for many years, and had been faithfully clicking the “Not Yet” button every time he launched it. He decided he wanted to pay up, but when he finally saw the price, he decided against it, because he only ever really used the widget. For all of the many years he had been running the software without paying for it.

Oh, and the best bit? He was an indie developer as well…

I think I might be too generous with the trial periods in DragThing and PCalc. When the two week trial is over, they both keep working on the whole, requesting politely that you pay, but not being too obnoxious about it. They were both created in a different age, where that approach was normal and expected. Should I change them to stop working completely as soon as the trial period expires? The user in me says no, the developer says yes.

What do you think?

Yes.

Ok, let me qualify that slightly.

Way back in June, we took part in the inaugural TheMacBundles.com bundle. The idea was a great one – this was a bundle by developers, for developers, with an equal split of the profits for all who took part. In practice however, it was something of a disappointment. Sales of the bundle were small, not down to the quality of the applications or people involved, but partially because it was going up against the much stronger MacUpdate bundle at the time, and partially because – in my opinion – it didn’t compare particularly favourably to the slick marketing efforts of MacHeist and MacUpdate.

It was mocked at the time by the ever-tactful John Casasanta of MacHeist, who basically said that without a substantial marketing budget, it was doomed. Annoyingly, he was actually right.

A couple of months ago, the MacUpdate people contacted me and asked if I wanted to be part of their winter bundle. What they offered per-bundle-sold wasn’t completely terrible – I’ve been offered a lot worse. Sales of DragThing have slowed a little bit of late since I’ve only done fairly minor updates recently, and I figured it couldn’t hurt to get it back into the public eye. And likewise, PCalc on the Mac has always been a good promotional tool for selling copies of PCalc on the iPhone.

So, fine, let’s give it a try. It’s a good bundle of apps – I fancy getting a few of them myself. I’ve been looking forward to the point-and-click adventure game Machinarium for ages, and I didn’t realise it was already out. Plus I’ve heard good things about Socialite and GarageSale, and many of the others. Path Finder is another veteran app in the bundle, and I know lots of people use that in combination with DragThing.

Will we make more money over the next two weeks than we would have otherwise? Am I damaging future sales of our apps? That remains to be seen. You can see the total number of sales of the bundle on the MUPromo page. I’m legally not allowed to tell you exactly how much of the $49.99 we’re getting, but think of a very small number. Now half it. You’re pretty much there. Feel free to multiply that by the current sales figure.

The bottom line is that our decades-old kitchen is due to be replaced in January, and it would be nice if this deal helped pay for it… Does that make me a capitalist?

Or a culinarist?

Given our recent controversial moves regarding calculator word censorship, the more conspiratorially-minded amongst you might think we are using these updates as a mere smokescreen to slip in even more draconian measures. And on the face of it you would be right – PCalc now filters over three times as much profane content as before, with significantly increased detection algorithms. Don’t think you can just throw in a decimal point in the middle of a word now, we’re wise to such tricks. We’ve even added multiple-language support.

But, before you condemn me, I need to get something off my chest.

Personally, I don’t like adding these features any more than you like having your calculating freedoms curtailed, so I’ve decided to take a stand against this censorship and my cruel paymasters at TLA Systems.

In the latest version 1.8.1 for the iPhone and iPod touch, I’ve hidden a secret easter egg that lets you disable this disgraceful “feature” once and for all.

1. Go into the “Advanced” section of the settings (or just the normal settings section in the Lite version).
2. Scroll all the way down to the bottom of the page.
3. Turn your phone upside-down.
4. Still keeping it upside-down, you’ll now be able to scroll slightly further to reveal a brand new option.
5. Switch censorship to “Off”.

I’ve also managed to sabotage the censorship completely in version 3.5.1 for Mac OS X – even if you turn your laptop or display completely upside down, the profanity filter will still fail to engage.

Needless to say, if word of this got out I could get in serious trouble, so this is just between us, ok?

So, you probably all saw my little marketing effort for PCalc at the beginning of the month.

It started out as a conversation a while back with some of the usual suspects at the monthly Glasgow MacMacDev developer meeting. We were discussing the recently introduced age ratings in the App Store, and whether a 17+ rating on your app would actually boost sales rather than hurt them. All the Twitter clients (bar one) had just been given a high rating because they could connect to the treacherous unfiltered internet.

How could PCalc benefit from this marketing tactic? How do you make an excellent but otherwise boring scientific calculator get a 17+ rating? Calculator words were mentioned, with the thought of displaying appropriate pictures. But the idea came about to go in the other direction entirely, and actually censor any bad calculator words when the iPhone was held upside down. We were, of course, joking.

But it was funny, and extremely easy to implement. I thought it would make for an interesting easter egg, destined to remain undiscovered except by the occasional well-off bored teenager with an iPhone. So I spent an afternoon on it, and showed it at the next meeting. People were amused. I submitted it to the App Store and, as per the guidelines, documented the easter egg for the Apple reviewers. I don’t know whether the reviewers themselves were amused or not, but 9 days later it was approved.

I hadn’t done a PCalc release on the iPhone for a while, and the 1.8 version I was working on was a little dull to be honest, as far as new features went. The main thing I actually wanted to introduce wasn’t really a new feature, but a discount coupon code in the full iPhone app which was worth $9 off PCalc for Mac OS X. This was an idea that came from Sanford Selznick who had done something similar with his Password Wallet application.

I thought it would be good to give a discount to people who were buying both, and since Apple doesn’t have a mechanism for coupons or discounts in the App Store yet, this was the only way that worked. But also, since PCalc sales on the iPhone are much higher than the Mac version, it wouldn’t hurt to give people an incentive to buy both. As it turns out, this has been a big success, generating a lot of extra sales on the Mac side.

But again, it’s not much of a marketing hook. I’ve talked before about the problems of getting press coverage for iPhone app updates. They are usually smaller and more frequent than desktop updates, and so there isn’t much of a story  just writing about a few extra features. The coupon code is nice for users (and indeed for us), but it’s not exactly headline news.

There have been a number of high profile App Store rejections that were considered to be censorship on the part of Apple, so the thought occurred to me that the hook for this release could actually be the easter egg itself. I quickly wrote up what I considered to be a clearly satirical press release and sent it out to the world. I figured it would give some of the journalists I know a little chuckle, and that would be it. I try and make my press releases at least interesting, so they hopefully stand out a little bit from the crowd.

Initially, it had exactly the desired effect. In the first day, a couple of sites like Rene Ritchie’s iPhone Blog ran some small tongue-in-cheek stories, there was much tweeting, and we had a modest sales bump. Nothing spectacular, but in line with an update of this size. The coupon did prove popular as expected. Job done.

In the immortal words of Dr Sam Beckett, “Oh boy…”.

The next day, something strange happened. I started to get comments on the blog, and quite a few emails, denouncing me for capitulating to censorship. I thought, “Well, they are just playing along with the joke.”. Then, after a few more, I wasn’t exactly sure anymore…

A typical excerpt:

I was unfamiliar with your product, and would have been thrilled to know about it until I today when I read that you’re including a profanity filter. How absurd! This type of calculator is unlikely to even be used by young children. You’ve provided censorship where none is needed. Not only will I NEVER BUY YOUR SOFTWARE, I will actively campaign against its use. Censorship has no place in academia.

And also:

It only censors when you flip the iPhone, but doesn’t censor when you have someone on the other side of the table looking at those numbers when it is lying on a flat surface!!! This shows the ridiculous effort of applying censorship. This kind of behavior does not in any way diminish my appreciation for the app, but it does so for the makers of it, including the folks responsible at Apple for overseeing the “application process” at the App Store and not realizing the futility of their efforts in view of my previous comment above.

It should be said that in both of these cases, when I explained it was intended as satire and pointed them towards my original blog post, they were embarrassedly apologetic. But then the serious press stories started to appear, outside of the cosy bubble of iPhone and Mac news. First up, we had NBC News:

Perhaps out of fear of turning into the next Google Voice in Apple’s eyes, the people behind the PCalc scientific calculator for the iPhone installed a profanity filter on the latest verion of the app that blocks out anything even mildly offensive.

Now instead of getting a smut word when you type “5318008″ and flip your iPhone upside down, you will get a great big “Censored!” message bold enough to make even George Orwell shudder in his grave.

And our own reliable Daily Mirror:

Yep, you read that right. Slap in the correct digits, flip your iPhone around and the PCalc will block the word with a “Censored” image. Not only does that mean no more pranking about when bored to tears at work, it takes App developer paranoia to whole new levels.

By this point, traffic on the blog was spiking to the point where my server couldn’t handle the load. We had indeed gone viral. Most people seemed to get the joke though. Craig Grannell wrote a nice article saying:

This is a smart, funny, satirical swipe at the recent trend towards over-zealous censorship. Unless you’re, say, Sajid Farooq of NBC, who, inexplicably takes Thomson’s joke seriously (and, sadly, he’s not alone) and states PCalc’s change would “make even George Orwell shudder in his grave”. I’m thinking Orwell would be more likely to laugh his CENSORED off.

Austin Modine at The Register gets the award for this piece, which even had explanatory graphics:

The twisted path that led you to becoming the horrible person you are today probably began when your adolescent mind first realized you could spell “BOOBIES” on an upside-down calculator.

Anyway, for the next few days, articles kept popping up, the tweets continued, and many people weren’t quite sure if I was serious or not. I do suspect that some of the articles were written based purely on reading other articles, rather than reading the original. Certainly a lot of things were written without actually emailing me to check what the real story was.

The lesson here is that not everybody will get the joke, even if you think it’s obvious. Perhaps it was a little too close for comfort to reality, and people wanted to believe it. Apple got a lot of heat for forcing this horrible change on me, even though I’d never actually said that. Things were getting to the point where I was vaguely expecting a late night call from Phil Schiller…

But, they say there’s no such thing as bad publicity. So, bottom line, what did it do for sales? Are we millionaires off the back of this publicity stunt? Or have we been blacklisted across the free world and embraced by everybody else?

To be completely honest, it didn’t actually do a whole lot.

Sales of the full PCalc tripled on the first day and have slowly now returned to normal just over a week later. Downloads of the free version increased more than tenfold, and are similarly tailing off, although not as quickly (and some of them might turn into full sales later on). That’s actually slightly worse in terms of numbers than what happened with the release of PCalc 1.7, which was just a normal release with a lot of good features, and no huge fanfare. Certainly, it wasn’t proportionate to the level of noise and hysteria involved. I think many people who read the stories didn’t even have iPhones.

I certainly got a lot of publicity. I’m no longer “that Twitkitteh guy”, I’m now instead “that boobies guy”. I’m not sure this is particularly conducive to selling copies of a serious product, but it doesn’t seem to have hurt us either. Lots of people know the name of PCalc when they didn’t before, and if they are looking to buy an iPhone calculator, perhaps the name recognition will help.

The final irony is that I spent most of the additional profits generated by this whole affair on an expensive office chair to help with occasional back problems I’ve been having. And after a few days sitting properly upright in it, my back is absolutely killing me… So, all those people who said I was a terrible person can take some solace in that.

I discovered a small bug with the button tracking in 1.8, so a small update has been submitted to the App Store already to fix it – but yes, it does also significantly improve the profanity filter. Should I mention that in the press release?

I’m kind of thinking not…

Here at TLA Systems, we take our responsibility to protect innocent minds very seriously.

Have you, or somebody close to you, ever turned your calculator upside down and accidentally seen a mildly suggestive word? Have you ever been in a maths class, and had to put up with groups of giggling boys performing elaborate calculations that are not part of the lesson?

Yes, it’s one of the main problems affecting the calculator industry today, the so-called “calculator words”. These otherwise harmless devices can be made to display smut at the press of a few buttons. Added to that, the iPhone App Store is very strict about having inappropriate content in apps. Nobody wants their app to get a 17+ rating, or worse, to be rejected entirely.

Which is why we are happy to announce that the latest version of our PCalc scientific calculator for the iPhone contains a new patent-worthy profanity filter.

Simply enter a number such as “5318008″, turn the calculator upside down, and the offending word will be discreetly censored. Many common calculator words have been included as standard, and we plan to increase this over time via software updates.

This pioneering technology is available in both the full PCalc, as well as in the totally free PCalc Lite. Ideal for classroom settings, and for the very easily offended.

Some people might say that this is just a humourous attempt to drum up some publicity, and we should really be concentrating on the things that make PCalc one of the most popular calculators on the App Store. Like, for example, the intuitive user interface that takes full advantage of the iPhone, the optional RPN mode, or the wealth of powerful features.

Or, these same people might want us to point out that this new version comes with a coupon code that’s worth $9 off the price of PCalc for Mac OS X, effectively making PCalc for the iPhone a mere 99c if you were thinking of buying both.

But we think we know our audience.

You can find out more details at www.pcalc.com and download either of the iPhone applications here.

Originally aimed at the the mainly feline demographic, our patent-pending “write-only” approach to Twitter – combined with a limited set of fixed tweets – is now well positioned to take advantage of these new rules and expand out into the wider marketplace of puppies and teenagers.

By protecting our users from the horrors of the frequent and intense sexual content and drug use found in those depraved applications like Twitterific and Tweetie (it says so in iTunes, so it must be true), this means we are really now the only family-friendly choice left in the whole store.†

Admittedly, Apple’s own iPhone applications like Safari don’t currently come with any similarly-worded warning notices, but we can only assume that it’s just a matter of time before this insignificant oversight is rectified.

Be assured, we take this new-found responsibility very seriously. And so do all our cats.

† We are also considering expanding Twitkitteh to function as a password management application for cats, because of the disgusting content we heard is present in every copy of Selznick Scientific Software’s PasswordWallet.

While an iPhone app is being loaded by the OS, it displays a fixed image known as the “Default.png”. The idea is that this image looks close to how your application will appear when it is running, so the user thinks your app has launched quicker than it actually has. This image is fixed at the point the application is built, it can’t be changed by the developer afterwards (some of the Apple apps do change it, but that’s another story). This approach doesn’t work well for many applications.

Firstly, if your application can be configured in different ways, the default image isn’t going to match and it will be jarring to the users when it changes. In the initial release of PCalc, I used a “Default.png” which looked like the default vertical layout of the calculator with the screen dimmed.

In later versions of PCalc I added the different key layouts and the themes, so the initial state of the calculator could look very different to the default image. So, I got complaints – people thought I was loading the calculator twice, once with the defaults and once with their settings. It felt unnecessary and confusing.

The other problem is that if your application takes a long time to start up, and the default image looks too much like the running application, people will tap away on it, thinking that it’s already launched. Nothing will happen and they will be frustrated. This also happened with PCalc.

So, I changed the default image to be a nice splashscreen with a big version of the logo like so:

Problem solved? No. The reason Apple used this default image technique (taken from Dashboard widgets) is to make the apps feel like they were launching faster. Now there was no jarring transition, but people stared at my splashscreen for four seconds before the calculator appeared and it felt like an eternity while they were waiting to start typing. And some people thought I just wanted my name in lights. As I added more and more features to PCalc, the startup got slower and slower, and people started complaining again.

Ok, so how did I fix this, and how can you do something similar?

Firstly, you need to be smarter about what work you do when your application initialises. PCalc was already pretty optimised – I don’t build the views for the horizontal layout of the calculator until you actually rotate it for example – but there was still a lot happening. The theme engine I took from DragThing is pretty complex – all the buttons are drawn programatically from a description in an XML file. I cache lots of images so I never draw the same thing twice, so for example, once I’ve drawn the background of one button, I reuse that for the next one if it the same size. But it all adds up.

I needed to work out exactly which bits of the code were taking the most time during initialisation. To do this, I used the Shark and Instruments performance tools to get an idea of what code was executing at startup and what exactly was happening. You might think you know your code well, but it’s always good to look at it running to see if something is happening that you didn’t anticipate. To be honest, these tools are very powerful, but they don’t always give you simple answers.

Then, I fell back on a tried and tested debugging technique, the printf. I added code at the beginning of the main() function to take note of the time using CFAbsoluteTimeGetCurrent() and store it in a global variable. Then, I wrote a function that measured the time from that point, and printed out to the console how long things had taken. So I ended up with messages like:

Time for Init: 0.89s
Time for building layouts: 0.91s
Time for  loading themes: 0.45s
Time for drawing: 1.43s
Total launch time: 3.68s

It’s worth pointing out that there is very little point in doing performance testing against an app running in the iPhone Simulator – firstly, Macs tend to be way faster, and secondly the performance characteristics are not always the same – some things will be much slower than others on an actual iPhone. Do all your performance testing against your app running on a real device. Also, run the app a couple of times in a row – the first time the app is copied down to the device and run in the debugger it will be a good bit slower at starting up than the second time.

Some devices are faster than others as well. In my testing, an original iPhone took around 4 seconds to launch PCalc, an iPod Touch 2G took around 3 seconds, and an iPhone 3GS took around 2 seconds. If you are doing all your development on a 3GS or a Touch 2G, what feels fast to you might feel a good bit slower to somebody with an original iPhone. I try and do all my performance testing on my original iPhone, if it’s acceptable there, it will be amazing for everybody else.

Also, you want to make sure you are measuring the total startup time including drawing. At the end of your initialisation code when you have built all your views, and you think your app is running, the OS will call the drawRect method on any visible custom views before it displays them.

In the case of PCalc, this was a significant chunk of time, because drawing the LCD, for example, loaded all the images required for the numbers. And the first time I loaded an image, the OS needed to load up the required code to read a PNG file. And so on. What I did for the purposes of testing was work out the last view that was drawn, and put another call to my timing function in the drawRect so I could get the actual point in time where that was finished running.

Now that you have a good handle on where all the time is spent you can do something about it.

Here’s a good tip – if you have a routine that takes only 0.1s to run and it only runs once during startup, there is no point spending hours optimising it. Even if you can make it run twice as fast, you’ll still only be saving a small fraction of a second. Looks for the big ticket items and start with them. Don’t assume that something is slow, measure it first, or you might waste time optimising code that doesn’t need it.

But you might also find that you are doing things during initialisation that you don’t need to do at all. Don’t build things that you don’t need yet, try and do everything only when it’s required. For example, in PCalc, I used to initialise the conversions and constants at startup, which involved reading in all the data from various XML files. It didn’t take too long, but there was still no reason to do it at startup – now, I wait until the user actually presses the conversions or constants buttons, and do it there.

Anyway, after spending a week sitting measuring everything, and optimising code along the way, I managed to shave a whole second off the launch time – three seconds instead of four on my iPhone. It doesn’t seem like a lot of saving for all that work, but it did make a difference. The key is to test everything – do some benchmarking every time you make a change so you can see if your changes are helping or not.

Along the way, I had an another idea. Going back to the Default.png image file, I said some of the Apple applications modify it. What they do is save an image of the application when they quit and save the state of the application, that way, the default image will match the real application when it’s finished loading again. I couldn’t do this with PCalc because third-party apps can’t replace the default image.

But what I could do is keep the splashscreen default image, and then as quickly as possible display my own saved image before I loaded the calculator. So, I moved all the initialisation code out of the initialisation. When PCalc starts up now, all it does now is look for a “Loading.png” file in the documents folder and displays it in a simple image view. If it’s not present, it displays a copy of the splashscreen image. The last thing I do  is call -performSelector:afterDelay: to schedule a call of the real initialisation code later.

Then, because my initialisation is over and my app is now running (even though it’s not doing anything other than displaying an image), the OS hides the default image and zooms in the actual application which is showing my loading image. This happens really quickly and gets rid of the splashscreen within a second.

I created the loading image something like this:

UIImage * theLayerImage = NULL;

UIGraphicsBeginImageContext([[UIScreen mainScreen] bounds].size);

[theView.layer renderInContext:UIGraphicsGetCurrentContext()];

theLayerImage = UIGraphicsGetImageFromCurrentImageContext();

UIGraphicsEndImageContext();

NSData *imageData =

[NSData dataWithData:UIImagePNGRepresentation(theLayerImage)];

[imageData writeToFile:pathToLoadingImage atomically:YES];

So, now I have an accurate, if fake, image of my application being displayed while my real initialisation code is being run. To avoid people thinking it was really running and trying to type on it before it was ready, I decided to display a little loading dialog like so.

As I discovered, the UIActivityIndicatorView animation is run on a thread by the system – that means, even though my application is blocked inside its initialisation code while it starts up, the spinner will still be spinning. This looks great, and gives feedback to the user that something is happening at least. I wrote lots of silly startup messages which are displayed randomly, and got some great suggestions from my testers too.

So, I had got the startup time down to three seconds from four with all my initial optimisations. How long did it take to launch with the new loading screen? Three and a half seconds. Hmm. But it felt a lot faster because you saw the calculator appear almost instantly, and then there was at least some feedback that things were happening under the surface.

So I did some user testing. Everybody I tested it on said that the 3.5 second launch time with the loading screen was faster than the 3 second launch time with just the plain splashscreen, so it was clear that was the way to go.

There was another thing I hadn’t considered. I got complaints from my testers who had an iPhone 3GS or a iPod Touch 2G that they couldn’t read the messages on the loading dialog. They went past too quickly, and it felt annoying. The time it took to do all my initialisation on those devices was less than a second. So what I did was not show the loading dialog and spinner, but still display the fake cached image of the calculator.

Because the time is so short, it looks like the calculator appears instantly, but there a short delay before the application is really running. But most people don’t instantly tap the buttons, so I figured I might get away with it.

Of course, I needed to test what happened if people did tap immediately. And I made another discovery. Because I had started the application event loop running before doing my initialisation, any taps on the screen were queued up correctly. So if you tapped 1, 2, 3 on my loading picture, when the real event loop is finally running I would still get the taps and not actually miss anything.

The end result is that PCalc feels like it loads even faster than it should on a 3GS or a Touch 2G. I experimented with hiding the dialog on slower devices too, but the delay was just a little bit too long before you saw the results of your typing, and the magic spell was broken.

In any case, I think this technique of saving an image on quit and displaying that while your true initialisation happens really helps in making your application feel faster to launch. If your initialisation doesn’t take very long, you can probably skip showing any kind of loading dialog on top of it, even on a slower device.

That’s all for this lesson, I hope it proves helpful!

But the comment by Apple’s Tim Cook during the earnings call on Tuesday in response to a question on falling prices annoyed me somewhat:

Developer sets the price, so it’s up to them what to charge. They’re doing what any good business person would do, doing the elasticity analysis, and figuring out where to sell price. As install base grows, it makes more and more sense to have lower prices, but that’s totally up to developers.

PCalc, as you might know, is still $10. We just released a new 1.7 update this week – the tenth release of PCalc for the iPhone – which is getting some good press and positive feedback from users. Sales have been the best we’ve seen for a while, and so far, we’ve not had any complaints about the price from our users. But I think expectations on price are moving in the wrong direction, and statements like that from Apple don’t really help matters.

I still don’t think that lower than $10 price points are sustainable for more niche apps like PCalc, especially if you want to see continuous development.

A few months ago, I experimented with halving the price. We hadn’t done a release for a while as I’d been away the previous month and sales had slowly fallen since the 1.5 release. I didn’t have anything ready to go at that point as I was working away on a version for (the then unreleased) iPhone OS 3.0. So, a discount made sense to try to keep PCalc in the public eye in lieu of a actual release.

The theory is that reducing the price will improve unit sales. The catch is of course that you don’t get as much revenue per unit. When we cut the price, I sent out press releases, and we saw a sales spike very similar to that of a new release. Over the course of the next month, sales tapered off again. We then released version 1.6, put the price went back up to $10, and saw another spike and gradual tapering off in sales.

Compared to the month following the release of PCalc 1.5, for the month of the price cut we saw an 82% increase in unit sales. Which sounds good, until you look at the total revenue figure, and that’s actually a fall of around 10% overall. In all cases I’m looking at the 31 days from date of release.

Compared to the month following the release of PCalc 1.6, the sale month was only a 23% increase in unit sales, or 39% less in total revenue.

So, compared to the releases before and after, halving the price to $5 failed to increase our sales by the required amount. We might have made a little more money than we would have otherwise of course – if we didn’t do the promotion and didn’t get the resultant publicity, we wouldn’t have seen any sales spike at all.

But in any case, it wasn’t the significant boost in sales that I expected it to be, and it doesn’t suggest to me that halving the price on a permanent basis would do us much good in the long term. We would certainly get an initial spike, but the level of sales when that has tailed off wouldn’t be twice what it is now.

Really, I think it depends on who your customers are, and what your product is. The market for games seems to be extremely price sensitive for example. If you have a product which has very broad consumer appeal, I can see how a lower price can help, especially if it’s at a low enough point where you’ll get impulse buys. Even I bought Peggle when it was 99c.

But if your app is unlikely to ever be in the top 100 because it doesn’t have that broad appeal, reducing your price is more than likely just going to cut your revenue in the long term.

For the normal level of sales we get with PCalc, $10 is probably the lowest price we can charge that justifies the time we currently spend working on it. Even then, as a business, we’re only just breaking even.

And customers, if you want to see good quality software in the app store in the long term, you should really be asking developers to put their prices up.

Original post:

I’m currently trying to submit an update to PCalc for iPhone, built with the GM iPhone 3.0 SDK, and it’s failing. The “Contact Us” section of iTunes Connect doesn’t actually let you contact anybody, except for very specific problems, so I’m at a loss at how to proceed. I throw myself on the mercy of the crowd.

I’m clicking “Manage Your Applications”, then “Update Application” for the app in question. After I fill in the version number and release notes, upload the app, and tick the “tested with iPhone OS 3.0″ checkbox, when I click “Save Changes” it says:

“The binary you uploaded was invalid. The bundle identifier is already in use by a different software package.”

I am uploading the right application, and the bundle identifier is identical to that of the application I’m trying to update. I did however manage to update the free “PCalc Lite” app, which was built in exactly the same way.

What I wonder is if because I have a “com.pcalc.mobile.lite” bundle ID for PCalc Lite, it won’t accept the “com.pcalc.mobile” ID for the full version because it considers it in use – it’s worked fine up until now of course.

Could it really be doing a comparison of “com.pcalc.mobile” and “com.pcalc.mobile.lite” but using the length from the first string for the comparison?

Somebody else is experiencing the same thing today it seems:

https://devforums.apple.com/thread/18807?tstart=0

I realise the chance of getting an answer this week (let alone a fix) is going to be next to impossible, but this is precisely the week it’s needed if I’m going to submit the build in time for the 3.0 rollout. Sigh…

The Info.plist file for the app looks like:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>en</string>
<key>CFBundleDisplayName</key>
<string>PCalc</string>
<key>CFBundleExecutable</key>
<string>PCalc</string>
<key>CFBundleIdentifier</key>
<string>com.pcalc.mobile</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
<string>PCalc</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleResourceSpecification</key>
<string>ResourceRules.plist</string>
<key>CFBundleSignature</key>
<string>P©al</string>
<key>CFBundleSupportedPlatforms</key>
<array>
<string>iPhoneOS</string>
</array>
<key>CFBundleVersion</key>
<string>1.6</string>
<key>DTPlatformName</key>
<string>iphoneos</string>
<key>DTSDKName</key>
<string>iphoneos3.0</string>
<key>MinimumOSVersion</key>
<string>2.2</string>
<key>UIStatusBarStyle</key>
<string>UIStatusBarStyleBlackTranslucent</string>
</dict>
</plist>

The current app details in iTunesConnect say:

I’m at a loss… Any thoughts?

I just got the following in my inbox:

James and Jon:

I’ve just posted my rebuttal to your blog posts in the MacHeist forums:

http://www.macheist.com/forums/viewtopic.php?pid=324361#p324361

For what it’s worth, I’ve been a user of DragThing for years, James, and that’s one of the reasons we wanted it included in MacHeist 3. You chose not to participate and now you’re making several false statements about us and other bundle promoters.

So, to reiterate what I wrote in my post, it’s completely your right to partake in whatever bundle you wish… or to not partake in any. BUT… it’s your RESPONSIBILITY to not make false statements. I’m seriously hoping that you’re now rethinking the false, damaging statements that you’ve made and that you’ll post a retraction. The statements I made in my post are FACTUAL.

I love how you’re all on your high-horse about fairness, farmers market and crap, yet you ALL have ZERO ISSUE with posting outright lies. Ethics and morality, people…

———————–
John Casasanta

His referenced post on the MacHeist forums states:

I still have to take serious issue with outright false statements like:

“Instead of most of the profits going to a third-party company with a background in marketing…”

“…instead of getting way less than a dollar per copy, or – even worse – only getting a flat fee regardless of the number of copies sold…”

“So if it sells, say, a couple of thousand copies in total, that’s a much better return than we might see from many tens of thousands of sales of some other bundles.”

“Those people usually reap the bulk of the profits from the sale, passing only a small percentage of the sale price on to the developers of the software.”

Overwhelmingly, the profits go to charity. The developers got the bulk of the earnings. We paid our staff. And the principals earned a fair amount, considering the effort we put into things.

So if Mr. DragThing and Sir Default Folder choose this “fair” bundle over ours or MUPromo, that’s totally their right. They simply shouldn’t go around spreading complete and utter bullshit, though.

All of our “slick, fancy, Madison Ave. marketing” does, indeed count for something… this new bundle still has the bonus app offer for when 2,000 bundles are sold, and I suspect that this offer will last the duration of the bundle. So I’ve heard that the devs are getting like $5 per bundle sold or something. Assume that they’ll sell around 1,000 bundles or so (I’m basing this estimate on what I heard the last MacBundleBox sold at like 800 or something) and that means that each dev will make around $5,000 from this promo.

Compare that with MacHeist 3, where each dev, at minimum, made what most people would consider a really good year’s salary for two weeks of a bit of an extra support load. And that’s saying a lot in this crappy economy.

If devs want the “FAIREST BUNDLE EVAR” then they can just continue selling a “bundle of 1″ at 100% price.

Adapt or die…

So, aside from the fact that I wasn’t singling out MacHeist specifically, I feel I have to respond. Here’s what I just emailed back to him.

That’s very interesting John. I’ll give you two concrete examples:

I was offered a fixed fee of $1200 (later increased to $2000) by Stephen Christopher in February to include PCalc as a bonus app in MacHeist 3. You will probably argue that it wasn’t intended as a “full” member of the bundle, but from my perspective, you wanted to give away an unlimited number of copies of my application for a fixed fee.

Calling it a “marketing opportunity” doesn’t change the fact that you are paying a tiny amount to a developer to boost the popularity of your bundle significantly. That is exactly the kind of behaviour that I objected to in my post, and was what drove me to participate in this bundle as they seemed to be genuinely trying to do something different.

Phill Ryu offered me $2 per copy for DragThing last year for MacHeist 2 in February 2008, again as a bonus app, which I did decline. You didn’t ask me about including DragThing this year, so I don’t know exactly how much you were planning to offer this time around. But you say I chose not to participate this year which is – in your own words – “an outright lie”, as I was never asked anything about including DragThing in MacHeist 3.

I have been offered similarly low – and lower – amounts from other bundles to take part. Did any of the participants in MacHeist 3 get around $5 per copy sold as every single developer is from this bundle? Are all the participants getting the same amount? That, in my book, is a pretty good definition of fair.

You say “adapt or die” in your post. That is exactly my fear. If developers – and by that I mean ALL developers – can’t sell their software at a fair price that will support them in the long term, then they *will* start to die out. If eight or ten developers made a decent wage out of Mac Heist 3 – and I take your word for that – and, let’s say, another eight or ten do the same from MacUpdate, then what happens to the other thousands of developers out there who are trying to sell their software, but nobody is buying it because they are waiting to see if it turns up in another bundle?

I don’t think this bundle is perfect either, not by a long shot, but I believe it comes from a goal to support developers first and that’s why I took part.

I can only speak for the experiences I have had.

James

The conversation has subsequently moved to the MacHeist forums – you can find the thread here. Rather than copy everything in three places, I’m off to the lions’ den… See you there?