
Dear business people, an iOS app actually takes a lot of work - kentnguyen
http://kentnguyen.com/ios/what-does-it-take-to-make-an-ios-app/
======
rickmb
This is a general problem with custom software, not just iOS apps.

Most businesses outside major corporations didn't start commissioning custom
software until the rise of the commercial use of the internet in the late
'90s, when all kinds of small and medium sized businesses wanted their own
website. Websites were relatively simple back then, and the people willing and
able to make them cheap. Hell, even though I was already a professional
programmer for years, back in 1994 the idea that someone would pay a few
hundred bucks me to make a "homepage" was just cool enough in itself.

Websites became more complicated applications, no longer something hobbyists
could do on the side, and became more diverse, including apps for specific
platforms like iOS. The cost of having an online presence has multiplied many
times in less than a decade because of the sheer amount of work involved, and
the level of professionalism required these days.

But most businesses don't commission software ever few months, or even every
few years. So every time they want a new app, or a refresh of their website,
they are suddenly faced with a shockingly high price tag compared to the last
time they wanted something similar (or at least similar from their
perspective).

And we're only just getting started. The shortage of decent developers has
only begun to translate itself into higher costs. Most employers are still
rather conservative in the current economic climate, and developers are
notoriously bad at selling themselves.

~~~
kls
There are 2 points we also have to consider when specifically talking about
the custom development market, one is that advertising development houses are
not helping the issue by putting out teaser ads like _Get your iPhone app idea
built for $5000_. It sets pricetags in peoples minds that are unrealistic.
When you get down to the fine print, if the app requires communicating to REST
service or design work that numbers is out the door even with the advertiser.

The second being many times custom development shops don't weigh customer
needs with COTS. For example in our shop we many times have customers that
come in looking for a web presence. When we analyze their needs, it is
apparent that Wordpress and a template will fit the bill and get them to
market the quickest. I am not a huge fan of PHP on a personal level, but if
Wordpress fits the bill I would be doing my client a disservice to not steer
them down that path. I think for quite a few custom development shops
everything looks like a custom development problem. I think if they would take
the time to learn some of the cheaper solutions that will work for lower
budget clients, then they can offer a product portfolio that matches the
budgets of the client.

~~~
rickmb
The latter is exactly what we regularly do. It's still a pain though, talking
a client down from their original ideas (sometimes piles of paper with all
kinds of ambitious features) to something that matches their needs within
their budget.

Plus, these often turn out to be not particularly desirable clients that take
up a lot of time, and there isn't sufficient margin on simple WordPress jobs
to give such clients the same amount of attention as on major custom projects.
It's very hard to make these clients happy with off-the-shelf solutions yet
still make a bit of profit.

COTS helps, but it doesn't cover the gap between client expectations and
reality. It's more of a "better-than-nothing" solution.

And don't even get me started on the cost of maintenance and upgrades. You
don't want to have a few dozen outdated leaky WordPress sites in your
portfolio, let alone a hacked site associated with your name.

~~~
kls
For us, we have a guy that manages all of these type of contracts. It's kind
of like an entrepreneur in the making kind of arrangement, for him. I agree on
the hacking issue, which is why we personally don't host Wordpress sites and
the person that handles Wordpress size clients makes it very clear that
Wordpress provides the platform, security and all, that we provide the design,
customization of template, SEO, analytical, etc.

While there are a lot of pain-in-the-rear small clients it is not unique to
them nor are all of them pains. We have had a lot of small clients turn into
large clients as well, we have had a lot of small clients refer us to large
clients. How we personally made it worth while was to find a person that
wanted to grow a company, but offered them the advantage of doing it from
within a current company. This person is now, managing Wordpress (Drupal and a
few others) for several shops like ours. He also receives a commission when
one of his clients outgrows him and is ready to move into custom development.
It has worked well for us, but it is by no means the bread and butter, but it
does save a lot of time by not spending cycles with people that just flat out
can't or won't spend the money to pay for custom software.

------
wtvanhest
As a "business person" I need to know three things to hire someone:

1) how much did it cost other people to build similar apps (comparative
analysis) 2) that you are able to build the product successfully (reducing
technical risk) 3) that the price is low enough that the estimated Rev will
produce a return (ROI)

\- If you can present those points clearly you will be in a much better
position to make more money with less frustration

