Sharing foreign experts ' views on the development of hybrid mobile applications

Facebook released its new IOS app in 2012, and in order to get a better user experience, they gave up the original HTML5 hybrid development approach. Given that 2010-2011 years, the performance of HTML on the mobile side is really unsatisfactory, the decision at that time seems to be understandable. In 2010 we felt that the IPhone was 3g/3gs enough, but it was too slow to look at the current standards. So when architecting for mobile applications, we need to consider the computing power of new mobile devices, rather than old, outdated devices.

Mobile development architecture design does not require too much consideration of device performance

One conclusion we have drawn from some tests is that today's mobile computing power is strong, the effect of running native applications and HTML applications is small, and the cost of HTML development is much smaller than native development.

Of course, this conclusion is not quite applicable in some areas. If you are developing a 3D game, the native development approach can bring a better gaming experience. But if your mobile apps focus on information like Basecamp, you can consider a hybrid development approach to reduce development costs. We are so, the following is our three-generation mobile product development trajectory:

First generation Products: Native shell (native shell) + nested WebView

This version is a simple native shell responsible for the interface navigation, nested a webview to display Basecamp Rail application, the display is basically our mobile Site page, plus some special style.

Nesting a native shell on a mobile Web page may sound a Web page, but the actual experience with the user is very different. Users can find our app in the Apple app Store, and once they log on to the app they can no longer log on (the mobile version of Safari appears to be emptying cookies so that you have to log in again). Our app is very popular, with users scoring between 4 and 5.

The entire app is developed by a programmer and a designer, and is not expensive because we can develop it on the basis of existing mobile web sites.

If we had developed a completely native app, 1.5 of the 10-person team would not have been able to complete it.

Second generation products: Native shell + Native navigation interface

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

We felt the power of the native navigation interface from the first IPhone app, so in the Android version, we moved from HTML page navigation to the native navigation interface. We generate the native navigation interface from the HTML page, the user experience is more fluent, the native interface and the HTML page experience difference is getting smaller, even it is difficult to distinguish which is the native part, which is the HTML.

The Android version was developed by one or two programmers and one designer (50% inputs). We have reused all the webview used in mobile sites and iPhone apps, greatly improving development efficiency, and users are buying it, with more than 1000 users playing 4.5~5 high score.

Many companies are complaining about the slow pace of their IOS mobile programs, and the Android project seems to be more so. Maybe they've gotten used to the development of the IOS project, perhaps because of the screen fragmentation of Android, but that's not the case for us. Our Android app is doing well, reusing 95% of the Code, and the development team has been kept on a small scale.

Using native development methods according to local conditions

We are currently developing a third generation of products, the release of the platform is temporarily confidential, but you should not be difficult to guess. In the first two generations of products, we have increased the use of native navigation interface, while further defining the WebView as the core of the overall architecture. In the third generation of products, we will choose local conditions to use the function of native development, good steel to use in the blade.

From the previous 100% HTML, to the current 90% HTML +10% native, we will choose the 10% part that is most worthwhile for native development, with the ultimate goal of making the app native part and the HTML part of the experience not much different.

Techniques used in mixed development mode

The hybrid development model is simple in technology, mainly dealing with WebView integration, Web page loading, and the cross linking of native content and HTML content, which may actually be much simpler than you might think.

In HTML, our rails Web application supports both Web and mobile platforms, with Rails 4.1 feature of variants playing a big role.

This also helps us to publish new features to a large extent. Imagine if we need to update so many platforms each time: Rails desktop app, a Rails API app, a client-side MVC app, a mobile web wrapper app, an Android app, a nd an IPhone app, companies like us with only 10 programmers and 7 designers simply can't afford to do such a huge amount of work.

In addition to the reduction in workload, bug fixes have improved because most of the code logic is on the WEB server side, and we can modify the code and publish it at any time without passing through the approval process in the Apple App Store. So our mobile app, like Web apps, is a continuous deployment.

As I mentioned earlier, mixed-mode development does not apply to all situations. Before 2010, when the handset processing ability is not strong, therefore the HTML/JS experience is not good, the user also does not like. However, the current situation, the mobile phone processing capacity has been greatly improved, HTML/JS performance is no longer a problem.

The challenge of mixed development mode to native development mode

The hybrid development model has its advantages in reducing development complexity, and if your product is focused on displaying and processing information, I think it can be used in varying degrees.

For small teams and companies, it does not necessarily take the IOS native app-first model. With blending mode, you don't need to start a new app, which reduces maintenance costs and is easier to extend to other platforms in the future.

Of course I know there will be a lot of people questioning this model, perhaps because there are a lot of places in their app that need to be developed (perhaps just as they think). Or maybe they've spent a lot of time making app UITableView look so beautiful that it's not perfect if it's not the case elsewhere. Perhaps the big company is like the time consuming power of the original development, money is so capricious.

In any case, hybrid development should now be a choice for our mobile development strategy. If you think this is a good choice, then congratulate you and play happily!

Original link: https://signalvnoise.com/posts/3743?utm_campaign=iOS_Dev_Weekly_Issue_175&utm_medium=email&utm_ Source=ios%2bdev%2bweekly

The following questions are added by David's reader:

Mike Waite @ 2014-05-08: I wonder how you decide which features to use for native development?

David @ 2014-05-08: Mainly by feeling, this is not a science after all. If you feel that some part of your app is better with native development, you can try a quick prototyping (spike). Many times we prove that our ideas are wrong in this way. Of course, if you need to use mobile phone features such as: camera and other devices, HTML is not yet applicable, but never say die.

Mike Parsons @ 2014-05-08: Good article. Are you curious whether you use a framework such as PHONEGAP or Cordova, or have you developed one yourself?

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

Derick @ 2014-05-08: How do you solve the problem of slow rendering of Android browsers? This is why more people on Android have tended to develop native apps.

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

Derick @ 2014-05-08: just recently. I guess it might have something to do with how much you use JavaScript. Because of my personal experience, the JavaScript on Android is running very slowly. If you are interested you can look at 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, of course, not as much as the Web MVC client does. In addition we used the Turbolinks:)

After the above description, it seems that foreign countries still tend to develop mobile applications, but at least at home, or a matter of opinion, let us wait and see.