In the early days of your product's mobile app, deciding on a tech stack, that will help you achieve rapid delivery at minimal cost, is absolutely key to a project's success. With different development approaches and frameworks on offer, this decision can be very daunting. Here's how my team went about making this decision over 3 years ago and what we learned in the process.
At Samewave, as with many early-stage products, it was paramount that we got a viable product to market in a cost-effective and timely manner. Hybrid mobile app development became a very attractive option for us because:
- When we started out developing our product, the Cape Town and broader South African developer market had a skilled developer shortage.
- Niche development skills, like native mobile app development, were even more scarce.
- Since our user interface was going to be similar across all platforms, we could leverage our developer's existing skills.
Since making the decision, we've been able to successfully deliver our product as a hybrid mobile app for over 3 years now. Let's unpack now how we got to this decision.
The development options
When we had to decide on a tech stack for our product, it was essential to first understand the options that we had and how they compared.
The three mobile app development options available today will all result in your app being added to Google and/or Apple's app stores. Which means that users are able to install them on their phones quite easily. However, the journey of getting your application to this point differs fundamentally.
Native mobile apps
For the ultimate in performance and capability, nothing beats writing native mobile apps with the language and Software Development Kits (SDKs) that are provided by the mobile operating system (OS) providers. This is because you get full access to the capabilities of the phone and OS, while the app runs at an optimal performance level.
This approach usually comes at a higher cost though, because you have to build a separate app for each platform you want to support. It wasn't a viable option for us due to the scarcity of native app development skills and the time and cost implications.
You can read more about native app development here: iOS and Android.
Pseudo-native mobile apps
These apps are single codebase, cross platform apps that are developed once and can then be packaged as a native app for each of the specific platforms that you need.
Similar to hybrid mobile apps, these frameworks allow developers to write code in well-known languages once, and then deployed it multiple platforms. At the same time, this development option also provides the performance benefits of native apps because it compiles to native application code for the various, targeted platforms.
While this sounds like a clear-cut winning option, it needs to be carefully considered because of drawbacks like these:
- For anything beyond standard functionality, you might still need to write some native code for Android and iOS.
- When new features are made available by the OS providers, there might be a delay before they are available in the framework. This means that you'll need to implement them yourself.
Examples of frameworks for building pseudo-native apps include React Native, Xamarin and Flutter.
Due to us starting this journey over 3 years ago, when pseudo-native app development was still in its infancy, it wasn't a viable option for us at that stage.
Hybrid mobile apps
These are essentially web apps that are wrapped in a native shell and executed in a browser context, called a webview. The big draw of hybrid mobile apps is that you can write the code once and then deploy it to many mobile platforms using well-known web technologies, like HTML, CSS and JavaScript.
But, this flexibility does come at the cost of having inferior performance and less capability when compared to native apps. Since your app is essentially running in a browser, and not as a pure, native app.
Examples of frameworks for building hybrid mobile apps are Cordova/PhoneGap, Ionic, Framework 7.
I'll explain the reasons why we ended up going with this approach in more detail below.
How do you know which approach is best suited for you?
As with most things in tech, there's no one-size-fits-all-solution, and it comes down to trade-offs. Having gone through this hard, decision-making process ourselves, we realised that you have to take the following factors into consideration:
- Budget
- Resources
- Time frame
- Feature set
- User interface
- Performance
When making your decision about which approach to use, the idea is to:
- Evaluate the needs of your app based on each of these factors,
- Weigh up how important each factor is in your specific context, and
- Get a feel for the option which might be best suited to your needs.
Based on these factors, I've put together a mini-framework that can guide you towards making a tech stack decision for your mobile app. Each section also includes a favorability scale that compares how favourable each development approach could potentially be.
Budget
Building apps natively requires you to write more than one app and possibly hire different developers for each app, which will be cost intensive.
In contrast to this, hybrid and pseudo-native apps can potentially be more cost-effective. Since you can re-use your team's existing skills, while cutting down on the time and budget that it takes for them to write and maintain separate codebases.
To figure out your budget constraints, you should ask yourself:
- Do you have restricted financial resources to get your app to the stage of product/market fit?
- What financial investment are you able to get over the short-to-medium term?
Samewave's budget was constrained because we were an early-stage startup with limited funding and a product/market fit which had yet to be proven. That's why we needed a solution that would allow us to iterate fast and get to the point of validation as soon as possible. This made the question of budget one of the biggest contributing factors towards our decision against native mobile apps.
Resources
When deciding on a tech stack, it's also incredibly important to have a close look at your team and their potential. The skills and talents of your existing development team will impact the viability of the development approach you choose. For instance, if you have an existing team of developers primarily experienced in web development, it might not be feasible to expect them to deliver pure, native mobile apps.
It is important to consider these questions:
- Considering the skillset of your current development team, is it possible to upskill them in a reasonable amount of time?
- Can you hire developers for the skills that you will need?
- Is the talent pool in your region sufficient for scaling?
- Is it a viable option to source remote or offshore developers to do the work?
At Samewave, our team consisted of developers who primarily had web development experience and skills. We chose to make use of those skills without bringing in more developers at that early stage. This helped us to keep our budget spend limited and deliver within a short time frame.
Time frame
This primarily relates to how much time you have to get your product to market. If the opportunity gap is short, you have less time available to get your app to users before they are potentially obtained customers of your competitors.
By developing apps natively, instead of with hybrid or pseudo-native frameworks, you are likely to have a longer lead time before your app is in the hands of your users. This is because you might need to hire new developers or upskill existing ones to develop separate apps.
That's why it's important to understand how much time you realistically have to get to market. If timelines are tight, you might need to consider a stopgap solution like going with a hybrid app for an initial release, and then looking moving to a native app in the long run.
While we wanted to prove Samewave's product/market fit as soon as possible, no competitors were dominating the specific market yet. This meant that there wasn't an immense amount of pressure to race to market, since we didn't have to beat or catch up to a competitor. As such, this factor didn't carry too much weight in our decision, whereas it might be more important in your specific circumstances.
Feature set
With native app development, the features you can implement are only limited by the capability of the platform that you are developing for. With a hybrid app, you are limited by:
- What is feasible in a browser context, and
- The native device features that you are exposed to you in your chosen framework.
Having a view of the features that your app will have, and the hardware that will need to be accessed on the device is essential to finally settling on an approach. You don't want to commit to an approach just to realise down the line that a key piece of your app's functionality relies on device access that isn't provided by your chosen framework.
Since our mobile app was an evolution of our web offering, our feature set was fairly basic and we had limited device hardware access requirements. This meant we could rely on the capabilities of hybrid app development.
User interface
If you want your app's user interface (UI) to look and feel like it 'belongs' on the platform you are running, then it will need to conform to the design and user interaction guidelines for that platform. These can differ a lot between platforms and you will need to optimise the user experience to stay true to the experience that the user is expecting.
However, if your app's user interface is unique to your brand and it doesn't inherit many aspects from the native OS's UI, then you'll likely want to create a consistent experience for your users across the different platforms.
Our app's user interface was fairly custom-designed and didn't have a strong requirement to leverage the native OS's design patterns and behaviour. So, we were open to adopting a hybrid development approach, instead of being forced in the direction of native app development.
Performance
If you need to run complex algorithms, or have a long list of complex, laid out data that the user needs to scroll through, you can safely assume a high need for rendering and processing performance. You will then need to get an understanding of the rendering and processing performance needs of your app.
Native apps offer you the best rendering and processing performance since they run at the most optimal level on the OS. Contrastively, hybrid apps are the least performant option due to:
- Them rendering within the context of a browser, and
- The overhead associated with parsing and executing JavaScript.
While we weren't planning on running complex algorithms or processing large amounts of data, we did need to render fairly complex layouts in long, scrollable lists. We didn't initially appreciate the performance impact that this would have, and it became clear over time how draining this particular feature was.
While no single factor should determine your choice, the one that I would highlight is performance as it can be very detrimental to the user experience of your application if you get it wrong.
Looking to our future
The hybrid mobile app development approach served us well during our initial phase of getting to market, since it helped us:
- Keep our costs low
- Utilise existing developer skills
- Get to market in a timely manner
- Deliver on our feature set
- Create a consistent user interface
- Deliver an acceptable, performing app
While it has its limitations and can throw a curveball every now and then, hybrid mobile app development is an option worth considering. This is because it can be the difference between launching an app successfully, or it becoming one of those that failed to launch.
We have reached the point now where we want to take our product to the next level so that we can offer best-in-class user-experience and performance. This means that we are evaluating whether mobile hybrid app development has taken us as far as it can. As such, we are currently re-evaluating our needs and aspirations to see where the future of our mobile app development will take us - this is most likely away from hybrid and into native app development.
Resources
- Airbnb share their experience using React Native to compliment their native apps.
- Ionic Framework (hybrid mobile app framework) published an eBook on Hybrid vs Native app development.
- The Front End Happy hour podcast discusses native mobile solutions.
Jean is a Senior Developer at Samewave where he focuses on their application's web, desktop and mobile client apps. This allows him to live out his passion for creating user-friendly product application interfaces. In his spare time, he keeps himself entertained with sports, gaming and spending time with his quadruplet daughters.
