Over the last 6 months, I’ve been building , a mobile app that allows users to judge photo battles from multiple categories (currently Animals, Babies, Food, Funny, Men, Nature, and Women) as well as submit their own photos to these categories to be judged. Photos are ranked using the ELO algorithm (what Eduardo Saverin drew on the window during that awesome ), with the highest rated being displayed on Rizer’s Leaderboard. Rizer FaceMash scene in The Social Network Rizer is a Hybrid app that uses and its to gain access to important native functionality on the user’s device such as: receiving push notifications, taking pictures with the camera, and processing in-app purchases. Apache Cordova plethora of native plugins From the outset, it was critically important to me that the average user had no idea that Rizer was a Hybrid app. This meant it needed to be well-designed, performant ( ), not lacking any native features a user would expect from this kind of app, and not devolve into uselessness the moment the device lost its network connection. Thankfully, according to my 40 family and friend beta testers, I achieved this goal (and I might even agree with them). hey that’s not a word! If you don’t believe me, or if it has been awhile since you played around with what you knew was definitely a Hybrid app, then I encourage you to , judge some battles, check out a few categories on the Leaderboard, and if you are feeling brave, submit some of your own photos. You just might walk away impressed with what a Hybrid app is capable of, and if not, at least you got to see some cute animals and babies. download Rizer Make No Mistake, Going Hybrid Is The Right Choice For The Vast Majority Of Apps It is important to understand three key points here: Put simply, if your users never complain about the performance of your app then it is . As a performance junkie, I understand the appeal of knowing that my app is running as fast as it possibly can, but we must be careful to avoid premature and over optimization. It might make me feel all warm and fuzzy inside knowing that my Native app renders 100 photos on the page 8ms faster than the Hybrid version, but do my users even notice or care? No. A Hybrid version of an app will never be as fast as a native version of the same app, but it doesn’t matter as long as the Hybrid version is . fast enough fast enough . In these cases a native app is almost certainly your best option because a Hybrid app . Canvas performance has greatly improved in recent years, but older devices will still most likely run a resource-hungry app too slowly. A resource-hungry 3D game or similar does not fit into my definition of “app” will struggle to be fast enough . Bad performance can no longer be used as an excuse to ditch the Hybrid approach. If you have recently tried making a Hybrid app and have not been satisfied with the performance then you need to seriously reevaluate your chosen design patterns and/or use of massive libraries like jQuery that you . Learn the modern DOM API if you haven’t. It is supported on all of the devices our apps target. Well-designed Hybrid apps running on top of a modern JavaScript UI framework are definitely fast enough don’t need There are some advantages to the Hybrid approach: major This is the obvious key advantage to Hybrid apps but it really can’t be overstated. There are less than 10 times throughout my project that I needed to branch the code based on the platform the app was running on (this was only ever necessary to fix an iOS bug, but more on that later). A branch in the code would look something like this: You get to utilize your existing JS, HTML, and CSS skillset to develop a that runs on both iOS and Android. single codebase if (device.platform === "iOS") {doRidiculousWorkaround();} else {doThingThatWorksAsExpected();} Throughout development, I tested all of my code changes on my Galaxy S7 Edge. The phone was plugged into my PC with USB debugging enabled, running a “debug” version of Rizer. If you type into Chrome’s URL bar, you will see a list of all Chrome tabs running on any device connected to your computer. By clicking on Rizer in the list, a new DevTools window opens up and I am able to fully analyze the app like I would a normal website. Pairing this capability with a live reload tool in my build system, I am able to make a change to my code and see the updated result on my device’s screen within seconds. . Viewing changes on your device during development is nearly instantaneous. chrome://inspect/#devices Nice . Rizer uses service (which is currently free) and its to check for an update every time it launches, and I honestly don’t know what I would do without it. Alternatively, can be used in the same way, but since it’s not free and I wasn’t using Ionic, it didn’t make sense to use. You can push updated JS, CSS, HTML, fonts, and images directly to all of your users without needing to recompile the app’s binary and getting App Store approval Microsoft’s CodePush Cordova plugin Ionic’s Deploy . Rizer runs on top of my own frontend framework (Do not bother using this, it’s undocumented and constantly evolving to fit my personal needs), but I could have successfully built it on top of React, Vue, or Ionic/Angular. You can pick the UI framework and build tools that you are most comfortable with Samson.js “Wow Sam, those advantages sound great! Are there any disadvantages?” There is ONE major disadvantage to the Hybrid approach: We as developers still need to care about iOS, which means we have to put up with Apple’s BS. Hey that rhymed. You might be confused. Even if we went with the Native approach, we would still care about iOS and therefore would still need to put up with Apple’s BS, right? Kinda. Here’s some Apple BS we can’t avoid no matter what approach we use: Xcode Provisioning Profiles Needing a Mac to compile the app Needing to use TestFlight for beta builds Admittedly, the app review time has dropped to about , but when your app gets rejected 7 times like Rizer did (for legitimately silly reasons), your patience can really start wearing thin. The app review process. 2 days on average In addition to the above, Hybrid apps also have to deal with this BS: The iOS WebView Wait, what? Can the iOS WebView really be that bad? . Yes A Tale Of Two WebViews The code included in our Hybrid app runs in a WebView, which is essentially a native browser bundled with app. On Android, our code runs in a modern Chromium-based WebView that for the most part works exactly as it should. On iOS, we have the choice of running our code in one of two WebViews: UIWebView or WKWebView. JavaScript Choosing between these two WebViews . sucks UIWebView was introduced in iOS 2 and was the only choice until WKWebView was added in iOS 8. UIWebView has great compatibility with most of the existing Cordova plugins, but is overall bloated and slow. There is between these two WebViews, but there is a dramatic performance difference due to WKWebView’s use of the Nitro JavaScript engine. little difference in HTML 5 support According to , WKWebView provides: Nitishkumar Singh A massive reduction in RAM usage, faster startup, JIT JavaScript compilation, out-of-process rendering, reduced memory usage, improved stability, better security, up-to-date web standards, etc. Before the launch of iOS 8 in 2014, many articles touting started popping up. There was a lot of excitement amongst Hybrid app developers to be able to take advantage of the above optimizations that WKWebView provides. what a big deal WKWebView was for Hybrid apps Unfortunately, when iOS 8 finally launched, WKWebView couldn’t just be dropped into existing Hybrid apps due to its lack of some requisite functionality . A full 3 years later, the situation has only slightly improved. The Current State Of WKWebView Thanks to some , some masochistic developers (myself included) are utilizing WKWebView in their Hybrid apps. I will be the first to say that when WKWebvView works, . But what about when it doesn’t work? Let’s dig in. fantastic work from the Ionic team it really works Rizer cold-launches and installs CodePush updates dramatically faster on my wife’s iPhone 7 than on my Galaxy S7 Edge. WKWebView issues that require hacky workarounds or complete abandonment of functionality: Inability to access files that don’t exist in the app’s root “www” folder. . This was nearly a showstopper for Rizer because I needed to allow users to crop and add filters to their photos, both of which require manipulating the image in a canvas and then extracting the pixel data from it. I say , because I was actually able to workaround this by branching my code on iOS and doing the following ridiculousness: Numerous CORS (Cross-Origin Resource Sharing) issues, including being unable to extract image data from a canvas that was drawn using a local image nearly a showstopper 1. Pass the fileURL of the photo we just took on the device to the FileReader API's "readAsArrayBuffer" function. 2. Convert the arrayBuffer returned from the "readAsArrayBuffer" function into a base64 string using the following function: function arrayBufferToBase64(arrayBuffer) {var binary = '';var bytes = new Uint8Array(arrayBuffer);var len = bytes.byteLength;for (var i = 0; i < len; i++) {binary += String.fromCharCode(bytes[i]);}return window.btoa(binary);} 3. Finish creating our DOM-readable "imageDataURL" by prepending "data:image/jpeg;base64," to our returned base64 string 4. Create a new Image, load our imageDataURL as its "src", and once the image is done loading, create a new canvas element and draw the image into it. It looks something like this: var image = new Image();image.onload = function() {var canvas = document.createElement("canvas");canvas.width = image.width;canvas.height = image.height;canvas.getContext("2d").drawImage(image, 0, 0);callback(canvas); // No CORS issues};image.src = imageDataURL; 5. Throw your computer out the window :) . There were times my wife would load Rizer’s Leaderboard page and be unable to scroll through the photos without going back to the previous page and then reloading the Leaderboard page. This was such a problem that I ended up needing to implement . . Unpredictable vertical scrolling behavior, and in my experience, completely broken horizontal scrolling iScroll Ugh . This wasn’t a showstopper for Rizer but it has prevented me from starting another project where it would be. This is completely unacceptable in 2017, and provides further evidence that . Complete lack of getUserMedia support Safari is the new Internet Explorer No programmatic control over showing and hiding the keyboard App-breaking conflicts with stable versions of the Cordova SplashScreen plugin App-breaking conflicts with stable versions of the Cordova In-App Browser plugin It is imperative that you understand that none of the above issues exist for Hybrid apps running on Android. In all seriousness, I have virtually no complaints about the app development-to-publishing process that has built. The Google Play Developer Console is incredible, with robust release management, A/B testing, in-app product creation, order management, app install and usage analytics, user feedback collection, and lack of an . And the icing on the cake is that we know our Hybrid app will render and function exactly as we expect thanks to Android’s Chromium-based WebView. Google absurd review process Apple is so far behind here that I can’t even talk about Google’s offering without sounding like a fanboy. Without a doubt, creating Rizer was a longer and more frustrating experience than I expected it be… thanks to Apple. My family can attest to how often I complained about Apple and iOS when they asked me how Rizer’s development was progressing. I am continually blown away by the fact that the has created such an abysmal development experience. most valuable company in the world I have tried to figure out why Apple isn’t motivated to streamline their Hybrid development process and bring Safari up to feature parity with the other modern browsers (it’s not like they don’t have the resources to do it), or simply allow the use of 3rd-party browsers like every other platform (including Windows) does. Are they trying to get developers to build their native iOS app before its Android equivalent, potentially making it less appealing for an iPhone/iPad owner to switch to an Android device since the apps they use everyday aren’t in Google Play? . I really hope not OK, So… Hybrid Or Native? In my experience, all of the potential show-stopping issues caused by going with the Hybrid approach have workarounds. They are frustrating to discover and implement, but they do work. For this reason, I am comfortable stating that . It will absolutely take you longer to develop a Hybrid app than it , but it will still take less time than developing two separate Native apps, and if properly designed, will feel just as fast as to your users. the Hybrid approach is the right choice for your next app should And hey, maybe one day in the future, Apple will course-correct and provide us with the development experience we deserve. Until that day, I fully expect this “Hybrid vs Native” debate to rage on.

Harmony

Apache

Apple

Google

If It Weren’t For Apple, Hybrid App Development Would Be The Clear Winner Over Native

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

10 good rules for bad App

10 Creative Ways to Use OTG Adapter with Smartphones

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

10 good rules for bad App

10 Creative Ways to Use OTG Adapter with Smartphones

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps