While you generally want to encourage as many app submissions as possible, it’s essential that you hold developer’s submissions to rigorous standards for performance, appearance, security, and more. A big part of doing so is rejecting apps and submissions which aren’t yet good enough. This can be a tricky task for many app marketplace teams, since they don’t want to damage valuable relationships with app partners.
In this guide, we want to walk you through the process of expertly handling and rejecting apps from start to finish on your app marketplace. First, we’ll talk about how you should actually reject apps in the smoothest, most understanding way, and then we’ll look at various strategies to reduce the number of rejections you have to send in the first place.
Best Practices for Rejecting Apps
So, an app submission has rolled in, and for whatever reason, you’re unable to accept it. One way or another, you’re going to have to say no to the submission. This is never fun, but you can make it a lot easier by following a few guidelines which ensure your app developers have the best possible rejection experience:
Reviewing app submissions quickly should be a priority for a few reasons. First, in the words of Sid Maestre, Head of Developer Evangelism at Xero, “our app partners have deadlines to meet and we’re there to support them.” That’s right: you can’t forget that many developers are actually part of a greater team — often working against internal deadlines. Aside from helping with deadlines, providing speedy decisions prevents unnecessary doubt and frustration on behalf of the developer — which can quickly mount up if their app has to be submitted multiple times. Aim to review apps within 48 business hours; if the stakes or requirements are higher (say with financial apps), it’s understandable if you need longer — but at least let your developers know.
This next tip is a given: be polite. There’s really no reason to get upset or angry with developers if they fail to meet app requirements — after all, they’re only human. Bear in mind that developers potentially have dozens of marketplaces to create for, so you should be particularly grateful they chose yours! To ensure politeness, it’s good to have a dedicated approvals team which can interact closely with developers, so as to cultivate empathy.
There’s nothing more frustrating than being rejected — from anything — and not knowing why. As such, make sure your app rejection message is highly-specific: clearly outline the exact reason or reasons for the negative decision. Your justification for app rejection should always be reflected in the marketplace’s approval criteria, so refer back to those criteria in the rejection letter.
Aside from telling developers why their app was rejected, a good rejection should explain exactly what developers can do to “fix” their app. In some cases, these are one and the same — but not always! For example, if an app is rejected for using your APIs too wastefully, suggest an alternative implementation which might correct the issue. Developers are sure to appreciate the advice, because ultimately, they too want to fix the app!
Looking around at how the world’s biggest developer programs handle app rejections, we found a great example over at Twitter. Check out this retrospective rejection letter they sent to a developer when their rules changed:
Your Twitter account (or accounts associated with you) currently has multiple registered applications, in potential violation of Twitter’s rules on the use of multiple API keys for a single use case. You can learn more about those rules here.
If these applications serve distinct use cases under our policies, please reply to this email with a specific use case for each registered application.
If these applications do not serve distinct use cases, please log into your existing account on https://developer.twitter.com/apps and delete any applications which are in violation of our rules.
Although the developer who received that message actually complained about one pretty big oversight on behalf of Twitter — a failure to specify which applications were in violation of their rules — it does, for the most part, follow our criteria. It’s polite, or at least, not impolite… it’s (mostly!) specific, linking off to the new rules, and it’s constructive, providing concrete next steps for the developer.
Minimizing App Rejections
The best approach to handling app rejections is making sure they don’t happen in the first place. Developers take the approval process seriously — often checking their app meets the approval criteria multiple times before they submit — so if you’re having to write lots of app rejections, you may need to invest more into proactively supporting developers. Thankfully, we have a few suggestions for that too!
Provide Clear Approval Criteria
The number one preventative for app rejections is a clear, precise set of approval criteria. Good approval criteria have a few things in common:
- They are easily accessible to developers. Developers are more likely to reference approval criteria if they are easy to access. Include plenty of static links to your approval criteria throughout your developer portal and other support documentation.
- They are highly specific and contain examples. Approval criteria should be as specific as possible; in many cases, it helps to provide multiple examples of what developers should and shouldn’t do. For example, instead of telling developers to reference your marketplace “appropriately”, give concrete examples of what they can and can’t call your marketplace.
- They represent the real expectations for apps. Make sure there are no hidden expectations in your approval process. All of the approval criteria — as are used by you and your marketplace team — should be available to developers.
- They have been tried and tested internally. If your marketplace hosts first party apps — as is the case at Salesforce, Shopify, and others — put those apps through the same approval process as all others. Encourage the development team to their share thoughts about the process with the marketplace team, thus cultivating empathy for developers and identifying immediate areas of improvement you might otherwise have missed.
The Shopify App Store has a great example of approval criteria. It’s well-organized, easy to find, and, most importantly, ultra-specific. It’s broken down section by section (pictured below are their Security guidelines), and even features an interactive checkbox next to every criterion.
Again, the most important quality is specificity; over at Shopify, you’ll see how every criterion is either self-explanatory or links off to an in-depth resource:
Shopify’s approval criteria are either self-explanatory or link to helpful resources.
Learn from Common Rejections
This is a really fun and effective suggestion for reducing app rejections: track why you are rejecting apps (i.e. which criteria they fail to meet), and periodically analyze that data to improve your developer portal. If apps are frequently rejected for the same reasons, you’ll know where to focus your efforts. You can try improving problematic criteria by being more specific, adding more examples, or helping developers tackle the problem itself…
Again: Shopify is a model example of this with their Common app rejections page.
Support Developers in Tricky Areas
If developers repeatedly struggle with the same criteria — and you’re sure those criteria are clear enough — you might want to invest in helping developers solve the root cause. For example, if developers regularly submit apps without the right graphics, consider hiring a team of graphic designers to help your partners create listing materials; this is exactly what Udemy — the video course marketplace — does with their Design Service.
Similarly, if you’re rejecting apps for poor use of your APIs, you might want to rethink how your APIs are built. Another way you can support developers, regardless of the nature of the problem, is by creating additional documentation, how-to guides, and other educational materials.
Rejecting app submissions doesn’t have to be a painful process with these tips. By being quick, polite, specific, and constructive, you check all the boxes for a positive rejection experience. Of course, the better alternative is to ensure apps don’t need to be rejected in the first place. You can do that by providing ultra-precise approval criteria (and sticking to them), learning from what developers frequently struggle with, and supporting developers in those areas.