Hybrid native apps are great for launching new mobile apps

Michiel Sikkes
January 11, 2016

At Firmhouse, we regularly build hybrid native apps when working on new mobile apps and Minimum Viable Products. We call these apps hybrid native because they are native iOS or Android apps that wrap a web view pointing to a backend Rails app, deployed on a regular URL. The app wrapper includes native functionality and UI like navigation, animations and Push Notifications.

So why are we building hybrid apps as opposed to either fully responsive web apps or entirely native apps with all native UI?

Our primary business is developing product experiments and Minimum Viable Products (MVPs) for startups and corporates that rapidly want to learn about their assumed customers and how they behave when using the initial product. Because of this, we need tools that help us quickly iterate on the initial product concept in a manner of weeks, not months.

We usually start out with our basic model: a responsive mobile web app served on a URL. Because we are web developers by heart, building a responsive mobile web app is the fastest way to getting something out of the door that delivers the assumed core value of the product we're trying to test. We can style and replicate any interface, run A/B tests, add tracking tools and deploy changes multiple times a day. It also makes internal testing and doing reviews with our customer extremely easy. We don't have any waste of preparing an app store submission, compiling native code, or having to wait for an app reviewer to accept our app. We can just get a domain name, fire up a new Rails app, deploy a staging and production environment and we're good to go.

This method proves to be difficult however when the product's concept needs a native mobile user experience or needs push notifications to function properly. Sure, you can fall back to email notifications or text messages but this just doesn't feel as natural for users of the app.

Developing fully native apps would be ideal once we figure out that is important for the early adopters. But native app development is not yet something we master enough to be able to develop new products rapidly. Let alone that it would require us to learn Android, iOS and maybe even Windows Phone development. There is also the problem of waiting for app store submission on iOS. Apps can take days to weeks to be approved. Waiting time will prevent us from rapidly iterating on smaller changes with our customers.

These arguments have led us to experiment with building a basic form of a hybrid native app framework that we can use for our projects. We develop all the core functionality and navigational structure in Rails, just like we would normally when developing a fully responsive mobile web app. Then, we write a thin native wrapper in RubyMotion that includes just one UIWebView. In that UIWebView, we load the root URL of our Rails app and let the web handle everything from there on.

In some apps, we add Push notification functionality and callbacks to the native wrapper. At the server side, we use Houston to call Apple's Push Notification service.

It is indeed simple, but a very powerful way to get our native apps out of the door and into the hands of real people as soon as possible. That way we can collect feedback, measure app usage, engage people through native notifications and decide if it's worth it to spend more time to build an entirely native app.

If you'd like to get in touch about building hybrid apps or have any other questions to ask me. Please let me know! @michiels on Twitter or via email at mailto:michiel@firmhouse.com. Have a good day!