Dear business elites, developing an iOS app is not that easy

[[143163]]

Let’s get straight to the point: How much does it cost to make an iPhone app?

This is the most common question. Many of my friends (mostly business people in suits) and my clients who have little knowledge of technology have asked me this question. Usually, I will give a rough quotation first, which is not detailed enough to require a contract to confirm every functional point. Even so, every time I give a quotation, the other party is shocked without exception (of course not because it is cheap).

To be honest, I'm not asking for too much. Take a look at this famous StackOverflow thread about how much it would cost to build an app like Twitterific, which later expanded to discuss the reasonable cost range for building an iOS app. Although the thread was posted in 2008 and the top answer was given by a developer from Twitteriffic in 2010, the numbers discussed in the thread are still very reliable today, and I expect them to be valid by the end of 2012. My price pales in comparison to the numbers in this thread.

The current trend is that all companies and businesses want to develop an iOS client, and this trend seems to be still hot in 2012. So I thought of writing this blog post. I want to talk about the various details and variables that will be encountered in developing an iOS application, so as to explain why the cost of iOS application development is so expensive. If you are considering developing an iOS application, and you are engaged in business rather than technology, if you are currently bidding or just want to learn more, then this blog post will be helpful to you. Of course, what I say is not limited to iOS application development, but is basically applicable to mobile application platforms such as Android, Windows Phone or Blackberry (if RIM is still alive).

[[143164]]

Things to consider carefully before development

Don't make snap decisions. You need to consider more than you think before starting. I usually help or guide clients to go through the following factors:

1. When talking to clients about their mobile applications, what surprised me the most was that they had never thought about the various aspects involved in supporting the operation of an iPhone application. The iPhone they imagined existed independently in this universe, so simple that they asked me to quickly give a project budget quotation without discussing many details. I asked them: "Have you considered the backend server? Does your application need to communicate with the backend server?" What, I don't understand? Okay, I will explain this question again in the language of earthlings: "Your application requires users to register, have you considered where to store the user's data? We need a place to save these data that will be used in the future." The first time I met such a client, I was furious. Later I found out that it was not the client's fault: I am a programmer, and CS architecture is something that I don't have to think about, just like eating and sleeping, and my clients are all tall, rich and handsome, they don't know anything about CS architecture!

So, if you don’t know much about technology, please listen to me carefully: if the mobile application you want to make requires users to register and log in, or if you want to control some outputs of the mobile application at any time, or even if you just need a simple function like a user feedback survey form, then you have to set up a backend server.

Two: OK, now you know you need a backend server. You also need to figure out a way for your iOS app to talk to your server, to receive data from each other. No, this is not a simple plug-and-play solution, not what you think! Everything needs to be custom developed, which is like inventing a language: you want your server and your app to communicate in a language, but you don’t want others to understand that language.

In jargon, this is called developing server-side APIs, or APIs for short. These APIs should be in place before developing the iPhone client. Why? Because you have to define the vocabulary and grammar of a language before you can speak it, right!? Well, this brings us to the third point - how to develop these APIs.

Three: Successful customization of the API is half the success of the project (and vice versa), so don't take it lightly. You need to consider your business data model, business process, parameters that need to be provided for calling the business, how the data interacts when a specific event occurs, etc. In short, what we have to do is to develop a website that runs your business process, but all the results of this website are not displayed in the form of web pages, but in lines of text and numbers. For example: a feedback page for a successful login contains only the word YES.

iPhone applications need to access these predefined interfaces and provide the necessary input (such as username and password) in a predefined format, and then parse the server-side feedback (YES or NO). Therefore, no mobile application can automatically include user registration and login functions.

There are too many issues to consider in server-side development: choosing a server, choosing which language to use, where to put the host to increase access speed, etc. I won't go into details here. If all this is unfamiliar to you, then you'd better ask the technical leader in the team, or simply let the developer make the decision.

Four: So, regarding the server-side API, you can either have your own technical team develop it and then give the complete API documentation to the iPhone app developer; or you can pay the iPhone app developer extra money to get it done. The iPhone app developer you find may or may not be able to develop the server-side. If he can, I suggest that it is best to let him be responsible for server-side development at the same time, because he knows best which server-side APIs are needed in the iPhone application.

If your server-side API already exists, in addition to providing relevant documentation to iPhone application developers, you should also consider enabling them to communicate easily with the server development team, because in most cases, iPhone applications need to add some new interfaces based on the existing API.

Now let’s look at iPhone app development itself

After talking for a long time, we finally start to talk about iPhone application development itself. Generally speaking, you can't do everything as you please on the iOS platform. You'd better confirm all the requirements before the developer writes code. This is different from developing a website. When developing an iOS application according to the contract signed by the implementation, the tolerance for requirement changes during the development process may be very low:

User interface: Whether you plan to use the iOS standard interface or custom elements, you must confirm it clearly before development begins, because the application's program architecture is designed based on the interface and user flow. A good example is the use of the iOS standard tab bar at the bottom of the interface. If you want to make the icons in the tab bar colorful, the code changes are not as small as you think!

Coupling between codes: If you are developing a website, you can add a page or a link at will. It is not so simple to make an iOS application. Many things need to be designed at the beginning. A change later will involve many things, and the specific reasons are beyond your understanding. After the code of the iOS application is written, can it be changed? Yes! But you must be careful. It's like designing a circuit board. If you accidentally connect the wrong wire, the whole circuit board will not work. Some people say that well-structured programs can have high scalability, but that is purely theoretical. Adding an email button to the About screen may only require a few lines of code, but adding a button to forward to Sina Weibo (Translator's note: the original text is to add a Facebook Like) is not that simple at all!

Make an iPhone app also support iPad: If we were to choose the most disappointing "requirement change", this one would definitely deserve it. The reason is simple: supporting iPad is not a damn additional feature! iPad apps are generally more complicated than iPhone apps, and the interface design and user experience are also very different. Let me ask you, is it the same thing to build an electric bicycle and then convert it into a gasoline motorcycle! ? Electric bicycles and motorcycles look very similar, but building them is completely different.

Take the popular Facebook official app, for example. Its iPhone and iPad versions may look similar, but the actual user experience is completely different. It's not just the interface that creates extra work, the requirements for the backend server APIs may also be different. Take Denso, an app I'm familiar with (I'm familiar with it because I developed it), its iPad version has several more features than the iPhone version, all of which require additional server-side APIs to support. Remember, the user experience requirements for iPhone and iPad apps are completely different.

Ready to get started?

I hope this article can help you and your team understand the various aspects behind the scenes of mobile app development. Unless you want to make a simple standalone application like a calculator, it is difficult to do it at a very low cost. In summary, if you think the cost of outsourcing is too high, then you have to hire someone to develop it yourself.

Of course, if you decide to outsource your mobile app development, I would also like to warn you about company politics. If you work for a large company or an organization with strict rules, it is important for you to help the contract developers navigate the red tape of rules and regulations, and even make some policy adjustments when necessary. I have worked with several large enterprise clients who looked very uneasy when I asked to see their server-side data interfaces. I think this may be because they are bound by company regulations and cannot disclose information, which is understandable, or they have not yet figured out how to operate in this situation, or their branding system is so annoying that they need to put the company logo on every screen of the mobile application! In the end, I did not work with such enterprise clients because I couldn't imagine how tragic it would be if I needed to add some server-side API interfaces one day and toss with their rules and procedures.

PS: Developing mobile apps is time-consuming, you'd better be patient.