~~~
kls
I don't disagree with you but I think ROI is a business owners case to make.
You know your projections and it is up to you to take what I say it cost to
fairly compensate me and see if it matches with your expected ROI, if it does
not, we can negotiate, if the numbers are not there, then they are not there.
But I don't think it is on me to prove out your ROI. Chances are you already
know this number, before you even start soliciting bids. Now if I come to you
with the idea, sure I would expect to have to prove the case as to how it will
benefit your company.

~~~
wtvanhest
Agreed. You can help the business person pay more for development if you can
help them maximize revenue or lower marketing costs (or some other outside
expense)

If you think of development as using technology to scale down cost or scale up
revenues there is plenty you can add as a developer to the ROI discussion.

------
zavulon
This is a message on NY Tech meetup mailing list, from about a half hour ago.
All I could do is shake my head.

_____________

I am seeking a telephony app. builder that can deliver a PhoneGap lie ( non-
native) inexpensive app. for a telephony project.

pay is:

$350 \+ 1% equity stake in a newly formed Delaware Corp. and 2.5% on all
residuals. possible board seat (future paid projects)

if you can deliver an additional investor, you can get 5% of the transaction
on the capital raised through you contact.

~~~
funkyboy
This is the worst I have seen. In the past I have been proposed around 1000$
but this wins, hands down! The world is getting crowded of last minute
entrepreneurs...

~~~
yummyfajitas
There are far worse. If you live in NY, you've surely run into Eric Leebow of
FreezeCrowd:

[http://nationaljobs.washingtonpost.com/a/all-
jobs/list/q-fre...](http://nationaljobs.washingtonpost.com/a/all-
jobs/list/q-freezecrowd)

<http://www.youtube.com/watch?v=dQx_pJyyyxc>

"Unpaid iPad Intern wanted to build a facebook killer."

~~~
ootachi
The depressing thing is that I suspect someone will actually take him up on
his "offer".

Isn't that pretty much illegal anyhow? Unpaid interns are not supposed to
actually create products.

Edit: It almost certainly is; part of the conditions for unpaid internships
are that "the employer that provides the training derives no immediate
advantage from the activities of the trainees, and on occasion the employer’s
operations may actually be impeded", and this is clearly false in his case. In
other words, that job posting is not only immoral, but illegal.

------
algoshift
Multiple reasons for this:

First, too many stories along the lines of "I built this app for $1,000 in
India and it is making me $50K per month".

Second, kids who don't know how to value their time who'll work like slaves
for $2,000.

Third, bad programmers who deliver product cheaply enough, however, the
underlying code is an absolute mess. They charge nothing, throw it together
and move on.

Fourth, people tend to come up with an idea of what it is that they want to
pay for something and try to fit that something to that number. When it comes
to software that's like the square-peg -> round-hole problem. I've been to
countless meetings where the other side says things like "We'd like to do this
for no more than $10K" ... and then they describe an intense six-month, four-
person job.

You can always try to educate. Sometimes that works. It can be painful. What
you don't want to do is be the educator and have someone else walk away with
the work for less (even if it is 1%) than what you would charge. So, don't
invest any time unless you know that there's a really good probability of
getting the deal.

~~~
sirrocco
> Second, kids who don't know how to value their time who'll work like slaves
> for $2,000.

That's not always the case - if you manage to work $2000 /8h/day/month in my
country , you're already being paid in the top .. 10% programmers.

Money has a different value based on location.

~~~
uptownben
> Money has a different value based on location. I have a hard time
> understanding the mentality behind statements like that. While currency may
> have different values based on location, time, effort, knowledge, experience
> shouldn't be so different in value. Don't you agree? I don't want to single
> out any countries, but just as an example, let's say American developers
> typically charge ~US$100 per hour, why would Indian developers charge
> US$15.00 (or vice-versa) for the same work? Doesn't that kind of "race to
> the bottom" simply de-value the profession and make things harder all
> around? If you have made the investment of getting educated, learning the
> technology, learning the business and can produce; you should be charging
> and getting paid accordingly, depending on the market, not your local
> currency or local minimum wage. When dealing with your local market, you
> will need to take local rates into consideration, but I don't see any reason
> to apply local rates and limitation to an international (Internet) market. I
> would genuinely like to know if I am completely off base, and if anyone has
> more insight on this.

~~~
biot
You can live like a king in India for a few thousand dollars a month. In San
Francisco, you'll be lucky to pay your rent. As a result, those developers in
India are happy to ask for less if that results in them getting the work since
$2K/month in India buys them the same (or better) lifestyle as $2K/week in San
Francisco.

