When you said “hybrid” a couple years back, most engineers would assume you were talking about “using a WebView in your native mobile app, maybe with PhoneGap”.
Fast forward to today and you see attention on a whole swath of solutions that try to deal with the fact that our customers want to use our experiences on a variety of platforms, and this is only exploding. Gone are the days where Windows, or The Web Browser, were near-monopoly’s. Now we not only have multiple operating systems, these operating systems come to us from very different types of computing platforms and interfaces: hand held, laptop, desktop, tv, watch, anything-that-talks-to-a-network. That bar for software quality has also been raised, especially on the user experience side, but we have finite resources for product development; hence the desire to get leverage from engineering (as well as design and other areas).
You can quickly start a religious war on the topic, with the two extremes being “everything must be native!” on the one side, and “leverage all the codez!” on the other. In practice there is a huge spectrum of leverage, and you can try to get it in a large variety of ways (e.g. “I will write everything in JavaScript and have it magically run anywhere!”)
I have seen people make choices based too much on bias and looking at the wrong level of abstraction to make the decision, so I have tried to define the principles of cross platform development.
Always Understand The Platforms
There are a legion of Web developers, many of whom would love to keep hacking on Web technology and ignore that iOS and Android stuff. There are managers who see their legions and want to choose solutions that can use them productively. It is smart to get people engaged and productive, but it is wrong to ignore the platform affordances, which will lead you to a destiny of a poor product for your users.
If you are developing a product for iOS, the team should have a deep understanding of the platform and its capabilities. Once you understand the platform, your users, and your products you can marry them all together for the best experience possible.
Don’t build the same experience for mobile and desktop
It isn’t enough to make your desktop web site “responsive”, throw some display:none on your Web app, and walk away for a beer. The mobile experience may be very different than your desktop one. When building out the mobile applications for Walmart we focused much more on the in-store use cases. No one walks into the store with their laptop after all. This meant that the mobile applications were vastly different to the mobile website, which was more focused on eCommerce. This doesn’t mean we weren’t able to get leverage, we were (some parts of the mobile app, the eCommerce parts, mirror nicely!)
The User Experience has to be responsive
If a WebView isn’t up to snuff then I don’t care how many web developers you have, you shouldn’t be using the WebView for the main UI of the application. This normally means that the view layer should render natively, as that is what gives you the right level of responsiveness. This doesn’t mean that you can’t power the view tier in a leveraged manner though. You could have certain logic in JavaScript that powers a native UI. React Native does this very well in the React world, but there are many more ways to do this too.
Your architecture should be flexible and future proof
Where is the escape hatch? What if that one piece of the UI isn’t fast enough, is there a way to get closer to the metal? How hard is it to drop down to that level to make it happen? Putting a native component into a WebView isn’t easy for example.
If iOS X comes out and has some crazy new functionality can you easily incorporate that into your application? Is there a nice abstraction to be able to do this? E.g. <MyComponent> does the right thing, but a very different thing on iOS, Android, and Web.
Be able to test as much as you can
When talking to an ex-Facebooker recently he claimed that the reason why Facebook took off to the races was deltoid, their multi-varient testing platform. This enabled a huge number of experiments to be run concurrently, which has huge changes throughout the product and organization. You can go from hypothesis to data and back again quickly. Rather than argue forever about a feature, just get it out there and see. The Web platform is fantastic at allowing these tests, so what is your strategy for running them on mobile? The app that you ship in the app store is a platform to run your experiences. That platform should have a configuration system, A/B testing system, and a great analytics system that all work together as a three legged stool.
Pragmatic Productivity
Who will be building and maintaining this application?
You can’t blindly do an analysis without looking at the staff, and potential staff, who will be working on the applications. Even if the current shape of the team isn’t the right balance (e.g. a ton of Web talent but less mobile talent) that doesn’t mean that you should fully discount a set of solutions though. You need a plan, which can include outside talent, training, and pairing up resources.
Chances are you will have some people who deeply know the domain at hand, and others that deeply know a platform. If you can get them working well together you can set yourself up for a great future. You don’t want a fantastic native experience that offers a ridiculous subset of features, and you don’t want every feature served up without a thought of the platform.
This also shows that a small team of top notch developers working on a rather small problem may correctly choose a very different engineering approach compared to a hugely complex service with a very large team. There is a good chance that the large team could use a platform that supports multiple ways to integrate with the main app (if there is one).
Tooling: React and RoboVM
Along with the people, you have the tooling and entire development process to look at. Recently I have been looking at two interesting choices to get some leverage. React Native has finally shown up with Android support (still early I know) and a lot of excitement. It is a great choice that trades off Web knowledge with view tier performance. You still need to know how iOS handles layout, and the services and capabilities available to you (as with Android), and that is a good thing! React is also being used as a general view on top of various bindings (such as Quip’s approach on top of shared C++).
RoboVM offers something very differently, but also gives you great leverage without giving up on the platform capabilities. Although you write your code using Java, the view code is split up for iOS and Android. On Android you are just writing a Plain Old Android App, and on iOS you are going through RoboVM. This means that your [Objective kindaRemindsYouOf:C] is Java-like instead (again: you need to know how iOS works!). Some will poo poo this: “I don’t like Java!”, or “Ugh if I am doing iOS I just want to write in Objective-C or Swift!” Well, you can actually do that. You can share the Java business logic code and call into it from your iOS application, so you can choose how far you want to go (escape hatch++). If you have a fantastic Android developer, they can jump and be up to speed pretty quickly (aside from learning iOS which isn’t trivial) and then they can have one IDE open that is working across the entire codebase of both apps and shared code.
Google Inbox uses another strategy where Java offers shared code, using GWT to get to the Web and j2objc to get to iOS. Everyone is hybridizing in different ways in an effort to get some code leverage!
There are trade offs everywhere you look. If you feel like you are getting away with a solution that has no trade offs maybe take another peak. The good news is, just as there isn’t a silver bullet, there also isn’t One True Way. Some times you need to make a decision and charge ahead.
What are the core principles that you look for?