But most people and companies aren’t Facebook, nor are they writing apps that have even close to the complexity of Facebooks apps. The reason that they are wanting to rewrite an in hybrid technologies probably stems from a bad decision point when building a hybrid application. Like any app, there are a number of landmines one can step on when building a hybrid that can result in a poorly performing app or one that is just downright impossible to maintain.
When hybrid applications first came on the scene, they were met with great fanfare and web developers started making apps right away. A few years later, there are many bruises, apps both good and bad, and lessons learned. Out of this grew this list of best practices – partially out of necessity and partially out of lack of another good list.
General principles for successful applications:
- Build apps with a purpose, not just to have an app. One of the biggest motivations for writing a mobile app is driven by marketing — business want a presence in whatever application store that is provided by the platform, but the app itself does little or nothing in terms of business value. A company will use a hybrid app that is more or less portals used to load a business’ website. Apps like this are generally rejected by the iOS App Store, and this approach really does not help a brand.
- Write apps to target multiple platforms. Perhaps the biggest motivation for writing hybrid applications is device portability. However, if an app is intended to target a single platform, there is little or no benefit from writing a hybrid application. Native applications in almost every case perform better and have a better user experience than hybrid applications.
- Choose a good platform. The platform doesn’t make the app, but it helps. It is the tool that enables the developer to write and deploy apps. Choosing a platform from the plethora of available platforms can be daunting, so here’s a few tips:
- Avoid vendor lock-in. Hybrid applications by nature are highly portable and there is a plethora of tools available to build from. Vendor lock-in for this reason isn’t necessary. Do a thorough investigation of a platform, its licensing, and also how it says build applications. If applications require high reliance on a platform to run, odds are vendor lock in will occur.
- Hybrid platforms should be extensible. Usually, a hybrid platform will have an API wherein a developer can write custom native code that can be used by an app. While this practice isn’t usually necessary and really should be used to avoid device lock-in, sometimes it is necessary.
- As with any development platform, a good development platform should have good documentation and support. Good support doesn’t mean that one has to pay for it. Many popular platforms have excellent community support, ample and complete documentation, code samples, and tools for debugging to help developers understand and use the platform.
- Look for a platform that receives updates regularly. Platforms from fly-by-night companies or indie developers run a high risk of abandonment. If the project is open source, look at the spans between commits and how many people are making commits. This can help gauge the viability of a platform. If the project is closed source, search online to see how popular a project is — does it have lots of plugins? Does it get a lot of attention on Stack Exchange? Are there lots of tutorials on YouTube? Are there lots of blogs posting about it? These more informal metrics can help gauge the viability of a platform in the same way looking at source code does.
- Look for a platform that is mature. Start-ups projects are usually cool, but they don’t always translate into successful application platforms. Mature platforms usually gain a following with a vibrant community. Look at how many open problems a platform has and also how long it takes to resolve problems. More mature projects will have fewer problems and will rapidly close existing problems.
- Write the apps as Single Page Apps (SPA). Single Page Applications load the resources they need when the app starts. Once the app is loaded, application states can be maintained in memory as with a traditional native application and without the overhead of needing to reload the page with each successive action. Navigating away from a page means that state has to somehow be handed off to the new page such a URL, post or through some sort of data persistence on the device, the re-read after the new page loads. Additionally, the app has to go through the compilation phase of the application all over again. This has detrimental effects on the applications performance and user experience alike.
- Remain device agnostic to the degree possible. The greatest motivation for using hybrid application is portability, so it’s imperative to remain as device agnostic as possible to insure device agnosticism. Hybrid apps by design can take advantage of features of a device such as the camera, GPS, file system, and so on. Any device interaction however, should be abstracted away from the application and exposed through a wrapper around the device. Better yet, use inversion of control and dependency injection so that device specific functionality isn’t a hard dependency and can easily be swapped out between devices.