Besides which, they're competing against all the other workers in their
country. If someone charges $50/hour and gets a lot of work for a similar
skill set as you, wouldn't you try charging $45/hour to get the business? If
the supply of workers is high and the demand for those workers is low, it does
become a race to the bottom. Additionally, they must charge less than their
American counterparts because of the inconvenience of being in a timezone
where the start of the day in India comes after the end of the day in the US,
the language/culture barrier, legal considerations (if someone rips you off,
you have better legal options available if they're not half a world away with
a foreign court system), and so on.

I'm sure if they could still get the work and charge more they would. However,
consider an American-based company wanting development work done. If they have
a choice between a $100/hour American worker and a $100/hour Indian worker,
odds are very good the American will get the work for all the above reasons.

------
waterside81
Our app (shameless plug: itunes.apple.com/us/app/little-
heroes/id477247738?ls=1&mt=8) cost $15K to make by a Toronto-based developer.
We were able to keep the costs that low (I think that's a pretty good price
for a better than average iPad app) because (1) all of the art was done in
house and (2) all of the server side functionality was done in house. Our app
developer _just_ had to wire up the various pieces. (I say _just_
sarcastically, it was still a lot of work).

If you have to outsource the entire cost of development, and you want a good
looking, well functioning app, it's very expensive. And then there are the
inevitable upgrades, improvements etc.

~~~
reidmain
So $15k was the cost the iOS developer charged you?

What was the cost of having the art assets and server side functionality done
in house?

Adding that to the $15k seems to be the actual cost of the app.

Also how much time was spent designing the app before art assets were made or
server side programming started?

~~~
waterside81
Right, that's the point I was making - if you had to pay for those services to
an external party, the cost goes up, quickly.

I did the server side work, my co-founder did the artwork, both at a > 0
opportunity cost I'm sure.

We designed the app ourselves, again, at some non-zero opportunity cost.

~~~
reidmain
But what is the app worth? This sort of creative accounting is the problem
that this article is trying to highlight.

If you strip out all the bullshit making an iOS app is going to be expensive
because you can't cheat time and everyone's time is worth something.

If you mention to someone that you made your app "for only $15k" this just
compounds the problem because that person has a skewed perception of what an
app is actually worth.

------
blahedo
This problem not only isn't unique to iOS dev work, it's not even unique to
programming. _Any_ custom work, from carpentry to bespoke tailoring to
artwork, is more expensive than most people expect, even when they account for
custom work being expensive. For instance, I knit, and have been asked more
than once if I'd accept a commission (for, say, a pair of socks)---and when I
decline, and say they couldn't afford it, they almost invariably throw out a
number like $60 or $80, very expensive for a pair of socks but _a small
fraction of minimum wage_ for something that could take thirty hours or more.

The problem is that so much of what we buy is mass-produced that we forget
just how expensive person-time is, especially creative person-time, since for
most modern products this gets amortised over hundreds or thousands or
millions of units. Even user-facing software has this issue, since the
programmers do their work once and then the marginal cost of each additional
copy is pennies or less. But custom work? There the cost is borne entirely by
the one commissioning the work, and if it's an individual, or a small business
or startup that has never had to purchase enterprise or custom software, they
simply have no analogous experience, with software or anything else, of
bearing the entire cost of everything.

~~~
yock
My wife crochets and several times we have looked into what it would take for
her to run a side-business with her talent. We always get stuck on the task of
selling these at a price that makes sense given the time and effort involved.
Others make it work, for example on Etsy, but I can't help but wonder if
they're practically giving away their works or if there really are those who
can throw together a blanket in a day.

------
mirkules
I agree with the overall sentiment of the page. A few questions to seasoned
iOS devs:

"With websites, you can simply add one more page, then create a link to that
page when you needed. However, you can’t do that with iOS app, everything has
to be set in the beginning, any changes might result in significant other
changes that you might not be able to understand why."

Isn't this what the Navigation Controller is for? You just push a view
controller onto the stack, and pop it when you're done.

Regarding the UITabBar: "if you want colors icons instead of the blueish tint,
the change in code is substantial!"

I have been using this method, which is not really complicated:
<http://sugartin.info/2011/07/01/customizing-tab-bar/>

You need to make images for the bar in both orientations (if you need it). The
only time-consumer is the "more" button, for which you'll have to create a
custom UITableView -- and still not have the handy "edit" command to rearrange
the tab bar buttons.

...unless this is the wrong method to use, in which case I would love to see
an example of the right way to do it.

~~~
zedwill
I believe he might be talking about modifying a view, as he presents the
example of adding an email button or a facebook one.

