Apps & Software


Race to the Bottom: iPhone App Store Pricing

I’ve had a notion for some time that the price wars on the app store may be detrimental to the community. I know I’m not alone in this feeling, and have found others online who would agree. Finding like-minded developers isn’t my goal. I’m wondering when, or if, the App Store will begin to resemble something a little closer to desktop boxed software prices.

I think it would be wrong to assume that mobile apps will reach the cost of boxed software. However, I do believe we’re shooting ourselves in our proverbial feet by pricing perfectly good applications at free or even $0.99. Admit this – comparing a $0.99 app to a $2.99 one, both with similar features, ratings, and quality user interface, which one are you more likely to buy? If you were the guy selling the $2.99 app, wouldn’t you feel compelled to lower your app’s price even just a little? I mean, some money is better than none?

Assumptions

You’re going to make a few assumptions, be it good or bad, but one way or another they will affect your sales. These probably fall into two or three areas, 1) lowering your price will communicate better value; 2) lowering your price will increase sales; 3) more sales means more profit.

Better Value?

That’s open for debate. Customers may think they’re getting a great app for cheap (high value), or they can see a lower price (whether your are lowering the price or setting a low initial offer) and think nothing of it because everything else in the category is priced roughly the same.

Increased Sales?

This might also be true. It almost goes without saying – people can buy more cheap apps on the same budget than pricey ones. I’ll give you a +1 for remembering the concept of supply-demand curves you learned in your high school econ class. There is, unfortunately, a wrench thrown into your increased sales equation – anecdotal evidence points to the best sales occurring right after launch and eventually falling off after the 60-day mark. We’re working with a limited time frame to make the most we can.

More Sales, More Profits

All things being equal this becomes a matter of math. Cutting your app’s price in half means you need to double sales to make the same amount of money. Do you think you can do that? Realistically? In the 60-day window where most developers see the largest chunks of their sales?

Closing Thoughts

I’m going to finish up with one thought that should bring this full circle. Before pricing your app consider the cost of the downward price war. You may make more sales, but you won’t make a decent income off of it. Should this trend continue, our users will become spoiled enough that they will hardly tolerate higher priced apps unless they are truly unique and worthwhile. This price war is only hurting ourselves and something will have to change or the App Store will end up a wasteland of low-quality apps because the true developer dollars will go elsewhere, thus making the iPhone/iPod Touch platform much less appealing for everyone.




Compile Multiple App Versions in XCode

Well on my way to becoming comfortable with Objective-C and Cocoa, I came across the need to create two versions of an app I was working on – one a “Lite,” and the other a full version.

Branch merging scares me

Like any good developer, I use source control management to keep tabs on my development cycles. This time, being no different than any other, I dutifully created a new branch for a lite version of my application once I completed the critical features milestone. Being one who doesn’t have a lot of use for branching in most projects, I was reluctant because (be honest here) the notion of merging back and forth between the lite and the full branches was a painful one.

Ok, I know – merging shouldn’t be that big of a deal, but what about this scenario? I’m adding some features to the full version that I decide I want to port back to the lite. Auto merging isn’t going to work (we can give the lite app all the same features of big brother), but neither am I so keen on going line-by-line every time I make a change. Cry me a river, right? Well, no. Actually, the solution is easier than that.

Enter: Compiler flags

I don’t know when I first learned about it – it could have been in my early programming days when I was learning about C – but I’ve always had ideas about compiler flags in the back of my head… very dim ideas. Look through Cocoa demo apps (check your Cocoa docs) and you’ll see several that have lines of code that seem to point to something specific:
#if defined(LITE_VERSION)
//do something here
#endif

That’s a compiler flag. That’s the key to getting your lite version separated from the full version at compile time (or runtime, or whatever, depending on your need). Using those compile flags you can separate specific portions of code for one version of your app to another.

I’ll save you the dirty details of how you do this. Instead, head over to Junda Ong’s blog.




My First Native iPhone App

It’s Thanksgiving Day weekend – one of my favorite of the year – because it gives me the chance for some nice, quiet R&D time without the pressure of clients or projects asking to get things done. This week I finally made it through enough of my Objective-C/Cocoa/iPhone books that reading further felt like I was just going over more specialized use cases. For now I don’t foresee the need to have covered every topic before I get started – the basics are covered.

Of the app ideas I had going into this weekend, I chose the simplest (training wheels – crawl before I can walk, right?). It’s a Tabata timer for interval-based workouts. Nothing too special. The basic functionality is there, but I want to pretty it up and add a couple features before submitting it to the app store. I doubt it’ll really make me any money, but I did it for the exercise, not for the big bucks. I’ll post screenshots and links when it’s finished/up.




Using Pinch Media Analytics in PhoneGap

Getting close to finishing up an app for a client in the coming weeks, my business partner and I decided it would be a good idea to include some analytics code so we could track how people are using our application. We ended up using Pinch Media’s Analytics to do our tracking. It came down to this: their code is REALLY easy to implement, and they provide us with just enough information to satisfy our curiosity. I think one of the biggest draws is that it records information regardless of the user’s online status – meaning offline app usage information is stored to a small database and then uploaded once the user reconnects. Had we used a web-based solution, which would have been natural given the nature of PhoneGap (the underpinning of our application) being UIWebView, we would have missed out on some details without considerable work-arounds to cache data as Pinch Analytics does.

Because PhoneGap is essentially a single view application that displays web pages, you are a bit limited with the extent that you can integrate Pinch Analytics out of the box… unless you use javascript callbacks to Objective-C within PhoneGap. That’s not the point of this post. The point is that you just need to follow Pinch’s instructions and you will have analytics data reported back to you within a few hours.

Moving forward, I’m likely to investigate some of the finer points of creating my own PhoneGap callback functions so I can embed Pinch Analytics Beacon methods, which are nice little ways to record information about discreet actions taken within your app – recording leader board views, for example.




PhoneGap Up To Speed

I recently ran across some major performance problems with a jQTouch app running in PhoneGap. Some of the symptoms included long pauses on touch events, non-responsiveness, and laggy transitions.

Brian LeRoux (Nitobi/PhoneGap), Jesse McFayden (Nitobi/PhoneGap), and David Kaneda (jQTouch) were the stars looking into this issue. Ends up Jesse found where the Accelerometer was taking a 40Hz sample rate and sending the data to a callback. The solution is to just disable Accelerometer use – either in the plist or, as I did, comment-out all the accelerometer bits. Likewise, I removed location functionality, as this app in particular doesn’t need it.

You can read Jesse McFayden’s post here. And if you’ll excuse me, I have an app to finish…