Hybrid apps in healthcare, part I - What to consider in the decision making

Hybrid apps in healthcare - What to consider in the decision making

Codepole recently held a webinar for Swiss Healthcare Startups in Switzerland. The webinar specifically was focused on shedding light on hybrid mobile applications, its suitability for healthcare apps, along with decision factors and how to approach such a decision. In this blog post, about decision factors, we will reiterate on what was presented at the webinar with also a bit more depth to the content. There will be a second blog post on how to approach the decision making in this area.

Quick repetition on what hybrid applications are

When building an application, you generally have 3 options. You can build an app to be:

• Native. This means that the application is written for a specific platform (i.e. Android, or iOS). The coding language is also specific for a given platform. Typically, this is Kotlin for Android and Swift for iOS.
• Web. This means that the application is written specifically to be working well as a web page (which can be browsed through PC or mobile). The coding language is also reflecting this, typically HTML5, CSS, or Javascript.
• Hybrid. This is a spectrum in between native and web. Typically, hybrid apps rely on web technology that is wrapped to allow app store publishing, or rely on cross-platform technologies that allow one code base to be deployable regardless of platform (i.e. Android, or iOS). Flutter and React Native are the most popular languages of the latter.

When is it relevant for me to start thinking about this?

We tend to ponder about new features and capabilities rather frequently. I suggest that we do the same when it comes to the technical stack and technology that we’re using. With this said, to decide on above is also a two-way door decision which means that it’s reversible (with some effort of course) - you can go with one early on and later change as you’ve validated the product further. You can also select one and stick with that for the foreseeable future. 

This means that it is relevant for you regardless of the stage of your product (idea, concept, MVP, production) and regardless of current state (no application, web application, native application, hybrid application). Of course, it is natural that such a decision occurs before an application is built - but we’re also big proponents of continuous evaluation of one’s tech stack and technical strategy.  

Decision factors to consider

There are of course a multitude of factors to consider in the decision of going hybrid or not. In the webinar, we shed some light on what we consider to be the most important factors.

Who are your users

As you are building an application, you will hopefully have end-users of that application. It’s important to ensure you decide on an approach that resonates with your users, otherwise they will be less inclined to use your application. 

• Age. Younger people today expect an application (i.e. not webpage), an application that is smooth, looks well-made, and that is fast. For a younger population, a native application is often preferred. For an older generation, usage on their terms is more important (e.g. desktop), function over perfection, and ideally something that is consistently looking across platforms. In this case, a hybrid approach is preferred.
• Market share of application devices (iOS, Android, web, mobile, desktop). In some markets, the share of iOS vs native might be well balanced, but in others greatly weighted to one over the other. A recommendation, especially starting out, is to also look deeper at region or client specific conditions. 
• Accessibility. Native apps typically support easier implementation of accessibility standards on mobile applications. However, hybrid applications offer deployment to multiple platforms, with a consistent look & feel which supports accessibility as people may use your product on their terms (e.g. through desktop).

Complexity of product

What is the technical and operational complexity of the product, or what will it be in the close future? For example, will you need to do heavy on-device computations? have bigger data volumes generated through the usage? Will the application be filled with a big amount of animations and graphics? If the answer is yes to any of these, a native approach is recommended as they excel in the area of computational performance and graphical performance. If your application will be and stay relatively low in complexity, a hybrid approach is recommended.

Native functionality of device

If you need to access native functionality of a device - for example camera, microphone, GPS, calendar, etc. - the general recommendation is to go native. Today, there are plug-ins that allow hybrid apps to also leverage device functions, but typically this is recommended only if no device function is required, or at maximum 1 or 2. There are also technical strategies where an application can be mainly hybrid, with some elements of natively written code. 

Platform consistency

Native applications are notoriously known for having their looks and feel be adapted to the platform to which they are being operated.

Specifically, an iOS user will for example expect the navigation of an app to work and look in a way that is consistent with ‘iOS’, while an Android user will expect the same but for Android. In the image attached, you can see the phones’ settings section for iOS and Android. Notice how navigating back is different. Due to this, a native approach is recommended if these nuances are important. In the long run, a natively written iOS and Android app might look different. That inconsistency may grow over time as the change speed to each platform differs.

A hybrid approach also allows (for the most part) consistency across platforms - i.e. your application will look the same on Android and iOS. This might be very powerful if you need to deliver your product on multiple platforms at the same time. 

State of the company

As with many product-related decisions, there are always trade-offs. Typically this is within the triangle of time, cost, and scope. 

• What is the budget? Native applications are typically more expensive from start to finish, and tend to take a bit longer time. Hybrid apps are relatively cheaper and faster to develop.
• How is the team structure? Building a native application requires platform-specific competence (i.e. iOS engineer, Android engineer, etc.) while hybrid applications require domain-specific competence (i.e. Back-end engineer, front-end engineer, full-stack engineer). Consider your current and desired state. 

• Building a native application - you will need to scale 2 competence-verticals (iOS and Android) as you grow the team.
• Building a hybrid application, you will need to scale the domain-competences (FE, BE, full-stack) although it’s a good bet to start on full-stack engineers only in the beginning.

Security

Regardless of what technical approach you select, including the coding language, there will be some inherent risk (medical risk, information security risks, etc) that are there. You will always need to assess those risks and put appropriate mitigations in place to ensure a safe product. 

Generally, native applications are considered more secure than hybrid apps. One aspect is that native applications have access to platform-specific built-in security features. Another is that hybrid apps have an additional layer of code per design to allow the application to exist on app stores, where another layer of code equals additional code that is vulnerable. Lastly, hybrid applications using web views must also consider web-specific vulnerabilities.

Again, it does not mean that native applications are invulnerable. Overall, always assess risks in your product and place appropriate mitigations in place.

Other market conditions

• Is the competition fierce? The speed and performance that a native application provides might be a required edge. Or perhaps multiple platforms (iOS, Android, Web) might be a required edge.
• What are your clients (e.g. clinic owner) expecting? Perhaps they have different concerns than you - For example, your client doesn't care about how much you spend on development, but they might care that their patient population is addressed in its entirety. Or what are tender requirements specifying? Perhaps there are requirements that only a native approach can resolve? Or perhaps the flexibility of a hybrid approach will allow you to compete for tenders in multiple regions/countries?
• What are your partners expecting? Perhaps they require an equal look and feel before an integration is to occur between your product and theirs. 
• Is the product validated? To test an idea, a concept, or a product - a hybrid application may offer you an attractive speed and price tag, outweighing the limitations. After you’ve validated your objective, you could pivot to a native approach.

Ending note

It’s always difficult to prescribe a set of “here are all the check-boxes you should consider”. However, we hope that this blog post at least shed some light on what you should consider. There might be additional factors to consider, so always consult your team, an old colleague, or someone with experience in the area that can help you out.

A video extract of our webinar where our explorer Gustaf explains the decision factors to consider in deciding for a hybrid approach in healthcare can be found here.

Feel free to reach out if there are any questions or you would like to get access to the full webinar recording,

Robert