Your Hybrid App is Going to Kill You
If your company only makes hybrid apps, you are going to lose in the end; it’s just a matter of time. Hybrid mobile apps do have their place, but most companies either ignore their limitations or don’t care enough to listen to warnings that are presented every day by native mobile developers.
Before we dive into things, let’s set some parameters on what I mean when I say that hybrid apps will suck the life out of you. I’m a mobile developer who has a lot of experience (more years than I care to admit) developing mostly native apps but a fair share of hybrid apps too. My first mobile app was for a Palm V written in C++. Does anyone remember those days? I’m not going to quote you statistics on how every mobile project fails. I really dislike the stats that float around the web from executives that have never coded an app stating how beneficial hybrid apps can be. It’s a real shame that these executives are the ones empowered with the decision making power to choose between hybrid and native apps; they doom their company’s mobile efforts with their unwise decisions.
So How Did We Get Here?
Why are hybrid apps chosen over native apps? Shortcuts! Hybrid apps are usually chosen because executives are looking for shortcuts. Some marketing genius (sarcasm) planted the seed that hybrid apps are developed quicker and are less expensive by hiring web developers instead of native mobile developers, investing less time, and targeting every mobile device without having to create multiple versions of the code. Guess what? Those claims are lies! (This is the case unless the project is so basic that it could have been a responsive web application from the onset, which doesn’t apply to what I’m referring to.) So sad, so pathetic, and yet it’s the current state of the mobile developer world. Hybrid apps appear to be here to stay. I’m willing to bet that when you ask the business gurus in charge why they chose hybrid for the direction of your company’s app, you will hear some variation of the reasons above. You’ve been warned!
The Lies Non-Technical Managers Tell You
As I mentioned above, I’m not going to allow the statistics of non-coders to to trump the experience of real developers. I will tell you that when one of these manager types tells you that your next project is going to be done in half the time, with a small team, and will support iOS and Android… you should run! These managers don’t know that they are signing your death certificate — or, at the very least, you will hate your life while on the project. How in the world did these individuals get put in charge any way? Ah, that is a question for another day. The key takeaway is that you need to be vary suspicious about the supposed sources of the claims that your next hybrid project is the right decision because the stats floating around the internet claim hybrid is winning the mobile race. If you’re a native girl or guy, I would say it’s time to look for a better job.
The Good Truth About Hybrid Apps
The truth about hybrid apps is that they are useful in some cases. Hybrid apps are good in cases where the application just needs to do basic display work in support of your main web application. When all you’re really doing is trying to get a bigger audience using the app stores (Google and Apple), then a hybrid app might work… especially when the app doesn’t really do anything useful.
Hybrid apps could also be advantageous when they are just components of a native app. However, in other words, you have a native app and want to add a web component from your web application. In this case, you can’t even really say you have a hybrid app.
Why Do Hybrid Apps Spiral into Death Cycles
Every hybrid app starts off with the best intentions. Armed with all of the success stats on hybrid apps your manager dumped on you (which you know to be complete crap), you launch you editor and code away. In the beginning, things are good. Your first set of features seem to be coming along nicely. And then it happens; you get your first request to do something that isn’t supported on Android but is supported on iOS. What do you do? Naturally, you add your first (of a long list to come) conditional statement to do feature A for iOS and do feature B for Android. A week later you realize that your code now contains so many of these conditional statements that you’re beginning to wonder if you should split your code into iOS and Android codebases so that you don’t have to keep adding conditionals! But wait, you can’t do that because your manager told you that hybrid apps are meant to be written once and run everywhere. But that doesn’t seem to be the case here, does it? Besides, if you split your code base, you would have to support two separate sets of code. Ugh! Two sets of code? One for iOS and one for Android? Forget that! Especially since your manager has also already informed you that you should be able to do this in less time than if you had written a native app. Two code bases would break a cardinal rule of having a hybrid app.
Let’s skip over the dual code base problem for a moment. You have bigger problems to address. After a while, you are beginning to see performance issues on Android. You want to ask the Android expert on your team why things don’t look right, but you can’t. Your manager didn’t let you add one to the team. Instead, you only have mobile web developers that don’t understand Java or the Android SDK. In order to do the next best thing, you search aimlessly through StackOverflow for an open source plugin that will hide the details of the OS. Your goal is to allow your web developers to make Javascript calls to their hearts’ desires without understanding the underlying operating system or how to fix the problems that are coming up. Congratulations; you just created your first cover up! You don’t really know how the problem was fixed or why this plugin fixed things, but who cares — you’re building a hybrid app and, according to your boss, you should be halfway done. You explain away the side effects of the plugin you introduced as issues you just have to live with. After all, you can’t be expected to fix Android OS issues or any issues introduced by phone manufacturers! Wow, that sounds good, and some of it might even be true. Too bad you don’t have an Android developer on the team to verify if it’s really true. Instead of a proper consultation, you add 20 more plugins to your app to handle additional problems that seem to be rapidly showing up.
Then you discover your more problems. According to your manager, you are weeks behind schedule. You just can’t seem to add enough conditional statements to handle all of the OS specific use cases or find enough plugins to address the issues that you don’t understand because you chose not to add any native mobile developers to the team. At this rate, you need to add a bunch more developers or sacrifice the release schedule to make the deadline — and who in the world set such a ridiculous deadline anyway? Given the opportunity to hire more developers, you grab a few additional web developers. Your manager is now telling you that this project is getting expensive and that there really isn’t room to hire native developers. You can have more bodies, but they need to be web developers. After all, the new developers could work on either iOS or Android issues and will be cheaper than highering expensive talent that can only work on iOS or Android. At this point your project is officially screwed, and you are powerless to stop it.
What Do We Do Now
The entire tragedy of hybrid apps hasn’t been fully represented above. The real saga is even more somber. When you take into account the sacrifices you make in terms of performance and features that users expect, the impact of choosing hybrid is even more costly. What user really wants to use an app that is slow and unresponsive? If you’re an iOS user, do you want to use an app that looks like an Android app? If you’re an Android user, do you want to use an app that feels like an iOS app? The answer is no! But the write-once mantra, would say, “It’s really not that important to please users; writing once will save you money!”
If you haven’t started that hybrid app, I suggest you really think long and hard before starting one! There is probably a real reason that companies like Facebook have abandoned their reliance on a hybrid strategy. Check out React Native if you have doubts on that claim. Chances are you aren’t going to finish your project quicker using a hybrid strategy. You aren’t going to save money, and you definitely aren’t going to delight your users by taking shortcuts. But hey, that’s you manager’s call, right?
If you are in the middle of a hybrid app, I so hope that you chose this route for one of the (two) good reasons I mentioned earlier. If not, get your resume in order and find a better job. You’re in for a lot of headaches with that project — ones that could have been avoided by going native from the start.
On a related note, check out my article on the common traits Rockstar developers possess.
