5 app development tips to help you avoid disaster

Mobile app development: it’s easy and straightforward in the lab, but once your app is deployed to the wild, all bets are off. You need to deliver seamless, fast experiences for users on low-powered devices, in any number of network environments.

When it comes to building mobile apps, uncontrollable user behavior can lead you down the path to death by 1000 papercuts. But by recognizing and avoiding these 5 top pitfalls for mobile development, you’ll set yourself up for success from development, to deployment, to scaling to a massive number of users.

Not Thinking About Engagement After Download

Congrats, you’ve successfully launched your app with the features and functionality that got the user to download your app in the first place. Now you have to get those users to continue using your app for the long haul.

The average mobile app retention rate (the proportion of users who return to the app within 3 months of their first session), is just 20%. That’s a stunning number: fully 80% of users never use an application after they try it out for the first time. The reality is that users have a seemingly endless range of app choices, and with such heavy competition, any issue in performance quickly leads to user churn.

To maintain app engagement, real-time alerts and notifications are relatively easy to implement and extremely powerful for maintaining a direct connection with the user. Push notifications, desktop alerts, SMS, email - you have a plethora of ways to deliver timely information to users even when their app isn’t open. Your users have their phone with them all day, every day, so you just have to worry about sending engaging messages that retain their interest.

Not Thinking About Global Audiences Early On

You built your mobile app for today, but did you build it for tomorrow? This is really where the adage “it works in the lab, but not in the wild” comes into play. Whether your overall user count has exponentially grown and you’re suddenly supporting thousands (or hopefully millions) of concurrent users, or your app has stayed small but is used globally, scalability must be top of mind. There are two big factors at play here:

• You need to ensure speed and reliability for as many concurrent users as are attracted to the app
• You need to ensure speed and reliability for users no matter where on Earth they’re located.

To deliver this scalability, you need global coverage and global redundancy. Global coverage means having multiple points of presence that automatically connect users to the closest data center, so that, for instance, users in Tokyo experience the same low latency connectivity as users in New York. And global redundancy means ensuring there is robust failover and data catchup built into your infrastructure: these ensure that users always have the latest, most relevant updates, and if one point of presence falters, that they’re instantly connected to the next closest.

Going Monolithic Rather Than Decoupled

Monolithic architecture is self-contained - where all components of the app are interconnected and interdependent. In other words, this approach, which was the foundation of the technology revolution, is tightly-coupled. On the other end of the spectrum, apps that are modular are loosely-coupled or decoupled, meaning that the app is comprised of independent microservices, as well as other programs that operate independently. A decoupled architecture protects against failure when changes are made because there’s less of a risk of other microservices failing; and when something goes wrong, it’s easier to isolate the issue.

When it comes to mobile apps, in particular, using a decoupled architecture allows you to build more scalable and extensible applications, faster. From a reliability standpoint, microservices are isolated, so the failure of a single service shouldn’t impact the other services. Fault isolation ensures that your mobile app itself is resilient to unforeseen circumstances. If, say, your push notifications service has an outage, the rest of your application will continue to operate normally, and, because microservices themselves are individual components, you could easily fall back to a different push notification service until your primary one is back to being operational.

Microservices are also highly receptive to playing nicely with third-party services. In building mobile apps, you often don’t have time (or, in some cases, the expertise) to build every feature and function from scratch, and will instead choose to integrate best-in-class services that are more reliable and trustworthy. Microservices empower you to quickly and confidently deploy challenging features like artificial intelligence or bolster security with developer tools to build feature-rich, secure apps.

Making Security an Afterthought

If it’s connected to the Internet, someone is going to try and hack it. It’s not a matter of if, it’s a matter of when. So when it comes to mobile apps, security cannot be an afterthought, whether you’re protecting your user’s data, the data they’re sending and receiving in transit, or your app itself.

Let’s look at data in transit as an example. Think of data in transit’ as ‘any message flowing over a real-time data stream’. This could be a chat message, an IoT reading, a financial stock price, or a push notification. There are core security requirements for data in transit that truly are table stakes.

AES/SSL/TLS encryption on every message must be included in any mobile app, big or small. And it must be end-to-end, meaning the message is encrypted before it is sent and decrypted once received: it is never unpacked and repacked while in transit. Beyond encryption, fine-grained access control is another must: you need to be able to grant and revoke read/write permissions down to the individual user. With full control over who can read - and who can write - data in your mobile app, you greatly improve your ability to prevent unauthorized access to the application.

Not Making Battery and Bandwidth Consumption a Priority

It doesn’t matter how great your app is - if it’s rapidly draining a user’s battery or eating up their bandwidth, they’ll look for alternatives.

When it comes to bandwidth management in building mobile apps, it's important to recognize that mobile users won’t always be connected to a reliable WiFi connection or even 4G. Nonetheless, users will often still need to use the app in unreliable or varying network environments - like moving in a car, going through a tunnel, or anywhere else with spotty coverage. If your application is built to perform only on the strongest internet connections, the app will start to underperform when put to the test, driving away your users.  

For battery consumption, it’s imperative to look at where and how energy is being used. Some common battery drainers include unnecessary background activity, inefficient refreshing, and location-heavy apps. When choosing any infrastructure or platform to power your mobile app, keep battery consumption in mind and see what features your service provider has to reduce it. Does the platform utilize efficient data transfer protocols? Does it include things like message caching? Does it allow you to use a microservices-oriented architecture? How that platform provider architects their product determines how well your product will perform.

Building mobile apps isn’t easy, but making the right infrastructure and design pattern decisions sets you up for success - from development to deployment to scaling to be the next big thing.