What are some mobile app upgrade best practices?

Sati Hillyer Looking to Hire a Ruby Engineer to join OneMob - 2015 Gartner Cool Vendor for CRM Sales

April 29th, 2015

We have a mobile app and we are noticing not all of the users are on the latest version. Our mobile is an enterprise app that customers will pay for, so we do not target consumers. I feel because it's an enterprise app that you've spent money on, it would be beneficial as the user to get forced to upgrade when there's a new version (typically every 4-6 weeks) because this ensures you have the latest features and enhancements.

Others in the team feel forced upgrading is a bad experience and will turn users against the app and make them stop using it.

We email users after a release, but that's not enough. We have a light weight in-app notifier when a new version is available, but they can dismiss and it doesn't return. We can use mixpanel to push an in-app notification, but again feels like a bandaid.

I'm fine when apps like Uber or LinkedIn force me to upgrade. And I feel a paying enterprise customer would be just as fine in this situation.

What do you think? Any best practices out there to ensure everyones on the latest and greatest?

Joanan Hernandez CEO & Founder at Mollejuo

April 30th, 2015

Hello Sati,

Having old version is an often problem in B2B environments, mainly because: if it works, don't fix it!

So, I would assume, those companies have someone handling the IT, thus that's the person that should be informed and suggested to upgrade. While customers are the ones with the money, as such, the one who decides, at the same time you should move on with your product. Just a curtesy e-mail saying that version is deprecated and continue the evolution. In case the customer comes with a requirement or problem, then the fix is for the newest version, not for that older one. Like everybody else experiences working with a computer. :-)

Cheers!

David Schwartz Multi-Platform (Desktop+Mobile) Rapid Prototyping + Dev, Tool Dev

April 29th, 2015

When you say, "We have a mobile app", what's your relationship to the users it's serving? It's not clear if you're just an outside contractor or a dev team within the company.

If you're within the company, I'd say dev team members are not the people to be making this decision. Who's the "customer" within the company for whom the app was built? THEY are the ones who should make this call. The fact that there's even confusion around this points to the likelihood that the "customer" is not being kept in the loop and isn't aware of this even being a problem.

App updates aren't a matter of "convenience" for users. If the customer is offering new services or features, they're paying for them to be delivered to users. If the supposed "convenience" of waiting a minute or two now and then for the app to update isn't being outweighed by the new features, somebody is wasting resources on needless crap.

Either way, it's not the role of developers to interject their opinions on the people who are paying them to add stuff to the app and then think it's "too inconvenient" to require the users to actually acquire the code they were just paid to create. If their "customer" didn't want their users to have the code, they wouldn't have paid the developers to build it. It's that simple.

John Anderson

April 29th, 2015

This is exactly one of the big issues with traditional App Development that we're trying to fix. Our App Development Platform (Ti-Browser.com) allows you to quickly build native Apps with XML. One of the big benefits is that users are always running on the current code without any updates at all. New code put into production is downloaded at run time automatically and transparently. Users don't have to go through an awkward update operation, the new code comes down automatically without any additional delay.

Question stats