Mobile applications can be essential for enterprise productivity. Employees are used to having everything at their fingertips. Why should their employer provide less efficient tools?
Ultimately, creating quality tools for your team will allow everyone to do their job better and make more money. When building enterprise apps for iOS, there are a few guidelines you should follow.
Get an Enterprise Developer Account
When deploying for iOS, it’s crucial to have an enterprise developer account. This allows your apps to be securely provisioned and deployed in-house.
Note: If you’re developing for Android, too, Google has a managed version of Google Play you can use for a enterprise. This presents some really cool opportunities for enterprises and developers.
When creating an account, make sure your IT team is using a shared password system and documenting appropriate usernames and who has access. I can’t tell you how many times I’ve seen somebody at the company create an account with their individual credentials. Two years later, they’ve left the company or been hit by a bus. It’s a pain to get back in to that account. Don’t make that mistake!
Make Your App Secure
Be smart. Just because the app isn’t going to be used by millions of consumers doesn’t mean you should be lazy.
Posting username and password over an unencrypted connection? We’ve seen it.
Storing sensitive credentials and session information in UserDefaults? Bad idea.
Follow security best practices, and don’t be lax because it’s an internal tool. Be smart and do what a good development team should do.
To enhance security and keep track of who can access your applications, use a mobile device management (MDM) platform.
MDM solutions allow IT teams to control cloud and mobile experiences on user’s devices. It’s a quick, effective way to get your team the tools they need.
At Broadway Lab, we’ve used Mobile Iron and have had plenty of success. It’s easy to integrate and gets the job done.
Build quality software. Just because it’s an internal tool, doesn’t mean you should hack it together. The goal should be for the tool to work well and for the appropriate teams to use it. Ideally, this will streamline their work or allow them to perform additional functions. Ultimately, saving costs or driving revenue.
The value the application provides should be enough that it makes sense to invest in a quality product. Even if it’s simple. If the value isn’t there, strongly consider scrapping the project.
Poorly developed apps are more likely to be a drain on your team than be an asset. Not building an app at all is better than building an app people don’t use.
Is the application getting the use you expected?
Ask the IT team: “How many employees use this tool on a monthly basis?” You might hear crickets.
Knowing the use case for the product and where employees are/aren’t using it is imperative for making product decisions.
If people aren’t using it, and they should be, ask yourself, “why?”
If the answer is to kill the product, then kill it. Maintaining software that people don’t use is expensive and unnecessary.