As an Android consultant I'm always amazed at how much clients underestimate the effort involved in putting together a high quality "simple" app. It's actually worse for Android, for some reason clients can't fathom paying the same for Android as they pay for iPhone apps. I always have to explain that it is no easier creating an Android app than an iPhone app. Of course people get what they pay for which is probably why the quality of Android apps in general is so poor.
It's actually a bit harder to create an Android app of comparable quality, isn't it?
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?
The other challenge is developing for all the variants on Android (OS version, different manufacture idiosyncrasies, hardware speeds, screen resolutions, orientation, virtual vs hardware keyboard) all increase the development time and especially the QA time on Android.
Android is costlier because designers don't like Google's widgets, so every Android app (that involves a "designer") makes their own instead.
This results in shitty apps that are costly to develop. Fortunately, most of the apps that people actually use don't do this, so it's not really a big deal for users.
The API's have more gotchas and simple bugs than the Apple ones.
The 1.6 API in particular has some hairy bugs.
The debug cycle takes considerably longer (almost 3x as long as the iPhone debug cycle for a non-media app).
The debugger doesn't work as well.
The lack of a GUI UI layout tool (there are some, they don't work well yet).
The project setup is considerably more time intensive (barring signing issues, which experienced iPhone shops don't have issues with really).
Now it's not all against android: The lax approval criteria and ease of market publications are awesome. I'm just saying it costs MORE to do android, I'm not saying don't do it.
And yes, you're right, custom widgets are harder in android than in iOS. If it makes you feel better, I find the amount people change iOS custom widgets silly too.
I can't speak to Android SDK's maturity, but I can say that the foundation of the iOS SDK has been around a long time. All our Foundation classes are still prefixed with NS. Almost all of the most basic stuff, and even a lot of higher level stuff as well, has come over from MacOS X and NextStep before that.
Yeah, OS X is an enormous, and often underestimated asset of Apple's. Put them on great footing from the very iPhone SDK.
On the NS prefix: Lots of fun to switch between iOS and OS X dev. Wrote my first OS X app a couple months ago and it was weird to stop using the UI prefix for all the view classes.
My big wish for the next major iOS SDK is to get bindings. Those are awesome on the desktop.
> My big wish for the next major iOS SDK is to get bindings.
I wouldn't expect this. Honestly I'd expect things to go the other way: 10.7 maybe deprecating bindings on the Desktop for things like table and outline views. Particularly since they added NSTableViewDataSource/Delegate and NSOutlineViewDataSource/Delgate in 10.6.
Really? With bindings you get to write so much less glue code for labels, button states and other UI widgets. It's a dramatic time saver for UI minutiae.
I actually do like them for labels, button states, and other what I'll call "scalar" widgets.
For collections, though, I feel like they're more likely to get you into trouble than to actually solve your problems.
I think you could do something substantially less complicated/powerful than bindings for the cases that bindings handle well, though, and I'd rather Apple did some innovating there than bring bindings over to iOS.
I'm also with the other folk who would much prefer to see Garbage Collection first. I rarely get into trouble with the reference counting system, but when I do it usually takes me forever to track down why my app is crashing without a single line of code written by me in the stack trace. Usually it's because I assigned an autoreleased value to an ivar in an init method while failing to retain it (a stupid mistake that I still make once every few months even after 5 years of Cocoa/Cocoa Touch work).
I've never found myself wishing for bindings on the iPhone. Maybe when I'm using Core Data, but thats not too often. And even then, its relatively easy and quick to abstract it all away.
I want GC on the iPhone. Not for the GC itself, just so Apple will make NSPointerArray, NSHashTable and NSMapTable part of the public API.
I have seen bindings running on iOS, and it has massive potential, especially for areas like live updating of on-screen table rows etc. Fully expect them there soon.
Will be astonished if they get deprecated on desktop, too. Value is far too high.
Yeah I took on a short Mac project a number of months back and got really messed up with the switch. The ubiquity of Core Animation on the iOS was what spoiled me I think. Don't hold your breath for bindings on iOS though. I'd rather have garbage collection anyway.
I'm sure garbage collection's on the way with the increases in processor and memory in iOS devices.
Lack of GC seems to be an artificial constraint designed to force dev's to take charge of a situation with very limited memory. Unless there was some major overhaul to the Foundation classes.
I can't really say whether Android is harder, but I think Apple's tight design guidelines make the design easier if you're using the default built-in controls.
for my sins I have been making mobile apps for over 6 years, the original problems we had explaining to clients about fragmentation in J2ME was even worse as Java was sold as write once run anywhere, A similar thing now happens with iPhone OS variants where people just see it as a "iPhone app"
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
A few years ago I taught a short game programming class. Just for kicks we had a quizz where the students had to look at 10 small downloadable games and estimate how much effort had gone into each of them. PopCap's Bejeweled 2 stuck in my mind.
The estimates ranged from 'a weekend' to 'maybe a month'. The truth: pre-production with 3 senior people for 2 months, post-production and polish with a team of 10 for a year. There were a lot of little gem games at the time. There still is. But Bejeweled was the one that sold over 50 million units.
I've seen several interviews with the PopCap founders where they've stated that they built the original in less than a year with just the three founders.
Maybe the polish came after the MSN games version?
They've got such an intersting story especially for HN audience - bunch of taltented guys in their 20s at the time, working for the man, going out to build something new and doing their best to survive while they got traction - I think their first deal was just $1500 a month for the original online version of bejeweld
I'm the dumbfuck that originally posted the 160 hours number. The only thing I'll say in my defence is that it was written in October 2008, two years ago. It certainly didn't take into consideration the many hours of development that have been done since, and the hourly rate was based on actual searches I did on freelancer sites.
I wasn't actually high. Just stupid. If there were a way to 'unaccept' an answer I'd have done so long ago. The user 'schwa' corrected me long before chockenberry noticed.
Wow, I hadn't noticed the time difference between the original thread and Chris's reply, thanks for pointing that out. I honestly don't think your estimate (I gathered that two months was more realistic) was that bad to get a first cut of a simple app out the door. I have never seen Twitterific but to your point it looks like it went through a fair number of iterations over the course of several years, plus a ton of design work, which you were not trying to account for.
I was discussing few days ago with someone who "work in IT" a project that he wants to get done. It's a Golf amateurs related website (JS/PHP App). I have told him that everything is simple and ready [can be found somewhere] (user login, querying a database, Image manipulation, user comments...) but the hard thing is putting all the functionalities together and making them really WORK. I estimated 1,500 USD, which I think quite low (pricing myself at around $15-20/hour), but I'm just starting and no kind of professional.
He thought it's quite high and he said he don't think such basic functionalities are quite hard to do. Yes, they are not. But testing, deploying, IE bugs, polishing and fixing are very expensive.
Software development is expensive, Polished Software is frikin' high expensive.
You need to price yourself higher. While $20 for you may be a lot (as I thought it was during school), for a reputable firm this is nothing, and it means you won't be taken as seriously. This manifests as them often wasting your time in terms of developing features they don't really need. This is probably going to happen in any software project, but a higher per hour cost makes people think about your time in a better light.
Also, get a retainer. Took my 18 months to get money from a friend's company once. Retainers get rid of so much BS.
If you're doing the work for a flat project fee, ask for 20-50% of the fee up front before doing any work. If you're going to be paid hourly, you probably would have provided at least an estimate of hours that the project will take. Your retainer should be 20% of the total of your rate times hours estimated.
Always request a retainer. Especially for new clients. Even more so for friends and family.
I either take 50% upfront or ask for Odesk. (Odesk will guarantee payments for hourly work).
I already figured out that I either get to the top (+$50/hour) from the first time or I stay low balled to $10-15. So right now, I'm improving my skills and building a portfolio.
That depends though, if you are in school and your alternate job is flipping burgers for around the same pay it is more attractive. Sure you could get more but there is a lot more in running proper professional freelancing, if your learning along the way and your client knows that life/ school will get in the way frequently it's a decent deal.
Of course one you get to the stage of having a business with all the proper overheads and spending fixed hours with good programming knowledge it becomes next to nothing pay.
Eh, even as a student, when your price range is putting you on par with lawn-mowing services, you're going to run into a lot of time-wasters and fools who think you ought to do it for a six-pack and the opportunity to wash their car. Hence the aforementioned "guy who wants a custom web application and thinks $1500 isn't a steal of a deal".
Raising your rates will winnow out the chaff and get you doing more serious projects that will look better on your resume.
It could, it could also hit you with people who expect you to drop everything, even if exams are on or assignments are due. Not saying this doesn't happen on the low end to but you can at least say to decent people that your lowering the rates to have more flexibility.
I come across a guy with the same sort of attitude when I first started, occasionally hit up hes website to see if it ever went anywhere after I realized the work was dead end, it didn't.
It's another of those situations where duplicating a polished application like that could indeed take 160 hours. It's downright easy when it's in front of you. You could probably do it in that time frame while learning a new language and a new framework to implement it in.
Discovering what constitutes "polish" for your application takes enormous amounts of time, iterations, failures, and attentive and intelligent developers / designers.
I'm not sure I agree with you here. I think in general, if you're straight up cloning an app, you're probably missing out on what makes people like the app in the first place. Or you just don't care, and you're trying to shove something out the door as fast as possible.
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.
Keep in mind, they are assuming an hourly rate of $150. However, this does put into perspective any jerk offering 5% equity for a developer who creates their "simple iPhone app."
Where do people get customers willing to pay $150/hr? Or is it a san francisco/new york thing and for the rest of north america/europe it's more like $50? (canadian here)
If you're in any of the big cities and your rate is significantly under $100/hour, you're probably under-charging if you've got decent experience and rep and are doing something heavily in demand, like mobile work.
$150/hour for devs as well known and with as good a reputation as the twitterific guys is pretty much par for course.
I recently increased my rate to €80/h (~$113). I lose some customers that way, but I don't think I've hit the glass ceiling yet. Saying that, I'm trying to get out of the contracting game.
Consider Matt Gemmell's answer on his 5/10/20 yr plan below. For those who don't know, Matt Gemmell does bespoke high-quality UI.
In fact, the whole Q&A thread is fascinating.
> What do you see yourself doing in 5 years? 10 years? 20 years?
In 5 years, hopefully earning a full-time living from software products rather than contracting. Beyond that, it's a stab in the dark, but I'll have a go: in 10 years, focusing on writing, speaking, mentoring and such (still within this field). In 20, ideally back in academia doing research and teaching.
> The common factor is probably that you should only pursue things you really, really care about (whether it's romantic partners or your actual job). Life's too short for anything less, and finding something/someone great is a lot easier than you think.
I'll be releasing something soon (with the help of a co-conspirator) to take baby steps in that direction. Larger products are also in the pipeline. In hindsight, contracting probably made getting to this stage harder (slower) than having a 9-5 job and working on my own stuff in the evenings/at weekends would have been. Especially early on, I was often 2 weeks from running out of money, and I still occasionally screw up estimates. Still, I've learned a lot in the process. Working up a buffer has certainly been hard this way, particularly with the insane tax & social security rates here.
Longer term, there's no way I'd realistically be able to be a mere employee without going nuts or locking myself out of the job market. Job hopping (I get bored with jobs that don't progress at my pace so quickly) looks terrible on the CV, contracting seems to be fine.
I'm based in Jacksonville, Florida. All of my work is freelance telecommuting though, and my standard rate is $125/hr. And I have no trouble finding work.
Already successful companies rarely can hand out 5% shares just like that, the existing shareholders probably won't have it. I'm fairly sure the OP is referring to "5% of app profits" offers, i.e. shares in a yet non-existant enterprise. You'd effectively be acting as an angel investor in a company run by someone who won't actually do anything. (investing time rather than money)
I am so glad to see someone that is not totally full of shit answer the "how much did x take to develop" question. I have made a few iPhone apps and I am always amazed by the low time estimates that non-iPhone developers give. Also, keep in mind that these are really good top notch developers. Double his time estimate for idiots. I probably fall somewhere right in the middle.
Unfortunately the underestimation of time behind technology is nothing new and not just an issue with mobile development. We get the same thing at work nearly every day. People come in, want a 50 page website designed from scratch, branded, built on a CMS, and programmed with lots of forms, Java functionality (simple jQuery stuff usually), and SEO and expect to pay $1000. When people like this come about, it's the professionals job to educate the client and help others understand how much really goes into development. Looking at a "simple" app or website that they'll spend minutes on (or more in some cases) makes it very easy to think, "Well it took me 60 seconds to navigate this page OR I picked this game up in a few minutes and beat the first couple levels, therefore it must have been simple to build."
I know people who increase (>= 2x) their hourly rate if they're expected to do the same amount in half the time because of a deadline. Who's to say that Iconfactory doesn't do something similar?
I wish there was more awareness in the general business community about how much effort goes into developing mobile apps. So few potential clients I encounter fully realize how much work goes into it, and when you give them an estimate the gap between their expectations and reality is glaring...
My first iPhone app was feature complete in about 20 hours. I've since spent an additional 100 hours on better graphics, better design, performance enhancements, and other polishing.
I haven't added a single new feature yet after the initial 20 hours, but the app is obviously much MUCH better and easier to use.
Wow, some of the comments about the costs there are flat out insulting. A well done app is going to take time and money to create and polish, and a simple app is almost always anything but simple. Twitteriffic is a well done, "simple", polished app, and $250k seems like a good number to me.
Personally, I'm still learning how to bill my time out properly. I've got a serious case of underestimatitis. Maybe Craig's numbers will help me understand how much time I really spend on a project.
One common technique used by agile methodologies (yes, I know that word has a ton of baggage) is to estimate in terms of story points rather than actual hours, days, etc. You start out thinking of a point as "one ideal day of uninterrupted work" to use as an anchoring point, and then for any work you want to do you break that work down into stories that you can estimate work for. If the story is bigger than about 3 points, you break it down further; if you can't estimate it, you do more research so you can.
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.
What level of granularity are you using in your estimates? Are you just calculating a number for the whole (eg "I think that will take 120 hours") or are you also breaking that down as much as possible? I've found that if I can get an estimate broken down into tasks of <10 hrs/ea then it actually turns out to be pretty close.
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.
I've been doing the former, and it definitely needs to change. I'm obsessing more about tracking my time to help me with future estimates, for one. I will also try breaking down into finer granularity and hopefully that will help as well. Thanks for the advice!
Personally, one thing I've found that helps with estimates is to think in terms of days instead of hours, and to assume a fairly low productive amount of hours (5) within each day when converting back. (Yeah, you'd hope to be productive for more than 5 hours in a given work day, but there are a lot of little things that steal your focus and eat a lot of time away from your project without you realizing it. Fail to account for them at your peril).
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.
Unless we are talking about templates and cookie-cutter apps, this whole thing has little meaning.
Really good stuff is done by hackers and painters, therefore when you estimate your costs, you only tend to see the canvas and a little gouache, which are a commodity—just like computing. And perhaps some of your time, most surely, if you don't have a good time doing it.
Saying, that the painting of a picture costs X€ is about a code monkey who has no idea about what the real work is truly about.
But yes, management does have an interest in the devaluation of productive work to leave room for their own overhead. There are thousands of apps out there in the world, and from that perspective it is nothing but throw-away-junk, warranting a low price.
Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?—Alan J. Perlis
Those who compete with slaves will also become slaves.—Norbert Wiener
In comparison, the first version of Dayta took a week of around 12 hour days. At $100/hr (I think you could find someone great, who works for that rate or less- hint: students), that's less than <$10000.
Of course Dayta is much less of an endeavor, but don't be phased because of the price of developing one of the best iOS apps out there.
This is 2nd order conventional wisdom. No doubt maintenance of an app takes time and effort. But the numbers thrown around assume high hourly rates for all involved. The only real cost is time and a grad student living on ramen can knock out something pretty decent in a month or so (less if they already know Objective-C).
And I've seen many spaghetti messes that had to be cleaned up by full-time "developers" who cared more about getting paid than if their code worked, let alone if it could be maintained.
This is true, there are many crappy developers out there. How do you find the good ones that take pride in the quality of their work? I don't know, except to say if you don't haven any technical know-how the best way is probably the same you might find a good plumber or auto mechanic or dentist or lawyer or any other professional service, hope you get lucky with some good references. I never hear people looking for those services ever saying "screw it I'll just get some cheap kids with no experience".
This is unfortunate - that seems like a lot of work for a relatively simple, albeit well-done app.
I might have to think twice about whether I want to do an app to complement a webapp I'm doing in my spare time (no prior experience on iDevice development).
Don't let a professional app like Twitterrific discourage you from taking a dive into iDevice dev.
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.
I hope I didn't confuse... that should be anti-crack kit. Specifically the kit uses various means to detect if the application had been cracked.
When applications are cracked there are various tell-tale signatures that are left behind such as modified plist files. These signatures are detectable by the kit, which I can check on via a call to the kit's "isCracked()" method. I collect this statistic, and if I wanted to could cripple the app.
Is there no way to validate code-signing on your app bundle? I would think that would still work even if the signing requirement was patched out of the OS.
It would take me as much time to do a Rails app well as it would for someone who has as much experience in Objective C as I do in Rails (that is, not nearly as much as I do with Cocoa).
I think you'll find that's actually pretty damn efficient for such an app. If you add interaction with a client changing their mind, etc (v. common..) then it could easily be higher. Much higher.
Hear hear. The user interface for my first app took me 3x as long as I expected, despite finding (unexpectedly) that Cocoa Touch to be one of the nicest API's I've encountered. It was because I re-built it several times to make it feel "right", and after watching users try it. Each time it got simpler. It probably only took a few days worth of coding for what went into the final app (the editing interface, not the whole thing) but the road to get there was long. I guess that's the value of an experienced UX designer -- they can do that work beforehand with paper and intuition.
The simpler you make something, the more perfect the execution of each of the remaining elements have to be, because your attention is now laser-focused on them.
A great read, but shocking in how much it costs on the App/dev/Infrastructure side. Each app seems like a startup in itself, yet, the risks seem far greater.
Are the dev tools that bad that it costs that much, and requires so many people, to produce a concept to result?
Writing a simple table view based app can be done in a night.
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).
I agree with the poster, but doesn't $150 an hour seem unusually high for a freelance developer? It is equivalent to about $300k yearly - no developer makes that kind of money by programming alone.
Not only is the lack of steady work a problem, but also there are other costs of freelancing that people don't consider when employed. I have to be pretty careful about additional taxes, cost of equipment and other necessities (everything from my own computer and software to desk, chair, internet and more), and especially for me, health insurance in CA where I have preexisting conditions that insurance companies hate. (And yes I've done my research on group rates and such...that's yet another thing I have to do that I wouldn't have to worry about as much if I were employed.)
So yeah, I might seem ridiculously expensive when I go bill someone at $200/hour, but I make nowhere near $300k and out of what I do make, I don't get to save a lot after paying all the bills. But in exchange, I get a lot more freedom when it comes to working, which leaves room to do other things in my life. It's a tradeoff I'm willing to make because I can find fairly steady work, but I would never do it if I had a family or if making money was my sole objective.
Okay now I wonder what they spend that time on, because I would never have guessed it took that long. Is it because it takes so long to get anything done in Objective C? Most IOS apps don't have that many features.
What's with everyone thinking Objective-C is inefficient (in developer-hours)? I have found it to be very easy to use. Granted, it does have its warts that make coming from a language like Ruby somewhat painful. But I second Craig's comment that "the notion that [the high number of hours burned] is the language's fault is laughable."
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.
Once you're into the territory of building custom UI controls, effort starts going up, up, up. I've found the existing UI classes to be perfectly good for their intended purpose, but try extending them and they'll frequently break, requiring either a rewrite or late nights of debugging (and you don't get UIKit's source). This is particularly deadly when doing contract work and the client's designer is used to web dev, where you can often hack around stuff. On iOS, "trivial" design changes sometimes cause major headaches.
The other not-so-obvious complexity here is probably the data model, which seems far from trivial, especially given the constrained memory environment (lots of images, etc.).
Objective-C is a bit irritating in it's dictionary & array/list syntax, it turns something that would be 20 characters in python or even java into something that is 100-150 characters. Similarly in string editing and xml parsing. TouchJSON works very quickly, but then you run against the obtuse array & hash table syntax when using it's result. Give us smalltalk binary & one character operators! The obtuse syntax hurts readability too.
I put these two macros in the prefix header for every Objective-C project I do. Say what you will about single character macros, these save me time and improve readability (for me, anyway... I'm not sure how others reading my code down the road fare, but so far there haven't been many of those).
Well, Twitteriffic for Mac still was unable to do retweets last time I checked. Ditched it for TweetDeck. I know this is kind of off-topic, but after seeing these large figures they are moving, I feel something close to unimpressed.
