Change is the only constant in the IT industry, and this change has been particularly dramatic in the case of the mobile phone industry. Let’s take a quick look at the transformation in this industry over the last two decades, and how this has impacted mobile app development.
Mobile devices have changed drastically, starting off from Nokia’s basic feature phones, moving to BlackBerry’s smart/business phones, and then to the revolutionary Google and Apple smartphones. With time, hardware has improved with increasing RAM and processor capabilities. Today, there are lot of cool hardware being built into phones to make them complete devices, right from cameras and GPS to accelerometers and fingerprint readers.
Over the years, plethora of mobile OS/platforms have been created and launched by companies like Sun, Qualcomm, RIM, Microsoft, Google and Apple — right from J2ME/BREW to BlackBerry (RIM), and Android, iOS and WP8. All these platforms support different native API suites and vary in terms of the framework they offer. In fact, the base programming languages of these platforms have been different. Java was used for J2ME, RIM and Android, while C++ was used for BREW, C#/C++ for WP8 and Objective C for iOS.
With the mobile market being shared by these different platforms/OSs, till a few years back it was difficult for developers and companies to create mobile applications for all platforms. It needed a diverse set of skills to develop and maintain mobile applications for each of the mobile platforms and, thus, presented cost and time-to-market challenges.
The alternate means tried included creating hybrid apps (Web based applications wrapped in native mobile app containers). Hybrid apps had their own limitations and were deficient in terms of performance, user engagement and effective utilisation of device hardware capabilities.
The recent innovation of bot platforms has introduced new possibilities for creating device and platform neutral apps. In the long run, bots (chat-bots) are predicted to substitute a major chunk of mobile apps. Though new, bot platforms are limited in terms of the API set, features and capabilities, as of date.
Hence, considering the diverse OS ecosystem, a mobile application design and development strategy becomes very important. A smart, strategic approach allows supporting multiple OSs/platforms and devices, without compromising on aspects like performance and user engagement.
This article is based on my years of experience in designing and developing games as well as consumer and enterprise-grade rich mobile client applications for all the earlier-mentioned platforms. Individual developers or organisations that plan to develop mobile client applications may find my experiences helpful in deciding on the most suitable mobile design and development strategy, after evaluating the pros and cons of each. I intend to share information about different mobile OSs/platforms for different era, the challenges they presented at the time, followed by the design and development strategy adopted to deal with those challenges.
Early 2000s: The era of feature phones with J2ME/BREW apps
During the early 2000s and until around 2004, BREW and J2ME games and apps were predominant in the market. The reason was simple — people were using feature phones and they needed lightweight platforms. Most feature phones supported either J2ME or BREW.
Qualcomm’s BREW was based on C/C++. On the other hand, J2ME (Java 2 Micro-Edition) was a stripped down version of Java’s Standard edition, with a limited API set meant for devices with minimal hardware. It was mostly used to build lightweight games, and basic applications for feature phones with limited functions, like those related to PIM (Personal Information Management). J2ME devices hardly allowed anything related to system/hardware interfacing and even if they did, things rarely worked as intended. This limited J2ME to be used mostly for gaming applications on feature phones and not for any sophisticated client application.
The challenges – poor hardware, as well as limited APIs and multi-tasking: The early feature phones came with quite a few challenges.
1. Building games or apps on J2ME was challenging owing to limited hardware capabilities. Many of the phones allowed a maximum of 64KB of JAR (J2ME binary size) and/or allowed 128KB of RAM. Even the most popular J2ME device in 2005, the Nokia 6600, supported 1MB of RAM for J2ME apps.
2. Also, since the API set was very limited, it only enabled the creation of very basic applications.
3. Multi-tasking was missing on most of the feature phones. J2ME apps used to pause as soon as they were moved to the background.
Alternative approaches to deal with small RAM and app binary sizes: Over the years, the design and development strategies adopted to overcome different challenges included the following.
1. Apps were packaged with very few resources (images), while other required resources were fetched once from the server via data calls and then cached locally to the record management system.
2. Apps were designed to load only a portion of the data or resource (image) required at any moment of time. Later, loaded resources were replaced with other resources needed for subsequent flows. For example, for one of the gaming applications (Shadow Showdown’s FOP), we chopped the big image of a character animation into three independent parts to keep the memory in check by optimising the size of the image part. We then used one part of the image at a time and then replaced it with another part when needed.
3. Usually, basic apps were built without a rich API set and no multi-tasking.
2005-09: The BlackBerry era heralds the first smart, business phone
Roughly between 2005 and 2010 was when BlackBerry phones enjoyed the most popularity. BlackBerry from RIM (Research in Motion) was the first smartphone introduced in the league of phones/platforms discussed in this article. Because of its security, it was considered the best business phone and preferred by enterprises. BlackBerry had its own OS, which provided multi-tasking and initially supported devices with a trackwheel and trackpad. The brand had many popular series of phones, like Curve, Pearl and Storm, to name a few.
BlackBerry provided a Java based API set. With rich APIs and multi-tasking supported by the OS, it became possible for developers to build sophisticated native business apps which hadn’t been the case for J2ME apps. Being able to use built-in device capabilities allowed apps to have features like file operations, native email, phone and SMS.
Rich applications, right from Reuter’s stock market app and the Stitcher radio (audio) app to OpenTable’s restaurant booking app and Broadworks Assistant VoIP calling background app, were all possible with RIM. Yet, creating mobile websites or Web based applications wasn’t feasible owing to very limited JavaScript support.
The challenges: Some of the main shortcomings of the BlackBerry included a small display, a complex UI API, an old Web kit and difficult backward compatibility.
1. One of the biggest challenges for BlackBerry’s popular 4.x device series (that included Curve and Pearl) was designing the UX and implementing it. BlackBerry phones already had only a single column view compared to screens that permitted the multi-column view for a wider Web area. On top of this, the hard keypad hindered the possibility of increasing the display height effectively.
2. The only way to create a user interface (UI) for BlackBerry’s Java apps was by using RIM native APIs. The UI API set and layout principles were complex, and this made it difficult to develop a rich UI.
3. The majority of BlackBerry users in the market had the old RIM OS version (4.x series) running on their devices, and the Web kit engine that came with 4.x was limited in terms of functionality and JavaScript capabilities. Hence, building mobile websites became really difficult. I remember that building an interactive Web calendar control became almost impossible for the BlackBerry OS 4.x series.
4. RIM supported static class verification, that is, if an app was compiled and packaged with a higher OS version’s native library API suite and possessed a higher OS API, then the packaged app would not install on devices with old OS versions. This made it difficult to enable backward compatibility while creating apps targeted for latest OS versions.
Dealing with the challenges: Listed below are some of the design and development strategies used to overcome the different challenges.
1. All key modules were served as Home Screen options, after which standard linear or tabbed (for big apps) navigation followed.
2. A reusable custom compounded and UI component library was created. This was done by extending standard containers and components (like a field manager, vertical/horizontal field managers, label/text fields, etc).
3. As 4.x devices covered a majority of the market initially, native RIM applications were the only option until the launch of RIM OS 6.x/ 7.x series with the Web kit 2 engine during late 2010-12.
4. Backward compatibility was smartly achieved by compiling a base version of the app with the minimum OS version supported by it. For all add-on delta features, add-on binary files were created for the app with a higher OS API and advanced functionality. The base code had a smart factory to check which OS version the app was running on, and dynamically loaded the implementation of the higher OS version if the device had the required OS version. While distributing the app, the distribution server would check the OS version of the device requesting the app download. For higher OS versions, the distribution server could load the JAD (Java application descriptor) file, which possessed entries of all binary files, including the base binary packaged with the minimum OS as well as add-on binary files packaged with higher OS versions to achieve advanced functionality.
2010: How Android and iOS transformed the mobile industry
The mobile industry underwent a disruptive transformation with the launch of Android and iOS during the years 2008-10.
Google’s Android and Apple’s iOS were launched to run on high-end mobile devices (like HTC, iPhone, etc). These devices were not just mobile devices but were almost small computers with great processing and computing capabilities. They had a lot of useful hardware built-in, like GPS receivers, cameras, accelerometers, etc. Android and iOS provisioned native APIs to access and use these built-in capabilities within applications.
Along with such great hardware capabilities, both Android and iOS came up with full touchscreen devices without hard keypads. This ensured that most of the screen height became usable and thus enhanced the usability of applications. Excellent gesture detection and touch capabilities of these devices provided an extraordinary user experience.
The challenge: J2ME, BREW and RIM were already around, and with the launch of iOS and Android, the mobile industry was using several mobile platforms between 2010 and 2012-13. Different platforms with different native APIs made it really difficult for developers/companies to build apps for mobile users.
It now became imperative for developers and companies to support all these platforms to cover the entire market. With different native APIs and different base languages, the task became really challenging. It required a different skillset to build mobile apps for different platforms, and this increased costs and time-to-market substantially, because different versions of an application were built and maintained for each platform. Domain knowledge couldn’t be reused with different teams which resulted in inconsistent app behaviour.
Web/hybrid apps: The industry was struggling with the many variations around mobile platforms and APIs. Moreover, there were new mobile OSs/platforms, which were on the verge of being launched. As a result, developers and companies started channelling their efforts and energies around creating platform-independent, Web/HTML based mobile applications.
Web kit engines were getting better with each new version of an OS. Also, the introduction of HTML5 gave developers the confidence to try and build mobile websites which worked across all mobile platforms. Website UIs got redesigned for single column view mobile devices and content was then served dynamically with the help of JavaScript (Ajax).
Mobile websites, a.k.a. thin clients, provided platform-independent solutions but observed less end user adoption owing to difficulties in using and managing different websites at the same time on mobile devices. Users always preferred quick app icons. Also, pure mobile websites running in browsers lacked the capability to use the inbuilt device hardware like the camera, GPS, etc.
Hybrid mobile applications overcame mobile website problems. They served Web based (HTML) content within a native mobile app container. The mobile app container houses the Web view, which loads the URL for the Web content (which can be thought of as the website’s URL). Hybrid mobile apps with a quick launch app icon freed the user from managing different website URLs.
Additionally, hybrid mobile apps leveraged the Web to native bridge interfaces (plugins), to utilise built-in device hardware capabilities within the app.
So hybrid mobile apps became the alternate option to deal with the time-to-market and cost problems arising from supporting multiple mobile platforms during the period 2010-12. These hybrid apps, unfortunately, soon came under scrutiny due to the adverse impact of Web content in terms of user experience and performance. This led to the famous discussion on ‘native versus hybrid mobile applications’.
Hybrid vs native mobile apps: This has been a topic of much debate for many years amongst developers and companies wishing to create mobile applications for different platforms — whether to opt for native or hybrid mobile apps.
The best way to decide between the two options is by answering a few questions like:
1. How much does cost and time to market matter to you?
a. If you have a highly skilled team, and time and performance matter to you, then native is a better choice. A skilled team can quickly learn the syntax of new mobile platforms and port a native mobile app to a platform.
b. If your team is small and you are targeting a quick launch for your mobile app, then hybrid is the way to go, as the same code can be reused across different mobile OSs/platforms.
2. Who are your target users? Is it going to be an in-house app meant for those within the company or a public app for your customers/end consumers?
a. If it is going to be a public app for your customers, then native is the better choice over hybrid because the user experience is of utmost importance to mobile users. Reports on the Internet suggest that around 80 per cent of users only retry a mobile app once or at the most, twice, if it fails to work as intended or if it is slow. It is important to keep users engaged at all times and that can be done via fast performing native apps. One key example is of Facebook migrating from HTML to a native mobile app to keep users engaged by serving more feeds at the same time.
b. If it is going to be an in-house app for users within the organisation, then hybrid apps can work, particularly if the app is meant for routine business operations. Internal apps need not be very exciting for users, as long as they solve the purpose in the expected timeframe.
3. What is the geography of your majority user base? How many platforms do you actually want to cover?
a. If you are targeting just one geographic region with the launch of your app, then native is a better choice, as you can just target the one platform that commands the highest market share in that geographic region (like iOS for USA).
b. If you are targeting to release your app globally, then a hybrid app can be opted for as the market will be shared by different mobile OSs/platforms.
4. How big or rich does your mobile application need to be?
a. If you are targeting to launch a full blown, rich mobile app with built-in device hardware capabilities like a camera, GPS, etc, then native is a better choice for enhancing the performance of the app, and effectively achieving touch/gesture handling and built-in device hardware capabilities.
b. If you are targeting to launch a minimum viable product (MVP) for your mobile app, then hybrid can be the option as performance may not be hampered much with less frequent Web-to-native layer interactions. Also, it gives opportunities to the developers to try out different ideas in no time — in the form of MVP of different hybrid mobile apps. They can later opt for the native app route for ideas that gain traction and, hence, need to be extended and scaled in the form of a mobile app (the way Facebook did).
2017: Android and iOS lead the mobile market
With great technological advances continuously enhancing the hardware, both Android and iOS have become the most popular choice of consumers today. With a growing user base, developer adoption and increasing app volume on Play/App Store, Android and iOS are now leading the mobile market with a major share of the global market.
As opposed to BlackBerry, both Android and iOS were launched with their initial focus on the end user. Gradually, the latter two also built security and APIs to cater to business and enterprise needs. With these platforms leading the market and with the growing BYOD culture, both these platforms have become the choice for business apps as well.
Ease of development via an easy and great API suite have resulted in developers and companies quickly adopting these two platforms. As a result, all other mobile platforms/OSs like J2ME, RIM, and even Windows Phone, which came into the market late, have lost their limited market share and almost vanished. This has solved the cost and time-to-market problem caused by supporting multiple mobile OSs/platforms. Developers/companies can now just create apps for Android and iOS. Moreover, with great and simple design wizards to create UIs on Android and with the introduction of simpler programming languages like Swift on iOS, it is now quick and easy to create iOS and Android native apps.
The challenge of apps flooding mobile devices: Developers have started creating separate Android and iOS mobile applications for every small function and are inducing end users to install many of them. This is now creating a problem with users’ mobile devices getting flooded with too many applications.
The future: Bot platforms and specialised mobile apps
Today, most mobile users are always connected to social messenger channels like WhatsApp and Facebook Messenger or to mobile OS specific messenger channels like iMessage. This increasing user engagement with messenger channels has influenced messenger app companies like Facebook and Slack to innovate and create bot platforms, which enable companies to create business-specific chat-bots to connect with their end customers on social messenger channels. Apple’s iMessage and Google’s Allo are both expected to have their bot platforms to help create chat-bots.
Bot platforms are allowing companies to mark their presence on channels where users are investing most of their time. This increases their chances of business. Chat-bots appear as normal messenger contacts to the end user in a messenger list, and thus do away with the need to have separate mobile apps for every small need. Moreover, bot platforms are device and platform neutral — for example, Facebook Messenger runs on all devices, be it mobile phones or wearables, for both Android and iOS.
Bot platforms are new, and deficient in terms of feature support and built-in device capability. So, for the next few years, chat-bots are expected to be used for basic functions and needs instead of having separate mobile apps. Native Android and iOS mobile applications are expected to serve specialised needs/requirements. As an example, it makes more sense to create high performing native mobile banking app for Android and iOS that leverage a built-in fingerprint reader to authorise app access, or use a GPS receiver to identify the location of a user’s mobile device and the server list of nearby banks/ATMs.
