How much did Twitteriffic for iOS cost to develop? Craig Hockenberry answers.

The real skill is in explaining why this is difficult and actually how much design work needs to be undertaken to make these "simple, clean" looking apps

However it has to be said there are some quick wins for mobile apps that can be achieved quickly, however something like twitterific which is probably one of the top 2% of iPhone applications the effort expended is not that surprising unfortunately

Apple gives you a boatload of really thoughtful, usable UI classes. What I've read is that Android's SDK UI code isn't nearly as substantial or mature. Can you confirm if this is the case?

edit: Then there's Core Data for object modeling and persistence, which is a huge time saver. Is there an Android analog of this with comparable power?

Maybe the polish came after the MSN games version?

eg -> http://venturebeat.com/2008/04/21/popcap-games-executive-int...

Incidentally, at $15-$20 an hour, you're severely under-pricing yourself, if you're in any major market in North America that I can think of.

Also, get a retainer. Took my 18 months to get money from a friend's company once. Retainers get rid of so much BS.

Bottom line, if you cloned Twitteriffic in 160 hours, I'm certain I'd still rather buy and use the original, even if yours is free.

That being said, the larger the project is, the greater the probability of underestimatitis. As soon as you hit 250+ hours, I've found estimates to become increasingly less accurate.

The original estimate someone put forth for twitterific was 160 hours of development. Ask yourself, could you reasonably expect to sit down today and from scratch, have written something as polished as twitterific, in only 32 days? Knowing full well you will need to spend days banging your head against some problem that should have taken you 10 minutes but somehow cost you 6 hours, testing and fixing bugs, profiling and optimizing slow code paths, polishing interactions, tweaking animations, and going back to the drawing board when some piece of functionality doesn't quite feel right?

The testing and tweaking alone can last for weeks in high quality projects, and 32 days only gives you 4.5 weeks from start to finish. It's absurdly low.

The important part is not that the estimates match any number of hours per se, but rather than the relative weighting is about right, such that something you estimated as 3 points is, in actuality, about 3 times as much work as something estimated at 1 point, and all 1 point stories are roughly comparable in terms of work.

What you then do is to empirically estimate the actual mapping of points to hours/days as you work by tracking your velocity. In a 40-hour work week, how many points do you actually get done? As you get better at estimating, ideally your velocity becomes more stable, and then you can map from points back to days in order to make scheduling decisions. We switched over project planning and estimation to that strategy on a fairly large project I was leading, and it helped give us much more accurate overall estimates.

Now, that's all easier to do when you're working on a long-term project, you're familiar with the existing code base and the problem domain, etc. such that you can actually break things down into stories and do reasonable estimates.

That said, I think that the general idea of point-based estimation is still useful for you: rather than trying to estimate hours or days, work on getting better at relative estimation using something like points, and then empirically measure your mapping from points to hours to determine your likely schedule and how much you should bill.

It takes a lot of work to make things look simple. And even more to make them well-done.

Prior to writing my iPhone app, I had 0 experience doing iPhone or Objective-C dev (I do have a comp sci degree which did help a ton.) All told it took me and my partner around 70 hours of dev/design work (some of that was me reading HCI guidelines for the iPhone.) We spent around $200 on an icon package, $75ish on an anti-hack kit, and had some server costs that got absorbed elsewhere.

It was a fun project and something we'll continue to play with in our spare time.

Making something that is actually useful, beautiful and performs well will take much longer. This is where things like writing the API consumer bits, handling persistent data stores and so on come in.

Then you need to polish it.

It's not so much about the language or framework as they are great once you learn them, it's just that the standards are set very high in the App Store (at least if you wish to be taken seriously).

That being said, I have worked on 20+ iOS apps now and most of them were finished with a MUCH smaller total number of hours than this. I don't disagree that taking something from "it works" to "it's elegant" takes time, but 1100 hours of dev time does seem a bit high. I, too, would be interested in more info (like total lines of code, whether or not they built a Twitter engine from scratch for the app, etc).

To anyone considering making an app: don't use this as a baseline comparison. You can get a great-looking app done in a lot less time than this.