You're a mobile app developer and you pride yourself in making great apps that stand out above the rest. You've added all of the features that you think your users want. You've ran your unit test, not once, but many times - they all succeeded. You just finished paying a designer to create great app icons and other image assets. You've invested all this work, yet there is a problem that you notice after your app hits the app store - you are seeing a very high dropoff rate after a couple of days. Your users are either not using your app anymore or have ,GASP, deleted it.
WHAT? HOW CAN THIS BE?
You begin by checking to see if your app is crashing or if there is some bug - nothing. You review log after log to see what exactly is happening and you still can't find it. The only thing you can do now is wait for the app store reviews to come in or maybe a user will email you. You're beginning to get nervous. Let me help you from an end-users perspective of why I just deleted the mobile app you worked so hard on!
You first start out with the idea that if you allow users to use existing social media accounts to sign into your app, that they will love it. It's less work for you as a developer and you don't have to maintain the backend server. Your users will love this as they don't have to create a new account and remember yet another password.
What happens when a user doesn't have a Facebook, Twitter or some other social media account? Don't laugh - I don't have a Facebook account and I'm proud of it. Yet, it locks me out of certain apps like this one. Your only available choice is to log in with Facebook.
The second problem is that even if they provide a way to login with a Social Media account that I use, I don't want them to have full access to it.
How do I know your app won't tweet something that I don't want to share or collect info about me or those that I follow or my followers?
Give your users the option to create an account on your service as well as give them the additional ability to use social media accounts. Futhermore, limit what your app has access to. Don't request access to the user's timeline or to post tweets for them unless it is critical to your app. Also since this is the first time they may have seen your app, give them the option to create an account on the phone as well as an option to email their password to them in case they forget.
Imgur has implemented a very nice login screen that has a nice design and options that will make both sides happy.
You've been developing mobile apps since the Blackberry days and you think you know a good experience from a bad one. You are even willing to bet on trying something different from other apps to stand out.
Who needs an indicator that says if you swipe right another menu will appear? Or better yet, let's change the meaning of common UI elements that we've grown accustom to? Like the hamburger icon or the back button for example. You could also just toss the Human Interface Guidelines and create something of your own.
What happens when a user is looking for basic functionality and has to tap all over the screen in order to find it? I've experienced this several times and I've always felt the developer was trying to save screen space, but at the expense of the end-user.
What about completely ignoring the human interface guidelines and making your app have a look and feel that you want? Here we see an app that is not only cluttered with lots of options on the main screen, but does not have the look and feel of iOS 7 and up (which is installed on 98% of active iOS devices). Everything is custom, from the buttons, text to even the back button.
What you probably don't know from the screenshots is that each block is actually a button and when you click it, it uses a custom animation that could probably be found from the first version of PowerPoint. Also in the second screenshot, the back button is at the bottom of the screen.
Users expect a modern look and feel regardless of the platform that you are using. The hamburger icon is adopted all throughout the major phone platforms to provide additional options for an app. There are no specific guidelines for which side the options should appear, but there is an idea of what the user can expect to see.
In this app by Telerik, we break it down into two sections. General Info and UI Controls. This allows the user to quickly find the part they are interested in.
Make sure your app behaves in expected ways. For instance, a user would expect a user profile icon to bring them to account settings. Here I click on my picture and was brought to "My Profile".
If your app has to have hidden gestures, why not offer a tutorial at the beginning of the app instead of letting users just figure it out. This app shows a lot on the screen, but only the critical pieces to get started. More importantly, you can go back to this "tutorial" page at any time if you are stuck.
After spending the better part of a year writing your app, you're ready to cash in. All of those nights, weekends, borrowing code from StackOverflow are about to pay off. You decide that you are going to put your app in the app store for free, but quickly ask for money. After all, it is a great app that people want and your research from other apps in the market shows that it should perform well and people are willing to pay.
While there are many apps in the app store that contain similar functionality, I'm going to try the free one first. Which is good news for you, as yours is free. But when I'm hit with this screen without checking out basic functionality, chances are I'll delete it.
I'm willing to bet that your app contains somewhere around 60% of the functionality that I was expecting and if I pay you, then I'll get the remaining 40%. However, I'm willing to download and use another free app to get the rest of the functionality that your app contains.
Take advantage of In-App Purchasing, but use it only when the right opportunity arises.
A great example of this can be found with an app called, "Working Copy". It is basically an app that allows you to push to a GitHub repo from your iPhone. The developer has two versions currently available:
When a user is searching for an app that promises to push to GitHub, they will try the free one first, as you can tell by the reviews in this example. But the developer has gracefully implemented IAP - as soon as your ready to push to your repo then you will be prompted to pay to unlock this functionality. He took it one step extra and will allow you to unlock the "push" functionality for 21 days for a fifth of the price. In the end, I ended up paying for this app.
Again, you've built an app, but you're completely paranoid that the user running your app is on a different version of the OS then what you built it for. Whether it is a minor or major update, you've decided to add code that will prompt the user that they are on a unsupported OS and close the app.
I know what you're thinking: Don't most app stores provide version checks before they let you download the app? The answer is yes, but it tends to lean on the minimum version set by the developer. If they install a minor update or even a major update, the developer can deactivate the app.
While there are a few edge cases of why you might not want your end-user to run your app on a newer version of the OS, I'd say they are few and far between. The newer version of the OS should be backwards compatible with apps written in previous versions.
In this example, this app simply popped up a dialog box after a minor update and terminated itself (which is forbidden by Apple's policy by the way).
Quit writing code that checks for the OS version and start writing code that checks for the presence of APIs or symbols that you need. This code will be different depending on which mobile platform that you are developing for, but StackOverflow is always just a click away.
I wrote this blog post after looking through my purchased app history on my iPhone and comparing it to apps that were still there. It brought back a lot of memories and that is how this post was born. The good news is that many mobile app developers have made these mistakes and corrected them in future versions. I hope that this post helps with your next app!
Feel free to share some of your reasons for deleting an app in the comments below.
Header image courtesy of William Brawley
Michael Crump is a Microsoft MVP, Pluralsight and MSDN author as well as an international speaker. He works at Telerik with a focus on everything mobile. You can follow him on Twitter at @mbcrump or keep up with his various blogs by visiting his Telerik Blog or his Personal Blog.
Subscribe to be the first to get our expert-written articles and tutorials for developers!
All fields are required