Practical Mobile Tactics 

Should your company simply leverage responsive web technologies or invest in a native mobile app? A lead mobile engineer takes you into the mobile development trenches to help you decide what would work best for your company.

Strategic_Mobile_Hero.jpg

If you’ve ever used Uber, or played Pokémon Go, you already know that mobile is taking over the world. Businesses and consumers alike are more reliant on their mobile devices than ever.  That said, the blogosphere has started to deride mobile apps, stating that the golden age of mobile is over. Furthermore, many front-end web frameworks are making it easier to make sure that your website is responsive to various screen sizes.  If you haven’t done so already, your organization is probably looking for a solution to “mobile”.  The Forrester report, “Putting a Price on Mobile Strategy” outlines a number of high-level strategies AD&D professionals can use to ensure successful mobile campaigns, but what does this information mean at a tactical level?  How does one choose between simply leveraging responsive web technologies and calling it a day, or deciding to invest in a native mobile app?  In this article, I’m going to share some mobile application tips from the trenches.

What is Mobile?

A “mobile solution” generally refers to either a web application that you interact with through your device’s web browser, or a mobile app that you download and install from your device’s marketplace. Assuming we’re focusing on the iOS and Android platforms, that means the App Store or the Play Store. 

These definitions may seem obvious to the technically-inclined, but I have seen users and enterprise personnel get confused.  This brings me to my first tip: Regardless of which mobile strategy you take, ensure that core concepts are solidly understood amongst the various stakeholders.  If your organization has both a mobile web site and a native mobile app, ensure that your staff understands the differences and capabilities of each channel. 

Why a Mobile App?

Some say that native mobile apps are over.  They will point to decreasing download numbers from the App and Play stores as proof that nobody uses mobile apps anymore.  I believe that these arguments miss the big picture completely.  While it is certainly true that most of us are no longer installing every app we come across, the truth is mobile app usage is going strong.  Moreover, we are starting to see the most successful and disruptive companies tie their web and mobile experiences together into a larger, more complete ecosystem.  In the modern era, the majority of quality websites are responsive; these websites don’t necessary supplant a mobile app when the need arises.  When we zoom out and look at these phenomena, I think a saner argument can be made: 

Mobile apps are not dead.  They just have to be good. 

While it is true that not every organization needs their own native mobile app, utilizing Forrester’s POST methodology to analyze the People who will be using the app, the Objectives of the application, the short and long term Strategies of the app, and the Technologies that will realize your goals can help you determine if a mobile app is right for you.  At the end of the day, you should invest in a native mobile app if you need to deliver a rich experience and enhanced capabilities to a well-defined audience of users.  A native mobile app can empower your users with:

  • complex data storage
  • robustness to connectivity loss
  • a platform-native look and feel
  • the ability to make use of camera, GPS, bluetooth, sensors (e.g. accelerometer, proximity, NFC), push notifications 

If you need to provide any of the above capabilities, a native mobile app is still the best way to achieve it.  Rich mobile applications are better suited to workflows that need to “just work” in the field, even without optimal network conditions.  When done properly, these experiences can seem nearly magical. Nothing can beat the level of engagement a great mobile app can bring to your users.  Just look to your own experiences for proof.

Considerations for Your App

If you’ve made it this far, and you think a native mobile strategy may be in your future, the following are some tips that I’ve picked up during my experience in working with mobile apps and the communities of users that develop around them.

Know your domain; know your audience.

Don't develop your website and mobile app in separate vacuums. While you do not need the UI details of the web and mobile experiences to be identical, the business concepts and entities expressed in both do need to be identical to avoid confusing users, and to keep functionality defect-free across channels.  

Your mobile app should be a first class citizen. Make sure your marketing team knows about the app and thinks about it during their campaigns. Ensure branding changes can include proper assets for the mobile app, and ensure they are delivered on time to support the App Store review process.

Our devices lose connectivity more often than we'd like to admit.  You can add value with your mobile app and set it apart from your website by including some offline capability.  Users will be delighted when core functionality "just works" even when connectivity is lost.  However it's important to understand that doing this adds complexity.  Offline/syncing concepts should be introduced as early as possible so solutions can be engineered.  Avoid creating an online/offline dichotomy where the app is expected to behave differently based on connectivity. Instead aim for a seamless experience where the app can perform actions offline and will communicate with the server in the background. Doing this well requires thought about the business domain.