It still doesn't make sense as you can use tools such as Interface Builder.
The only thing that applies, you could still be building the view
programmatically or need custom animations. That needs coding. And of course a
facebook button needs to handle things such as authentication than an emailing
one does not.

About the UITabBar, you can always use the black one. Or use this little trick
for greater effect which is less demanding on custom images:
[http://stackoverflow.com/questions/571028/changing-tint-
back...](http://stackoverflow.com/questions/571028/changing-tint-background-
color-of-uitabbar)

I also do apps for a living and it is true that business has unreasonable
expectations on time and cost. Not to speak of the myriad of people that want
a whatsapp clone for 500$

~~~
pmjordan
_It still doesn't make sense as you can use tools such as Interface Builder._

I was bitten by this on my first major contract iOS app, so I think I know
what he means. Interface Builder will get you most of the way fairly quickly,
which is deceptive.

Then you start refining to try and match the photoshop mock-up for visual
design, and find the built-in UI classes don't handle this. Buttons not
supporting labels below an image by default, or multiple buttons next to each
other on the navigation bar, or a background that moves with a table view,
etc. etc. [1]

You get to work on custom subclasses (or adapting some open source ones).
Interface Builder doesn't let you set properties of custom views, so your view
controller starts being filled up with all sorts of stuff that really should
be in the nib file.

Then you find out that actually, various labels and text views need to support
multiple lines of text. This messes up your beautiful layout from IB. Struts &
Springs are now useless for half your screen elements, and you put custom
layouting code in a custom container view's _layoutSubviews_ method or your
view controller just to push stuff down the screen and resize your scroll
view's _contentSize_. The complexity of this layout code grows for every
supported orientation and device type.

Your NIB files are now a mere shadow of their existance at the beginning of
the project, so at this point, making a change to move some views to a
different screen (is that only on iPhone/iTouch or iPad too?) is no longer a
trivial exercise at all.

Yes, it's all manageable. But there's a whole range of sudden complexity bumps
at "80% done" where the existing tools leave you stranded. If you originally
quoted for functionality covered by IB but then need to customise it, that
will take a lot of time, and you'd better have budgeted for it.

[1] The situation has improved somewhat with iOS5, which makes supporting iOS4
(let alone 3) devices the IE of iOS development.

~~~
DougWebb
Thank you for this description. I've done a bit of Android work, but no iOS
work yet. Most of my career I've done web apps, and my recommendation to my
company is to do web apps instead of native apps for all of our mobile
projects. You've reconfirmed my suspicion that native apps get into a lot of
hidden complexity that's not apparent from the "Hello World" tutorials.

------
hello_moto
Most enterprise projects don't want to pay for usability. That's the bottom
hard cold fact.

Enterprises want to move fast, if they can, but they can't because of the
mistakes they've done in the past were covered with more processes to make
sure that 1) it didn't happen again and 2) if it happened, we can blame the
process.

Sometime engineers don't understand 2 facts:

1) You will get fired if you made mistakes

2) You will make mistakes

So people tend to hide and blame "processes" to avoid firing.

CEOs are cold blooded firing squad. Just like "Businesses". What matters are
profits.

Business people will wear a very thick layer of skin and try to pull
unimaginably stupid statements to push the price down ranging from "I thought
Facebook was done in a weekend" to "It shouldn't take a day or two to fix a
'simple' Database issue. You just go there and change the data"

~~~
wallflower
> Database issue. You just go there and change the data

I have heard stories of how very large financial institutions never ever
delete a database column from a table, they just keep adding columns. They
will not delete a data column for the very real fear that mission critical
applications will stop working properly or fail silently.

~~~
rwallace
Which is a very wise policy. It's not like deleting apparently unused code
that you can get back from version control if you turn out to be wrong. The
cost of carrying a hundred unused columns around forever is negligible
compared to the cost of deleting one that turned out to be still used.

------
rockarage
ios is a lot of work, programming in general is a lot of work. It is 2012 not
1992, business people in all fields should know programming is not cheap.
Business people who do not do the research, don't bother with them. Avoid them
at all cost. I've learn the best clients are the ones who value your work and
are willing to pay for it. Their is a shortage of great programmers.

~~~
cryptoz
> It is 2012 not 1992

On the other hand, think of what you could accomplish with a weekend of work
in 1992 and compare that to 2012. Our abilities as developers/designers/etc
are vastly improved due to improved infrastructure, tools, communications,
resources, etc.

