Last weekend I had the privilege to be able to attend the inaugural 360MacDev conference in Denver. While many readers may only be beginning to think about deploying apps on OS X, there are many developers out there who’ve been happily making a living doing so for years. The overlap, or synergy, if you will, of the iOS and OS X communities was clearly evident at the conference.
As every seasoned iPhone developer knows, the Christmas season is Big. Retailers, online and physical, make most of their annual revenue in the fourth quarter. It’s not quite that lopsided for iDevs, but the rewards can be great, both before and after Christmas. As everyone knows now, Apple shuts off access to the iTunes Connect portal from December 23rd to 28th, meaning you must get all updates and price changes in effect by the 22nd.
This a post about using Xcode’s distributed build feature to shorten your development cycles. Many indie developers are constantly seeking a way to shave a few seconds off the edit-build-debug workflow. If you have more than one Mac at your disposal, or even if you work in a small team, you can effectively pool compile resources to speed build times.
[Guest post this week by Trish]
The Beatles!!! On iTunes!!! Depending on what side of the fence you’re on, this was either a ‘day you’ll never forget,’ or a big yawn. If I tell you that I’ve been a lifelong Beatles fan, and, in fact, saw them at the Baltimore Civic Center on Sep 13, 1964, you’ll know which end of the spectrum I fall on.
The national media picked up on the story. I saw the Beatles when I walked by my TV. I saw the Beatles on the top internet news stories. I saw the Beatles on USA Today on my iPad. Out of curiosity, I googled ‘Beatles’ and ‘iTunes,’ and read that something like 28 Beatles tunes were in the top 200 downloads. That’s when it hit me – why are we here at Mundue LLC not taking advantage of all of those sales?
When I mentioned this to Mr Mundue (aka Matt), he said that Apple had sent out official iTunes Affiliate artwork. That did it! Apple was expecting us to monetize the event. We got right to work creating a house ad to display in our app, and we were going to monetize the Beatles songs and albums using Apple’s affiliate program. Brilliant! And let’s not forget that $149 box set. Probably every third or fourth sale would be for the box set, right?
The dollar signs were swirling around in my head. This was great! Not only was the best group of all time finally on iTunes, but I was going to capitalize on it. Let’s see, how many box sets would people have to buy in order for me to make back the money we plunked down to see Sir Paul in August? How many singles?
And if this works out, just think of all the future possibilities. Every time a big album comes out, we create a house ad and, voila, the money starts rolling in. Why hadn’t we thought of this earlier? Well, nevermind, at least we thought of it now. I couldn’t wait for the affiliate numbers to start coming in!
And then, they finally did.
So how much did this Great Beatles Experiment bring in? Forty nine cents. Yup. Forty nine cents. I was devastated. How could that be?
I can only venture a guess. Looks to me like most people download music at home, on their computer, not on their iPhone. We had plenty of clicks, so I guess a lot of folks checked out the Beatles offerings from their phones, but waited until they got home to actually make their purchases. I dunno. They surely bought boatloads of Beatles tunes that day. Just not on my watch.
Which leaves me with 49 cents. And a deflated ego. And a looong way to go to pay off those tickets. But still a huge Beatles fan.
Four weeks have elapsed since we raised the price of reMovem and the skies have not fallen. Yes, the daily rankings have taken a hit, but the revenue is holding steady and has even grown a tad. Interestingly, I haven’t had a single comment about the price change, and the ratings are still a solid 4-½ stars. We don’t consider this an experiment, but will closely monitor the results over the next few weeks to help decide if/when to lower the price again. If you’re curious about the effects of such a change on a stable mature app, then read on.
This is a short post since I’m on the road, still at the tail end of the 360iDev conference. Apologies for the brevity and late date, but I don’t want to miss my deadline.
I was going to write about how awful the current App Store review times are. I’d been waiting for an important update for 9 days, which seems about normal these days. I frankly expected it to take up to 14 days, which has unfortunately been more common lately. Then I got that happy email with those three magic words.
It’s widely assumed that lowering price can increase sales. In theory the lower the price, the larger the increase in sales. This can indeed offset the difference in price and possibly even increase bottom-line revenue. What happens when you raise the price instead?
We’re lucky to live in a big little city (Colorado Springs) that has a vibrant iPhone developer community. There are regular CocoaHeads and NSCoder meetings, as well as non-affiliated iPhone meetups and various UX discussions. Just last night we were able to see and critique some interesting demos of unannounced projects. We also got into a lively discussion about best practices for an App Store description. This kind of feedback is highly valuable.
I am not a developer and I don’t play one on TV. I used to make my living by testing software that other people write; in other words I got paid to find fault with other people’s work. But I gave all of that up when I moved from Boston to Colorado with my husband Matt (aka ‘Mundue’), and I decided that this would be a good time for me to take a shot at helping him write and maintain our iPhone apps.