Users from all fields are increasingly using their smartphones and tablets for their extreme multitasking abilities and their efficiency. The medical field is no exception. The opportunity to touch the patient in healthcare and clinical research is large.
Companies, organisations or healthcare institutions may want their connected applications to run on the desktop, tablets and on both iOS and Android phones. Native, hybrid and HTML5 are the 3 different development technologies for designing and developing these connected applications. The choice of which technology you use will depend on what type of application you are building, who are your most valuable users and what is the development cost and time that is acceptable both short and long term.
In this blog, we deal with developing medical mobile apps, the problems developers encounter while creating these apps and how to surmount such issues.
Firstly, it’s good to get to know the different development technologies available:
The choice of native, hybrid or HTML5 for design and development of your connected app will directly impact:
- Time to market
- Design and development cost
- Ratio of in-house to external design and development resources
- Level of device flexibility
- Features and functionality
- Use acceptance that translates to tangible value-add
- Level of security
- App update and refresh cycle
Here are the questions to discuss with your company or organisation to see how does each of this technology stack up:
What App requirements/features are essential in this release?
|Requires computing power||Yes||Constrained||Low|
|Rapidly changing graphics or fluid animations||Fastest||Constrained||Slow for many|
|Update interface without new download, run A/B test||No||Some||Yes|
|Distribution||App Store||App Store||Web|
What level of device access do we need?
|GPS, accelerometer, compass||Yes||Yes||Yes|
|Security||High secure file storage and fast encryption||Medium-Secure file system, shared SQL||Low-Shared SQL|
|Offline use/local data storage||Online and Offline||Online and some offline||Mostly online|
What is our development budget and how experience is our team?
|Development & debugging tools||IDEs for rapid and precise develop, debug, test||Tools getting better but not as mature as native apps||Limited tools. Developers code in editor and debug in the 4 popular browsers|
So, when should you absolutely choose native or hybrid over HTML5?
|Offline access||Native||Many mission-critical applications have to function whether connected or not (e.g. data capture, inspections and data analytics). While it is and performance issues. As a rule, HTML5 is not a good choice if the user needs to manipulate and work with the data while disconnected and/or maintain transactional integrity for subsequent synchronisation. Native apps have no such limitations, offering unlimited, secure offline storage. Hybrid apps by default use HTML5 storage. A hybrid apps data-intensive mobile applications will require significant customisation. If offline storage and use is important for your application, you will want to choose native.|
|Complex applications||Native of Hybrid||While native is costly because you have to rebuild for each platform, HTML5 can become even more costly in debugging and testing if you try to create more than a simple, focused application. If you are developing an application with more than a single focus or an application that should “feel like” an iOS or Android app, you will want to choose native or hybrid.|
|Secure applications||Native of Hybrid||File transfer encryption is possible but slower than native. Implementing even trivial security measures that is standard on native platforms can be complex tasks for HTML5 app developers. If security is important for your applications, you will want to choose native or hybrid.|
No matter how much an app developer tries to create a foolproof medical app, she can never be certain that it be totally trouble-free, until and unless it has actually been developed and deployed to a particular mobile platform, which we will explore further in the next blog.