Native app? HTML5? Hybrid? An inside look at how and why Verdens Gangs transitioned its VG+ mobile app


VG+ is VG’s premium subscription-based digital product and VG’s third editorial product, consisting of the best content from the printed VG newspaper with the best content from VG’s free news site.

Context-aware content — tailor made for each platform — ensures the ideal reading experience per device. Users can quickly and easily gain news insight on their mobile while enjoying a more immersive experience on the iPad.

The first version of VG+ was released in 2011 as an iPad app. It was a native application that won multiple awards, including the “Best iPad App in the World” at the WAN IFRA Cross Media Awards in 2011.

In 2013, we ditched our native apps and created a new set of VG+ hybrid apps (Android, iPhone, and iPad). The goal was to combine the best of Web technology with the best of native technology. We also created a new set of editorial tools that are tailor made to the needs of our editorial team and to creating interactive and instantly available content for mobile devices.

We had just started the VG+ 2.0 project to develop hybrid apps when Mark Zuckerberg announced, “The biggest mistake we [Facebook] made as a company was betting too much on HTML5 as opposed to native.” Speed and stability were the main factors influencing Facebook’s change of mind and move back to native.

Taking an award-winning native app and transitioning to a hybrid app was a very difficult decision. Our native app was popular with our users, it was winning awards, and we were steadily increasing the number of subscribers to our product. We still had a number of challenges with the native app — as I’ve outlined below — which we believed could be best addressed by developing a hybrid solution.

We believed that given the requirements of our project, we could combine native and HTML5 functionality in a way that would give us the best of both technologies — the flexibility of HTML5 and the speed and stability of native.

The project took just over six months to complete and involved creating a new set of hybrid apps along with a new editorial tool that allowed the editors to design and create articles rendered in HTML5.

Editorial control over article layouts: The biggest problem we had with the first version of VG+ was with the lack of editorial control over article design.

The VG+ 1.0 iPad app contained a compiled set of article layouts within the app. The editorial desk used an editorial tool to choose from this pre-defined list of article layouts. The layouts they chose matched with the compiled layout within the iPad app. If the editorial desk wanted to create a new article layout, the app developers had to create a new app, send it to Apple, and wait for Apple’s approval.

This traditionally is not how an editorial desk works. In the printed world, design editors can design any layout they desire, giving them freedom to enhance different stories through use of text size, colour, and images.

With VG+ 2.0 we wanted to give the editorial desk full control over the design of article layouts (font size, font colour, picture positions, text flow etc). Together with Aptoma (a company that creates publishing software) we created a new editorial tool (Dr Mobile) that made this possible.

Our app development partners Agens helped us with integrating this content into the VG+ apps — the output of which is HTML-rendered articles that are designed by our editorial team. These articles are embedded in a Webview within the hybrid app. 

The advantages of using HTML to render article layouts are:

  • HTML is a very effective technology at displaying text and image layouts.

  • It made it easier to preview content displayed in the app from within the online editorial tool. What you see is what you get (in the app).

  • It reduced the article and issue size. HTML allows us to reduce the average size of a daily edition. An app displaying PDFs or large images would have tripled the size of each edition.

  • It is easier to make layout changes on the fly and release rapid bug fixes.

  • It is easier to perform text searches than when using apps that display image content only.

The total control over the design process empowers the editorial desk with the ability to enhance the article content and the users reading experience. The tool also allowed the desk to instantly publish enhancements to article layouts without the need to send a new app to Apple for approval.

This also reduces the need for users to constantly update the app because of simple improvements to article layouts. Below is a video showing how this design tool works.

Multi-platform support: When we released the first version of VG+, it was only available as an iPad app. We wanted to support multiple devices and multiple device sizes.

By using HTML to render article layouts, we have reduced the development time and cost needed to support new platforms. The HTML needs to be tweaked for each platform and sometimes for particular android devices, but so far we have not experienced any major issues with supporting multiple platforms.

The editorial tool allows us to create new HTML layouts per platform or for different screen sizes. So depending on the importance or popularity of a device, we can customise content just for that device. We also have the option to easily create responsive HTML layouts that adapt to all screen sizes.

Features: We wanted to combine the best of native functionally with the best of Web technology. We didn’t want to switch completely over to a Web app like the Financial Times. It was still important for us to take advantage of certain native features, such as: text push, newsstand, storekit, article navigation, pinch, zoom, bounce back, etc. 

We also have the option to create a native layer on top of the article Webview in the app, which gives us the flexibility to create native components if we believe certain features created in HTML are not good enough, with a native image gallery, for example.

