Kicking off the first installment of App47’s Summer Lecture Series, we want to examine the critical importance of managing app versions and updates. We’re in the midst of working on a platform feature improvement that further streamlines app management, so the topic is top of mind lately.

One thing we’ve learned to emphasize with almost evangelical enthusiasm is the need for people to have the latest versions of their mobile apps. And that enthusiasm is tempered with an understanding of how the enterprise works differently than the consumer space.

With respect to consumer apps, updates are all but optional. We all know a friend (or perhaps are that friend) who perpetually has the small red circle with a double-digit number on the upper right corner of their App Store icon. How important, really, is having the latest version of Cupcake Maker or Fish With Attitude? Sure, the update is probably worth doing, but we’ll get to it when we get to it.

Enterprise app performance, however, suffers from the cavalier consumer attitude. Consider that every mobile app talks to a backend system. It’s a burden to maintain that support matrix on the enterprise side; if your employees are not upgrading, you’re forced to support older APIs — a big resource drain.

Another big concern met by updates is security. Smart app management means remaining tuned in to emerging vulnerabilities (e.g. exposed data, authentication, permission checks, etc.) Find a flaw and you need it patched ASAP. Employees who heel-drag on updates are actually increasing the risk of compromised security throughout an organization.

So, with security and efficiency in mind, how do you enforce app updates without adopting some kind of off-putting sledgehammer mentality? For us, it’s the velvet hammer — a gentle, but ultimately forceful policy that keeps everyone up to date.

Part of our solution offers a few reminders/invitations to upgrade, followed by an auto-upgrade that launches with the app starts. In effect, a user gets three to five alerts or opportunities to upgrade themselves. If no action is taken after that threshold, the next launch of the app simply prevents the app from running until the user upgrades. The app itself is effectively saying, “hey, I told you you needed to do this a couple times. Now you need to upgrade to continue using the App.”

That strikes a balance between overbearing enforcement (which might create frustration and a sense of user mistrust) and detachment (which means the apps don’t get upgraded, inviting any number of deeper inconveniences).

With that kind of policy in place, you know you’re always equipping staff with the best-performing version, you’re always testing against the most current version, and you’re always ensuring that optimal security and cost-management factors are in place.