Everything About Creating a Strong Mobile App Hybrid Architecture


What is a hybrid app?

Hybrid can mean multiple things to many people in the mobile development community. Typically a hybrid app means it’s using Xcode + Swift, and conforming to all the platforms conventions regarding navigation/presentation. The building blocks of the app are composed of UINavigationController, UITabViewController, UISplitViewController, UIViewController, etc. Within those containers, we can have many screens where the content is built using UITableView or UICollectionView, we can have even more where that role is filled by a WKWebView.


Hybrid architecture offers some key benefits compared to pure native or web-based apps:

  • Faster, cheaper development by reusing web code
  • Easier cross-platform development and maintenance
  • Ability to leverage web technologies like CSS, JavaScript, etc.
  • Access to native device capabilities not available to web apps
  • Distribution through app stores alongside native apps
Mobile App Hybrid


Turbolinks is the one core library to use for managing hybrid architecture. The framework handles communicating with Turbolinks.js and allows the use of a single WKWebView, shared across multiple different screens.


Typically most of the navigation inside a hybrid app is url based. A url can come from a number of sources (web link, push notification, universal link from another app, native action, etc), and they all go through the Router. This router is responsible for figuring out exactly what action to take for a given url. The router may open the url in Safari if it’s for another domain, display a media viewer if it’s an image/video, or in the common case, create a new view controller to display. The router hands off a view controller to the Navigator which handles the presentation. Most view controllers are pushed on the current navigation stack, but you can also support presenting certain screens (like new/edit views) modally, or replacing the current screen when appropriate.


The last component that makes up the hybrid architecture is what can be called the “Bridge”. This is an umbrella term for all the various parts of the app involved in native→web (or web→native) communication. The primary code here is a local JavaScript file (written in TypeScript) embedded in the app and injected into the webview using WKUserScript. This provides native code an API for communicating with the webview without needing to directly query the DOM or do complex JS. Using a WKScriptMessageHandler, the developer can respond to messages sent from the web view through the bridge.

Getting the best out of Hybrid architecture

Mobile apps should all be about user experience. If the user experience is bad, users don’t hesitate to uninstall the app instantaneously. To avoid this unfortunate experience most developers choose native development. With hardware getting stronger and web technology becoming more responsive, we don’t have to entirely rely on native development. We just have to be smarter about our hybrid architecture.

Here’s a great example of a good hybrid architecture.

App requirements:
3 Tabs – Home Tab, Messages Tab, and Gallery Tab
We can create a tab view controller in iOS with 3 tabs

  • Home Tab – Create a router and it will navigate us to Home Tab URL which is an RSS reader
  • Message Tab – Tap on the Messages Tab, to take you to Messages HTML page. (But here is the beauty of a great hybrid architecture, when we enter a message we can switch a web text entry to native text entry to take all the advantages of smooth animations and dictionary.)
  • Gallery Tab – Tapping on the Gallery Tab can be a photo picker and we can route to choose the photos from the native app.


Most developers learn a great hybrid architecture through trial, error and past experience. Share your experiences in the comment section below.