Shopify rejected
your app. Here is
what it actually means.

You shipped the app. You submitted it. A week later an email arrives and the status reads Reviewed, not Published, with a list of things to fix. The first feeling is that Shopify rejected you. The more useful read is that a reviewer just handed you a punch list. In almost every case the email tells you exactly what failed and what to do about it, and the founders who panic are the ones who skim it.

I helped build the Partner Program in the early Shopify years, so I have a soft spot for what the review team is actually doing. It is not gatekeeping for sport. The review exists because a bad app on a merchant's store can break checkout, slow the storefront, leak customer data, or quietly overcharge. Every requirement maps to one of those failure modes. Once you see the review as a set of merchant protections rather than arbitrary hoops, the whole thing gets readable.

This post is the decoder. The rejections that catch first-time founders, the five requirement categories Shopify will not bend on, the performance gates that have grown real teeth, how the billing and listing rules work, the timeline and resubmission flow, and why clearing review is a completely different bar than earning the Built for Shopify badge. There is a pre-submit checklist at the end you can run before you click submit. If you are earlier than this and still scoping the build, start with how to build a Shopify app in 2026 and come back here when you are ready to submit. I have watched founders treat this gate as a black box and burn six weeks on it, and I have watched founders treat it as a checklist and clear in nine days. The difference is almost never the quality of the product. It is whether they understood what the reviewer is actually checking.

A rejection is usually
a punch list,
not a verdict.

Here is the thing most founders get wrong on day one. Shopify's review has a "Request for Changes" state that is not a rejection at all. The reviewer pauses, writes down what needs fixing, and waits for you to reply and resubmit. Your app sits in Reviewed status, not dead, not approved, just waiting on you. Treat that email as a to-do list with a name attached to each line.

The reviewers are specific on purpose. If your OAuth flow throws an error on a fresh install, they will tell you the screen and the step. If you are charging through Stripe instead of Shopify's billing, they will name it. The work is rarely "make the app better in some vague way." It is "this exact thing is broken or non-compliant, fix it." Founders who read the note literally and fix only what is named tend to clear review in one more round.

The trap is reading rejection as a referendum on the whole product and rebuilding things nobody asked you to touch. That wastes a week and sometimes introduces a new problem the next reviewer catches. Fix the named items. Reply. Resubmit. The point of the rest of this post is to make sure the named items are short, because you anticipated them before you ever hit submit.

A real person installs
your app and tries
to break it.

Before you can read a rejection well, you have to know what produced it. A human reviewer tests your app against a written checklist. They are not running an automated scanner and rubber-stamping the output. They install your app on a test store, walk the setup, use the core feature, then uninstall it, reinstall it, and poke at the seams looking for errors. If something throws a console error or a 500 while they are doing that, it goes on the list. The mental model that helps is simple: assume a careful, slightly skeptical merchant is going to use your app for the first time with no idea how it works, because that is who is reviewing it.

Your app moves through four states as this happens, and the status banner in your Partner Dashboard is the source of truth. Draft while you are still building and filling out the listing. Submitted the moment you send it in and it joins the queue. Reviewed when a reviewer has looked at it and needs changes, which is the state most founders misread as a flat no. Published when you clear. The reviewer works through branding, the install and onboarding flow, the functionality itself, and the listing, in roughly that order, and they will stop early if the app will not install at all.

That last point matters more than founders expect. If your OAuth flow errors and the reviewer cannot complete the install, the review stops right there. They have not seen your feature, your settings, or your billing screen. The whole evaluation hangs on the first sixty seconds working. This is why I tell founders to make the install path bulletproof before they sweat the polish on a screen the reviewer might never reach. Give them a clean way in, a working test account, and a short screencast of the setup, and you remove most of the friction that drags a review into extra rounds. The same care you put into first-session onboarding for real merchants is exactly what the reviewer experiences first.

The rejections that
catch founders
over and over.

