A crash course in app development methodologies.

This post discusses the differences between responsive and web friendly websites, app development methodologies and everything you need to know about sub-domains and whether you should publish your mobile website on one.

What you need to know about domains

A domain name is the string displayed before the last period in a web address which then is followed by the so-called TLD (top level domain) which can be distinguished in six groups as illustrated below:

• Country code top-level domains (ccTLD)
• Generic top-level domains (gTLD)
• Infrastructure top-level domain (ARPA)
• Restricted generic top-level domains (grTLD)
• Sponsored top-level domains (sTLD)
• Test top-level domains (tTLD)

(Thrall.org, 2017)

For most web users the two TLDs of interests are Generic TLDs (gTLD) which include .com, .edu and .gov; and Country TLDs (ccTLD) including .fr for France and .se for Sweden.

Sub-domains

A sub-domain is a prefix that can be used to differentiate segments of web content and common use cases and examples on sub-domains are:

Different language versions of a website

french.thewebsite.com

english.thewebsite.com

Country-specific webshops

sweden.webshop.com

uk.webshop.com

Mobile adapted versions of primary content

mob.newspaper.com

While the decision to use sub-domains to differentiate language- and country-specific versions of web content are
self-explanatory, sub-domains sometimes also are used to distinguish mobile- and desktop versions of a website as illustrated in the last point in the above list.

One typical instance when such strategy is used is content-rich websites including news- or governments sites where part of the content is hidden for mobile users to simplify the mobile UX. This is perfectly legitimate if an organisations web analytics clearly show that mobile users rarely consume explicit parts of the web content and where a technical audit also attest that hiding parts of the content will increase loading speed and lead to a more user-friendly UX. A mobile optimised website can then be published on a sub-domain to indicate for users what version of the site they are visiting. In all instances where content visible for users on a desktop version of a website are hidden for mobile users, there is, however, important to always include a link to the desktop counterpart as users who first have visited the site using a desktop computer might be confused if they later re-visit the site from a mobile device looking for the same content.

Content published on a sub-domain is by Google and most other search engines recognised as separate websites and to avoid duplicate content in the search results, Google, therefore, will include only one reference; either the primary domain or the sub-domain (Support.google.com, 2017a). To keep control of which domain that should be displayed in the SERP (usually the primary domain), it is, therefore, important to indicate pages that should not be indexed either in the htaccess file, a robot.txt or by using a ‘no-index meta tag’ on the duplicate pages.

It should also be noted that many CMS’s lacks multi-domain support and that a sub-domain strategy, depending on the CMS used by the organisation, might result in the need for two separate databases with two non-synced back-ends as a result. While this is not a major problem for smaller websites not frequently updated, this for larger sites can lead to substantially more work in keeping both databases in sync and up-to-date.

Responsive vs. Web-friendly

In most cases, a better way of adapting a website to the limitations of the mobile eco-system is to make it web-friendly and using a single domain for both the desktop- and the mobile experience.

While a responsive website adapts to the size of the visiting device accomplished by structural elements defined with relative values such as EMS or percent instead of fixed pixels and by the implementation of media queries (W3schools.com, 2017); a web friendly website accounts for much more than just the visual experience including:

• A design that adapts to any screen size.
• A page load of maximum 2 seconds, also on slow connections (Kissmetrics, 2017).
• A response rate of 0.1 seconds (Nielsen, 2017).
• That the site work also on old devices with limited JavaScript capabilities; including all UX-elements such as buttons, menus and navigation.

Apps

Mobile Apps, simplified, can be described as stand-alone applications usually created to solve a particular task in a more efficient manner than what can be achieved by a typical mobile-friendly website.

Apps can be the sole reason why a company exist as with Snapchat (2017); they can be created as a way for an organisation to gain an additional source of income; and/or being created to offer a better user experience for mobile visitors. Apps also have become an important alternative for organisations which suffered as the result of ‘ad-blockers’ which, according to Harvard Business Review (2017) for some companies has led to a net loss of advertising income as high as 50%. To bring back some of this lost revenue, many of these companies, especially within publishing, have pursued to create apps to make sure that adverts are not blocked.

The decision to create an app, however, need to be carefully assessed. Every app needs monetary recourses and staff; not only for the initial development but also for content production and on-going management. From a marketing perspective apps also are no different from any commercial product and will need a separate marketing plan and funds for advertising. Companies with no experience from running apps also need to set-aside resources for educating their marketing staff in the specifics of app marketing, which include building a thorough understanding of App Store Optimization (Kissmetrics, 2017).

The four principal methodologies of app development

The following section discusses the four principal methodologies of app development. Technical and practical differences of each method also are presented together with potential advantages and disadvantages from a digital marketing perspective.

