Here are several important things to consider before building a product across multiple platforms.
I’m a cross-platform native mobile developer. I write iOS apps and Android apps, and I write every app natively using the SDK for each platform instead of any kind of write-once-run-everywhere-solution. This tends to be more time-consuming, but it also leads to a host of benefits around the stability and maintainability of your application.
Clients often come to Vokal wanting to build an iOS app, an Android app, and a website, as well as a backend to hold all the data and work with all applications. I’ve worked on several applications like this, writing code for both iOS and Android.
In my experience, I’ve seen two basic approaches to getting an app up and running on multiple platforms:
- Build everything at once — The backend, the native mobile apps, and the website.
- Build everything in stages — The backend and a single app or website, then each successive application.
Approach #1 is generally taken when a deadline is the primary concern. Approach #2 is generally taken when cost is the primary concern.
Having worked on applications taking both approaches, I’d like to outline some of the pros and cons of each approach, and which one I’ve seen lead to greater success in the end.
Approach #1: Build Everything At Once
The everything-at-once approach can be very tempting for a client with a large budget, a tight deadline, or both.
The ideal version of this approach is to have a well-defined product, with the backend team sprinting just ahead of the client applications. The backend would build out and test an API endpoint (i.e., a point of communication between the backend and other client applications) in one sprint, and a sprint or two later, the client applications would build out the features which consume this API endpoint.
The benefits of this approach in theory are great:
- All platforms are supported from the get-go.
- You can launch everything at once, in one big push.
- All developers can communicate and be on the same page as changes occur.
- Developers can help each other out: iOS and Android developers may exercise the backend in different ways.
In practice, I’ve seen this lead to problems from a development standpoint:
- Any delay in building out the backend rolls over and delays not just one app, but multiple apps.
- Any downtime on the staging server or error in an API (both of which are common during early stages of development) affects multiple teams.
- Any necessary change in the API which only becomes obvious after integration with the apps must be made in multiple places.
In all of these cases, costs wind up ballooning because every one of these issues is felt in many places at the same time. Delays can also feel much more frustrating because it’s not just one thing being delayed, it’s everything.
The drawbacks of this approach also apply to design. When design is racing ahead of each feature, it can be difficult to take platform-specific idiosyncrasies into account.
The simple existence of a hardware back button in Android can lead to a number of navigation complications which aren’t possible in iOS. Historically, iOS and Android have had very different models of granting permission for applications to do something (use the camera, use the microphone, access the user’s location).
Additionally, it’s much more difficult to get and take into account any feedback from users when you don’t have any users beyond the people testing your application. Once you receive that feedback from users, any changes which need to be made, either to features are design, once again must be made in multiple places, exacerbating the costs.
Approach #2: Staged Rollout
Staged rollout is a popular choice for startups, since the cost of building and maintaining multiple applications is pushed down the road a bit. After all, it costs less to pay for two developers (typically backend and iOS) than for several (backend, iOS, Android, Web).
The downsides are pretty obvious from a business standpoint:
- You only have your app available on one platform at first.
- You need separate marketing strategies for each platform’s launch.
From a development standpoint, there are substantial benefits to consider. For the initial application, they’re largely around simplification of the process:
- The backend only has to worry about one application breaking things. This makes identifying errors much simpler.
- Reducing the number of people communicating while the API is in flux makes changing the API a lot easier, since it only affects one team.
For the subsequent applications, the benefits are around definition and stability:
- The API is generally much more stable since it’s been hammered out with the first application, allowing significantly faster development times on subsequent applications.
- Behavior and UI are far, far more clearly defined since they’ve already been through the client-developer-design feedback loop on one application.
- Since most of the UI and interactions will be well defined by the initial application, it’s easier for designers to focus on platform-specific idiosyncrasies and make sure they’re handled appropriately per platform.
- UI or feature changes deemed necessary after user feedback from the initial application can be built the revised way from the start on newer apps — so only the initial application needs to be changed.
I also saw an interesting and unexpected benefit in a recent application where I wrote the initial iOS app, then turned around and wrote the initial Android app a couple months later.
I write a lot of tests, and iOS in particular encourages using very long and descriptive names for tests. What this allowed me to do when writing the Android app was copy all the names of the tests, and then write tests which checked the exact same behavior in Android much more quickly.
This helped me not only by making sure I was matching the behavior across platforms, but by very clearly documenting the current functional requirements of the application in a way a requirements document shared among members of the team cannot necessarily do without constant updating.
From a sales and marketing standpoint, you can also make lemons into lemonade: You can keep your marketing budget limited and targeted for the initial release, and then you can adjust your marketing based on feedback from your initial users about the most useful and unique features.
Which approach should you choose?
In my experience, the Staged rollout plan comes with significant benefits from both a development and business standpoint. While it can be difficult to use with immovable deadlines, I’ve found that the reduction in hassle when building the second and subsequent apps was huge.
The biggest thing to consider when deciding how to structure your project: How well do you know your customers? If you’re creating a new version of an existing product, it may be easier to anticipate your customers’ needs, and have thorough definition of everything before any development gets started. This can reduce possible changes through the development of the apps, saving you time and budget.
If you’re creating a brand new product, there’s a bit of a myth that you have to have your application as perfect as possible before releasing it into the wild, because when it’s released, you’ll have a stampeding horde of customers immediately. Usually, even with the most solidly built application, growth can be slow until your marketing machine fully fires up.
While you want to have your application built as solidly and working as well as possible before it goes out to customers, the feedback you get from your early customers can be critical to the survival of your business. You can find out what’s working and what’s not, and what features users want to see more (or less) of in your continuing development. Anything beyond that is guesswork - potentially very expensive guesswork if you guess incorrectly about the features your customers will want.
Even if you have the budget to build everything at once, consider putting the initial version out on one platform both for the simplification of the development process, and to be able to incorporate changes you get from working with users in the newer versions.
Ellen will speak on this subject in significantly more detail at MobileWebDevCon in San Francisco on July 15.