The failure reasons are not mysterious, and they cluster. After enough launches you can almost predict which one a given app will hit. Here are the five that come up most, with the merchant-protection logic behind each one, because once you understand why the rule exists you stop tripping it.

Notice the pattern. Four of the five are about the merchant having a clean, safe, honest experience, and one is about money flowing through the right pipe. None of them are about whether your idea is good. The review is not judging your path from MVP to your first million in ARR. It is judging whether your app is safe to put on a real store.

There is a second pattern worth naming, and it is the one that costs founders the most rounds. Reviewers stop at the first blocking problem. They do not write you an exhaustive list of everything wrong with the app. They install, hit the thing that breaks, document it, and move on. So you can fix the one named issue, resubmit confident you nailed it, and get rejected again on a second issue the reviewer never reached the first time because your OAuth error stopped them at the door. This is not the reviewer being cagey. It is the queue working as designed. The practical lesson is to fix the named item and also self-audit the rest of the hard-fail list before you resubmit, so the next reviewer reaches further into your app than the last one did.

The expanded table below is the full catalog I keep in my head when I am pre-flighting a submission for a founder. It maps each common rejection to the requirement category it lives in and the merchant harm it prevents, because the category tells you where else to look. If you tripped a privacy webhook, the rest of your security and OAuth surface deserves a second pass too.

Print that, or keep it open in a tab while you self-review. Every one of those rows is a thing I have watched a real app get sent back on. None of them require talent to fix. They require knowing they exist before you submit.

The five requirement
categories every app
is graded against.

Shopify's requirements look sprawling until you sort them into the five buckets a reviewer actually works through. Once you have the buckets, a rejection email stops being a surprise and becomes a label. The reviewer is telling you which bucket failed. Here is the map.

Functionality. The app installs cleanly, the core feature works, and nothing throws an error while the reviewer uses it. They install, set it up, use the main thing it does, then uninstall and reinstall to make sure that path is clean too. Web errors during testing, 404s and 500s, broken settings screens, and an app that does not do what the listing says all live here. This is the bucket most apps actually fail on, because it is the one a careful tester surfaces just by using the product like a real merchant would.

Security and OAuth. HTTPS everywhere with a valid certificate, a standard OAuth flow that requests only the scopes you use, session tokens instead of third-party cookies for embedded apps, clickjacking protection so your admin pages cannot be framed by a malicious site, and the three mandatory GDPR webhooks wired up and responding. This bucket is binary. There is no "mostly secure." A missing privacy webhook is a hard fail regardless of how good the rest of the app is.

Performance. The app responds fast under load and does not drag down the merchant's storefront. The public guidance is responses under roughly 500ms for 95% of requests and a storefront Lighthouse impact under about 10 points. This is the bucket that grew teeth most recently, and it is covered in its own section below because the numbers matter and founders consistently underestimate them.

Listing. The app card, the screenshots, the icon, the description, and the pricing. Reviewed as carefully as the code, because the listing is the promise and the app has to keep it. As of March 26, 2026, Shopify enforces tighter image rules (requirements 4.4.4 and 4.4.5) that I break down in the listing section. Get this bucket wrong and you can pass every technical check and still get sent back.

Billing. If you charge, you charge through Shopify's Billing API. Subscriptions, one-time fees, and usage charges all route through Shopify. This is the bucket with the least gray area and the highest cost to get wrong, because fixing it is often an architecture change, not a config tweak. It gets its own section too.

The reason the buckets are worth memorizing is that they tell you about adjacent risk. If a reviewer flags one listing problem, there are usually more in the listing bucket they did not get to. If they flag one security item, audit the whole security bucket before you resubmit. Founders who think in buckets resubmit once. Founders who fix one line at a time resubmit four times.

The 2026 requirements,
and which ones are
truly non-negotiable.

Inside those five buckets, the individual requirements split into two kinds, and confusing them is how founders burn time. One kind is hard pass-or-fail compliance: you did it or you did not. The other is performance and quality, where there is now a real numeric floor. Both matter, but you fail differently on each. Here is the live checklist as it stands in 2026.