You _could_ build a distributed photo hosting and viewing application back in
1992. But you'd probably be writing it in C++ and it might take you a long
time to get something that even works, much less looks reasonably okay and
attracts an audience.

Now in 2012, you could hack that together in a weekend. To make it a real
project may take a few weeks or months, of course, but the pace at which we
can build things is indeed speeding up.

~~~
mechanical_fish
The problem is that once we make 80% of the process vastly more efficient, all
it does is throw a spotlight on the remaining 20%. (This is the unheralded
dark side of the Pareto principle. ;) Not _everything_ about building an app
gets more efficient with time.

You can now throw together a photo-hosting and viewing application in a couple
of days. But that doesn't necessarily yield a site that runs itself. Teaching
the customer to use the code still takes about the same amount of time.
Editing the theme over and over again, iterating a design cycle that
incorporates emails and meetings between you and the customer and the
designer, still takes about the same amount of time. The process of moderating
the uploaded photos to screen out the spam and porn still takes about the same
amount of time. Usability testing still takes the same amount of time.

(And even in the enlightened year of 2012 there are still standard things that
all sites could use, like proper reverse-proxy caching and solid backups, that
over half the Wordpress blogs on earth seem to be lacking. Apparently we're
not even done automating the things that could be automated.)

The other problem is that if the customer steps off the well-worn path they
will fall into a very deep pit lined with invoices. If Wordpress does it out
of the box, it's cheap. If Wordpress _almost_ does it out of the box but it
requires even the smallest amount of custom coding, it's expensive. And
knowing what things are expensive and what are standard requires skills that
customers don't have, so they have to pay a programmer to advise them, and
_that_ is itself inefficient and expensive...

~~~
Tossrock
> The problem is that once we make 80% of the process vastly more efficient,
> all it does is throw a spotlight on the remaining 20%. (This is the
> unheralded dark side of the Pareto principle.

I think this might be better referred to as the well-known outcome of Amdahl's
Law: <http://en.wikipedia.org/wiki/Amdahls_law>

~~~
mechanical_fish
Agreed, but if I'm going to jokingly but inaccurately name-check a principle
involving the number "80%" I might as well pick on poor Pareto. He's used to
it by now. ;)

------
casca
This is completely false. Only a decent iOS app takes a lot of work. A crappy
one can be done very quickly and cheaply.

~~~
waterside81
I think it's a safe assumption to make that the author was talking about
building high quality apps that one can be proud of.

~~~
kruhft
> building high quality apps that one can be proud of.

And that's the problem right there. The developer is not being paid to do
that, they are paid to finish the app that was asked for as quickly and
cheaply as possible, at least from the client's perspective. Of course they
_want_ a high quality app, but are not willing to pay the price, so most
development ends up being shovelware. But it is work, just not the most
glamorous work that one can dream of.

------
sunchild
I get where OP is coming from, but I think this sort of overstates the case. A
well designed app would leverage the existing APIs and UI kit.

The iOS and Cocoa Touch APIs are really robust, and with libraries like
RESTKit, it's not _that_ big of a deal to whip up an app that works well.
Indeed, I've done it a few times myself.

The problem is that no one is ever satisfied with the UI kit that Apple
provides. Browsing Navigation views of Tables, and doing simple CRUD to a
simple backend (e.g., Rails on Heroku), is a weekend project, IMO.

I think OP is really talking about how unrealistic people's
expectations/requirements are – not how difficult it is to make a working iOS
app.

------
adelevie
So there is high demand for iOS apps (the "business people" are clamoring for
them) and "50%" of the project (the backend) is a total PITA. This is the
recipe for Parse/Stackmob/Cloudmine/etc for ruling the world.

------
pashields
The author hints at, but doesn't push the issue that the cost is all really in
the customization. If you were to build an app using only standard apple
components, the cost would be significantly less (at least 2x). Those custom
components take a lot of effort, particularly when you end up hacking Quartz.

A quick example, I implemented a very good looking custom badge system for an
app. The result looked just liked design, could be generated programmatically,
and worked like a charm. It also took me a couple of days to implement the
whole thing in quartz. If I were doing this as consulting, that's a $2-3000
feature. These things add up very quickly, particularly if someone wants to
"try a few out."

------
Jabbles
I have no experience designing iOS apps. Could someone explain briefly why
they are so inflexible?

 _Tightly integrated code: With websites, you can simply add one more page,