Understand that a great mobile app experience may rely on asynchronous communication between the app and server.  Be conscious of what kinds of updates or content delivery are required to take effect instantaneously for all users.  Ensuring that certain kinds of changes happen in real time can get expensive from an engineering perspective.  This is especially true if you also want robust offline functionality.

Unlike the web, where 100% of all activity will correspond with a web request, some mobile app activity will be performed local to the device.  It's important to use something like Google Analytics to gain some visibility into what users are doing.  More importantly, if your web site and mobile app represent a single contiguous system, you need to design appropriate analytics metrics that will accurately describe the performance of your app.  For example, if users frequently begin transactions on the web and finish them on the app or vice-versa, simply measuring conversions on web vs mobile will dilute the synergy between experiences and create a false dichotomy for how your system is performing.

A mobile app is a program running on your device and it can crash, especially when your users have a wide array of devices.  You should use something like Fabric.io to capture crash reports.  Part of your quality of service routine should be to track these reports and aggressively attack any issues causing crashes in the field. Nothing will frustrate users more than a crashing app.  Shoot for 100% crash-free users.  Realistically, do everything you can to stay above 98%.

Because a mobile app should be used to deliver a specific experience to a target demographic of users, apps can often benefit from a strong user community.  At the very least, read and respond to reviews on the App Store, or integrate your app with something like UserVoice to build rapport with your users. With UserVoice you can accept feature suggestions, establish polls or voting on what your users want you to prioritize, and/or connect them with Tech Support.  Additionally, services like Urban Airship make it easy to engage users with push notifications and an easy-to-implement Message Center.

User Interface: Go Native

You should not force UI elements to be exactly the same across each mobile platform.  Breaking platform-specific idioms can increase development costs and cause maintainability issues.  Your users will be accustomed to the UX of their chosen device, so it's better to follow the design guides for each platform as best you can (iOS / Android).  Rather than micromanaging every single UI element, it is more important to ensure the business concepts are consistent across each channel, so that information can flow throughout your ecosystem effectively.

Layout dimensions should not be hard-coded or otherwise fixed.  This was common in earlier years, but today, platforms have facilities to support a wide range of screen sizes; use them.

Don't perform any kind of blocking operation on the UI thread.  Use operation queues or ansyc tasks to keep the UI responding to events, even if the user has to wait for a database or network result.  If you need to lock UI elements until a result is computed, you need to explicitly manage that and design an experience for it.  Android apps will throw an App Not Responding (ANR) dialog if you block for more than a couple of seconds.  If this occurs it will damage your reputation for quality.

Architect for Agility

Most tutorials and classes about app development focus on simple apps for brevity.  Often this means app developers will put all of the business logic into the ViewControllers or Activities.  If your application has any considerable business logic, you should create objects and layers to encapsulate that logic away from any platform dependencies.  This makes your application much easier to unit test and change.  It also makes it easier to perform a visual redesign without affecting functionality.  I recommend using a VIPER architecture or Model-View-Presenter pattern.

Persistence: Data is Love. Data is Life.

Considerable offline functionality in a mobile app will require a persistence layer within the app. Generally this is Core Data on iOS and SQLite + Content Providers on Android.  These data stores are similar to, but not exactly like RDBMS's.  It's important to completely understand how these components of mobile platforms work and what their limitations are.  For example, Core Data has historically had some design considerations that need to be followed in order to avoid concurrency issues.  On Android, access to SQLite can cause blocking, so devising a way to load data from the internal DB in the background is important to prevent performance issues and ANR dialogs.  

Mobile devices are getting more and more powerful and can persist a sometimes surprising amount of data, but this should not be taken for granted.  Provide a way to limit the amount of data that will be synced and stored on the device.  For example, limit order history to some practical subset of what is available on the web.

Build some way to avoid repeatedly re-writing the same data to the database.  For example, don't retrieve the totality of the product catalog over and over and write it into the DB.  You can create hashcodes to describe entities or entire data sets.  The mobile app can send and receive these hash codes via web services to check if it needs to refresh data.

Encrypt sensitive data such as credit card numbers or social security numbers.  Generate a key pair and bundle the public key with the app.  Store masked versions of this data to display.  Of course, do not do any kind of decryption for the purposes of display.