The hard-fail rows are binary. You either use the Billing API or you do not, you either ship all three GDPR webhooks or you fail, you either handle the app/uninstalled webhook or you leave merchant data orphaned. There is no partial credit and no charm-your-way-through. Get these right before you submit, because no amount of polish elsewhere offsets a missing privacy webhook.

The performance rows are newer in their teeth and worth taking seriously. Shopify wants apps that respond fast under load and that do not tank a merchant's storefront speed. The rough public guidance is sub-500ms responses for the large majority of requests and a storefront Lighthouse impact under about 10 points. If your app injects heavy scripts into the theme, this is where you get caught. The same discipline that keeps you past review is what keeps merchants from uninstalling, which is why I treat speed as a retention lever, not just a launch hurdle. It connects directly to app onboarding benchmarks: a slow, heavy app loses people in the first session whether or not a reviewer ever flags it.

One nuance worth flagging on the OAuth row: scope minimalism is part of the bar, not just a nicety. If you request write access to orders and the reviewer cannot see why your app needs it, that is a question you will have to answer, sometimes a change you will have to make. Ask for the narrowest set of scopes your feature genuinely uses. Over-scoping reads as a privacy risk, and the reviewer is paid to be skeptical of it.

The performance gates
founders keep
underestimating.

For years, performance was the soft part of review. A reviewer might mention your app felt sluggish, but it rarely blocked a launch. That has changed. Speed now has numbers attached, and the numbers are checked. Two separate measurements matter, and founders mix them up constantly, so let me separate them cleanly.

The first is your server response time under load. Shopify's guidance is that 95% of your requests should return in under roughly 500ms. This is about your backend, not the browser. If your endpoints get slow when more than a handful of stores hit them at once, that surfaces here. The fix is usually boring infrastructure work: caching, database indexing, moving heavy operations to background jobs instead of blocking the request. Boring, but it is the difference between an app that scales and one that falls over at the worst possible moment.

The second is your storefront impact. If your app injects anything into the merchant's theme, a tracking pixel, a widget, a script, Shopify measures how much it slows the storefront and wants the Lighthouse performance hit to stay under about 10 points. This is the one that catches founders who built fast admin pages but never measured what their storefront injection costs. Run Lighthouse on a test store with your app on and with it off, and look at the delta. If it is more than 10 points, you have work to do before you submit, not after.

Then there is the higher bar that lives one tier up, in Built for Shopify. For apps that load in the Shopify admin, the badge requires Core Web Vitals measured at the 75th percentile of real page loads: Largest Contentful Paint at or under 2.5 seconds, Cumulative Layout Shift at or under 0.1, and Interaction to Next Paint at or under 200 milliseconds. Crucially, these are measured from real merchant usage, not a lab test. Your app needs at least 100 data points for each metric over a rolling 28-day window before Shopify will even assess it. That last detail trips people: a brand-new app with five installs simply cannot earn the badge yet, no matter how fast it is, because there is not enough real-world data to measure.

The review-row numbers (the top two) are what you need to launch. The Built-for-Shopify rows are what you chase later. Do not let the badge-level Web Vitals targets scare you off launching, but do not ignore them either, because the architecture decisions you make now are what make the badge reachable later. An app built to inject a single, deferred, lightweight script clears both bars. An app built to load a heavy bundle on every storefront page clears neither. The same architectural restraint applies when you start bolting on AI features, where it is easy to ship something heavy without noticing, a tradeoff I get into in the guide to AI for Shopify app founders.

The listing rules that
fail apps which
otherwise work fine.

Here is the rejection that stings the most, because the founder did everything right on the engineering side. The app is fast, secure, billed correctly, and clean on uninstall. And it still gets sent back, because the listing broke a rule. The listing is reviewed as carefully as the code, and it is the promise the app has to keep. Treat it as part of the product, not the marketing afterthought you slap together the night before you submit.