Web apps

Web apps are, in essence, web pages built with a mobile-first perspective designed to look and feel like a native app described in Appendix 5. They are written in HTML5, CSS and JavaScript, and runs in the web browser accessible through a normal URL. While HTML5 give access to many hardware features such as GPS, accelerometer, camera and offline access (HTML5 Rocks, 2017; Technologies, 2017); the main difference between native and web-apps from a technical standpoint, is that native apps are written in
device-specific languages and, thereby, have a much better performance which is explained in Appendix 5.

From a production and marketing perspective, web-apps have both advantages and disadvantages.

The fact that web apps technically are websites, they are cheap to develop and also need no special back-end services, allowing for the use of any CMS including WordPress or Joomla. On the negative side, web apps offer less performance compared to native apps and have less access to device hardware features than a native app.

From a sales- and marketing perspective web apps do not differ from regular websites and a marketing team can use the same traditional marketing tactics (on-site and off-site) as in traditional web marketing; including SEO, link building and optimisation of content and code. It should be noted, though, that web-apps are not installed on user devices, nor can not be sold or marketed through the app stores. Whether this is an issue or not, of course depends on the organisations underlying business goals of creating the app.

#Web app example

In 2011 Financial Times (2017) after previously offering their readers a native app, withdrew this from the Apple’s store and instead published a new web app. Difficult to distinguish from a native app with no visible browser buttons, horizontal swipe functionality and the utilisation of the web worker API making content also available offline; the app is built using normal HTML5 and, in essence, is a normal web page. (Nngroup.com, 2015)

Native Apps

Native apps are written in the language of the hardware platform of the device that runs it. They utilise data processing capacity more efficiently than web-apps and offer a faster and more “smooth” experience, in addition to also having access to almost all hardware features of the running device. Contrary to the beliefs of many marketers, though, “going native” is not necessary to gain access to basic device functions like the camera, speedometer or the GPS, nor to create apps that function in the same manner as a native app in offline mode without an internet connection something which can be achieved through the ServerWorker API (mobiForge, 2017). Native apps, however, handle offline behaviour and hardware access much more efficient than web apps and for many data-intensive applications including graphic intensive games, native apps are the only viable alternative.

From a technical standpoint and the fact that native apps are written, not in a universal language like HTML5, but in a device specific language; native apps need to be developed in two different versions; one in Swift for IOS (Developer.apple.com, 2017) and one in Java for Android (not to be confused with JavaScript). Computationally intensive applications such as physics simulations and, as noted above, games, sometimes also are developed in C or C++ (Cprogramming.com, 2017) to maximise processor performance and many C-developers use the Android NDK library (NDK, 2017) to simplify app development in “C.”

Considerations when developing native apps

As noted above; for computationally intensive applications there might be no other alternative than to “go native.” Native app development, however, is very different from the development of web apps and the primary concern for many organisations with a native app strategy is cost. A true native app strategy with maximum device compatibility (IOS and Android) need to be developed in two versions. This means two separate apps often developed by two different teams with different coding skills and with high development costs as a result. This is also is why many organisations with a native app strategy often choose to develop their apps in only one version; either for IOS or Android. With two different apps in two different languages, a custom back-end also has to be developed, which depending on the complexity of the app, can cost more to develop than the actual app.

The best way for an organisation to look at a native app strategy is to treat a native app project as any other type of product and not only as a tool for marketing which often is the case with websites and web apps. A native app strategy, like any app strategy, also need to include a plan and resources for content production and marketing which include ASO (app store optimisation), SEO, advertising and PR. One of the main reasons to why many app ventures fail is not because the product is bad or doesn’t have a place in the marketplace, but because of a weak market strategy and inadequate resources to inform the market that the app exists. With 6.503.500 apps published in the major app marketplaces (Statista.com, 2017) all fighting for the customer’s attention, the old maxim “build it and they will come” can’t be further from the truth. One of the most important roles for a marketer working with a client with no previous experience of app projects, therefore, is to make sure that this is clearly understood and that sufficient resources are invested in the project.

Hybrid apps

A hybrid app is basically a web app which is hosted in a native container program or “shell” that translates the HTML and Javascript code of the web app to the native language of the device. Sophisticated hybrid frameworks like PhoneGap (2017) and Ionic (2017) enables organisations to develop apps functioning both on IOS and Android using a single codebase of standard HTML. Hybrid apps developed with these frameworks also to a great extent looks, feels, functions and have access to the same hardware features as a native app but can be developed to a fraction of the cost.