then create a link to that page when you needed. However, you can’t do that
with iOS app, everything has to be set in the beginning, any changes might
result in significant other changes that you might not be able to understand
why. The way iOS codes are structured is like a breadboard, everything is
hard-wired, you still can change a few things here and there, but if you
change the wrong wire, the whole board might stop working. Even extremely well
structured code does not increase the flexibility by a lot. Adding an
additional email button to ‘About’ screen might only be worth a few more lines
of code, but adding a Facebook Like button on the same page is a different
story, don’t expect that to be done in a few hours._

~~~
justinvoss
The author may be overstating how rigid they are. iOS apps can be much less
dynamic than web apps, mostly because you're working at a "lower" level in the
GUI stack. Instead of having a layout engine that recalculates the positions
of your UI elements for you (eg, HTML and the box model), you mostly have to
manage the position and sizes of everything yourself.

You could create your own layout engine, but most developers choose not to,
especially since the consistency of iOS hardware means they can predict screen
sizes easily. Your other option is to make your app a thin wrapper around a
Webkit view, but that tends to produce poor results (see the Netflix iOS app
for an example).

~~~
randomdata
> Instead of having a layout engine that recalculates the positions of your UI
> elements for you (eg, HTML and the box model), you mostly have to manage the
> position and sizes of everything yourself.

I'm not sure that is strictly true. The autoresize model[1] will cover a lot
of cases. The place where it does break down, and where HTML does shine, is
with variable sized data such as paragraphs of text. However, that is starting
to encroach on document territory anyway – meaning you'll probably want to use
something like UIWebView to display that data.

Anyway, not trying to point out the obvious. I've just noticed that not all
iOS devs are even aware of the autoresize functionality, so I figured it was
worth noting.

[1]
[http://developer.apple.com/library/mac/#documentation/Cocoa/...](http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaViewsGuide/WorkingWithAViewHierarchy/WorkingWithAViewHierarchy.html#//apple_ref/doc/uid/TP40002978-CH4-SW12)

~~~
justinvoss
I'm definitely aware of the autoresize tools, but like you said, as soon as
you start to have variable sized data it all sort of falls down. Then you wind
up having to switch to using a UIWebView, which means redoing a lot of work.
It can also be a huge headache to support both portrait and landscape mode
with only the autoresize tools.

------
Aqua_Geek
> These APIs must be in existence before you can proceed to make the iPhone
> app.

I disagree. Yes, it's nice to have everything in hand when you start, but I've
built multiple apps concurrently with the backend development. The trick is to
isolate your networking in the model layer (a good practice regardless of
whether or not the API is already done). This allows you to stub or use dummy
data until things come online.

~~~
Czarnian
You're right. The APIs don't need to be implemented, just documented.

I'll go you one further. It's better to work without a functioning API. With
stubs and dummies, you can tightly control inputs and test way more
effectively. If you're developing against an active api, you add a whole level
of complexity that makes it that much harder to debug. I don't know how many
hours I've wasted trying to find bugs that turned out to be outside the scope
of what I was working on.

------
mbesto
My company builds enterprise grade apps (meaning they tie into enterprise
systems) and what often is missed is the amount of time (money) required to
get usability correct. What often is missed is why usability is important.
They think their web application or on-premise application can simply be
ported over to mobile very easily.

WRONG. Mobile applications supplement existing solutions, which means they
generally are a subset of features tailored to a handheld device. Enterprises
generally don't adapt a lean methodology. For example they just assume that
the current Facebook app you see today was birthed in a weekend...as Facebook
itself was. Which, as we know all know here, is simply not true.

------
feralchimp
In any business where you're contracting directly with clients, especially
performing technical work for less- or non-technical people, dealing with a
wide variance in expectations and being prepared to (calmly, patiently)
explain your LOE estimates is just as important as being able to
code/design/etc.

It's not their responsibility to know the market they're trying to consume;
it's yours. Be prepared to quote market rates for varying levels of
experience, and have examples to explain why your time is priced in whatever
tier you consider yourself to be in.

------
jsankey
I wonder how much of this is because iOS apps are typically priced so cheaply.
The thinking goes something like "If you can buy quality apps for $1.99 then
how much could they cost to make?". Of course some apps make a lot of money at
this price point, but it's widely reported that the vast majority make a loss
on the developers' time. I suspect even the majority of non-junk apps (which
rules out a lot of apps!) make a loss in this sense. If developers aren't
valuing their work correctly, how/why would the people hiring them?

------
ryanwaggoner
This might be a stupid thought, but I wonder if there's a psychological issue
at play for iPhone apps in particular where people subconsciously think small
form factor = pretty simple = pretty cheap.

Of course, the reality is usually exactly opposite.