Start with the things that get an image rejected outright. Screenshots cannot show a browser window, a desktop background, or operating-system chrome. They cannot show the Shopify logo, the green shopping bag, or a myshopify.com URL in the address bar. Your icon cannot use the Shopify shopping bag or any Shopify trademark, cannot contain text, and should use bold colors and a simple recognizable shape at 1200 by 1200 pixels with a little padding so the mark does not touch the edges. These sound petty until you remember the listing sits next to thousands of others, and Shopify is protecting a consistent shelf.

The image rules got stricter in 2026. As of March 26, 2026, Shopify enforces two requirements that change how listing imagery is judged. Requirement 4.4.4 demands that screenshots primarily show your app's actual interface and features, no desktop backgrounds, no browser frames, no images that are just your logo on a color field. Requirement 4.4.5 demands that every image in your listing be unique, each one showing a different feature, view, or app state. You can no longer pad the gallery with five variations of the same hero shot. If your listing was approved before that date with repeated or chrome-heavy images, a future update can trigger a re-review against the new rules, so it is worth fixing proactively.

Then the copy. The single fastest way to fail on listing content is to describe a feature the app does not cleanly deliver. The reviewer reads your description, then goes looking for each thing you claimed, and if a claim does not hold up, that is a rejection. So write the listing against what works today, not what is on the roadmap. Pricing has to be clear and honest, with no hidden charges that appear only after install. The whole point of the listing review is that a merchant should be able to trust the card before they install. Once you are listed and the listing is honest, the next problem is getting it to rank and convert, which is a different discipline entirely and the subject of my App Store SEO guide.

Why the Billing API is
the rule you cannot
negotiate around.

If there is one rule I would tattoo on a first-time founder's wrist, it is this: charge through Shopify's Billing API, or do not charge at all. Every charge tied to your app, subscriptions, one-time fees, usage-based charges, has to flow through Shopify's billing. Routing payment through Stripe, a credit card form, or any external checkout is not a fixable note. It is a hard rejection, and it is the single most common reason a first submission fails.

The reason this rule is absolute is worth understanding, because it tells you why there is no exception to argue for. When merchants pay for your app through Shopify, the charge shows up on their Shopify bill alongside everything else. They have one billing relationship to manage, one place to see what they are paying, one consistent way to cancel. That is a real merchant protection. It also funds Shopify's revenue share, which is how the platform pays for the App Store, the review team, and the distribution that gets your app in front of merchants in the first place. The exact split, and how it has shifted, is laid out in the 2026 Partner Program agreement. You are paying for the channel. The Billing API is the toll booth.

The trap is architectural, not philosophical. A founder who already has a SaaS product with Stripe billing, then decides to build a Shopify app as a new channel, will instinctively reuse the Stripe integration they already have. It works in testing, it ships, and it gets rejected, and now the fix is not a config change but a billing-system rebuild against a new API. If you are planning a Shopify app and you charge for it, design for the Billing API from day one. Retrofitting it after a rejection is the expensive path, and it is the one I see most often. This decision sits right at the heart of your path from MVP to your first million in ARR, because how you bill shapes how you price, trial, and upgrade.

One clarification that saves confusion: the Billing API rule covers charges for your app. If your app facilitates a different kind of transaction, say it is a payments app or it processes orders, those flows have their own rules and APIs. But the subscription a merchant pays to use your software is unambiguous. That goes through Shopify billing, full stop, and the reviewer will check it on a test charge.

How long it takes,
and how to resubmit
without restarting the line.

Plan your launch around the real clock, not the optimistic one. A first review typically runs about 5 to 10 business days, with the initial pass often landing in 4 to 7, and the full path from submission to publication stretching to 2 to 4 weeks once a round of changes is involved. The queue depth and your app's complexity both move that number. Build the buffer into your launch plan so a single round of changes does not blow up a dated announcement or a partner co-marketing slot.

