Updates to App Store submission requirements: build, grow, then expand

Shopify App Store
1

Hi everyone,

We’re updating App Store submission requirements to help keep the App Store a place merchants can trust. The core idea is simple: build an app that delivers value, grow its adoption, then expand. Before adding more apps to the App Store, partners should validate that their existing apps are delivering value to merchants.

What’s changing

  • Establish adoption - Before you list an additional app, your existing apps need to show real merchant demand. Partners will need to reach at least 10 installs on their app from full-priced Shopify stores before listing another one.

  • Address feedback - If a submission is rejected, take the time to fix the issues before you come back. Rejected submissions will have escalating cooldowns before resubmission, so repeated attempts without meaningful changes will mean longer waits. Our review feedback is meant to help you build a better app for merchants. We want that feedback addressed properly, not resubmitted as-is.

  • Verify your identity - Identity verification will soon be required for partners submitting new apps, so merchants know who is behind the apps they install. This adds a layer of accountability and helps merchants trust the apps they find in the App Store.

  • Validate your idea - An app that no merchant has installed after six months hasn’t found its audience, and will be automatically removed. This will be rolling out starting today, so If you have an app in this position, it’s a good time to step back and focus on something merchants are asking for.

Why we’re doing this

We want the Shopify App Store to be a place that rewards partners for building tools merchants actually use. Merchants should be able to install apps with confidence, knowing the apps come from partners who are accountable for them. These changes give partners a clear growth path: prove one app works, learn from real merchants, then expand on a foundation of traction. More broadly, we want an ecosystem that rewards depth over volume. Build something merchants use, grow it, then expand.

We know changes like these affect how you plan, so please tell us what’s unclear or what you’d like us to consider as we roll this out. Ask questions in this thread.

Thank you for building for what merchants need!

2

This is great news, thank you! Truly this is needed! One related thing I’d love to see get attention: app discoverability. We’re seeing noticeably less App Store traffic lately, ads included, as merchants ask Sidekick or use the admin search instead of browsing. That shift makes sense. The catch is that Sidekick seems to search the App Store and pass along the top three results, so whatever shapes search ranking (category keywords in an app’s name, review velocity) now decides what merchants see everywhere. I’d love to see Sidekick use its own judgment about which app fits the merchant’s problem, and maybe point people to the App Store to explore once in a while :slight_smile: Or improve App Store search itself, so the gains flow through to admin search and Sidekick too. One more wish: a trust status for app developers that goes beyond Built for Shopify, similar to the partner tiers (Platinum and so on). Happy to share what we’re seeing on our side if it’s useful.

Realizing now this should maybe be another thread :innocent:

3

I’ve delisted quite a few apps, but I still get Dev Dashboard warnings about deprecated APIs and expiring tokens for apps that aren’t worth maintaining anymore.

Could we allow partners to permanently delete apps with fewer than 30 total installs? I’m talking about small utility apps that merchants likely installed once and forgot about, not apps they actively depend on. Currently, even one install prevents deletion.

4

This is great news, especially the identity aspect. Merchants deserve to know exactly who they’re trusting with their business & data.

5

I understand what Shopify is trying to accomplish with these limits, but I think there are a couple of things worth reconsidering.

One concern is how this affects developers building apps for niche markets. For example, I have a B2B app targeting a relatively small merchant segment. Reaching 10 qualifying installs in that space can take longer than with a general-purpose app, but that doesn’t necessarily reflect the app’s quality or usefulness.

I’m also currently developing a separate app that serves an entirely different market. With this change, I can no longer submit it for review until the B2B app reaches the threshold.

I think a transition period for existing developers, or an exception for apps already in development, would be reasonable.

It would also be helpful to expose the actual qualifying install count in the Partner Dashboard. The current merchant exports don’t provide enough information to reliably determine which installs count toward the requirement.

