My Couch to 5k update to version 1.2 went live in the App Store last week, and this week sales are down 40%. Coincidence? Maybe not. When a new version comes out in the App Store, its reviews and ratings are all reset on the description page, so if your app had lots of 5-star reviews and ratings, it’s all lost until your users write new reviews and make new ratings for the new version.
If your app has a lot of competitors, those ratings and reviews are what separate you from the rest. Someone looking at your new version will think your app is new and untested.
It used to be that the App Store advice was to update often to get on the “new releases” page and get a corresponding sales boost. Today, with the volume of low-quality new releases, having good reviews is more important, so you had better make sure your version 1.0 is complete and polished enough to get good ratings, and if you already have a 5-star app, don’t update it unless there’s a major bug to fix.
Maybe this week was an anomaly, but previous updates to Couch to 5k and Couch to 10k have never resulted in more sales right after the update was released. In fact, the opposite happens: there’s a sales dip for a couple weeks before they return to the previous levels.
From a customer’s perspective, it’s annoying to constantly have to update your apps, especially if the update doesn’t fix any major bugs or add any new features.
I have over a year of sales data on Couch to 5k and other iPhone apps, and I have over 10 years of experience in selling Mac software, and the iTunes App Store is very different from the Mac. On the Mac, you add features and fix bugs incrementally, releasing a new version as often as every 2 weeks, and sales increased because news of the update gets around to VersionTracker and blogs and web sites. So you would update early and often. And major new versions (2.0, 3.0) would result in huge sales spikes from people upgrading.
In the App Store, that no longer works. You have to come out with a fairly complete and polished version 1.0, and if you do have a hit, you have to limit your updates to a few times a year in order to preserve your ratings and reviews.
I finally got around to setting up my MiFi2200 for the iPad, which kept dropping the WiFi connection to the MiFi. I changed the 802.11 Mode to 802.11g only, and changed the Security to WPA2 Personal.
It seems that the iPad does not like the mixed 802.11 B & G mode and will keep dropping its WiFi connection. It still doesn’t like a weak connection but at least it will auto-reconnect when it can only see the 802.11g network.
The WPA2 Personal security setting is just to use the latest type of security available.
And one more thing: I used iStumbler to see what 802.11 channels my neighbors are using. I live in a dense urban environment and can see over 100 WiFi networks when I sit on my stoop, so to avoid interference from other nearby strong WiFi signals, I chose Channel 1.
iPhone development using view controllers with Interface Builder can be tricky if you don’t know what’s going on. I see a lot of code where the programmer is a bit confused.
So here’s a few tips if things aren’t working quite right with your View Controllers:
If you’re programmatically creating your view controller but loading the views from a nib, make sure your nib filename is correct. It should be just the nib name without the extension. So if your nib is named “MyAwesomeViewController.xib”, pass just “MyAwesomeViewController” into initWithNibNamed:…. If you’re copy and pasting code from another view controller, this is where I often forget to change the nib name.
Another common mistake is to create everything in the nib and then forget to connect the IBOutlets and IBActions.
But the main problem I find is that programmers don’t understand when awakeFromNib, init, initWithCoder:, viewDidLoad, viewDidAppear, and all the other view lifecycle calls are made. It’s a bit tricky.
If you put an instance of your view controller inside of a nib, and the nib is loaded, the system will deserialize your view controller using initWithCoder: and then call awakeFromNib. If you don’t do that, and create your view controller in code, you have to call init or initWithNibName:bundle:.
Here’s the tricky part: if you write your view controller to work both when it’s loaded from a nib and when it’s created in code, there are two different code paths you have to write for. One for the nib-loaded case, where it calls initWithCoder: and awakeFromNib, and another for programmatically creating it, in which case initWithNibName:bundle: is called.
Then viewDidLoad gets called. I see programmers putting code here which should be in the initialization methods instead. The problem is that if the controller’s view gets unloaded due to a memory warning, and then the view is reloaded later, viewDidLoad gets called again, with potentially harmful side effects. You should put code that sets up the view, such as setting up UILabels and other views, in viewDidLoad.
Also, the “File’s Owner” object in a nib does not mean that the view controller is being loaded from the nib. That’s just a proxy object for the view controller that calls initWithNibName:bundle:. View controllers that are instantiated in a nib will have an orange ball in the nib file in IB.
My preferred method is to create view controllers programmatically. Each UIViewController subclass has a plain “init” method that calls [super initWithNibName:@”NibName” bundle:nil] so that the caller doesn’t have to remember the name of the nib. Then I don’t write the initWithCoder: or awakeFromNib methods.
However, there are times when loading the view controller from a nib makes sense, and in that case remember to implement initialization in initWithCoder: or awakeFromNib, and don’t put one-time initialization code in viewDidLoad.
I just spent an hour writing a reply to an email from a recruiter looking for iPhone developers, and the gist of it is that I don’t want to work for your startup. I already have my own company, and it’s doing really well, thank you. It makes far more than you’d be able to pay me, and I don’t really need the money anyway.
Everybody comes up to me with ideas for a game or an app, and if you’re not going to tell me your idea, I’m not going to go with what you’re playing or sign an NDA. Your partnership with a major brand or big name company sounds impressive, except I don’t care. Your unique idea probably has a dozen other people already implementing it as an iPhone or iPad app, or it’s been done decades before, or it’s just not something I’m interested in.
I’m far more likely to collaborate or work with you if I know you personally, or at least if we’ve talked in person at some event. I’m more interested in you as a person rather than as just a business prospect. Most of my apps were originally made for friends or for myself and grew organically from what people wanted.
What it comes down to, and this echoes the Agile Manifesto, is that individuals and personal relationships are far more important than your idea or brand.
The C4 Conference is no more. A year ago, that would have made me sad, but today I’m no longer such a hardcore Mac programming geek that I need to go to another conference like C4. This year so far, I missed Macworld, but went to SXSW, MaxFunCon, and two Tweet-ups. I’ve also been to many tech events in NYC but the focus is usually not on computer science at those.
I think it reflects a shift in software development in general, away from a focus the low-level computer science questions and towards a focus on user experience and combining technologies at a higher-level such as location-based services to make things like Foursquare.
I think the Appcelerator Titanium controversy last year had something to do with it. There were some disparaging remarks about Titanium, which lets you build apps for multiple platforms at once, on the Twitter backchannel last year, and Rentzsch spoke out about it during the conference. Then Apple came out with Section 3.3.1 which bans such cross-compilers or interpreters.
I know some people who come from a web development background, and they generally have much better tools and techniques such as unit testing. Apple’s Xcode and Obj-C 2.0 are nowhere near the state of the art of computer science, and most Mac and iPhone OS developers are ignorant or even hostile to innovations which could make their lives easier.
But when you step back and look at the whole process of shipping an app, programming is only a small part of it: maybe one fourth. There’s also the text, graphics, and sound content of the app, market research and other marketing, and customer support and user testing. So when Apple came out with Section 3.3.1, it was such a small change that I just didn’t care.
Another thing is that I think that with iPhone OS development becoming more mainstream, it’s a lot easier for me to meet other iPhone developers at events that are local or that aren’t specifically aimed at Cocoa developers. It’s still hard to find Mac developers.
And another thing is that I much prefer to talk to people who aren’t developers, or at least don’t do that full time, because it gives me a different point of view. They often have ideas or problems they want to solve that I as a programmer, and my programmer friends, don’t think about. My best apps were those that I wrote for someone else who isn’t a programmer. App that I write for myself or people like myself tend not to sell that well.
So while I agree that computer science is important and what Apple provides is ages behind what’s possible, it’s only one part of being a software developer. I’m becoming more of a project manager, designer, and marketing person and less of a programmer. In NYC I’m finding lots of local meetups that fill my needs for programming conferences. So while it’s sad that C4 is gone, I think I had already moved on and wouldn’t have gone to another one anyway.
HelTweetica 1.0 hit the App Store last week, and it’s free, at least for now.
I made this app mostly for myself. When I got my iPad on launch day, I was hoping to see a good Twitter app, but after a few days of going through all the Twitter iPad apps I could find, I decided I had to write my own.
But when Twitter acquired Tweetie, I thought that there was no future for Twitter apps on the iPad since they would come out with their own free version. That could still happen any day. So I finished up my app by cutting out unfinished features and doing a little testing to make sure it worked.
It took 3 tries at submitting it to the App Store and an iPadDevCampNYC, but version 1.0 finally made it into the App Store. I wasn’t expecting so many people to like it, but after getting some feedback, I realized I needed to flesh out the app by finishing some of the features and filling in a lot of the holes.
So the past week I’ve been working on an update to the app. But I’m going to MaxFunCon this weekend and I need to pack and prepare for that, which gives me time to think about whether it’s still worth it to work on a Twitter app.
My motivation was initially to have a Twitter app on my iPad that worked the way I wanted it to. But I also like getting feedback and validation, and the recognition of my peers and from people I respect.
Eventually I’ll have an app that’s on par in features with Twitterrific or TweetDeck, at least for the features I care about and that other people care about, and maybe when it hits version 2.0, it’ll be a $3 app. I don’t like to make promises because things could change quickly, but at least in the next week I’m going to continue to work on it and release a version 1.1.