Your app moves through four states, and the status banner in the Partner Dashboard is the source of truth, not your inbox. Draft while you build and fill out the listing. Submitted once you send it and it joins the queue. Reviewed when a reviewer has looked and needs changes. Published when you clear. When you get a Request for Changes, you make the fixes and resubmit from that banner.

Here is the part founders fear and should not. Resubmitting is normal, expected, and usually faster than the first round. A resubmission re-enters the queue, but typically at higher priority than a fresh submission, so the second pass generally comes back quicker than the first. There is no penalty for being rejected, and no cap on how many times you can resubmit, as long as you are making genuine fixes each time. The thing that does hurt you is resubmitting carelessly: an app that bounces back repeatedly with sloppy half-fixes can eventually get suspended, which is a far worse state to be in than "Reviewed."

So resubmit well. When you reply, write a short note that maps each fix to the reviewer's named issue: "On the OAuth error you flagged, we corrected the redirect. On the second item, we added the customer-redact webhook handler." That note does two things. It speeds the re-review because the reviewer can verify your fixes directly, and it forces you to confirm you actually addressed each named item. Fix exactly what was named, plus self-audit the rest of that requirement bucket, and do not silently change ten unrelated things, because every unrelated change is fresh surface area for a new note. If you blow past 10 business days with no movement, nudging Partner Support for a status check is fair game. The fastest path through is one careful resubmission, not three rushed ones. That discipline carries straight into the work that comes after launch, the distribution playbook for getting installs: rushed work creates the next failure, in review and in growth alike.

The pre-submit checklist
I run before any app
goes into the queue.

You cannot guarantee a one-round approval, but you can stack the odds heavily in your favor by pre-flighting the exact things reviewers check. Before you click submit, run your own review against the hard-fail list and the listing rules, deliberately trying to break your own app the way a reviewer will. Most rejections are things a founder could have caught in 30 minutes of honest self-testing.

Walk the install flow on a clean development store as if you were a brand-new merchant who has never seen your app. Then test the ugly paths, not just the happy one. Uninstall the app and confirm no orphaned theme code remains. Confirm every charge runs through the Billing API on a real test charge. Confirm all three GDPR webhooks fire and respond, plus app/uninstalled. Hit your endpoints under a bit of load and watch the response times. Run Lighthouse on a storefront with your app active versus inactive and read the delta. Here is the full checklist in one place.

The last row is the one founders skip and the one that quietly buys you the most goodwill. Give the reviewer a pre-configured test account or a development store with sample data already loaded, working credentials, and a short screencast of the install and setup. Reviewers install, uninstall, reinstall, and try to break your app, so anything that helps them reach your core feature in the first two minutes shortens the whole review. An app that ships with clear test data and a setup video tends to clear in fewer rounds, because you removed the friction that drags a review sideways. Clear this checklist, submit, and you have done the work that turns a black-box gate into a predictable nine-day wait. The review is the lock on the door. Once you are through it, the actual growth problem begins.

What app founders ask me
about getting through
App Store review.

A note on sources: the review requirements, app statuses, performance guidance, and the Request for Changes flow are from Shopify's developer documentation, including the App Store requirements, about the app review process, the common rejections page, and the app requirements checklist. The Built for Shopify Web Vitals targets (admin LCP at or under 2.5s, CLS at or under 0.1, INP at or under 200ms at the 75th percentile, with a 100-call-per-metric minimum over 28 days) are from the Built for Shopify requirements. The stricter listing-image rules (requirements 4.4.4 and 4.4.5) take effect March 26, 2026, per Shopify's clearer standards for app listing images changelog. The first-review window (roughly 4 to 10 business days, 2 to 4 weeks through a round of changes) and the resubmission-priority behavior reflect Shopify's published guidance and developer-community reporting; queue times vary. The read on which rejections actually catch founders, the requirement-bucket framing, the prep sequence, and the review-versus-badge distinction are mine, from helping build the Partner Program and taking a software company through this gate.