I agree with the goal of maintaining a high-quality App Store. I just think there should be some flexibility for developers working across different merchant segments, particularly when the new requirements affect projects already underway.

(I am all for the other changes with identity, response to feedback, etc.)

6

These are good news. But why don’t you require identity verification from the current apps as well? There are many apps live without any information about the company or people who’s behind the app.

7

Hi Josh - thanks for sharing your concerns. How niche are you talking? We assumed 10 installs is a small threshold even for B2B. Is there a better number?

8

Hi Simo,

Have you gone through the steps here to sunset your apps: Sunsetting your app

9

I agree! Can we get verification for all app devs please!

10

I honestly don’t know what the right number is. I think this may be one of those situations where a single threshold doesn’t necessarily tell the whole story.

It’s hard to quantify exactly how niche an app is, but different types of apps naturally have different audiences and adoption rates. My B2B app is seeing organic adoption, just at a slower pace than my more general-purpose app.

Maybe an alternative would be to allow developers to have one published app below the 10-install threshold, but not two. That would still discourage developers from repeatedly publishing apps without gaining traction, while allowing some flexibility to explore different markets.

For example, a developer with one established app and one newer app still building adoption could submit a third. But if two published apps were both below the threshold, they’d need to grow at least one before submitting another.

That seems like it might accomplish the same goal without making every individual app a blocker.

11

Hey @matt, Lots of discussions across the community around this one. It a massive problem, with the potential to kill off many good devs!

Main one (I think) is here Shopify Sidekick App Recommendations – A Nightmare for Developers Outside the Top 3?

Then we have another just trying to warn merchants, here Shopify merchants, be careful with Sidekick's app recommendations!

12

Love this!! The focus should always be on quality and delivering great products that customers need. THANK YOU

13

@jzaz I agree with @Josh-Five_Acre_Code re: B2B and/or niche apps; especially if they are not “inexpensive” or a mass market targeted app.

Some B2B apps have a multi-month sales/onboarding cycle – so if a dev has more than 1 app in the pipeline, waiting for app #1 to get to 10 will prevent app #2 from getting its review.

And if the apps are part of a larger suite of solutions (perhaps related), the developer may want to try to time two or three apps to land within a reasonable time period.Having to force the onboarding of one app in order to get number two into review doesn’t always add up

As much as I know Shopify wants to automate this with predefined non-negotiable rules, this may need to be a human evaluation on a case-by-case basis?

If a developer can make a reasonable case for app number 2 or app number 3 before app number 1 hits 10 paid merchants, there’s probably some justification. For some developers, I would hope Shopify is open to an appeal, not just the blanket rule that will force Shopify to not even let the apps in the door for review.

I hope this makes sense?

14

Failing an app review for a new app already kicks you back to end of the long review queue - I waited 10 business days for my first review, now waited another 7 business days and counting. I have no record of the original review other than the e-mail, and no way to provide feedback - simply re-submit and pray we didn’t miss anything. There were a lot of things in the review e-mail that were copy/pasted that really didn’t seem relevant to our app at all (i.e. test credentials and URLs), but I can’t point it out to anyone.

I think the escalating cooldowns is a great idea if there was an actual dialog occurring between the reviewer and the app owner - otherwise it’s just a mechanism to punish app developers who don’t get it perfect the first time around. It’s been almost a month since I’ve submitted, but I’ve only had one review that the reviewer got tripped up on entering a value into a multi-value input. I’ve improved the UX to prevent this, but it’s such a little thing that really tacks another 2 weeks of lost revenue for a tool we’re really excited about.

15

We’re an agency that builds Shopify apps, and this change hit us in the middle of the review process, with no notice.

Before the announcement we had several apps in review and ten in our pipeline, most of them built for our local market. Since the rule went live, none of them is in review anymore. Every one shows “Submission limited”. Months of work that were already in the queue are back to square one, and nothing in the announcement explains what happens to apps that were already submitted.

