When coming to mobile app development, there is always a debate whether to make a native mobile app or to make an HTML-5 mobile website. Let's have a look then:
| Native App | HTML-5 Site | |
| Activation | Long and winding - go to App Store or Google Play, locate the app, download, install, open the app and locate the target content | Short and simple - with the web link, click and open it with a built-in browser |
| Development cycle | Long | Relatively shorter |
| Platform supported | Different app for different platforms - iOS, Android etc.; but not available for desktop | One site for different platforms |
| Cost | Expensive: cost usually doubled for iOS and Android | Economical: only develop one site |
| Performance | Fast for user interface or interactive elements | Relatively slow for loading screens |
| Push notification | Available | Available via web browser with a session; can only make use of emailing without a session |
| Interfacing with device peripherals e.g. camera, mirco-phone, location, accelerometer and other sensors | Available | Mostly not available, unless interfacing exists via web browser |
To strike a balance between the 2 options, a mid-range solution becomes available to bridge the gap:
- Activation: same as native app. But because the HTML-5 mobile site is ready, users may also launch the app with a web link
- Development cycle: same as developing an HTML-5 mobile site, plus developing a native app with a web-view control linking to the HTML-5 mobile site
- Platform consideration: using the same technique, the major HTML-5 site is accessible for iOS, Android and desktop
- Cost: much less expensive than developing different version of the same native app for different platforms
- Performance: acceptable if game-like interaction is not a must
- Push notification: available
- Interfacing with device peripherals: not available
Therefore, whether to take the mid-range approach very much depends on the clients' requirements. Whole Person Education Foundation "ICAN" mobile app (iOS, Android) is one of the examples: They released a reference book to promote mental health care to the general public, and yet wanted to engage their readers via other more interactive elements. And of course, time and budget were limited, and so they decided to go for the mid-range approach i.e. to develop an app on both iOS and Android but with a web-view control linking to a mobile site running on ourDB, where different workflows have been designed enabling readers to:
- take a survey once per 3-month for 3 times and then scores on different aspects are given to assess their mental health conditions
- self-evaluate their health conditions by a report, where they can see whether they have improved or not based on 3 survey results
- review the book contents through vivid animations or videos with notification reminders according to their review progress
- post their comments about the book or other interactive contents to the foundation, and share them on social media
On the other hand, the foundation may log in ourDB backend to:
- analyze the readership by their dimensions like age, gender, affliliations etc.
- know which topics the readers are mostly interested
- see whether readers have taken surveys and from the survey results, how much mental health improvements the readers have
All in all, having known more about the readers, the foundation can make use the data to improve their publication contents and the events they organize, and everything as a result, to help people in the public strength their mental health and live a better life.