It is doubtless that the mobile industry is a competitive space, driven by numbers, industry, and profits. Devices, hardware, technology, and software are anywhere from predictable as a yearly iteration to a fierce struggle, with names like as Apple and Google taking a lead, with yearly iterations of new iPhones, Androids, and features sweeping the industry.

There is no question for why this is. 81% of Americans are in possession of a smartphone and in 2018, global app revenue reached $92.1 billion.[1][2] These are staggering numbers, continuing to grow as there is more mobile app usage, downloads, advertising, device adoption rates, and so on.

A customer does not witness this struggle and does not need to know about the conflict happening between-and-by businesses in this competitive race. But they do grow, and as more customers engage in the growing mobile landscape, companies and developers are in a hot race to obtain as great of a market share as they can.

These are all incredibly important facts. A developer, a company, and a budding start-up all share common challenges within this evolving, competitive field-consistently innovating and iterating, lest they fall behind their contemporaries.

While centric on iPhone and iOS development, this discussion aims to highlight on three major fields of challenges for mobile development.

1. The Customer is Always Right.

It goes without saying that the worst mobile app is a glorified web portal or a fancy bookmark.[3] Your app should be something that provides value, gives some benefit, and have some uniqueness to avoid being overshadowed by a competitor.

As well as the challenge in actually creating a product; between drafting, market research and analysis, designing, developing, testing, and maintaining; there is a greater challenge present that looms above all.

“The customer is always right”.

That is, in the billboards of top-rated applications, growing rivals in your industry, and the relative ease it is to find, install, and use alternative platforms, what justifies your own app as being “correct” for a customer? And while it may easy to get your customers in the door, what value will keep your customers coming back, in an industry where retention is less than a third across 90 days?[4]

The unique values of a product will not be discussed here, only the global challenges that all mobile apps face. Beyond the innate challenges of marketing in a consumer-centric platform, the technical challenges and their associated consequences also exist.

Crashing is a forefront of what comes to mind as a pain-point, but it is not the only factor. Users may endure any number of headaches, from excessive storage consumption, mobile data usage, obnoxious UI, and painfully slow loading.

Customers hate to wait, and that’s a fact.[5][6] In a world of convenience where a customer may even be migrating from device-to-device every few years, what remains constant is their sense of ownership. While users may spend upward of two hours each day on their smartphones, being asked to endure a few seconds of waiting is unacceptable.[7]

Paradoxically, it’s best that a phone doesn’t choose what it does, but the user. Apple strongly emphasizes this way of thinking within their Human Interface Guidelines:

“Throughout iOS, people—not apps—are in control. An app can suggest a course of action or warn about dangerous consequences, but it’s usually a mistake for the app to take over the decision-making. The best apps find the correct balance between enabling users and avoiding unwanted outcomes. An app can make people feel like they’re in control” [8]

*The only interactive part of the map is the size of my thumb. It doesn’t grow.*

There are any number of metrics one can use to determine how your app is greater than your contemporary and competition, from built-in system metrics to static analysis tools; but the customer should remain the sole judge of performance.

2. The Uniqueness of a Mobile Computer

The number of widgets and gizmos on a device also far-exceed those on a traditional desktop-sitting computer. Accelerometers, gyroscopes, a fixed-size screen, GPS, Bluetooth, biometric sensors, NFC; and perhaps more; all contribute to a powerful set of tools both available, and encouraging, for a developer to play and create unique applications with.

Such tools are familiar in the realms of embedded computing and Internet of Things (IoT), and much like these realms, mobile computing shares the same sets of problems. Promises and guarantees of a wired, secure desktop with ample resources are not granted here: any device can always be assumed to operate on a finite amount of battery, lose connections to external devices and networks, be constantly creating new wireless connections, and so forth.

But while an embedded computer can be optimized for the exact tasks it will perform, in a well-defined environment, no such promises can be made for a smartphone.

The user, themselves can be unpredictable. A user may spend a great majority of their time using an app, streaming video or data, saving images, music, and videos, closing apps, opening new apps, turning their device on-and-off, and so on. Depending on the nature of the app, the user may also be introducing a myriad of new variables as user input.

In the foreground, it is the developer’s job to be as robust as possible. Is the device out of space? Are you appropriately disabling different hardware devices when you are done using them? Did the user lose connection to the Internet? Was some data possibly lost? It is the developer’s responsibility to safeguard against any potential for error.

In the background, as well, there is still responsibilities. Does your app manage your Remote Notifications well enough, or does it constantly wake up the user’s phone screen, draining the battery? Are you reasonably using the user’s location while they are using text messages or a messenger app? When the user leaves your app, are you prepared for the situation that the OS terminates your application in the background? Do you properly persist your state such that a user could never know the app is closed the next time they reopen it?

*Another issue to consider: users can disable some functionalities, outside of the app.*

Clearly, there are many questions to ask, and plenty of work for developers to do for a plethora of fringe scenarios.

3. A Moving Landscape

On November 3, 2017, the first iPhone X was released. Featuring beveled edges and doing away with the fingerprint scanner in exchange for facial recognition system, it presented a new set of challenge in the landscape of iOS development.

This month, September 2019, the Samsung Galaxy Fold will enter consumer markets. With a foldable screen, there exists an entirely new dimension to develop, manage, and lead UI/UX changes on one of the largest mobile platforms.

There are constantly ever-new breaches in mobile development. And while there are niches of stability and continued backwards-support for enterprise and last year’s models, no company would ever dare represent themselves in the public image by not supporting the new toys being released every few years.

For an app that’s solidly established itself on a device, what does it mean when you’re suddenly thrust with a new set of requirements that never existed a decade ago? Even more, what does it mean for a developer when he or she is given a set of tools to make these changes months before their real-world counterparts enter the public market? What pressures exist for a company who stands proudly as ambassadors of new technology, and for their implementers that cross their fingers in silent prayers that nothing goes wrong?

This is the slippery slope of mobile development. Stability is ever-desired for your entire consumer base and yet the competitive market shifts itself, evolving your platform as it tries to out-do their competitors.

Of course, it doesn’t stop at hardware. Changes can occur at software, too, even for APIs that a development team has gotten comfortable with.

Consider iOS 11, which had done away with the shared cookie space for the in-app Safari browser.[9] For teams that had relied on features such as this, how do they sufficiently support both version sets, pre- and post-11, much less, test it? And more importantly, what will they do to adjust to these changes? What, then, becomes the new best-practices to follow?

The world moves fast, companies move faster, and occasionally even government parties also invokes changes. And with these innumerable changes, new challenges arise to meet the ever-growing, constantly evolving demands of the market as these entities interact with one another.