Hybrid apps, however, do not have the performance of a well coded native app.
The reason for this comes from the fact that hybrid apps involve an extra layer of code between the actual app developed in HTML and Javascript running inside the native container of the hybrid framework and which then needs to be “translated” to the native code of the device. However; only for the most computationally intensive apps, the difference for a user between a native app and a well coded hybrid app is very difficult to distinguish. Any organisation considering a native app strategy, therefore, carefully should evaluate whether the substantially higher cost of developing a native app can be motivated compared to a hybrid app strategy.

It should be noted that Hybrid apps, though, not only is used by organisations as a way to save money. One interesting feature of Hybrid apps is that they like web pages can be updated remote without any input from an end user which can be compared to
native apps which rely on end users to manually update an app when a new version is released. For development- and marketing teams this brings some significant advantages such as the possibility to perform A/B testing and changes to the UX at any time and frequency without the need for action by the user.

#Hybrid app example


To many native proponents surprise, the Instagram app, in fact, are a hybrid app. By utilising the UIWebview (Developer.apple.com, 2017), Instagram runs the full web application from a server and with their hybrid app acting as a container. This allows Instagram to perform instant updates, A/B-testing and changes of the UX without any action from the users of the app. (Ormandy, 2015)

The golden middle way: native scripting.

There is a fourth app development strategy that organisations should consider;
native scripting.

The idea of native scripting is to translate standard web code (HTML, Javascript and CSS) into native code (Swift and Java). Doing so, a single codebase, thereby, can be used both for Android and IOS lowering production costs and saving time while at the same time simplifying back-end management. The main difference with this methodology compared to hybrid app development is that apps developed with native scripting, in essence, are true native apps. While native scripting frameworks, arguably, do have a steeper learning curve than the hybrid counterparts, many hybrid apps on the market would have a significantly better performance if developed with native scripting; notably to the same or lower development cost. Two of the most popular native scripting platforms are React Native (2017) and Telerik (2017).

Summary

With the objective to give an overview of some of the main considerations of app development, this report has discussed different types of web domains and the four central methodologies of app development; web apps, native apps, hybrid apps and native scripting. Advantages and disadvantages of each app methodology also have been discussed, both from a technical and digital marketing perspective.

References

Android NDK. (2017). Android Developers. [online] Available at: https://developer.android.com [Accessed 13 Jun. 2017].

App Store. (2017). The Walking Dead. [online] Available at: https://itunes.apple.com/us/app/walking-dead-new-frontier/id1156258040?mt=8 [Accessed 14 Jun. 2017].

Cprogramming.com. (2017). Differences Between C and C++ – Cprogramming.com. [online] Available at: http://www.cprogramming.com/tutorial/c-vs-c++.html [Accessed 13 Jun. 2017].

Developer.apple.com. (2017). Swift – Apple Developer. [online] Available at: https://developer.apple.com/swift/ [Accessed 12 Jun. 2017].

Developer.apple.com. (2017). UIWebView – UIKit | Apple Developer Documentation. [online] Available at: https://developer.apple.com/documentation/uikit/uiwebview [Accessed 14 Jun. 2017].

Financial Times. (2017). Financial Times. [online] Available at: https://www.ft.com/ [Accessed 14 Jun. 2017].

Friedl, J. (2017). Guetzli doesn’t seem to respect PNG color profiles · Issue #64 · google/guetzli. [online] GitHub. Available at: https://github.com/google/guetzli/issues/64 [Accessed 12 Jun. 2017].

Google. (2015). Building for the next moment. [online] Available at: https://adwords.googleblog.com/2015/05/building-for-next-moment.html [Accessed 12 Jun. 2017].

Harvard Business Review. (2017). Ad Blocking’s Unintended Consequences. [online] Available at: https://hbr.org/2015/08/ad-blockings-unintended-consequences [Accessed 12 Jun. 2017].

How is JavaScript different from Java?. (2017). How is JavaScript different from Java?. [online] Available at: https://www.java.com/en/download/faq/java_javascript.xml [Accessed 13 Jun. 2017].

HTML5 Rocks. (2017). Capturing Audio & Video in HTML5 – HTML5 Rocks. [online] Available at: https://www.html5rocks.com/en/tutorials/getusermedia/intro/ [Accessed 12 Jun. 2017].

Ionic. (2017). Ionic. [online] Available at: https://ionicframework.com/ [Accessed 13 Jun. 2017].

Itunes.apple.com. (2017). App Store Downloads on iTunes. [online] Available at: https://itunes.apple.com/us/genre/ios/id36?mt=8 [Accessed 12 Jun. 2017].

Kissmetrics. (2017). App Store Optimization – A Crucial Piece of the Mobile App Marketing Puzzle. [online] Available at: https://blog.kissmetrics.com/app-store-optimization/ [Accessed 12 Jun. 2017].