Our one published app is a niche product with a very specific differentiator. It was never meant to reach volume fast. Now it decides whether anything else we build can even be reviewed.

Three problems with the rule as it stands:

  1. It protects incumbents. Who will take the risk of building a focused alternative to a dominant app, knowing that nothing else they make can ship until that one app reaches 10 paid-plan installs? The apps that gain from this are the ones that are already big.

  2. It punishes portfolios. Companies that were investing in more than one app at a time now have to stop and chase installs for the existing ones, even when those apps serve a small, well defined niche. “Depth over volume” should not mean one bet at a time.

  3. It hurts local markets. Apps built for a single country’s payment, shipping, or tax reality have a small addressable base by design. Ten qualifying installs there is not the same as ten installs for a general purpose app.

What we’re asking for:

  • Grandfather every app that was already in review on the day of the announcement.
  • Allow one published app below the threshold, so a single niche app does not freeze a whole company.
  • Show the qualifying install count per app in the Partner Dashboard.
  • Give us an appeal path with a human on the other side.

To answer the question asked earlier in this thread: the problem is not whether 10 is the right number. It is that the number is applied to every app in an organization, retroactively, to submissions that were already in the queue.

There is a bigger issue behind this one. It is getting hard to justify investing in the Shopify ecosystem when it feels like Shopify is no longer interested in that investment. Each change seems designed to make building harder and less motivating. Rules change overnight, with no transition and no warning. How do we commit budget and people to a platform where, two months from now, someone can wake up and decide to change everything again?

We built these apps because we believed in the platform. Right now we are reassessing whether it makes sense to keep investing here at all.

What should developers in our position do with apps that were mid-review last week?

16

I second these. I had 2 apps in review that compliment each other but not all clients need both apps. Both had been in the pipeline for over a week, and one just got pushed back out. Now I’m unsure how I will serve the other customers that need the second app. Please at least grandfather the apps that were already in review. Also our second app had a very generous free tier and the new limits would have us rethinking whether to put some small dollar amount on the free tier just to avoid it becoming a bottleneck for all future apps, just to pass the 10 paid install bar.

That being said, I completely agree with build and grow, then expand. Most of us are not trying to shotgun dozens apps into review. That scenario should be avoided at all costs. But one at a time is pretty limiting if an entire team needs to sit and babysit one app at a time.

17

I’ve been thinking more about these changes and wanted to offer a different way of approaching the problem.

Looking at all four changes together, I suspect Shopify is trying to address a few related issues. I don’t have access to Shopify’s internal data, so these are assumptions, and if they’re incorrect, some of the suggestions below may need to change.

What I suspect Shopify is trying to solve

  1. Submission volume has increased significantly, possibly driven by developers rapidly producing large numbers of apps without sufficient testing or development effort.

  2. Too many apps are entering review with avoidable issues, consuming reviewer time and creating longer queues for everyone.

  3. The App Store is accumulating apps that have little or no merchant adoption, making discoverability harder and potentially affecting merchant confidence.

  4. Some developers may be publishing apps in volume without investing in their ongoing quality, support, or maintenance.

Taken together, the new identity verification, escalating review cooldowns, six-month removal policy, and installation threshold seem designed to address these problems.

I generally support the first three changes. It’s the universal installation requirement that I think deserves another look.

How I would approach it

Rather than immediately applying a fixed threshold to everyone, I’d start by examining the data to understand where the actual problems are coming from.

1. Identify what’s driving review volume

I’d look at submissions per partner, rejection rates, resubmission frequency, reviewer time consumed, and how those numbers correlate.

For example, if a relatively small percentage of developers are responsible for a disproportionate amount of review work, I’d focus restrictions on those patterns.

If developers submitting multiple apps have high first-pass approval rates, I wouldn’t necessarily consider them part of the problem just because they’re productive.

The escalating cooldowns seem like a good step in this direction. I’d measure their impact before assuming additional restrictions are necessary.

