Mobile App Platform Considerations

Clutch interviewed representatives from some of the top mobile application development companies on the topic of app platforms and compiled their advice on what to consider when selecting a platform.

Read the full interviews and more insights from Clutch's research on the App Development resources page.

When deciding which type of mobile application to build, such as native, hybrid, or mobile Web, there are many considerations depending on your company’s specific needs and goals. Here are the major ones, for both consumer apps and internally utilized enterprise apps:

• Functionality
• Audience and reach
• User experience
• Development cost and speed to market
• Cost and ease of maintenance

Read more below about each of these factors below.

Functional capabilities will vary depending on the type of app platform you select. Native apps can utilize all of the functions of the specific device, including features such as Touch ID, swipe gestures, and notifications. Mobile or responsive Web apps, on the other hand, cannot access device functions, since Web apps are stored on the server and are, therefore, independent of the device. Hybrid apps are able to access many of the device’s features, but are somewhat limited. Hybrid apps work well when you have large chunks of Web content you want to display while still taking advantage of the native device user experience and some device features. Read more about hybrid app use cases.

“We did an informational application [as a hybrid app], where it was mainly just getting information from a Web service and putting it into an app. It was sort of like a blog. We did that quite well. For anything that involves gaming or anything that requires a bit more control on the push notifications and things like that, I think native is the way forward. But, if it's something simple with not too much functionality, we can use a hybrid model rather than a native one.”
— Taj Dhunay, Project Manager, The Sound Pipe Media

“Primarily it's been our enterprise customers that come to us and say, "We've got users that are on Android, users that are on Apple devices, and users that are on Windows devices. We need this app to function across all platforms." We would develop comparable native apps for each platform. One application that comes to mind would be a product called NVContacts, which is basically NVIDIA's internal company Rolodex that we developed for them, and that runs on all three platforms. It uses contact information, calendar, and things like that. It uses the specifics native to the device, and it didn't make sense to utilize a hybrid approach there. Also, that particular application requires a high level of security, and the implementation of that security is different depending upon which device you use.”
— Paul Fruia, VP Engineering, Softeq

“[Hybrid] sounds really good, but it does have tradeoffs, however, because the functionality that you have available to you in those platforms is always behind the functionality that might be available in iOS or Android natively.”
— Tobias Dengel, CEO, WillowTree, Inc.

The intended user base for your app is a primary determinant of which type of app platform to use. The research and decision process for determining the audience of an enterprise app is distinct from that of a consumer app.

Enterprise Apps

Enterprise apps are those that are used within a company for a specific business purpose. An enterprise app that must be accessible on every type of device an employee could own is well-suited for a hybrid or responsive Web app, if the functionality allows for it and is appropriate. If the app requires higher levels of security or more access to native device features, and your company has a higher budget, you could also develop multiple native apps.

For other enterprise situations, if one type of device is uniformly distributed internally, then by default there will only need to be one native app built.

“One of our current clients initially wanted to do native iPad development for a sales and marketing tool repository. They wanted to store sales and marketing documents, and then detail their sales process so that their sales people know when they should present certain documents along the workflow. We found that what they really wanted to do is manage all of that content externally using tools that they already know. They also weren't sure if all of their salespeople were going to use iPads. About 75 percent of their sales force uses iPads. The other 25 percent have iPads and just don't use them. So, we were looking for a way to get a tool into the hands of users that they would actually use.

By approaching it from the hybrid viewpoint, we can still do a touch first interface that is accessible from not only phones, but tablets as well and also desktops. So, we expanded their user segment exponentially by allowing them to have a tool that could function on whatever platform their end user is most comfortable using. That was the determining factor. They wanted to reach as many users as possible. They still wanted it to be touch first, but they realized that developing on iPad might not be the best choice.”
— Adrian Dawson-Becker, Mobile Strategist, Myriad Mobile

"[For enterprise apps,] if businesses have a BYOD, or Bring Your Own Device, strategy then, sometimes, we will look at HTML and either hybrid applications or wrapped Web applications if they need to get applications out to their entire workforce quickly and everyone's different devices. Other times, everyone on that team has been provided iPads or iPhones, so we know it will be an iOS application."
— Sarah Weller, London Managing Director, Mubaloo

