The Hybrid Promise, Revisited

Can you still hear the old native vs. hybrid debate? I can’t. It bores me. It bores me because the arguments are the same that they were 3 years ago. However, I can’t afford to ignore this just because it bores me. So I find myself dealing with this every so often. It usually goes like this:

Manager: “Thanks for joining our team. We need someone experienced to accompany our new high profile, mission critical project. This is our first mobile App, so it must be a success! We spoke to <global consultancy company> and they suggested we develop a hybrid App, since our in-house developers have experience with web development. Six of our best developers are currently in a 5-day intensive training getting up to speed with HTML5, CSS3 and JavaScript.”

I: “Your App looks quite complex, have you assessed the architectural drivers to see if hybrid is the right choice for this project?”

Manager: “Sure, this is our architecture” (hands me a sheet of paper with some data services, some mobile device pictures and some boxes that describe an App running in a WebView)

I: “Well, this is not an architecture.” (I really enjoy this moment a lot, since most managers are happy they got such a crappy n-tier diagram at all. I take a couple of seconds to enjoy the manager’s face expression)

Manager: “What do you mean? This is our architecture. We have a DB layer here and our services here and the hybrid application over there running on the mobile devices!”

I: (Keep waiting for a few more seconds, since I know he is going to say it in 3.. 2.. 1..)

Manager: “Ahh look, I know what you mean. We have chosen to use framework XY because we will have a model-view-controller architecture in the App!”.

I: “Ok I see. However, a framework is not an architecture, it’s just a tool. And MVC is not an architecture either, it’s a design pattern widely misunderstood and over-rated. Architecture is about intent. What is the intent of your App?”

Manager: “It’s a shopping App. You can see that in our architecture. We have a frontend that the user operates to search for items, add them to a shopping cart and place an order. We have services for managing the user’s account, place orders and process payments.”

I: “This still is not an architecture. You could use the exact same boxes to describe a pizza ordering App or an App for calling a cab.”

Manager: (starting to sweat) “So what the heck is our architecture then?”

I: “Every App has an architecture, whether you actively craft it or not. In this case you haven’t yet, so I can’t tell you what your architecture is. However I can work with you guys to help you get there. It would have been good to do this before committing to a hybrid approach and framework XY and sending your developers to a training though.”

Manager: “Why is that? It can’t be wrong to follow a hybrid approach. It allows us to write the code once for all platforms, so we get things done faster and cheaper.”

I: “So how many platforms do you want to deliver the App to?”

Manager: “All relevant iOS and Android phones and tablet devices. Windows Phone will potentially follow later.”

I: “Well that means a whole lot of devices, all with different screen sizes, CPU speeds, display resolutions, UI paradigms, etc. By going hybrid you add different browser engine implementations to the mix, complicating things even further. In my experience this only pays off if the benefits of a hybrid implementation are greater than the added complexity it brings. Is that the case for your App?”

Manager: “Uh… er…”.

I: “Let’s work through it on a very high level. From the following list of architectural drivers, please tell me the two most important ones: security, scalability, availability, performance, usability, extensibility, testability and maintainability”

Manager: (after some thought) “Security and Usability. This is a shopping App, so it has to be very secure. The users can place orders and pay stuff with it, entering credit/debit card information or using online payment services like Paypal. Also usability is key, we want the best possible user experience. It all has to be very fluid and animated nicely even on low end devices.”

I: “Ok, let’s talk about security first. We both know there is no 100% security, so the question is: how hard do you want to make it to break the App?”

Manager: “Well, very hard of course.”

I: “Do you have an idea of how you want to accomplish that?”

Manager: “We will use https for all connections and encryption with large keys for offline data. Also we will minimize and uglify all JavaScript in the release builds of the App”

I: “What you mentioned is very important, but for an App which sets Security as it’s highest architectural driver it not nearly enough. You said the App would be dealing with online payments. This makes it a high value target for criminal hackers. You have to think about anti-debugging techniques, string obfuscation, dynamic code, man-in-the-middle attacks, library method hijacking, rooting/jailbrake detection,  and more.”

Manager: “I think I’ve heard some of these in the context of native Apps, but like I said we are building a hybrid one. Do we still need to care bout all this?”

I: “Well, the base of your App still is native, so you will have to care about all of the above. And if you stick to the hybrid approach, you will have to care about even more. You see, your App logic will run in a Webview, which inherits the security risks of the respective branch and version of the underlying browser implementation. Further, most complex hybrid Apps will require the use of native plugins to communicate with the native side. These plugins are another source of security risks that you ‘buy’ when going hybrid.”

Manager: “Damn! Why did these guys from <global consulting company> not tell me all of this?”

I: “Because they want to sell their services, and using the hybrid promise as an argument helps them do that. In my experience, the hybrid promise holds true only for small and simple Apps. For complex Apps or Apps with high ranked architectural drivers like Security or Usability, it is actually cheaper to develop a native App.”

 

No comments yet.

Leave a Reply