Web, Hybrid or Native Mobile apps – which one to choose? In the previous blog article we discussed web-based communication solutions and their advantages over native ones. This time we will discover why it is more preferable to use native or hybrid applications for mobile devices.
Mobile devices like smartphones and tablets have two important limitations:
- CPU and battery usage
- Technology limitations
Because these two factors must be taken into account, collaboration apps for mobile phones must still be native or hybrid apps. Native means using Objective-C and Swift (with iOS devices) and Java (with Android devices). Hybrid means that a mix of native code and Webviews are included in the app.
This approach was demonstrated by companies like Facebook and their early attempts at using only web standards when making a real-time app. Their attempts at using only web-based apps (usually WebView inside a native app) were unsuccessful.
I believe it is only a matter of time before technology will overcome these obstacles. Meanwhile, let’s investigate, in detail, why building communication applications using only web apps is so difficult.
Technology limitations
Apple just recently added support for WebRTC in iOS 11 and Safari, and still continues working on it. As such, there are still problems with using the phone’s microphone and speaker to make a call simply by using Safari or a WebView.
Chrome for Android supports WebRTC, but the operating system automatically puts the app to sleep if the user does not interact with the device. This behavior causes interruptions to calls/conferences.
PUSH Notifications, which are necessary to inform the user of incoming events when the web app is closed, are even more necessary on mobile devices, as the browser activity stops immediately when the user changes tabs or moves to another app.
Unfortunately, mobile browser PUSH notifications are currently only available in Chrome and Firefox for Android.
Other issues involve:
- Lack of audio device selection (for example, to switch audio to a Bluetooth headset)
- Lack of complete hardware interaction (for example, with the proximity sensor)
In conclusion, pure web-based applications can currently be used for chat applications on all platforms, and also for casual voice calls using Android (which already supports WebRTC).
CPU and Battery Usage
Web apps (using JavaScript) typically use more resources (CPU/memory) of mobile devices than well-written native apps.
As a consequence web apps usually run slower than native apps and use more battery power.
Call Interruption Protection
In the past, a common problem was that VoIP calls on iOS and Android devices could be interrupted at any moment by incoming mobile calls.
CallKit for iOS 10 finally allowed developers to completely integrate VoIP calls within the smartphone native call history and management. VoIP calls are no longer interrupted by incoming mobile calls. Bluetooth headsets that are compatible with the smartphone can even be used to control phone calls.
Make sure that the smartphone VoIP application provided with the communication solution you choose supports such features for both for iOS and Android. If you are about to build such a solution, make sure CallKit support is on your list.
Conclusions
As we saw previously, web apps can be used on mobile devices, but with limitations. They are perfect for occasional usage by customers because they provide the same advantages as web apps on computers: easy access and integration inside websites, without requiring the installation of third-party apps.
Teams and recurrent users should instead use a native app that supports audio, video, screen sharing sessions, and other important features (such as call interruption protection via CallKit). As already mentioned, it is just a matter of time, but currently, only native apps can guarantee a solid user experience.
In the next blog posts I will explain what SIP, XMPP and WebRTC mean, and why they are so important in any communication solution.
Information request: