I’m a huge proponent of hybrid mobile app development. I work on the Ionic team at OutSystems, I create content around Ionic’s tools and services, and I’m even writing this for the Ionic blog so it’s completely fair to say I have a bias (as well as a vested interest) in the success of Ionic. I am proud to share the elegant solutions we develop to the problems developers face because I believe it simplifies development.
Today, I want to take a different approach. As someone who has established a strategy for mobile app development projects, I want to shed my Ionic hat and examine the hybrid versus traditional mobile app development debate from a broader perspective that ignores Ionic’s contributions.
During my time working on mobile app strategy I found myself directly contributing to native and hybrid codebases so I can speak to the challenges associated with multi-platform development without needing to focus on specific technologies. My objective is to analyze the conversation to assist you in making the best decision for your project and to set you on a course that contributes to its success. Whether that includes Ionic or not!
Caveats
To begin, there are numerous limitations to the mobile app development strategy; however, in my experience, there are probably three primary considerations that development teams make when selecting a technology: time, resources, and money. While there are development teams that don’t have to take these categories into consideration, every mobile app development project I have worked on has been constrained in one way or another by one of these categories. I’m going to assume, based on my knowledge of mobile app development, that these categories likely limit you and your teams. Second, app development is fraught with fanaticism, particularly when deciding which technology or approach is “better.”
If I have learned anything in the last ten years of app development it’s that “better” is relative to the boundaries of your project. In the words of Adam Savage, “Every tool’s a hammer” so you can really make your mobile apps with a lot of different technologies but I would rather put nails in a wall with an actual hammer instead of my MacBook Pro. Instead of just giving you a tool that doesn’t matter, my point is that I want to assist you in defining the scope of your project so that you can narrow the list of tools. Since my goal is not to dispel fanaticism toward particular technologies or tools, I am assuming that you are defining strategy independently. Naturally, if your team doesn’t use technology, use the tools at your disposal to do what’s best for you and your team. With that being said, let’s dive into it!
Background
According to a recent article from Ionic, “there are more than 5.5 million Android and iOS mobile apps on the market.” This means that developers and development teams must produce high-quality applications in order to not only meet industry standards for a regulatory landscape that is constantly changing but also to exceed user expectations, which are defined by an ecosystem that is shaped by development teams much larger than themselves. Mobile apps are getting more difficult to build in order to stay compliant but you and your teams are competing against much larger development teams to get users in your mobile apps. The reality is that creating compliant mobile apps with killer user experiences can take a significant amount of time, money, and resources and those larger development teams likely have what they need to do that.
However, creating high-quality mobile apps that exceed user expectations while staying on budget and meeting deadlines is difficult even with well-equipped development teams. With any method that you and your teams employ, creating mobile apps is difficult. Fortunately, there are ways to streamline the software development processes and produce superior mobile apps but it requires us to look at what strategies are available to us.
Strategies
When discussing mobile app development there are typically two main styles of application development strategies that people refer to: Traditional & Hybrid app development.
Traditional mobile apps, or native apps, are written in a language and format specific to their platforms. In this case it would refer to Swift/SwiftUI/UIKit for iOS in Apple’s ecosystem and Java/Kotlin for Android in Google’s ecosystem. Depending on whether you’re building mobile apps for iOS or Android, these traditional mobile app development ecosystems use various languages and methods to build, test, and deploy apps.
Hybrid mobile apps are installed directly on the user’s device and written in a single codebase. Having a single codebase significantly reduces the complexity of testing, deploying, and managing apps, despite the fact that you still need to work with the differences between iOS and Android. To deliver for both platforms, you don’t need specialized talent working independently on an iOS or Android app, and every developer on your team can contribute to both platforms. This is accomplished by wrapping the underlying code in a native container that runs on the user’s device.
The data layer, the business layer, and the presentation layer are the three fundamental layers of architecture that underpin both traditional and hybrid applications. It is essential to comprehend that every component of the architecture contributes to determining the strategy of what will be chosen for the presentation layer, even though the discussion of traditional and hybrid app development strategies typically focuses on the presentation layer. The data and business layers each consume their own time, money, and resources so limitations can have a significant impact on what can be done with the presentation layer. For instance: if you have a limited number of full-stack developers whose talents all rely on JavaScript, and they utilize JavaScript throughout the architecture of the application, then it’s more likely that the team will try to utilize that skillset in the presentation layer to reduce complexity when building the app. Teams can definitely go against this but the time, money, and resources required to build the app can grow dramatically.
The Possibilities and Risks of Traditional Development As someone who has contributed to native codebases, there are benefits to choosing traditional development when you are building your mobile apps. The benefits include the ability to use the latest – and greatest – features of the platform you are developing for, the ability to have more polished user experiences, and the chance at having the “most performant” app. It might seem contradictory to discuss these benefits of traditional mobile app development on the Ionic blog but I do think there is a time and place for traditional app development.
The ability to utilize the most recent or platform-specific features created by Apple and Google for their ecosystems is, in my opinion, the greatest benefit of traditional mobile app development. This is advantageous because hybrid platforms typically lack native integrations for these features, necessitating in-house integration development, or because the feature you are developing would not benefit from a hybrid development approach. A perfect example of this can be found in a recent article I wrote on using AR Quick Look with Capacitor where I leveraged Apple’s AR technologies in a hybrid app. You can do it, but outside of the specific use cases described in the article, it doesn’t make sense to incorporate it into most projects because that feature is only available in Apple’s ecosystem, where it would be simpler to develop it. The polished user experiences are the subsequent benefit. Apple and Google both have their own user interface guidelines for building successful apps within their ecosystems that vary from one another. Users in those ecosystems expect their mobile apps to look and function in specific ways so, in a hybrid approach, you might be making some level of sacrifice for cross-platform capabilities that you wouldn’t have to take in a native development approach. You also have the ability to fine-tune in greater detail each platform’s user interfaces and user experiences than what is available using a hybrid development approach.
The last benefit is performance. The reality is that with a hybrid approach you are adding a layer and there is a cost in performance that happens that wouldn’t necessarily exist with a traditional mobile development approach. This is especially true with Apple’s ecosystem where the code is literally developed for the hardware that it’s running on. This means that with native codebases you can technically create “more performant” apps than what you can utilizing a hybrid approach.
While these benefits look good on paper, practically, it’s not beneficial when developing your applications in most cases. Few projects utilize the newest features within the first several months of release and, by the time development teams do plan on integrating those features, they are usually available for use in hybrid development approaches or the features wouldn’t be beneficial on multiple platforms (i.e. the AR Quick Look project I mentioned earlier). In the case of fine-tuned user experiences, the experiences become overly engineered to the point where there is no longer any connection between the various versions of your mobile apps and they become completely separate applications, making management of them more and more difficult. If you read my article on performance, then performance is a diminishing return that greatly depends on the actual architecture of your apps and has little effect when compared directly.