One of the first questions almost everyone asks when they start talking about an app idea is this: should we build it for iPhone or for Android? This question used to be very critical for the budget, because each platform meant a separate team and separate development. Today the picture has changed. Still, to make the right decision, you need to look first at your customers, then at your budget and at what the app will do. In this article we cover these three topics in order.
Start by looking at the phones your customers use
In Turkey, most phones run on Android; the share of iPhone users is smaller. However, this ratio varies from one audience to another, and your customers may not match the general average. Instead of guessing which phones your customers use, you can measure it. If you have a website, the device and operating system breakdown appears in your visitor statistics (for example, Google Analytics). This breakdown is the most reliable clue you have about who your app will reach. If you don't have a website, your social media account statistics, or a short question you ask your customers, can also give you an idea. Who the app will serve also affects the decision. For an app aimed at your customers, being on both platforms means leaving nobody out. In a regularly used service such as ordering or booking appointments, every person who says “your app isn't available on my phone” may be a lost customer.
How does a single codebase work on two platforms?
In the past, the iPhone app was written separately with Apple's own tools and the Android app with Google's own tools. This is called separate (native) development for each platform. Today, with tools like Flutter or React Native, the app is written once and runs on both platforms. Screens, business rules and communication with the server are managed from one place. When you fix a bug or add a new feature, the change applies on both kinds of phone at once. Each platform still needs its own testing and store preparation, but most of the work is shared. One of the biggest benefits of this approach shows up in maintenance. With two separate apps, every update is done twice and the apps can drift apart over time. With a single codebase, users on both platforms see the same features at the same time. Even so, a single codebase does not solve everything in one go. For example, our own product Shutli runs on iPhone and Android with a single codebase, while features such as the home screen widget on iPhone and the live score on the lock screen require additional platform-specific work. Details like these become clear when the scope is discussed and are listed separately in the quote.
When is a single platform enough?
If the budget is limited, the first solution that comes to mind is to start with one platform. Sometimes this is the right decision. However, since the cost of the second platform with a single codebase is not as high as it used to be, it is a good idea to first see quotes for both options side by side. If the difference is small, starting with two platforms keeps you from losing part of your audience from the outset. The situations where a single platform really makes sense are usually these:
- If only your own team will use the app and everyone on the team has the same kind of phone, that platform is enough.
- If you want to test your idea and most of your audience is on one platform, you can launch the first version there and expand later.
- If your app relies on a feature that only exists on one platform, the choice is already made: that platform.
- If you have measured your audience and it is clearly concentrated on one side, leaving the second platform for later takes pressure off the budget.
- If your budget only covers one platform, doing one completely is better than doing two halfway.
When is separate development needed?
For apps that use the phone's hardware very heavily, such as the camera, sensors or graphics processing, and where even the smallest performance difference matters, separate development for each platform may be preferred. Graphics-heavy games and some specialized hardware apps fall into this group. In that case, each platform needs its own expertise, and maintenance is carried out on two separate apps. For the kinds of apps businesses most often need, such as ordering, appointments, loyalty, catalog or field apps, a single codebase is usually the more sensible choice for both budget and maintenance. The two approaches can also be combined: most of the app is written with a single codebase, and only the part that truly needs it is developed specifically for each platform. Also remember that choosing a tool is a long-term decision. If you want to change your team in the future, you need to be able to find developers experienced with that tool. Because Flutter and React Native are widely used, this is usually not a problem.