Four Problems Your App’s Architecture Should Solve

Written by: on June 27, 2017

This year marks the 10th anniversary of the iPhone’s launch, but next year marks an even more important 10th anniversary—the launch of the App Store. With the App Store came the app economy and the steady evolution of the app ecosystem. In the last decade we’ve seen every kind of app imaginable, and more. The iOS App Store and Google Play Store each contain over 2 million apps. With that volume and time, one would think no stone could be unturned, technically speaking. Every problem has been encountered, and every reliable solution has been found. The golden architecture exists. So what is it? Well, it depends.

From a technology perspective, an app is the sum of the problems it has to solve. Just as no two apps have the same problem set to solve for, no two problems necessarily have the exact same solution. Developers need to solve the problem at hand, not shoehorn solutions into problems that don’t quite fit. That said, a software problem is more than the technological challenge. Time-to-market, cost, flexibility, and roadmap all have to be factored in when solving problems, and all of them have an effect on an app’s overall architecture. While that’s true, there are some common problem spaces that have to be considered when starting to think through the execution of a mobile product, and best practices to go with them.

The Truth

Apps are made of data. In modern apps, that data can come from several places, typically the user or the cloud. It’s important to decide at the beginning of the product development process where “The Truth” comes from, and how it will be handled. At a minimum, a good architecture will answer these questions:

  • If the user gives your app their data, does that data stay on their device, or go to a server in the cloud?
  • If it goes to the cloud, how will the app handle conflicts?
  • When does data in the cloud become invalid?
  • How frequently should the app check for the latest data?

No two products will have the same answers to these questions, but every product needs to have well-considered answers due to the intimacy and immediacy of the mobile user experience.

The Waiting Game

A key ingredient of the mobile user context is being on-the-go. It may not be the way we intend our apps to be used, but users frequently need to get in, get what they need, and get out. The worst user experience in that scenario is an app that causes them to wait unnecessarily. Naturally, it should be the goal to make every aspect of your app as fast as possible, but there are a few key touchpoints that should be optimized using the whole system architecture to support:

  • The Launch Sequence. Every app has a set of tasks that need to be completed before the user can access its features. Typical examples include downloading app configuration files, fetching assets, and synchronizing user data. Determining the bare minimum that is necessary to get the app off the ground and then optimizing the hell out of this process is critical to making the app launch snappy.
  • Networking and Processing. As data is shuffled to and from the server, the user is sometimes forced to just wait. A good app-supporting server architecture should have flexibility to ensure response times are low, payloads are small, and data is available on-demand. A content management system that was built to support a website is not going to be sufficient for mobile out of the box—it’s going to need some work.
  • Monitor and Measure. Each app will have a unique set of bottlenecks. By outfitting the app with networking and process analytics, a developer can identify those bottlenecks in production and then formulate a plan for refactoring the architecture to eliminate inefficiencies.

The Failure Case

One of the most common anti-patterns in software development is ignoring error cases. Things are going to fail, and users are going to find themselves in error states—there’s no way around it. Ensuring that failure is planned for and accounted for in your architecture is critical to the user’s success. Server redundancy, failover plans, data backups, and app resilience should all be considered and planned for from the start of product development.

The Future is Now

Flexibility is one of the most difficult things to plan for, but also the most important for a new product to take into account. Technology changes and evolves steadily, as do product and user needs (and it’s unlikely all of these will magically align). Building an architecture that supports easily replacing and upgrading components is a challenge worth spending time and energy on. This means building loose couplings and respecting modern design patterns for separating concerns in the app implementation. Server-side, this means designing around microservices with elasticity in mind. The smaller and more self-contained your modules are, the easier they will be to maintain or replace as the need arises.

Whether your app is an App Store veteran or just an itch you haven’t started to scratch yet, taking the time to plan for and build the right architecture will help your mobile product and your users succeed. Having a product architecture that keeps data, time, failure, and the future in the forefront will prepare your app for the next 10 years of the mobile ecosystem.

Bradford Dillon

Bradford Dillon

Bradford Dillon is a Senior Technical Architect at POSSIBLE Mobile. He’s been building apps for iOS and other touchscreen interfaces for the last ten years, and enjoys writing code that makes writing code more enjoyable. In his spare time he builds skills that are primarily suited to entertaining his kids.

Add your voice to the discussion: