Top Experts Explain When To Build A Cross-Platform App
A few days back, product development experts gave their views on outsourcing product development vs building an in-house team. The next logical question for many founders building a mobile app is whether to build a cross-platform app or not.
There are plenty of resources and tons of content already written about this subject across the Internet, but all of them give you insights based on their underlying interest in the subject at hand – either for or not.
We get asked a lot about the same topic and know for a fact it’s a hot topic of discussion. So, we went out and asked some of the top product development experts about their views on when should an entrepreneur build a cross-platform app – not whether should build or not.
The two most popular cross platform app development technologies are Flutter and React Native. Check out our detailed guide on flutter vs react native to build a cross platform mobile app.
Here’s what the 7 experts have to say:
#1 Majority of apps on the app stores are not designed to be cross-platform
I’m working on Brew Coffee, an artisan coffee recipe app, that will be iOS only. iPhone is my primary platform because of performance and design. I don’t like Android hardware, animation frame rate, responsiveness, or development tool chain.
On mobile, people build cross-platform apps for any social/network type app because the more people that can use the service the better the experience is. Facebook isn’t anything to you if none of your family or friends use it. The same is true with Slack. These types of networked and multi-user apps really need to be on all platforms.
With Mac/Linux/Windows the desire for cross-platform is generally a business decision that may be fueled by an existing user base, client request, or business driver (i.e: revenue). Skype needs to be available everywhere to be useful. Other apps like Final Cut Pro can do just fine being a macOS only app.
A lot of times apps that were not built from the beginning for cross-platform would require a ton of re-engineering in order to get the code to work on multiple platforms. Assumptions made with the original design don’t hold true between platforms, which can lead to significant costs if cross-platform isn’t done from the start.
It is a decision made based on user experience, cost analysis, and customer base.
With that said, the majority of apps on the app stores are not designed to be cross-platform, since they leverage the latest technology and APIs that a developer is familiar with. Targeting a single platform is a lot easier for a single developer since it requires less work, time, and problem-solving. A majority of apps on the app stores don’t make enough money to cover the development costs for a single platform, let alone multiple platforms.
#2 You should try to be as cross-platform as you can
A cross-platform app—which I’ve come to define as an app that can be used and operated natively in all environments/platforms/operating systems/devices—is an ideal software product. A cross-platform app can be accessed on any device, and I can’t think of a reason why this wouldn’t be the preferred situation in most cases.
Often, it’s not that a cross-platform app isn’t the preferred option, it’s just that the resources available during product development are finite. So, we have to make compromises, and that often means choosing which platform/s our product will initially deploy on.
For instance, if I recall correctly when Netflix initially launched its video-streaming service, it first focused on perfecting the product experience on Web browsers. As the product matured, Netflix incrementally developed product experiences beyond the Web browser. Today, they even have native Netflix apps for specific devices, such as Sony’s PlayStation 4 and Samsung’s smart TVs.
Another example: Instagram first launched just on iOS. Then the product launched on Android. And now you can access portions of the app using a Web browser.
What I’m trying to get at is that you should try to be as cross-platform as you can. But an equally important point I’d like to make is that you should still launch even if you can’t support every single native, device/platform-specific experience out there. Get your app development company to build the MVP and just get the mobile app out the door and to as many people as you can.
The most cross-platform product you can build right now will be a product that can run on a Web browser—a Web app—because it’ll be able to run on a ton of devices and operating systems. That’s where I recommend starting. Or you can take the Instagram route and choose to initially launch and focus on a specific device platform—a strategy that will help you conserve your resources, and let you deploy and refine your product more quickly.
#3 Talk with professional developers that understand the issues
Wallace McClure, Co-Founder, Developer, Product Manager at Club Pro Card
Cross platform development is a complicated topic. The promise is that it is ‘write once and run everywhere with no modifications’. Nothing could be further from the truth for any application that is beyond simple demoware.
There are many questions to ask.
- First off, what do people mean by cross-platform development?
- Do you want one executable that runs across various mobile devices?
- What about code that is compiled for each platform and then runs on the device?
- What about the user interface? Users want applications that look like all of the other applications on their device.
- Do you have code that provides native UI controls for each platform?
- Do you give the user non-native UI controls?
- What about time to market?
- What happens when engineering has one set of expectations and users have others?
I’ve built applications with cross-platform tools and then users want additional features that are only a part of the native platform. Do you start over? Do you spend a lot of time trying to create a more native looking platform? When you do this, the costs can easily increase above and beyond the cost of multiple native applications. What do you do regarding the inevitable bugs in the cross-platform toolkit? There is no simple answer to any of this that works correctly in every situation.
The absolute best thing that customers can do is to talk with professional developers that understand the issues, have a face to face discussion regarding the situation, needs of the application, and such. From there, it is possible to determine the best course of action.
#4 The two deciding factors are scaling and time-to-market
Running more places is better, but what does it cost? It may take more development effort. It certainly will take more testing effort since each platform will need to be tested separately. You also have to decide whether to develop using the common features of each target platform, creating a generic application or take advantage of each platform’s unique features but write (and test and maintain) more code.
One deciding factor is scale. If you’re an enormous company, increasing your user base 1% by supporting an unpopular platform may be a big win. If you’re a small company, maybe not.
Another factor to consider is time-to-market. The best approach may be to target your biggest platform first, keeping portability in the back of your mind, but being willing to sacrifice it in order to get the first release out quickly.
#5 There is nothing compelling for the users in the cross-platform
I think the cross-platform is critical these days, as the mobile market is heavily divided between iOS, Android and to a lesser extent Windows. It is tempting to try and make one app work for many platforms without dedicated re-purposing, and I think this is generally a mistake especially for high-budget applications because it leads to a “non-native” look and feel.
Users are divided between iOS, Android and Windows, and then a handful of other lesser known operating systems. So, if you want to reach the maximum number of people, you need to make your app available to the devices that they have.
In the gaming market, which I know more about, it can make sense to build a game once in Unity and then deploy out to multiple platforms because the tooling of things like Unity is so strong.
So, cross-platform works really well in terms of games made with Unity.
There are a whole host of things that allow you to try and build a cross-platform app that runs on different platforms, but if you got the budget to create native apps for different devices, that is going to give you a better result.
Unless your app is a thin app, which is basically a repackaging of a website, you can’t just represent your website in an app because you need to add a little bit of more value in the app. If your app does a little more than a website would perhaps you could get results, but still not the look and feel of the native app.
So, building cross-platform depends on your budget, how fast you can iterate, how much of lost quality really matters to you and your users.
There is nothing compelling for the users in the cross-platform app. Done properly, native apps are going to give better user experience.
It might be that the features of iOS allow you to do something earlier than Android and vice versa and then you will be tempted to do that. But perhaps a cross-platform tool will prevent you from doing that. If you are going to use one of the cross-platform tools, you are always going to be lagging behind.
So, you produce a product version one, you make the specializations or the special changes to ensure it is smooth on iOS and Android. When you go to your version two of the core product, you’ll have to start again. So, new features will take you longer to build in cross-platform.
The other thing is somebody like Apple, may mandate a new way of doing things which may mean you need to make a fundamental change to your app to keep it like iOS. If you are in a cross-platform, you may find that leaks across to the other platform. So, if you want to build a cross-platform app, check how that will change your core product.
#6 Cross-platform frameworks are last resort in my technology analysis
I usually look at cross-platform frameworks as a last resort in my technology analysis. Native framework providers still provide the best solutions from a user experience and performance perspective. Cross platform has its place though, it requires careful planning to ensure it is a good fit.
From a project perspective, I get the appeal of cross-platform, but it still remains a bit of an ideal on many projects. I too want to have a single code base instead of multiple to maintain. From a practical perspective, it is very difficult to create a great user experience with cross-platform frameworks. There are several reasons for this.
- Native app software framework providers work very hard to make sure programmers have access to the full device capabilities. There is more than creating a great user interface. There are also options to turn on and off with the device, wireless features, sensor access and others. Access to these features is limited in a multi-platform framework, which means you have less to work with.
- Cross platform frameworks often have inherent performance issues to work out. One way to think about it is you are using an extra layer between your app and the device. You can almost always tell apps that are developed with these frameworks because they feel less responsive and a bit sluggish unless the team really put in the time to optimize them.
- Look, feel and UI guidelines differ between major mobile platforms. Apple have their way of doing things, Google has theirs, Microsoft has their own, you get the picture? For example, on Apple devices, we are used to app button controls on the bottom of an app, but on other platforms, people may be used to them being on top. Cross-platform developed apps often look a bit weird on different platforms because they may not follow any UI development guidelines, or they follow the preferred platform of the people who developed them. A one-sized fits all solution is very difficult to do well and requires a lot of design work. To do it right, hire an app design agency to look at each of the platform development guidelines and figure out a way to be compatible.
- Bug fixing can be a bit of a nightmare on cross-platform solutions because there is a lot of fragmentation in hardware and certain devices may behave differently. Even within Apple devices, there can be a lot of variation in hardware. For example, your app might rely on a particular movement sensor, and one model of the device uses a different vendor than the others. It turns out it is not compatible with your cross-platform framework. Tracking these issues down can be incredibly time-consuming and frustrating. People don’t report bugs that tell you these details, they can’t see or figure out what is wrong, all they know is they were doing something, and your app crashed. Your native framework provider has solved these issues but they haven’t made those solutions public. (After all, they want you to use their solution, not someone else’s.)
- The time savings of using a cross-platform framework can be completely eaten up by addressing the above issues.
That said, I’m not against using cross-platform frameworks, they have their place to be sure. However, they do not offer the easy solution that they might appear to. They are still a lot of work and have unique challenges. I have seen them used well for certain classes of apps, but they required planning, skill and a lot of research from an experience and technical implementation perspective. I have witnessed several teams that weren’t prepared look to them as an easy solution, only to drop them after significant effort and go with multiple native solutions instead because it was an easier path. With proper planning and taking the above considerations into account, multi-platform can work well.
I have enormous respect and empathy for cross-platform framework providers. They have huge challenges, and I hope that in the near future we will be able to get the same user experience as with native solutions. I worked with similar technology in the pre-smartphone era and it was incredibly frustrating trying to keep up with the native providers. Some of them changed their APIs and hardware implementations frequently, putting cross-platform solutions like ours at a disadvantage.
#7 Native has unmatched user experience as compared to cross-platform
Rahul Varshneya, Co-founder of mobile innovation consulting firm, Arkenea, Contributor to Inc, Entrepreneur and Huffington Post
Time and again, cross-platform technology has proven to under-deliver when it comes to building an experience rich mobile app. In my opinion, though, there’s nothing wrong with cross-platform technology or platforms per se. The problem is in the reason why people use it and what they leverage it for. The most common reason for building on cross-platform technology is cost savings. And that’s the worst possible reason why one should leverage cross-platform for.
Cross-platform technology should ideally be used for validating a product concept with a closed user group or a focus group, where you want to test very specific things and get feedback from an audience that is diverse.
Once you get your desired feedback, build a native product, which has unmatched user experience as compared to cross-platform technologies.