Mobile App Development: 8 Best Practices
Creating great mobile enterprise apps isn't necessarily easy, but it can be easier if you follow these eight critical tips.
![](https://eu-images.contentstack.com/v3/assets/blt69509c9116440be8/blt7f6137c95fd50398/64cb39ae70a0fc261343cf38/Image_1.jpg?width=700&auto=webp&quality=80&disable=upscale)
If you're in enterprise IT in 2016, the odds are pretty good that you've already been tasked with building a mobile app, or that you'll get that type of project sometime in the next few months. We get it. Mobile apps are cool.
When you're asked to build an app for the first time, it's natural to start looking at all the things that are different between building an app and developing an enterprise application. You might look at frameworks, languages, APIs, and SDKs.
While you're doing all that, you might well miss the really important things -- the things that will make a difference between an app that your users find delightful and an app that finds itself in the trash folder.
Here's a little secret: In many ways, developing a mobile app is just like developing that big enterprise application. Oh, sure, the details are different, but when it comes to the foundation issues, you can take the secrets for a successful mobile app, apply them to an enterprise application, and still be in pretty good shape.
[See 10 Programming Languages That Will Keep You Employed.]
I've put together the following list by talking to developers, looking at stories of how successful apps were developed, and drawing on my own experience managing application development. I hope that you'll find most of these pointers obvious. If you do, it means that you've been paying attention as you developed applications in your own career.
If that's the case, then why present this list at all? I'm putting it together because it might allow you to talk about these points with your executive management, your colleagues, and your teammates. Frankly, if it helps start a useful conversation at the front end of a development project, it will have done a pretty good job.
With that said, I recognize that there are other tips that can make a huge difference when it comes to putting together a successful app. I'm curious about the tips that make up your list.
Are there tips on this list that you don't find useful? Are there additional tips you think should go on this list, even if putting them there means kicking one of the incumbents to the curb?
I'd love to know your list and the tips that have made the biggest difference when it comes to the teams you've managed -- and the apps that have been your biggest successes.
If the app you're building matters to the company in any way, then it's almost certain to involve sensitive information or information that is private to the user. In either case, you need to keep that information secure. You should start the process of thinking about security at the beginning of the development process, not the end.
Thinking about security from the start means knowing what kind of input you'll be dealing with so you can build data testing into the app. It means understanding the network components and communications mechanisms so you can secure the data in transit. Security means knowing what authentication mechanisms are in place and what ones are available for use, so you make sure only authorized users get involved with data. It means a lot more, too.
Ultimately, though, it means building security into the app rather than bolting it on at the end, and that's the critical difference. So make sure that the very first whiteboard at the start of the project has "security" on it -- your users and your organization will be grateful you did.
Apps don't live in a vacuum. Even if they're designed to the most flexible HTML5 standard, the platform on which they run will matter. So will the expectations of the people using the app. So will the way those people use the app. All of it matters, but too many developers act like they simply don't care.
The first thing to do is bring users into the process early -- before the first line of code is written. Talk with them about the app and really listen to their answers. Then, don't stop listening. Make sure that there are feedback mechanisms built into the app and that your team is paying attention to the information coming back via that mechanism and others.
You should pay attention to support logs. You should run regular analytics (more on that, later). You should make sure that someone from the user community remains part of the development team as long as the app is in the field. I guarantee it will change the way you view the work you've done.
No matter how agile you become, if you want to create reliable, successful code, you need to do some planning ahead. If nothing else, choose key pieces of the application framework and decide what they will be and how they'll be implemented. Then get flexible with what goes on between them.
You can (and should) build the user story into the planning, and you should allow for the flexibility required to deal with new conditions or unexpected results from testing. But all of that flexibility should come within a known framework. Plan ahead. You'll really be much happier if you do.
We like blinking lights and pretty pictures. I get it. And I understand that each week brings something new in the way of an interface to copy or an app that is the new definition of perfect. I'm here to tell you that none of that matters as much as the functionality that goes on at the core of your app. Get that right, and the pretty interface will follow.
By "core" I mean the essential business function of your app. Make sure that the app processing is rock solid, that the interface to the backend database is absolutely locked down, and that the results returned to the app are correct. Make sure all of that is working perfectly and then the time you spend working on the bells and whistles will be seen as a solid investment.
There are lots of arguments to be had about testing. Who should do it? When it should be done? What's the best methodology for doing it? What's not up for discussion is whether you should be doing massive, iterative testing to begin with. The answer, in case you were wondering, is "yes."
It is a shame that users have become accustomed to acting as beta testers for every new app. Break the pattern. Make sure your app is solid and reliable before releasing it to your users. Test functionality, test performance, test security, and test everything else you can think of. And don't stop testing just because the app has been released. Platforms, networks, and user patterns change. Keep testing.
Back when I said that you should know your users I mentioned the importance of listening. Well, it's so important that I'm giving "listen" its own spot on the list. Ask your users for feedback, give them a mechanism to make talking to you easy, and then really listen to what they have to say. It's not easy, but if you can get this one right you'll create much, much better apps.
It's easy to become defensive when people are telling us about shortcomings in our work. Don't do that. Stay open to what the users are telling you and listen hard for the meaning behind the words.
Users will use confusing terms and the "wrong" words to describe what's happening, but really hear them and you'll find cases you didn't test, assumptions you made in error, and odd stuff that shouldn't be happening but is. In all of those cases, if you really listen, your users will end up happier because you'll end up creating a much more successful app experience for them.
No one likes a slow app. Sure, we can all tell stories about how things were when we were getting started in IT, when we would leave our stack of punched cards to be read and come back a few hours later for the results. But no one wants to go back to that. Each and every user wants results right now -- maybe a little sooner.
There are a lot of things that can have an impact on app performance. You should constantly monitor the app, the networks, and the server to make sure there aren't problems. Set up alerts so you know about issues before they become problems that become angry phone calls to support.
Design performance in and make sure that performance stays within design parameters. Yes, I know that I've wandered squarely into DevOps territory, but if that's what it takes, then you should embrace the discipline and make sure that no user has to wait on an app to get his or her job done.
If we're talking about a mobile app, then it's a lead-pipe cinch that we're also talking about a network app. It's the rarest of enterprise apps that live on their own, so you need to decide early on what your app will do if it can't find the network.
The answer will, of course, depend on exactly what the app is supposed to do. It might be that the app will locally store enough data to allow it to function for a short time away from the network. It's possible that the app can go into store-and-forward mode until connectivity is restored.
It might be that you just need to come up with a really nice "waiting for the network" screen. In any case, you need to respond to network connectivity with the proper results.
You also need to take the network into account when it comes to performance and security. It can get complicated, especially when you're talking about large user populations and apps that can hop from 4G to WiFi networks without missing a beat. Regardless of the complication, you must be willing to make the effort to get it right. You do remember all the testing we talked about a few moments ago, right?
Building a successful mobile enterprise app isn't simple but it is do-able if you take the time to walk through the right process. These are some of my key steps in that process: Now that you've seen them, what do you think? As I said at the beginning, I'd love to know your top tips. I'll listen if you tell me that mine need improvement. I'll see you in the comments.
If we're talking about a mobile app, then it's a lead-pipe cinch that we're also talking about a network app. It's the rarest of enterprise apps that live on their own, so you need to decide early on what your app will do if it can't find the network.
The answer will, of course, depend on exactly what the app is supposed to do. It might be that the app will locally store enough data to allow it to function for a short time away from the network. It's possible that the app can go into store-and-forward mode until connectivity is restored.
It might be that you just need to come up with a really nice "waiting for the network" screen. In any case, you need to respond to network connectivity with the proper results.
You also need to take the network into account when it comes to performance and security. It can get complicated, especially when you're talking about large user populations and apps that can hop from 4G to WiFi networks without missing a beat. Regardless of the complication, you must be willing to make the effort to get it right. You do remember all the testing we talked about a few moments ago, right?
Building a successful mobile enterprise app isn't simple but it is do-able if you take the time to walk through the right process. These are some of my key steps in that process: Now that you've seen them, what do you think? As I said at the beginning, I'd love to know your top tips. I'll listen if you tell me that mine need improvement. I'll see you in the comments.
-
About the Author(s)
You May Also Like