2. Separate app quality from app adoption

I wouldn’t assume that 10 installs necessarily establishes quality, or that fewer than 10 indicates a lack of value.

I’d look at retention, uninstall rates, merchant complaints, and whether adoption is increasing over time.

I’d also consider App Store exposure. An app with four installs from 100 listing visits tells a different story than one with four installs from 10,000 visits.

If an app has low adoption but the merchants who install it continue using it, that might indicate a legitimate niche product rather than an unsuccessful one.

Conversely, if an app attracts 50 installs and nearly everyone uninstalls it immediately, those 50 installs haven’t necessarily demonstrated meaningful value.

I’d want to understand those differences before deciding what the right threshold should be.

3. Consider portfolio-level limits instead of requiring every app to reach 10 installs

One fairly simple alternative would be to allow developers to have one published app below the 10-install threshold, but not two when submitting another. I don’t necessarily think this is the right answer, but its a better answer.

That would give developers room to explore new markets while preventing the repeated publication of apps that aren’t gaining traction.

You could also consider submission frequency and review history. A developer publishing an app every few months with a good review record probably presents a different risk than someone submitting dozens of apps with repeated quality issues.

These approaches aren’t mutually exclusive.

4. Measure the results and adjust

I’d want to establish a baseline before the changes and track whether they’re producing the intended outcomes.

Some things I’d look at:

  • Are review queues getting shorter, and is reviewer time per approved app decreasing?

  • Are first-pass approval rates improving?

  • Is the number of unused or poorly maintained apps decreasing?

  • Are merchants experiencing fewer problems with newly published apps?

  • Are legitimate developers being blocked despite good review histories and healthy merchant retention?

If review efficiency improves substantially but legitimate developers are being blocked from releasing quality products, I’d consider that a signal to adjust the restrictions.

I’d also backtest the proposed rules against historical submissions to see how many developers would have been blocked, and whether those developers were actually contributing to the problems Shopify is trying to solve.

And for a change this significant, I think a transition period and a clearly defined exception process would make sense.

Ultimately, I think the important question is what behavior Shopify is trying to change.

If the problem is excessive low-quality submissions, target the submission and review patterns. If it’s abandoned apps, the new six-month rule already addresses part of that. If it’s developer accountability, identity verification is a sensible measure.

The 10-install rule may reduce the overall number of submissions, but reducing submissions and improving the quality of submissions aren’t necessarily the same thing.

I’d be interested to know which problems are actually driving this policy and what Shopify’s data shows. If my assumptions are off, I’d certainly reconsider the approach.

I think there’s a reasonable middle ground here that protects merchants and the App Store without unnecessarily restricting developers who are building legitimate products for smaller markets.

18

One other concern is how abruptly this changes the rules. It feels like Shopify went from having no speed limit to setting it at 1 overnight, without even giving developers a speedometer.

We’re now being held to a qualifying install threshold, but there’s no clear way to see how many qualifying installs we actually have. The available merchant data doesn’t reliably tell us which stores Shopify counts.

If we’re going to have these restrictions, we should at least have visibility into the metrics being used to enforce them.

More broadly, I think this is a pretty hard swing of the pendulum. There are probably ways to address the underlying problems without going from relatively unrestricted submissions to blocking developers based on the adoption of every app they’ve previously published.

19

Thanks for laying this out. One wording question, so we count the right thing:

The changelog says “at least 10 installs on their app from full-priced Shopify stores”, but the submission guide says “10 or more paid installs from active stores on paid plans”.

Does an install count when the merchant’s store is on a paid Shopify plan but they use the app’s free plan? Or does the merchant also need an active paid subscription to the app?

The answer changes how a new developer should price a first app, so a clear line in the docs would help a lot.

Also +1 to the earlier request to show each app’s qualifying install count in the Partner Dashboard. Counts update daily, so seeing where we stand would save guesswork.