Native Social Media App

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.

Here’s why:

Limitations of Web Views

The UIWebView, which was the only one available on iOS until iOS 8, suffers from a serious shortcoming — memory management.  It is a memory hog, and the programmer does not have any control over the Javascript garbage collector.  This results in an app with a significant memory footprint that is nigh-upon impossible to contain.  The result is a progressively slower app that ultimately gets killed by the OS.

The WKWebView is a lot better, but is also seriously limited.  First let me say that it is a wonder of speed and memory management, and it is the view that we use in ZipZap for the web browser.  In fact, if an app is going to be written 100% in HTML5, then using the WKWebView is probably a legitimate option.  However, this view enforces limitations on cross-domain scripting. so that integration of native functions, particularly the use of JavaScript injection from the app side, is essentially impossible.  For example, the app cannot call a JavaScript function that exists in a third party library from the app.  The call will fail for because it is considered to be a cross-domain call.

Execution Speed

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.

Memory Management

The programmer interfaces with HTML5 pages with Javascript.  The V8 Javascript engine used by the WKWebView is extremely robust, but it still takes control of memory management away from the programmer, and puts it into the hands of the engine writers.  This is okay for most situations, but it prevents the programmer from optimizing and reusing display elements in the display layout.

Hardware Integration

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.

Conclusion

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.

Leave a Reply

Your email address will not be published. Required fields are marked *