~~~
mrbrandonking
You're absolutely right. "Simple to use, simple to build" is another thought
in people’s minds. They don't realize it's actually harder to build something
that's simple to use.

------
csomar
It's the same problem on Web Development. It's actually worse. As JavaScript
and the DOM are quite hard to handle (cross-browser issues too) to build the
simplest features and interactions.

I found out that it's not worth it to mingle with offline-small business.
Their budget is usually $1,000-$2,000. That's barely enough to buy a stock
template, a couple of plug-ins, setup WordPress and customize it a little.

The problem is not with small or medium businesses. You need businesses that
works on the web. Their web presences is everything they are. They know how
web dev. is hard and expensive and they also value it. Highly.

If you are a freelancer, find a few of them. Make a good relation. That's it.
They'll make you a good salary.

~~~
weixiyen
> It's the same problem on Web Development. It's actually worse.

For me, on average, the same type of UI / interaction in iOS takes about 3-5x
more to develop versus web.

~~~
jnbiche
He didn't say the time needed to develop an app was the same, he said the
problem was the same. The problem seems to be that people undervalue
programming/design work, and web development is not exempt from this.

------
ldayley
Peoples' "Amazing app idea!" is the new "Amazing screenplay/TV show idea!".

Like creating quality TV/Film content, crafting mobile applications takes
time, talent, and money and one day this will be better understood by the
mainstream.

------
brianstorms
I can't tell you how many VCs and angels, all of whom should know better,
would ask "why did it take so long to build your iPhone app" and "why did it
cost so much to build" when they're not including the weeks/months it took to
design it, plus build out a very complex backend of servers ingesting licensed
data, all the application logic on the backend, all the API calls on the
backend and corresponding API connections on the app end, and on and on. It's
a big complex project.

The idea that you can whip up a very complex iPhone app "in a weekend or two"
is naive and, dare I say, bubblethink.

------
16s
I think one issue is the word "app" and how it's thrown around so easily these
days by people who don't fully understand what an app is. It sounds so
simple... "just make an app" or "there's an app for that". While devs know
that "applications" are hard to write and take much planning, design and
infrastructure to build and deploy and support, business people only hear the
one syllable word "app" and they equate that that word with "easy and
convenient". So bringing their expectations in line with reality is a
challenge.

------
slakr78
Worst. Article. Ever. Having just been in the situation of being a large
corporation client trying (successfully) to hire a firm to do this, I'd like
to point out that everything you've said about the prep here is just wrong.

(1) Big infrastructure needed: Seriously, if the client is not picky, you
should be able to build a working basic infrastructure for the back end in a
week. And that's generous.

(2) You need a way to communicate: The claim that there is no standard way to
do it is just plain wrong. There is absolutely a standard way, its how
everyone with a brain does it these days, and its easily supported through
every device SDK - you use HTTP

(3) Design the API: No, design the app. Then determine what question it needs
to ask the server, and figure out how to make the server answer them.
Designing the API first is a very engineer thing to do - if you're the only
user for the API its just a flat-out wrong approach

(4) Pay for it: Sure, but I'll pay for the amount of time it should take to do
this. Which is a week. Engineers that want me to pay for them to sit and write
200 page requirements specifications need not apply. I want to work with the
people that want to build something on day 1, and then keep tweaking it.

~~~
funkyboy
How do you know it takes a week to do it?

------
xarien
I didn't actually read the blog. Why am I commenting? I want to share the
reason why I didn't read the blog.

I judge books by their covers. In fact, I don't know anyone who doesn't
outside of trying very hard to convince others they do not.

The layout of the blog draws my attention to your picture and subsequently
your "download my resume" link. I clicked since I was interested in learning a
little about the author, his background, and what may have caused him to write
such an article.

As soon as that link opened, I knew I would not read the blog post because the
resume layout rendered the content difficult to read. Why does that bother me
so much? The answer is simple: it ruined your brand for me before I even had a
positive impression. Right off the bat, I'd give 2 suggestions to clean up
your resume a little:

1) Do something about the half bar headers you are using as it currently
divides the page when viewed, this wouldn't be an issue if you actually had a
2 column design which lined up, but it doesn't.

2) Never and I mean NEVER use justified alignment unless you're publishing a
newspaper.

Sorry if I seem a bit harsh, but being that you're fairly young and these are
very simple mistakes to correct, I thought I'd point them out.

Best of luck!

~~~
xarien
So I lied, I did end up skimming the post.

