Hybrid: The Turbo Button of Development

john-salzarulo-342868-unsplash.jpg

Building a mobile-app based service like Dwell is a lot of work. We need two native apps (iOS and Android), a mobile-web version, a desktop-web version, and an API to power all of that1 (and I’m sure we’ll think of even more platforms in the future). That’s a lot for any team, but our team is tiny compared to a lot of modern app teams. A lot of major apps have dozens or even hundreds of app developers working on their apps2. We have 2, and we’re trying to release Dwell in only a few months’ time.

How can we pull this off? What’s our secret? Hybrid Development. By leveraging a mix of native and web-based content we are able to share work across all of our major platforms without sacrificing the user experience.

Since I know you didn’t click that link above, here’s the tl;dr on Hybrid Development: Native Controls use code that will only run on that platform (iOS-only or Android-only, for example). We have to write that code from the ground up for each platform we want to run on. For some features in the app this is our only option, or clearly the best option for our listeners. Web Based Controls, on the other hand, are like little mini websites within the app. They run on code we can (mostly) write once and share across all our platforms.

In practice, this means that some of our content is loaded and displayed directly from the web (and shared among platforms), while other features are implemented directly in programming languages like Swift, Objective-C, Kotlin, etc.

With this development approach we can build Dwell in the timeframe we need (i.e. quickly), with the features we need, on the platforms we need, without needing a development team of hundreds. And, we’re doing it all without 100-hour-week death marches. It’s kind of like riding on afterburners. 🚀

For example, we can design our home screen once to provide a consistent UI across all of Dwell, including delivering custom content for each user (if necessary), and we can update that content as often as we need, all without having to spend months inventing our own custom UI for each and every platform3.

And, at the same time, we can develop a custom native audio player for iOS that’s tailored to fit the iPhone and takes advantage of all the native functionality iOS can offer us. (And of course, we’ll build another one for Android)

The best part, of course, is that our listeners don’t have to worry about any of this. For you, it’s just a seamless, simple, beautiful interface for listening to the most important book in history: the Bible.


1: Desktop Web and Mobile Web versions don’t have a release date at this time.

2: And tens of millions of dollars of venture capital.

3: Stay tuned for more examples in the future.

 Shhhh! Enjoy this sneak peek of the audio player as we continue to refine the design.

Shhhh! Enjoy this sneak peek of the audio player as we continue to refine the design.

Jeff McFadden