Storing data on a mobile app means that you do not have direct control over that app's state.  Make sure to design database migration routines to handle any schema changes during app updates.  If a user loses all of their data, in the best case they will have to re-download everything, which is costly to their data plan.  In the worst case, the data may be unsynced, and it will be lost.

Networking and Web Services: REST on quality APIs

Obey REST architectural guidelines: Use the different HTTP Request methods, use meaningful HTTP status codes, and set headers appropriately.  The networking libraries inside of mobile apps can make use of best HTTP practices for the purposes of optimization.  Not adhering to proper HTTP practices can cause them to fail.

Develop your mobile app so that it can ignore extra fields in REST payloads for which it does not have a mapping.  This allows you to add new fields to your services (for new versions of your app) without creating breaking changes which require a new version URL.  Nevertheless, build your client and server integrations to support versioning in some way.  For example you can send a version query parameter in your request from the app and use a Factory class on the server to provide a new implementation of the service.  Alternatively, you can put a custom header in all requests specifying your app's version, and you can use the app release version to switch on the web service version you need.  This is especially important if you release your APIs and mobile app on different schedules.

Adhere to separation of concerns when designing your web services.  This makes it easier to write syncing code which is less error prone, and allows you to add additional entities and relations in your app without creating breaking changes for previous app versions.

Respect the Data Plan.

Always provide a way to paginate results from your web service.  This is important of course for large product catalogs or content repositories, but also for user data.  You may be surprised to find that your mobile app crashes because it runs out of memory while swallowing a payload of 10,000 contacts!

Avoid creating a web service that does too much work at once.  Regardless of whether your app communicates synchronously or asynchronously, you don't want very long response times from the server, as it can impact scalability.  Remember that the cellular connection speed can increase transport latency beyond what you'd expect for a desktop browser.

Use tools like Charles Proxy or mitmproxy, or built-in platform tools to simulate slow connection speeds during testing.

Find the best bite size for your meal.  You must strike an appropriate balance between creating too many individual network requests and creating fewer network requests which are too large or long-running.  One approach to this problem is to make your services as small and as modular as possible. Then you can create a meta service to batch several of these small requests as your design considerations deem necessary.

Deployment: Where Rubber Meets the Road

Your responsive website will most likely be deployed along with the rest of your website, and you probably have direct control over that deployment schedule, because you probably have direct control over the servers on which it runs, whether they are on-prem or in the cloud.  A native mobile app will need to be deployed through the App and/or Play Store(s), and in the case of Apple, a manual review process is required before you can get clearance to release.  These differences can seriously affect release train scheduling during crunch time, and it is important to plan accordingly. 

You have to plan your releases, especially if you plan to deploy web functionality, APIs, or content that must coincide perfectly with your app release.  You must have your mobile app and web-services production-ready ahead of time so they can be approved and ready for deployment in time for your web release.

Your app can be rejected.  The Apple/Google platforms check for various things like API compliance, copyright infringement and keyword spamming in your store description.  You may have to make unforeseen changes and re-submit your application.

You can do internal or enterprise deployments with Mobile Device Managers or beta-testing services like Fabric.io and Hockeyapp.  This gives you much more control over when and how you release, but there is some overhead in provisioning all of the devices.

Unlike a web site, you cannot guarantee that 100% of all users will have your app update the instant that it is released.  You need to avoid making breaking API changes between versions, or otherwise intelligently version your services so that old versions will continue to work.  Some users will never update their app at all.  You can build-in your own mechanisms to force required updates by locking the present version with a dialog and a link to the app store.  Forced updates can make lifecycle coordination much easier, but users will be frustrated by frequent forced updates.  My recommendation is to create this functionality early on, but to use it as sparingly as you can.  As mentioned, it is better to design backward-compatible backend changes as much as possible.

It’s Worth It.

Native mobile apps can introduce some complexity to your technology organization, but a good mobile app can provide one of the most engaging digital experiences, and could become a staple of your customers’ lives.  By thoroughly applying the aforementioned tactics, you can ensure that your mobile strategy will Grow Smart over time.

GET IN TOUCH

Send us a note. Drop by. Or give us a call. We would love to hear from you.

Say hello.
Send us a note.
We park here, but work globally.
11480 Commerce Park Drive, Fifth Floor, Reston, VA 20191
  • Chicago
  • DC
  • NYC
  • Raleigh
  • Rochester
Ring. Ring.
1.844.256.0329