DHH on hybrid mobile app development

[[125180]]

David, Ruby on Rails author, 37signals partner

Best-selling author, speaker, racing driver, amateur photographer, family man

37signals released the Basecamp iPhone app in February 2013. Before that, we had tried many things to decide whether to use native or hybrid development. When the project started in 2012, most people were leaning towards native development.

Facebook released their new iOS app in 2012, abandoning the original HTML5 hybrid development approach for a better user experience. This decision made sense at the time, considering that HTML performance on mobile devices was not satisfactory in 2010-2011. In 2010, we thought the iPhone 3G/3GS was cool and fast enough, but by today's standards, they are too slow. Therefore, when designing the architecture for mobile application development, we need to consider the computing power of new mobile devices, not those old and outdated devices.

Mobile development architecture design does not need to consider device performance too much

One conclusion we have drawn from some tests is that today's mobile devices have strong computing power, and there is little difference between running native applications and HTML applications, while the cost of HTML development is much lower than that of native development.

Of course, this conclusion is not applicable in some areas. If you want to develop a 3D game, native development can bring a better gaming experience. But if your mobile application focuses on information processing like Basecamp, in order to reduce development costs, you can consider hybrid development. We did this, and here is the development trajectory of our three generations of mobile products:

First generation product: native shell + nested WebView

[[125181]]

This version is a simple native shell responsible for interface navigation, nested in a WebView to display the Basecamp Rail application, which basically displays our mobile website page, plus some special styles.

Nesting a native shell on a mobile website page may sound like a web page, but the actual user experience is very different. Users can find our app in the Apple App Store, and once they log in to the app, they never have to log in again (the mobile version of Safari seems to clear cookies frequently, forcing you to log in again). Our app has been very popular, with user ratings between 4 and 5.

The entire app was developed by one programmer and one designer, and the cost was not high because we could develop it based on the existing mobile website.

If we had developed a completely native app, it might not have taken a year and a half for a team of 10 to complete it.

Second generation product: native shell + native navigation interface

The Basecamp Android app we released a few months ago is our second-generation product, and we’ve made a lot of improvements to it.

We felt the power of the native navigation interface in the first generation of iPhone app, so in the Android version, we switched from HTML page navigation to the native navigation interface. We generated the native navigation interface from the HTML page, and the user experience was smoother. The difference between the native interface and the HTML page experience was getting smaller and smaller, and it was even difficult to distinguish which was the native part and which was the HTML.

The Android version was developed by one or two programmers and one designer (50% input). We reused all the webviews used in the mobile site and iPhone app, which greatly improved development efficiency. At the same time, users also bought it, and more than 1,000 users gave it a high score of 4.5~5.

Many companies are complaining about the slow progress of their iOS mobile projects, and Android projects seem to be even more so. Maybe they are used to the development process of iOS projects, or maybe it is because of the screen fragmentation problem of Android, but these are not problems for us. The Android app we launched performs well, reuses 95% of the code, and the development team has always remained small.

Use native development methods according to local conditions

We are currently developing the third generation of products. The platform for release is confidential for the time being, but you should be able to guess it easily. In the first two generations of products, we added the use of native navigation interface and further determined the overall architecture with webview as the core. In the third generation of products, we will choose the functions that need to be developed natively according to local conditions.

From 100% HTML before to 90% HTML + 10% native now, we will choose the 10% that is most worth doing native development. The ultimate goal is to make the experience of the native part and the HTML part of the app not much different.

Technologies used in hybrid development

The hybrid development model is technically simple, mainly dealing with webview integration, web page loading, and cross-linking between native content and HTML content. In fact, it may be much simpler than you think.

On the HTML side, our Rails web application supports both web and mobile platforms, and the Rails 4.1 feature of variants plays a big role in this.

This also helps us a lot in releasing new features. Imagine if we need to update so many platforms at a time: a Rails desktop app, a Rails API app, a client-side MVC app, a mobile web wrapper app, an Android app, and an iPhone app. A company like us with only 10 programmers and 7 designers simply cannot afford such a huge workload.

In addition to reducing workload, bug fixing efficiency is also improved, because most of the code logic is on the Web server side, we can modify the code and publish it at any time without going through the approval process of the Apple App Store. So our mobile app is also continuously deployed like the Web application.

As I mentioned before, mixed mode development is not suitable for all situations. Before 2010, the processing power of mobile phones was not strong, so the HTML/JS experience was not good and users did not like it. But times have changed, and now the processing power of mobile phones has greatly improved, and the performance of HTML/JS is no longer a problem.

Challenges of hybrid development model to native development model

The hybrid development model has its advantages in reducing development complexity. If your product is mainly for displaying and processing information, I think you can adopt this model to varying degrees.

For small teams and companies, it is not necessary to adopt the iOS native app first model. Using the hybrid model does not require you to develop an app from scratch, which can reduce maintenance costs and make it easier to expand to other platforms in the future.

Of course, I know that many people will question this model, perhaps because there are many places in their app that need native development (maybe they just think so). Or maybe they have spent a lot of time making the UITableView in the app look very beautiful, so if other places are not like this, it will not seem perfect. Or maybe big companies just like time-consuming and labor-intensive native development, and they are so willful because they have money.

In any case, hybrid development should be an option for our mobile development strategy now. If you think this is a good choice, then congratulations, have fun!

Original link: Hybrid sweet spot: Native navigation, web content

Here are some additional answers from David to readers:

Mike Waite @ 2014-05-08: I'm curious how you decide which features to develop natively?

David @ 2014-05-08: It's all about feeling. It's not a science. If you feel that a part of your app would be better developed natively, try doing a spike prototype. Many times we've proven our ideas wrong this way. Of course, if you need to use mobile features such as cameras and other devices, HTML is not suitable for it yet, but never be too sure.

Mike Parsons @ 2014-05-08: Great post. Curious if you guys use a framework like PhoneGap or Cordova, or if you developed one yourself?

David @ 2014-05-08: We don't use any framework. (xxx characters omitted here)

Derick @ 2014-05-08: How do you solve the problem of slow rendering speed of Android browser? This is also the reason why more people tend to develop native apps on the Android platform.

David @ 2014-05-08: I wonder if your conclusion is recent or previous? The Basecamp Android app runs very smoothly on my Nexus 5 and HTC One.

Derick @ 2014-05-08: Just recently. I guess it has something to do with how much you use JavaScript. Because in my personal experience, JavaScript runs very slowly on Android. If you are interested, you can read the following article: https://www.timroes.de/2013/11/23/old-webview-vs-chromium-webview/

David @ 2014-05-08: We use a lot of JavaScript, though not as much as the Web MVC client. Also, we use Turbolinks :)