Performance: It was important that the app didn’t feel “Webish” or sluggish. Speed is a defining factor with mobile apps; users’ tolerance to wait on a mobile device is far less than that on a computer. We wanted to maintain a native snappy experience. 

To optimise the performance of the app, we decided to implement certain features natively. The table of contents view is native, by using snapshots of the first page of each of the HTML rendered articles using phantomJS.

Once a user taps on an article within the table of contents, we dynamically switch to a Webview and to the HTML-rendered article. The navigation between articles is handled by the native layer in the app, reducing the perceived lag time when navigating between articles.

The next and previous Web views of an article are pre-loaded so that the content is instantly displayed once the user begins to swipe between pages of an article. 

Skill set: HTML is the most-used programming language among developers and is built on open standards. By using HTML5 to render articles within the app, we increased the pool of potential qualified resources to work on this project. 

It also allows us to reuse a lot of knowledge and Web components created for other VG Web projects within the VG+ project. Device and OS fragmentation is also proving to be more and more of a challenge when developing pure native apps. By reducing the amount of native code developed, we have reduced the number of problems related to OS fragmentation.

App Store distribution and monetisation: It was still important for us to be present on Apple’s App Store and the Google Play store. Building a hybrid app gave us the flexibility to offer both App Store subscriptions and our own subscription service (SPID subscriptions). One-click payment and stored credit cards have proven to be an effective way to sell content. The only disadvantage is Apple’s 30% cut of the earnings. 

Budget: Developing pure native code for each platform is expensive (objectiveC on iOS platforms, java on Android, HTML on the Web). We reduced the cost of developing new apps or new functionality within the app by developing a large portion of the code base in HTML and reusing the code when developing for new platforms.

The initial cost of changing over to a hybrid solution was offset by the cost savings achieved since changing over. For example, our release cycle has changed dramatically, changes to article layouts no longer require an update to the app and a submission to the AppStore. The cost and time to develop an Android app was also reduced since we could re-use a lot of the same code in the Android app. 

Native app developers are currently more difficult to recruit and tend to be more expensive than Web developers. A lot of app development is outsouced, further increasing the cost of developing apps for each platform. 

General challenges to consider when choosing a HTML or the hybrid app approach:

  • Weigh the costs of tweaking the HTML for each browser. The advantages of using a cross-platform language may soon be eroded if you need to customise your code for each browser version or operating system.

  • Page rendering of Web content is not as seamless when turning the iPad from landscape to portrait. With VG+, we have chosen to only support landscape view on the iPad and portrait view on smartphones.

  • Applications reliant on hardware access are better off choosing native (games, camera, location etc). We have a limited need for creating native components in VG+. By choosing a hybrid approach, we could implement the best of both native and Web.

  • A native feeling differentiates premium products from Web products. If a premium app feels “Webish” or there is a lag in loading content, customers associate this experience with the Web. This is a bad association to establish when trying to convince the user to pay for a premium digital product as opposed to free content on a Web page.

  • HTML apps tend not to feel as polished as native apps. Also, they generally don’t look like native apps.

  • The Webview used in apps is slower than Safari. Nitro JavaScript Engine is not available in UIWebView.

  • Apps/mobile content need to be fast. Natively rendered content have a tendency to render quicker than HTML content.

  • The traditional problems with Web development are associated with supporting old browser versions. The same problem has begun to develop on mobile platforms as new versions of browsers and different versions of webkit are released per operating system

Conclusion: I think the most important advice I can give is to try use the right tool for the job. The right technology for VG+ at this time was to develop hybrid apps. We have developed both native and hybrid apps for different VG products based on different project requirements.

In our case, a hybrid solution was the right solution for this product. The hybrid approach has allowed us to selectively choose the right technology (HTML or native) for different features and to achieve the performance and user experience we and our users demand from a subscription product.

Our users are also happy with the new app. Since the release of VG+ 2.0 in March, 2013, VG+ has had phenomenal growth with 45,000 subscribers. At this point, it is the eighth-largest newspaper in Norway (this includes printed newspapers). We have also had a rapid increase in page views per user and time spent within the apps.

VG+ 2.0 received a special mention at this years European WAN-IFRA awards in the category “Best in Tablet Publishing” category and it is in a finalist in the 2014 Appy awards in the Consumer Magazine/Newspaper App category.

Advice for others considering such a move?

There is no right or wrong strategy. It really depends on the requirements, resources available, and the time and budget of the project in question. Technology is changing rapidly, native software development kits and Web standards will continue to develop. The decision process will also have to adapt both with new and changing technologies and user habits.

By continuing to browse or by clicking “ACCEPT,” you agree to the storing of cookies on your device to enhance your site experience. To learn more about how we use cookies, please see our privacy policy.