“Let’s make an iPhone app!”
I heard this ad nauseam from entrepreneurs in the early 2010s when the Apple App Store was still in its infancy. At that time, Android was nothing more than a cheap, obscure alternative. Ten years on, the mobile market has changed significantly. In the United States alone, more than a third of all adults use a smartphone as their primary device for accessing the internet. What's more, that smartphone often doesn’t come from Apple. Today, an Android device is a common sight in the hands of the average consumer. In fact, Samsung, not Apple, currently sits atop the charts for the number of smartphones shipped worldwide.
Despite these market changes, many startups still choose to launch their new apps just on the iPhone, at least at first. The reasoning behind this decision is pretty simple. App development isn’t cheap, and targeting one system instead of two is a surefire way to cut costs. And that’s before we even take into consideration the many variables that Android presents. Different screen sizes and OS versions, to name just two examples, complicate product development on the platform, further raising costs.
But cutting off Android means giving up a sizable percentage of the target audience, which hurts sales and hinders product development. The latter is especially worrisome for young startups trying to refine products through frequent user feedback. Limiting development to just the iPhone means that the initial customer base is skewed, leaning toward specific demographics that might not represent the whole of the potential target market.
What can you do to overcome this obstacle and release your products to a wider audience without running into exorbitant development costs?
The Basics: Do You Need a Mobile App?
First of all, let’s challenge some assumptions. Despite what conventional wisdom might say, there are ways to reach your target smartphone user without relying on an actual app.
The mobile web has evolved considerably over the past decade. Smartphones are now powerful enough to render complex web interfaces smoothly, providing fluid 2- and 3-D animations that make the user experience very similar to that of native apps. Building these interfaces is also relatively easy. You can choose from a number of frameworks to build a modern-looking UI, from mobile-specific ones like Ionic to more generic propositions such as Bootstrap. These normally sit on top of React or AngularJS, the most popular responsive web app frameworks in the world right now, which are used and trusted by all sorts of companies, including Spotify and PayPal.
Implementing a mobile web app instead of going native is an enticing strategy to reduce development costs since the app is multi-platform from the get-go. You also don’t need to recruit specialized Android or iOS developers to get it up and running. This approach does have some drawbacks and limitations, however.
On the technical side, some smartphone features are simply not accessible from the browser. For instance, notifications aren’t there yet, although web specifications for them do exist. Desktop browsers implement them, but mobile ones do not. Choosing to go down the mobile web route means conducting a thorough feasibility study to see what’s available on both iOS and Android and then doing lots and lots of testing.
Features aside, another big drawback of mobile web apps is that they need to be downloaded from your servers again and again, costing you bandwidth and frustrating the user. Loading time can become a dealbreaker for users with slow mobile connections, especially as the app grows. Worse, caching and cache invalidation present numerous issues as well.
Also, web apps aren’t as immediate to use as the traditional native apps that the average smartphone user is accustomed to. Although there are ways to add a web app shortcut to the home screen on both iOS and Android, this is an unusual operation for the user. It also creates an extra step to access your app that’s cumbersome and may be perceived as unnecessary, ultimately driving your prospective user away.
Having said that, for small apps that are mostly meant to relay data to the user without more complex additional features, the mobile web is a compelling option. For good examples of apps in this category, look no further than Paypal’s own mobile app by accessing the normal login URL from your mobile device. You can also check out clothing giant Uniqlo’s site, which turns into an awesome mobile web app when accessed from a smartphone.
These mobile websites really blur the line between a native app and the mobile web. Whether this approach is sufficient for your app, again, depends on its intended feature list. But fear not: if you find the mobile web approach lacking, there are still a couple of options to explore before turning to a full native app approach.
The Hybrid Approach
You can mitigate some of the downsides we just explored by using the so-called “hybrid” approach. You can wrap a web app inside a native container and release the result just like a native app on both iOS and Android through conventional means.
This approach isn’t new. Cordova, one of the main frameworks enabling such behavior, has been going since 2009. Today, though, these frameworks are more compelling thanks to the complexity of the web apps they can wrap.
Also, these wrapper frameworks further reduce the gap in functionality between native and mobile web by implementing custom JavaScript APIs. Through these APIs, the developer can access certain smartphone features within the hybrid app that wouldn’t be available otherwise. These include notifications and data from device-specific sensors like the accelerometer, to name just two, opening up a world of possibilities not accessible from the web browser.
From the end user’s perspective, the experience of using a wrapped app is largely similar to a native one. Ultimately, a browser is still responsible for running your code, though. As a result, performance is still lacking in comparison to the native alternative.
Despite the drawbacks, good apps can come out of this approach. Adobe curates a gallery of such apps, built on their own open-source PhoneGap platform, itself derived from the Cordova codebase.
As you can see from those apps, the wrapper approach is not as popular today as it used to be. That’s partly because the mobile web has advanced significantly, and partly because a better alternative is now available for the times when a mobile web app isn’t enough.
Cross-Platform App Development
Cross-platform app development frameworks are a relatively new approach that’s similar enough to the hybrid method that sometimes they’re even mistaken for one another.
A cross-platform framework allows you to code your app once and produce two distinct native apps at compile time: one for iOS and one for Android. The apps produced, however, are truly native. There’s no trickery or runtime environment here to affect the performance of the resulting software. With this approach, you can take full advantage of the underlying device and its features and you can produce apps that are virtually indistinguishable from their fully native counterparts.
Because this approach is fairly new, there aren’t many frameworks in this category. Flutter, an open-source project by Google, is probably the most popular one available today. To understand how helpful such a framework can be, let’s look at a common example of its usage.
Say your app needs to support in-app purchases. Traditionally, you’d have to understand how the Apple App Store handles this kind of product and the related APIs. The same goes for Android and the Play Store. Instead, Flutter allows you to use the in_app_purchase plugin and access both systems holistically. The plugin takes care of the communication with the native store for the platform the app is running on, be it Android or iOS, while your team can concentrate on the higher-level workflow for the end user.
The main drawback of using Flutter is that it uses Dart, a somewhat niche language, for development. Any developer coming from either React, Java, JavaScript, or Objective-C shouldn’t have much trouble adapting to this new language, but there’s still a learning curve to take into account. Also, the abstraction provided by this system means that previous experience with either iOS or Android frameworks is less relevant, and even seasoned developers will need to spend some time retraining.
There are some alternatives to Flutter that use more popular coding languages, such as Xamarin from Microsoft or React Native from Facebook. None of these compile directly to a native app like Flutter does, though. As a result, they sit even more in the gray area between a hybrid and a truly cross-platform solution. Even so, their performance might still be sufficient for your app, making them especially suitable if your team is already familiar with .NET or React web development, respectively.
If you want to take a closer look at Flutter apps, the gallery on the Flutter website is a good place to start. The gallery features notable names like the New York Times and Chinese internet giant Tencent, among others.
Don’t Forget Your User
Technology isn’t the only consideration to take into account when deciding to go cross-platform with your new mobile app. Regardless of whether you choose the mobile web, a hybrid approach, or Flutter, the biggest risk still lies in the experience you create for the user. This needs to make sense for them for any chance of app adoption. Delivering something clunky or too far removed from the native experience on either platform could quickly send your users looking for alternatives.
Although Android and iOS have been converging for a while, from the way notifications are handled to the way system-wide navigation is implemented, there are still fundamental differences in usage and presentation that you need to take into account when you create a cross-platform app. You could disregard these differences and create a user interface mainly targeted at only one of the two systems — likely iOS — but that will make the app feel unpolished and out of place for the other half of your user base. Better options are either to create two separate front-end skins using device-specific UI conventions or opting instead for a more device-agnostic UI that doesn’t lean too heavily one way or the other.
This is a good problem for your UX and UI design teams and something to keep in mind as you develop your project. More crucially, this is not a place to cut costs. A mindfully designed, delightful user experience can make your mobile product succeed just as much as the feature set that you implement, if not more. This has always been true, but it’s even more important these days as the app market’s saturation means that unpolished, unrefined, apps are quickly passed over and forgotten by both customers and App Store/Play Store curators alike.
Parting Thoughts
Today’s mobile landscape is more varied than a decade ago. You can’t focus solely on the iPhone when developing a new app. The good news is that there are ways to produce professional-looking apps that work on both systems without having to spend twice the amount of money. You need to carefully tread the fine line of cross-platform app production, though, keeping user experience considerations front-and-center.
Native apps are still the way to go if you’re using bleeding-edge device features or otherwise require a lot of processing power for your product like running AI models in real time on the smartphone itself. For everything else, you can look into cross-platform app development frameworks, mobile web apps, or hybrid solutions that run web code inside a native wrapper.
After all, native apps weren’t even part of the roadmap for the original iPhone. iOS 1.0 only came with guidelines for web apps and didn’t expose any native SDK to the developer. Native apps became a reality only a year later with the introduction of iOS 2.0 and the App Store, paving the way for the mobile ecosystem as we know it today. It made sense back then, with the mobile web in its infancy and the reduced computational power available on smartphones.
Ultimately, there’s no reason for a startup to build a native app these days, save for very specific niche cases. The alternatives really are that good.