Consumer Apps

For a consumer app, it is extremely important to conduct market research and determine what devices your target users prefer. They may prefer one native platform compared to another, indicating that you could focus resources on developing a native app for a single platform. In other cases, you might find that your target user base is widespread, for which you will require multiple native apps or a hybrid or mobile web option.

“In India, Android has a bigger market share than iPhone. If a customer from India has an iPhone app and not Android, that means he is not covering the majority of Indians – just the wealthy class audience, but not the middle class or several other consumer markets.”
— Manish Jain, Director, Konstant Infosolutions

"With consumer [apps], it will be iOS or Android first, and then moving forward on to the next platform. Sometimes, we have done both. It depends on the client. If it's a larger corporate client, for example a big retailer, they can't launch with only one platform because they need to make sure that they're addressing all of their audience."
— Sarah Weller, London Managing Director, Mubaloo

If you have the budget to develop native applications and/or your desired app functionality requires a native approach. It may be ideal to release the app on a specific native platform first that covers a significant portion of the intended audience, and then build another version of the app on another platform if it makes sense financially later on. This allows you to gather important user feedback first that you can then incorporate in the second app.

“Limiting the features, the functionality, the scope, and the purpose of the application initially to create that minimum viable product is a really key thing to making sure you’ve got not only the cost in an area that can be absorbed initially, but also to ensure that you have a plan moving forward for success in maturing the application based on user feedback. “
— Jeremiah Jacks, CEO, Digital Brand Group (DBG)

“Our advice to clients: if they want to build for both platforms, pick one and do it first. Then, once you’ve fleshed out all the user experience, design, and functionality issues, you can start figuring out what it’s going to take to build the product on the other platform.”
— Don Bora, Principal in Technology, Eight Bit Studios

It is widely accepted that the user experience on a native app is ideal for a couple of main reasons. First, the speed is faster on a native app, since it does not rely on the internet to send and retrieve data. Native apps can fully function offline, whereas Web apps and the Web components of the hybrid apps require an Internet connection. While many hybrid or web apps use caching to mitigate this issue, there could be some functional limitations when network connectivity is weak. Speed may be crucial for certain consumer apps, such as games.

“One of the big drawbacks in hybrid applications is that because, by nature, they're based on the Web, they actually require the bandwidth to be suitable enough to render in the browser, so what happens many times is that the user experiences latency or slowness in the speed of the application and reaction time.”
— Jeremiah Jacks, CEO, Digital Brand Group (DBG)

“It depends on the client's needs, but we suggest mostly native over other opportunities like hybrid or mobile Web. We think that native is the best we can bring to our customers, in terms of performance, in terms of security, all of that. The price is going to be a little bit higher with native. In terms of the speed of development, it will take us more time to deliver native apps compared to other solutions."
— Artsiom Kozel, CEO and COO, Intellectsoft

Also, the interface of a native app is intuitive and consistent with the device’s built in user interface. This means the buttons, layout, and so on are familiar to the user and thus provide a smoother user experience. Hybrid apps can also take advantage of this familiar user interface in many respects. Web apps, on the other hand, are consistent in their design across every device, which requires figuring out a happy medium user experience that is perhaps not ideal for any specific device.

“In the opinion of users out there, and just looking at analytics and what people want and how they're behaving on their devices, native applications are it. Some clients will want to just make it once and service everyone through the Web and save a bunch of time and money. Well, I guess you could, but in almost all cases, you're going to end up with a relatively poor user experience compared to a natively delivered mobile application. The recent example of Facebook's dive into mobile is textbook. They went with a mobile Web app at first, and realized it was a tremendously bad decision from a user experience standpoint, and scrapped it. Now, they have native applications. Users don't want the mobile Web. Users want really high-performing, snappy, natively coded applications.”
— Gavin Fraser, CEO, Small Planet Digital

