In This Chapter

Uncovering the difference between mobile web apps and native apps

Knowing when to build a hybrid native app

Seeing the different parts of an app

Three objects were considered essential across all participants, cultures, and genders: keys, money, and mobile phone.

—Jan Chipchase, Nokia

Mobile phones are increasing the reach of web applications and those connected to the Internet. Every year, people buy 300 million desktop computers but almost 2 billion mobile phones — and the number is steadily increasing.

With all these mobile phones users, it takes less time than ever to build a massive user audience. Facebook, which initially started as a website, reached 1 billion users after eight and a half years. Whatsapp, a mobile messaging app, registered the same number of users in just six years.

In this chapter, you learn about the creation of mobile applications that run in a browser on any mobile device as well as applications that are downloaded from an app store and run directly on only one type of mobile device, such as an iPhone or Android phone.

Defining Types of Mobile Apps

Web applications are websites you visit using a web browser on any device. Websites optimized for use on a mobile device, such as a phone or a tablet, are called mobile web applications. By contrast, native mobile applications cannot be viewed using a web browser. Instead, native mobile applications are downloaded from an app store such as Apple’s App Store or Google’s Play Store, and designed to run on a specific device such as an iPhone or an Android tablet. Historically, desktop computers outnumbered and outsold mobile devices, but two major trends in mobile usage have occurred recently:

• In 2014, people with mobile devices outnumbered people with desktop computers. This gap is projected to continue increasing, as shown in Figure 7-1.
• Mobile-device users spend 80 percent of their time using native mobile applications, and 20 percent of their time browsing mobile web applications.

Companies are called mobile first when they design and develop the mobile version of their applications before the desktop version. For example, Instagram first built a mobile application, which continues to have more functionality than their regular website.

When coding mobile applications, developers can build either

• Mobile web applications by using web development languages such as HTML, CSS, JavaScript for the front end and Python, Ruby, or another server-side language for the back end.
• Native mobile applications by using a specific language. For example, Apple devices are programmed using Objective-C or Swift, and Android devices are programmed using Java.

The choice between these two options may seem simple, but a few factors are at play. Consider the following:

• Companies developing mobile web applications must make sure the mobile version works across different browsers, screen sizes, and manufacturers, such as Apple, Samsung, RIM, and Microsoft. All these variables result in thousands of possible phone combinations, which can greatly increase the complexity of testing before launch. Native mobile apps run on only one phone platform, so you need to account for less variation.
• Despite running on only one platform, native mobile apps are more expensive and take longer to build than mobile web apps.
• Some developers have reported that mobile web applications have more performance issues and load more slowly than native mobile applications.
• As mentioned, users are spending more time using native mobile applications and less time using browser-based mobile web apps.
• Native mobile apps are distributed through an app store, which may require approval from the app storeowner, whereas mobile web apps are accessible from any web browser. For example, Apple has a strict approval policy and takes up to six days to approve an app for inclusion in its App Store, but Google has a more relaxed approval policy and approves an app within two hours.

In one famous example of an app rejected from an app store, Apple blocked Google from launching the Google Voice app in Apple’s App Store because it overlapped with Apple’s own phone functionality. Google responded by creating a mobile web app accessible from any browser, and Apple could do nothing to block it.

If you’re making the choice between building a mobile web or a native app, consider the complexity of your application. Simple applications, like schedules or menus, can likely be cheaply developed with a mobile web app, whereas more complex applications, like messaging and social networking, may benefit from having a native mobile app. Even well established technology companies struggle with this choice. Initially, Facebook and LinkedIn created mobile web applications, but both have since shifted to primarily promoting and supporting native mobile apps. The companies cited better speed, memory management, and developer tools as some of the reasons for making the switch.

Creating Mobile Web Apps for Any Phone

To build a mobile web app, you use the front-end languages HTML, CSS, and JavaScript. CSS controls the website appearance across devices based on the screen width. Screens with a small width, such as those on phones, are assigned a vertically based layout; screens with a larger width, such as those on tablets, are assigned a horizontally based layout. Because mobile web apps are accessed from the mobile browser and are not installed on the user’s device, these web apps usually can’t send push notifications (alerts) to the phone, can’t run in the background while the browser is minimized, and can’t communicate with other apps.

Although you can write the HTML, CSS, and JavaScript for your mobile web app from scratch, mobile web frameworks enable you to develop from a base of pre-written code, much like the frameworks for programming languages (such as Rails for Ruby). These mobile web frameworks include a collection of generic components that are reused frequently, and allow developers to build, test, and launch websites more quickly. Twitter Bootstrap is one such mobile web framework, allowing your websites to have a consistent look across devices.

For applications that have additional complexity, such as storing user data or payment mechanisms, you can use back-end languages such as Ruby, Python, or PHP.

As you increase feature complexity, keep in mind that phones typically have limited to poor bandwidth, a small screen size, and finite battery power.

Any website can be viewed with a mobile browser, but websites not optimized for mobile devices look weird, with the regular website font size and image dimensions either improperly scaled down to fit on a mobile screen or not adjusted at all (as shown in Figure 7-2, left). By contrast, websites optimized for mobile devices with CSS have fonts that are readable, images that scale to the mobile device screen, and a vertical layout suitable for a mobile phone (as shown in Figure 7-2, right).

