If I Want To Build An iPhone App & Android App, Will It Cost Twice As Much?

(Cross-posted from the ChaiONE Blog)

Here at ChaiONE, we're often approached by individuals & companies looking for guidance on their mobile initiatives. One issue that frequently surfaces concerns addressing a user base that may consist of a mixture of iOS & Android users. This is common when the software will be consumer-facing where Android has a large market share, or in BYOD (bring your own device) scenarios where a company won't be issuing a standard device across its workforce.

In cases where the user base platform landscape will be heterogeneous, many organizations consider building a cross-platform app using technologies such as HTML5 or Titanium. Depending on the type of app desired, this may be an economic option. For simpler apps where access to the device's more advanced capabilities aren't needed, a cross-platform app can sometimes get your software into the hands of users for less upfront development cash outlay.

While ChaiONE's Director of Development, Ben Scheirman, will discuss in detail in an upcoming blog post about the many advantages of developing native apps instead of cross-platform apps, for the remainder of this article let us just assume that there are indeed compelling reasons to build individual native apps for each platform instead of a write-once, deploy everywhere approach. If you're considering building a native app for iOS, and a native version for Android, will this cost you twice as much? The short answer is no. Let me explain why.

During the course of an app development project, there are several types of activities that must occur. Usually a period of user research will precede all other activities to ensure the yet-to-be-built app will in fact meet the needs or fulfill the desires of the individuals who will actually be using the software. Once that is validated, an app development team will then begin designing the app, both in the context of user experience paired with visual design and foundational technical architecture. Notice that I haven't mentioned anything specific to iOS development or Android development yet. This is important.

Apps rarely exist in isolation. By that I mean most modern mobile software isn't self-contained. Instead, it's more common that an app will frequently communicate with the outside world, pulling in new data from different sources or pushing out data created in the app to other servers. This communication with the outside world is accomplished via Application Programming Interfaces, or APIs. While the concept of APIs are beyond the scope of this article, at a high-level it's a structured way for two software entities to consume & transmit data between each other. If the APIs your app will utilize already exist, the app development team will just need to document the structure and plan to build the app in such a way that can interact with them. If the APIs your app needs don't currently exist, then the development team will need to define and subsequently build them so the app can eventually utilize them.

All of the activities I have outlined so far are mostly platform agnostic. Regardless of the platform you target, these efforts would need take place. These efforts are also foundational, meaning they need to take place before the team begins development on the app itself in earnest. Depending on the nature of the app, these efforts can often be time-consuming, especially when you'll be creating your own APIs. However, once these activities are complete, the outcomes can be leveraged across multiple platforms in a near-trivial manner.

Let's say it took somewhere between 25% & 50% of an overall single-platform project budget to accomplish the tasks described above. If you opted to build an iOS app first, you wouldn't have to allocate the same amount of time if you then decided to build an Android app, too. You can make whatever minor adjustments from a design perspective that are necessary for the new platform, but you don't have to rethink the overall structure or technical foundations that you've previously defined. And that's why it won't cost you twice as much to build for two platforms.

As a final consideration, I'd like to highlight one approach that I've observed to work well. If you do opt to natively develop for two or more platforms, consider staggering the development efforts. For instance, let the Android development efforts lag a few weeks behind the features being developed in the iOS app, or vice versa. The advantage of this approach is that it allows new problems or challenges to be solved on one platform before they're encountered on the others. This way, if business logic or other considerations must be unclogged, you're not delaying progress on multiple platforms at the same time.