“There is a perception in the enterprise world that the cross-platform solution is the way to go because you can deliver faster in the market and, in some cases, this is true. I would say it is true if you care less about the user interface and user experience. If you really care about how your app looks and functions and how your app is perceived by users, at this point in time, you wouldn't probably go the cross-platform way, because whether you're using HTML5 or tools like Appcelerator, there are still performance problems. These options are limited in the different UI [user interface] compatibilities and how you can style different elements, so there are still many problems that they need to address. If you really care about performance, responsiveness, and the UI of your app, you should consider a native solution. So, no matter whether you're enterprise or you're a startup, everything depends on your aims and goals.”
— Andrew Garkavyi, CEO, Stanfy

Another key consideration for building the app is how quickly and at what cost you can bring the app to market. While costs can vary greatly depending on the app’s functional needs and what type of development option you choose, the choice of platform is also a large factor in the number of labor hours it will take to build and test the app.

In regard to the time to build the app, native apps are specific to each operating system, so multiple versions will need to be coded from the ground up if you want your app to run on multiple platforms. Mobile or responsive Web apps, on the other hand, are perhaps the least labor intensive to code in that only one version is created to be used across all devices. Hybrid apps fall somewhere in between, depending on the amount of device-specific functionality that needs to be built out.

In terms of testing time, depending on the number of device types you plan to support, it is a costly testing process to ensure that the content renders correctly and that the functionality works properly on every device. The more devices, the more cost and time required. (Note that the testing time is not only dependent on platform choice; it also varies depending on the complexity and use case of the app. If the enterprise app requires a high level of security, for instance, more stringent testing will be required.)

"[Clients will] need to decide if they should go with native or hybrid if they want two platforms. It depends on cost and other parameters. If a customer wants to build an app for iPhone and Android, it means that Android could take 50 days, and iPhone would also take 50 days, which equals 100 days. At the same time, if they opt for hybrid, it means it can be developed in 60 days on both the platforms. They can later port the same application on Windows with little effort. Hybrid provides the maximum advantage in terms of making an app widely available. The only thing that is sacrificed is user experience, so that’s something they need to make sure is OK for their application, such as a business app, something that’s not a game or user-centric."
— Manish Jain, Co-founder, Konstant Infosolutions

Much of the cost that goes into having a mobile app occurs after the initial version is created. You’ll need to update the app to new software and hardware versions as they are released. You may also want to add functionality to the app later on or make changes based on user feedback. With a native app on multiple platforms, you’ll have to make any changes to each version of the app, which can be time consuming and costly. Mobile Web apps are generally simpler to update and maintain since there is only one version. Hybrid apps are somewhere in the middle depending on whether the change needed is on the Web content or on the OS-specific code.

If your company has development capabilities in-house and you intend to maintain the app internally over time, the platform choice should certainly take into account the specific technologies your staff is skilled in.

“I think they need consider maintenance, and what kind of developers they have internally. They can choose a platform to develop on, like Xamarin, which is a C# platform, because if they have many C# developers internally that may make a lot of sense versus developing in iOS or Android. This would be a good option even if they outsource the design and development of the initial app, which often makes sense because of the expertise working with folks who have launched hundreds of applications. The maintenance plays into it longer term. So, if you have a couple iOS or Android folks, you might want to do a native application. If you have C# folks, you might want to do Xamarin. If you have Web-based folks, you might want to do an app that's largely hybrid, so big chunks of the app are actually HTML, which might be easier for you to support. Or, you might have a strategy of having the app supported externally, then obviously the long-term maintenance and support matters a lot less.”
— Tobias Dengel, CEO, WillowTree, Inc.

Each of these factors is important to consider, and the platform you choose in the end will depend on your priorities in these areas. There are trade-offs you may have to make depending on your budget and needs.

*Relative to the other options given here, in most experiences, assuming you select the platform for its recommended use case, and assuming the developers have expertise in developing for that technology. This also assumes you are building the app for at least two app ecosystems, such as iOS and Android. Costs vary depending on app complexity. Learn more about costs to build an app.