Coding Native Mobile Apps for iPhones and Android Devices

Native mobile apps can be faster, more reliable, and look more polished than mobile web apps, as shown in Figure 7-3, left. Built using Java for use on Android devices, and Objective-C or Swift for use on Apple devices (iOS), native mobile apps must be uploaded to an app store, which may require approval.

The main benefits of an app store are its centralized distribution and capability to curate, catalog, and feature apps, which can drive downloads. Also, because native mobile apps are programs that are installed on the mobile device, they can be used in more situations without an Internet connection. Finally, and most importantly, users appear to prefer native mobile apps to mobile web apps by a wide margin, one that continues to increase.

Native mobile apps can take advantage of features that run in the background while the app is minimized, such as push notifications, and can communicate with other apps. These features are not available in a mobile web app. Additionally, graphics-intensive apps, such as games, perform better as a native mobile app.

Although native mobile apps offer better performance and a greater number of features, they require longer development time and are more expensive to build than mobile web apps.

Another way to build a native mobile app is to use a hybrid approach that involves building an app with HTML, CSS, and JavaScript, packaging that code using a wrapper, and then running the code inside a native mobile app container.

The most popular wrapper is a product called PhoneGap, which recognizes specific JavaScript commands that allow access to device-level functionality that’s normally inaccessible to mobile web applications. After one version of the app is built, native mobile app containers can be launched for up to nine platforms, including Apple, Android, Blackberry, and Windows Phone. The major advantages to using this hybrid approach follow:

• You can code the app using languages you already know, resulting in a much smaller learning curve.
• You can build your app once, and then release it to many platforms simultaneously.
• You can prototype, test, and receive feedback on your app quickly and more easily than when building a native app from scratch.

Major apps, such as the BBC’s Olympics app, have been built using this approach. However, if the app takes off, it is often rebuilt into a purely native version to increase speed and reliability.

Imagine you know how to play the piano, but you also want to learn how to reproduce the sound of a violin. One way you could do this is to buy a violin and start learning how to play. Another option is to buy a synthesizer keyboard, set the tone to violin, and play the keyboard so that it sounds like a violin. This second option is similar to the hybrid approach, except in this example, the piano is HTML, CSS, and JavaScript, the violin is a native iOS app, and the synthesizer keyboard is a wrapper such as PhoneGap. Just like the synthesizer keyboard can be set to violin, cello, or guitar, so too can PhoneGap create native apps for Apple, Android, and other platforms.

Identifying the Parts of an App

Whether you’re building a mobile web app or a native app, the component parts of an app run on both the client and the server.

The client is your personal mobile device that runs a local version of the app. The server stores the master copy of the app code and related databases.

Client components or processes affect the look, feel, and functionality on the mobile device. The following are typical components and processes that affect the client:

• User interaction and user experience (UI/UX) design: The small screen and virtual keyboard require a good amount of thought around how the app will receive user input and what to display. UI/UX design is the process of designing how the app will look, feel, and operate. Minor changes and design choices can have a huge effect on the ultimate success of the app. For example, when the Tinder dating app launched, it differed from other dating apps because users browsed through short picture profiles of people by using a simple left-right swipe gesture instead of viewing lengthy detailed textual profiles. This change helped Tinder capture 90 percent of the online dating market in less than one year.
• Wireframes: After you determine the main user interactions and displays, you use wireframes to display each screen and exactly how the users will interact with the app. Initially, these wireframes can be rough sketches. Then, usually before writing any code, high-fidelity versions with images are created for developers to use.
• Caching: Because mobile devices typically have limited bandwidth and speed, you can improve performance if you locally cache, or save, certain data onto the phone. For example, if you were creating a restaurant reservation app, you might store on the phone the restaurants where the user makes the most reservations instead of requesting these frequently visited restaurants from the server each time the app is launched.
• Synchronization: Users often expect that a mobile app, unlike websites built for desktops, will work even when no Internet connection is present. This expectation creates an issue because changes made to the app when offline must be uploaded to the server, and any conflicts must be reconciled. For example, suppose you lose your Internet connection while you are accepting a meeting invite using the calendar app on your phone. The app needs to have code that decides how often and when to upload your accepted meeting invite to the server.

Server components or processes occur on the company’s server, in the background or in real-time, and support the app’s functionality. The following are typical components that run on the server and processes that affect the code or components running on the server:

• Logic: Code must be written to decide what information to permanently save for later retrieval and what to display to the user and when.
• Storage: Databases must be created to store user-generated data and anything else your app will display to users.
• Notifications: These pop-ups appear even when the app is closed, keeping users engaged by reminding them to use the app. Notification events can be trigged by time, user activity (for example, you just made a payment), or an external event (such as someone just shared a photo and tagged you in it).
• User accounts: Creating and deleting user accounts, authenticating users, and allowing access to some or all app features are necessary for any app that stores sensitive information.
• Referrals and sharing: Integration with email providers and social networks are another way apps gain new users. Each social network, such as Facebook or Twitter, has its own steps to authenticate and share user content.
• Versions: Unlike software you install on a desktop, mobile software is typically updated more frequently with new features and security fixes. Some users will not upgrade to the latest version of your app, so you need to make sure that any new versions of your app do not conflict with older versions.