Kissmetrics. (2017). How Loading Time Affects Your Bottom Line. [online] Available at: https://blog.kissmetrics.com/loading-time/ [Accessed 12 Jun. 2017].

KissMetrics. (2017). How Loading Time Affects Your Bottom Line. [online] Available at: https://blog.kissmetrics.com/loading-time/ [Accessed 12 Jun. 2017].

Meunier, B. and Meunier, B. (2017). 82% Of Sites Use Responsive Web Design In 2015? Try 11.8%. [online] Marketing Land. Available at: http://marketingland.com/82-sites-use-responsive-web-design-2015-try-11-8-114050 [Accessed 12 Jun. 2017].

mobiForge. (2017). Taking the web offline with service workers – mobiForge. [online] Available at: https://mobiforge.com/design-development/taking-web-offline-service-workers [Accessed 13 Jun. 2017].

NDK, G. (2017). Getting Started with the NDK | Android Developers. [online] Developer.android.com. Available at: https://developer.android.com/ndk/guides/index.html [Accessed 13 Jun. 2017].

Nngroup.com. (2015). Mobile: Native Apps, Web Apps, and Hybrid Apps. [online] Available at: https://www.nngroup.com/articles/mobile-native-apps/ [Accessed 14 Jun. 2017].

Nngroup.com. (2015). Website Response Times. [online] Available at: https://www.nngroup.com/articles/website-response-times/ [Accessed 12 Jun. 2017].

Ormandy, K. (2015). Your favourite app isn’t native. [online] Kennethormandy.com. Available at: http://kennethormandy.com/journal/your-favourite-app-isnt-native/ [Accessed 14 Jun. 2017].

PageSpeed Insights. (2017). PageSpeed Insights. [online] Available at: https://developers.google.com/speed/pagespeed/insights/ [Accessed 12 Jun. 2017].

PhoneGap, A. (2017). PhoneGap. [online] PhoneGap. Available at: https://phonegap.com/ [Accessed 13 Jun. 2017].

Play.google.com. (2017). Play.google.com. [online] Available at: https://play.google.com/store/apps?hl=en [Accessed 12 Jun. 2017].

React Native. (2017). React Native | A framework for building native apps using React. [online] Available at: https://facebook.github.io/react-native/ [Accessed 13 Jun. 2017].

Savvy Apps. (2017). How Much Does an App Cost: A Massive Review of Pricing and other Budget Considerations. [online] Available at: https://savvyapps.com/blog/how-much-does-app-cost-massive-review-pricing-budget-considerations [Accessed 12 Jun. 2017].

Snapchat. (2017). Snapchat. [online] Available at: https://www.snapchat.com/ [Accessed 13 Jun. 2017].

Statista.com. (2017). App stores: number of apps in leading app stores 2017 | Statista. [online] Available at: https://www.statista.com/statistics/276623/number-of-apps-available-in-leading-app-stores/ [Accessed 13 Jun. 2017].

StudioPress. (2017). Fast WordPress Hosting + Mobile Responsive Themes by StudioPress. [online] Available at: https://www.studiopress.com/ [Accessed 12 Jun. 2017].

Support.google.com. (2017). Duplicate content – Search Console Help. [online] Available at: https://support.google.com/webmasters/answer/66359?hl=en [Accessed 12 Jun. 2017].

Support.google.com. (2017). Meta tags that Google understands – Search Console Help. [online] Available at: https://support.google.com/webmasters/answer/79812 [Accessed 12 Jun. 2017].

Technologies, I. (2017). HTML5 Camera Access with BridgeIt. [online] Bridgeit.mobi. Available at: http://bridgeit.mobi/html5-camera-access.html [Accessed 12 Jun. 2017].

Telerik. (2017). Telerik. [online] Available at: http://www.telerik.com/nativescript [Accessed 13 Jun. 2017].

ThemeForest. (2017). Website Templates & Themes from ThemeForest. [online] Available at: https://themeforest.net/ [Accessed 12 Jun. 2017].

Thrall.org. (2017). Top Level Domain Names / Country Codes. [online] Available at: http://www.thrall.org/domains.htm [Accessed 12 Jun. 2017].

Time.com. (2017). Here’s Exactly Why You Should Care About Ad-Blockers. [online] Available at: http://time.com/4038410/ad-blocker/ [Accessed 12 Jun. 2017].

W3schools.com. (2017). Responsive Web Design Media Queries. [online] Available at: https://www.w3schools.com/css/css_rwd_mediaqueries.asp [Accessed 12 Jun. 2017].