There is a significant amount of discussion on the web regarding native vs. web vs. hybrid apps. Here is an interesting one. Here is another one. This one discusses Uber and Instagram. A couple of these discussions are oldish, so things may have changed. For the record, here is a definition of terms:
Native App: An app that is written in a compiled programming language, using the operating system’s API.
Web App: An app that runs on a web browser inside a native app.
Hybrid App: An app that uses both web browsers and native code.
And let me offer a caveat as well. Most of what I am going to say applies primarily to iOS. Android uses Java, which is a fundamentally bad choice from a performance perspective (although I understand Google chose it for its “write once run anywhere” paradigm). Additionally, the Android API is very splintered. There are a large number of API versions, and these are written for a dizzying array of hardware. It is impossible for the average developer to test his codebase on anything but a fraction of these hardware platforms, and so an HTML5 web app may be preferable. On iOS however, the story is different. There is a high degree of similitude among the hardware platforms that iOS supports. Additionally, Objective C and Swift both compile to machine-executable code (not bytecode as in Java).
Based on the links above, it appears that most (but not all) of today’s popular social media apps are hybrid, but generally rely heavily on Web Browsers. To some extent, this is understandable give the fact that many of these companies began as web companies, and so probably designed their API’s to return HTML. ZipZap 2.0 has the advantage of having undergone a complete rewrite, and so we were able to take advantage of the latest standards and methodologies. Hence our API uses JSON exclusively, and so is easy to parse and display in either a web or native environment. Of course we still use a web browser as a web browser, but our experience with both the UIWebView and WKWebView has convinced us (in our already strongly-held belief, I should add) that native apps are superior in every way to hybrid apps.
Limitations of Web Views
As already mentioned, the WKWebView is quite efficient at rendering content. However, there is still tremendous overhead in parsing HTML and translating that HTML into the native elements (e.g. UIImageView) that make up a standard view. Creating UIImageViews and labels, and placing them directly in code, is far more efficient. In addition, Web pages require almost infinite display flexibility, and so must handle a tremendously large number of cases. A native app only uses a subset of those cases, and opportunities abound to optimize the display code.
Interfacing with the Camera and GPS, encrypting local storage, and a whole host of other functions are very difficult or impossible to carry out in HTML5. Indeed, the need to implement these functions is what drives most apps to by hybrid, rather than strict web apps. The requirement to interface drives the iOS developer to use the UIWebView (to preempt cross-domain scripting errors), which encumbers the developer with the memory management nightmare attendant to that view.
From a strictly performance perspective, native code is always better, and that is why we developed ZipZap Streams natively. However, there are often business considerations that override performance considerations in any endeavor. For our part, we decided that having a fast and stable app is of the utmost importance. However, we don’t yet have an Android app, and might not ever have one. That is the cost associated with doing the iOS app right. Not everyone will make the same decision.