The problem is that you are generalizing way too much. Does every app need to
communicate with a server? Nope. In fact, you don't even need to host the app
download or transaction as it's done for you via itunes.

Additionally, even if client / server communication is necessary, what's to
say the server doesn't already exist? Who's to say there's currently no
communication with the server through web clients? If that's the case, you
simply have to implement or expand the current interface...

Summary: Don't generalize....

------
orbitingpluto
I recently made an Android app for $150. Ad supported. Now with 1 million
users. That's about 1/30th of what it has earned so far.

Hard way to learn to value my own work more.

~~~
yesbabyyes
Ouch. Go to patio11 for counsel, collect $15k. ;-)

------
agentultra
Depends on the app and the expectations of the business stakeholders.

For example, my company focuses on building media-based apps. We have a
platform and internal SDK that allows us to build these apps quickly and
afford-ably (and not just on iOS -- we can release simultaneously on Android,
Blackberry, WP7 and others too).

There are other services that make developing apps for mobile smartphones
cheaper as well.

It's a fresh market and the consumers in this market don't know the options.
Not every app is a unique, bespoke snowflake that requires a massive budget
and a team of highly-specialized engineers. Once they do though I think we'll
see a lot of these budgets come back down a bit.

------
jnbiche
As a full-stack web developer with particular strengths in server-side
development, this whole discussion has opened my eyes to a whole new potential
clientele: iPhone developers. Building a nice RESTful API is something I enjoy
doing and that I'm good at. I never imagined that I would end up marketing my
services to other developers, but clearly there is a market there. I'll have
to start hanging around mobile development forums, at least until Parse.com
and its competitors put me out of business.

------
6ren
From the referenced SO question
[http://stackoverflow.com/questions/209170/how-much-does-
it-c...](http://stackoverflow.com/questions/209170/how-much-does-it-cost-to-
develop-an-iphone-application) on apps costing $50-150-250K to develop.

Is there really enough money made from apps, to justify this cost?

------
matwood
While trying to describe a rather large system change an SVP in a large
company once told me:

 _it's just an 'if' statement_

~~~
ovi256
I found the best answer is to respectfully state the logic the change needs,
the inputs to the logic and where they come from, and any trouble spots in
implementing that. If the reason for their view was ignorance, this will solve
that.

If it was malevolence, they'll refuse to budge and you'll know to run. Fast.

~~~
weixiyen
I would think to run in either case.

------
MaxGabriel
I'm learning iOS development. I won't start this now, as there's alot more of
iOS to learn, but what are the main languages/frameworks are being used server
side to interface with iOS apps?

~~~
AznHisoka
Ruby on Rails... Python... anything really that supports REST

------
rzrzrz
I tend to agree with what you have said. But then, it is unavoidable that high
costs would push businesses to other solutions (e.g. outsourcing) for costs
savings.

------
AznHisoka
Not to mention dealing with provisioning profiles and certificates. Creating
an adhoc distribution version was one of the most frustrating experiences.

~~~
sashthebash
Please check out <http://hockeyapp.net>

------
SatvikBeri
Thank you for using simple language-I found this article to be really
accessible.

------
matthavener
I wonder how much of the server aspect is reduced with the existence of
parse.com. You still have to build your model, but I would imagine a lot of
the server setup and "data format" concerns are no longer valid.

~~~
j2pro
It doesn't appear to help me. I need to develop an app that pulls data from an
ERP system with an Oracle DB back end. The ERP system does not have an API.
And authentication has to be done through Active Directory.

------
jsavimbi
Please raise your hand if you're approached by on a weekly/monthly basis by
some bright-eyed, overly optimistic, non-technical person who wants you to
build them an "app", of any kind, for the quoted price of somewhere between
$10K - $20K.

That's the price of a demo.

~~~
ryanwaggoner
Sorry, but I think you're being a little overly dramatic. I'm relatively new
to iOS development (just over a year of doing it full-time) and I've built
quite a few apps for clients for <$10k and for somewhere between $10k and
$20k. There is a LONG list of apps that can be delivered in 100-150 hours. At
$95-125 / hr, that puts you solidly in the $10k - $20k range.

~~~
Aqua_Geek
I agree - 100-150 hours is a large enough bucket IF the app is somewhat self-
contained or has very limited server interaction (e.g. just consuming an API).
I've built dozens myself that fell in that range.

Once you start having to send data in the opposite direction and keep it in
sync, however, you'll quickly find yourself spending far longer than 150
hours.

------
Radzell
Thank you this is one of my biggest pet peeves as a developers business people
thing it is so easy.

