
Category: Shopify App GrowthReading time: ~22 minutes
Building a Shopify app is a significant investment of time, money, and energy. You've spent months architecting the solution, writing the code, designing the UI, and convincing yourself — and maybe some investors — that this is going to work. Then you submit to the Shopify App Store and wait.
Then comes the rejection email.
For many first-time Shopify app developers, this is a deeply frustrating moment. Not because rejection is unusual — it is extremely common — but because the feedback can be vague, the list of required changes feels overwhelming, and the clock is ticking on your launch timeline.
The good news is that the vast majority of Shopify App Store rejections are entirely preventable. They are not the result of a bad idea or an underfunded team. They stem from a well-documented (if scattered) set of technical, design, billing, and content requirements that Shopify enforces rigorously — and that many developers only discover after they have already submitted.
This guide covers every major reason Shopify apps get rejected, explains what Shopify is actually looking for at each stage, and gives you a practical framework for building your app — and your launch plan — around those requirements from day one.
Whether you are planning your first Shopify app or you have had a submission rejected and are trying to understand why, this guide is designed to give you clarity.

Before getting into the specific rejection reasons, it is worth understanding the mindset behind Shopify's review process. This context shapes everything.
Shopify's core customer is the merchant — the business owner who installs apps to grow their store. Shopify is extremely protective of this customer. Every app that gets listed on the App Store reflects, in some way, on Shopify itself. A buggy app that breaks a merchant's checkout, a poorly designed app that clutters their admin, or an app that leaves orphaned code in their theme after uninstall — these are all problems that Shopify treats as direct threats to merchant trust.
This is not pedantry. It is product philosophy. When a Shopify reviewer rejects your app for what feels like a minor UI issue or an edge case in your billing flow, they are not being bureaucratic. They are making a judgment call about the experience a merchant will have when they install your app on their live, revenue-generating store.
Understanding this shifts your perspective. The goal of the review process is not to filter out bad developers — it is to filter out bad merchant experiences. Once you internalize that, the specific requirements stop feeling arbitrary and start making logical sense.
Shopify's review team tests your app systematically. They install it, activate core features, check for console errors, test the billing flow, uninstall the app, and then check whether anything was left behind. They look at your app's impact on storefront performance. They review your listing copy for accuracy and completeness. They check your privacy compliance. They verify that your app behaves correctly in edge cases.
It is a thorough process. Knowing exactly what they are testing for is the first step to passing it.
This is the single most frequent cause of app rejection. Analysis of review logs suggests that over 60% of rejected apps fail at least in part due to missing or improperly implemented GDPR webhooks. It is also one of the most preventable failures.
Shopify requires every public app — regardless of whether it actually stores personal data — to implement three mandatory GDPR webhook endpoints:
The key word in all of this is mandatory. These webhooks are not optional based on whether you handle customer data. Shopify requires you to acknowledge these requests regardless. Even if your app does not collect any personal data, you still need to configure your endpoints to receive and respond to these webhooks — typically with a 200 response confirming receipt.
Many developers assume that because their app "doesn't store user data," these webhooks don't apply to them. This assumption is incorrect and it will get your app rejected.
What to do: Implement all three GDPR webhook endpoints before you submit. If your app truly stores no personal data, your handlers can simply return a 200 OK response. Document in your privacy policy how you handle each type of request. Test your endpoints with actual webhook deliveries using Shopify's Partner Dashboard.
Billing is the second most common trigger for rejection, and it comes in several forms.
Using a third-party payment gateway for app charges
Shopify's Partner Program Agreement is explicit: any charges for your app — subscriptions, one-time fees, usage-based billing — must be processed through the Shopify Billing API. You cannot redirect merchants to Stripe, PayPal, or any other external payment processor to pay for your app's plans.
This is a non-negotiable requirement. It is not a guideline. Apps that attempt to collect payment outside of Shopify's billing system will be rejected, and if discovered after launch, removed from the App Store.
The Shopify Billing API handles subscription charges, one-time application charges, and usage-based charges. It creates a consistent billing experience for merchants (they see all their app charges in one place within Shopify), and it is how Shopify takes its revenue share.
Leaving billing in test mode
This is a surprisingly common mistake that trips up developers who test their billing flows correctly and then forget to flip a single flag before submission. When you configure charge requests in the Shopify Billing API, test charges include a "test": true parameter that prevents real money from being charged.
Before submitting for review, every charge request in your production app must have "test": false, or simply omit the test parameter. If you leave test mode enabled, merchants who install your app will not be charged — which means the reviewer will notice that your billing flow appears to work visually but does not actually process a charge.
Charging before the free trial period ends
If your app offers a free trial, the Billing API has a trial_days parameter that specifies how many days before the merchant is charged. Shopify reviewers will check that you are not attempting to charge merchants immediately on installation if a trial is advertised.
What to do: Use the Shopify Billing API for every monetizable interaction in your app. Test your billing flow completely on a development store using test mode, then switch "test" to false before submitting. Audit your pricing plans against what you have advertised in your listing to ensure consistency.
When a merchant uninstalls your app, your app must leave their store exactly as it was before they installed it. Any code your app injected into their theme must be removed. Any data your app wrote that is not covered by GDPR webhooks should be cleaned up appropriately. The merchant's store should perform exactly the same after uninstall as it did before install.
The most common failure here involves theme modifications. If your app adds snippets, liquid code, or JavaScript to a merchant's theme to enable front-end functionality, and those files remain in the theme after the app is uninstalled, Shopify's reviewers will catch it. The merchant's store is now loading scripts that reference a now-deleted app, slowing down their storefront without any functional benefit.
Shopify's preferred solution for apps that need to interact with the storefront is Theme App Extensions, also called App Blocks. These are a native mechanism for embedding app functionality into merchant themes through Shopify's own extension framework. The key advantage: when an app using Theme App Extensions is uninstalled, Shopify automatically removes the associated App Blocks from the merchant's theme. The developer does not have to implement custom cleanup logic.
If you are still modifying theme Liquid files directly rather than using Theme App Extensions, you need to implement an uninstall webhook that triggers cleanup of any code your app has added. This webhook handler must be tested. Reviewers will install and uninstall your app and inspect the theme files afterward.
What to do: Use Theme App Extensions wherever possible for front-end functionality. If you must modify Liquid files, implement and test a robust uninstall webhook that removes every trace of your modifications. Test the full install-uninstall cycle on a development store and inspect the theme files manually after uninstalling to verify cleanup is complete.
Security is taken seriously at every stage of the Shopify review. There are several specific security requirements that catch developers off guard.
Missing or incorrect security headers
Your app's embedded admin interface must include the appropriate HTTP security headers to protect against common web vulnerabilities. The most frequently flagged are:
frame-ancestors to https://[yourstore].myshopify.com (and Shopify's admin domain), not block all framing entirely.Getting these headers wrong in either direction — too permissive or so restrictive that your app breaks inside Shopify's admin — will result in rejection.
Third-party cookies in embedded apps
Shopify prohibits embedded apps from relying on third-party cookies to manage sessions. This was a significant shift that caught many developers off guard when it was introduced, and it still trips up new developers who are building on older tutorials or documentation.
The required replacement is session tokens — a mechanism where your app authenticates requests between the client-side (the embedded admin interface) and your backend using a short-lived JWT token provided by Shopify's App Bridge. If your app's session management relies on cookies being set in an embedded context, you will fail review.
No HTTPS
Your app must be hosted on a reliable server with a valid SSL certificate. HTTP is not permitted. This applies not just to your app's admin interface but to any URL you register in your app's configuration, including callback URLs and webhook endpoints.
What to do: Audit your HTTP response headers for the required security headers before submission. Test your embedded app in Shopify's admin and verify that the frame-ancestors directive is correctly configured. Replace any cookie-based session management in your embedded app with Shopify's session token mechanism using App Bridge. Verify every URL in your app configuration uses HTTPS.
Shopify's OAuth implementation follows a specific, documented flow for authenticating merchants and requesting permission scopes. Any deviation from this flow — whether intentional or accidental — is grounds for rejection.
The most common OAuth-related issues include:
read_all_orders when your app only needs to read recent orders, or requesting write access when read-only is sufficient, will raise concerns with reviewers. Excessive scope requests are also a trust signal for merchants — they make your app look more invasive than it needs to be.What to do: Follow Shopify's official OAuth documentation step by step. Use Shopify's own CLI and templates where possible — they implement the correct OAuth flow out of the box. Test your OAuth flow with multiple test stores, including testing the scenario where a merchant denies permissions.
Shopify cares deeply about the speed of merchant storefronts. Every millisecond of additional load time introduced by your app reduces merchant revenue and degrades customer experience. This is not theoretical — Shopify's own research shows the direct correlation between page load speed and conversion rates for merchants.
If your app adds scripts, CSS, or other assets to the merchant's storefront, Shopify reviewers will check the performance impact. Shopify has a formal performance scoring mechanism that measures the contribution of app code to storefront load times. Apps that add excessive bloat will be rejected.
Common performance issues include:
What to do: Test your app's performance impact using the Shopify storefront performance tools before submission. Load your scripts asynchronously and only on the pages where they are needed. Minify and bundle your assets. If you are using Theme App Extensions, take advantage of Shopify's built-in performance optimizations for App Blocks. Aim for a net-zero or near-zero performance impact on page load times.
Shopify's review team actively tests your app. They do not simply verify that it looks functional in screenshots. They install it on a development store and attempt to use it — including testing edge cases, error states, and less obvious flows.
Common functional issues that lead to rejection:
What to do: Test your app comprehensively on multiple development stores before submitting. Go through every user flow yourself as a merchant would. Deliberately make mistakes — submit empty forms, click buttons multiple times, close modals mid-flow — and verify that your app handles these situations gracefully. Pay particular attention to the install-uninstall-reinstall cycle.
Shopify expects apps listed in its store to feel like they belong in the Shopify admin. The design system Shopify uses for this is called Polaris — a comprehensive set of UI components, color systems, typography guidelines, and interaction patterns that create a consistent merchant experience across all apps.
Apps that deviate significantly from Polaris design conventions — whether through cluttered layouts, misuse of admin UI blocks, inconsistent typography, or non-standard interaction patterns — will receive feedback requiring redesign.
This does not mean every pixel of your app must be a standard Polaris component. Shopify allows for brand expression and creative UI decisions. What it does mean is that the fundamental structure of your admin interface should feel familiar to merchants who use the Shopify admin every day. Navigation patterns, spacing, form elements, modal interactions, and notification patterns should follow Polaris conventions.
Beyond Polaris compliance, general UX quality is evaluated. If a reviewer cannot immediately understand what your app does and how to perform its primary function, that is a UX problem that will generate feedback.
What to do: Build your admin interface using Polaris components. Review the official Polaris documentation for your specific UI patterns. Ask someone unfamiliar with your app to attempt to use it without instructions — if they get confused, your UX needs work. Pay particular attention to your onboarding flow, which is the first experience a new merchant will have with your app.
If your app accesses or stores sensitive customer data — defined by Shopify as certain fields from the Customer and Order APIs including email addresses, phone numbers, birth dates, addresses, and order details — you must apply for Protected Customer Data access through the Partner Dashboard and receive approval before using those fields.
Apps that attempt to access protected customer data fields without the appropriate approval will be rejected. Even more importantly, you cannot simply apply for this access at the time of submission — the approval process takes time, and you need to factor it into your development and launch timeline.
Beyond the API access level, your privacy policy must accurately disclose what customer data your app accesses, why it accesses it, how it is stored, how long it is retained, and how merchants and their customers can request access to or deletion of that data.
What to do: Early in development, identify every API field your app accesses and cross-reference it against Shopify's Protected Customer Data list. If you need access to protected fields, apply for it through the Partner Dashboard well ahead of your planned submission date. Draft your privacy policy to explicitly address each data type your app handles.
Your app listing is reviewed alongside the app itself. Shopify's reviewers check that what is described in your listing accurately reflects what your app actually does. Misleading descriptions, exaggerated claims, or significant gaps between described and actual functionality are rejection triggers.
Specific listing issues that cause problems:
What to do: Complete your app listing with screenshots and descriptions that accurately reflect your current production app. Write your listing copy for merchants, not for developers — focus on outcomes and merchant benefits, not technical features. Test every link in your listing. Have someone else read your listing and then use the app to see whether their expectations match reality.
Shopify maintains a list of app categories and functionality types that are prohibited from the App Store. If your app falls into one of these categories — or if a core feature of your app involves prohibited functionality — it will be rejected regardless of how technically sound it is.
Prohibited categories include apps that:
Beyond outright prohibited categories, Shopify also has guidelines around apps that work with adult content, gambling, or other sensitive verticals, which require additional compliance steps.
What to do: Before building, review Shopify's current list of prohibited app categories in the Partner Program Agreement and App Store Review Guidelines. If your app operates in a sensitive vertical, understand the additional requirements before investing in development. If you are unsure whether a specific feature might be problematic, reach out to Shopify Partner Support for guidance before building.
Most developers encounter these requirements for the first time when they get a rejection email. The smarter approach is to build your app with the review checklist in front of you from the beginning. Here is how to restructure your development process to make the review a formality rather than a surprise.
Before writing a line of code, spend time with Shopify's App Store Review Guidelines, the Partner Program Agreement, and the Common Rejections documentation in Shopify's developer docs. These are not the most exciting reading, but they define the playing field. Know what is permitted, what is prohibited, what requires special approval, and what your app will need to implement regardless of its core functionality.
If your app will need Protected Customer Data access, apply for it now. This approval takes time, and waiting until submission to discover you need it will delay your launch significantly.
Decide early whether your app will use Theme App Extensions for storefront functionality. If the answer is yes, plan your architecture around this decision from day one. Retrofitting an app from direct theme modification to Theme App Extensions after the fact is painful.
Treat the following as foundational infrastructure, not optional add-ons to implement before submission:
GDPR webhook handlers: Implement all three endpoints at the very start of your project, before you build any user-facing features. They are simple to implement and painful to forget.
Shopify Billing API integration: Build your billing flow using the Shopify Billing API from day one. Do not plan a payment system and replace it later — design your entire monetization architecture around the Billing API from the beginning.
Security headers: Configure your HTTP security headers in your application framework and test them with a tool like SecurityHeaders.com before you have built any significant UI. Fixing headers retroactively after your admin interface is built can introduce unexpected compatibility issues.
Session tokens over cookies: If you are building an embedded app, implement Shopify App Bridge and session token authentication from the beginning. Do not build cookie-based session management with the intent to replace it later.
Uninstall webhook: Implement your uninstall cleanup logic early. Test the full install-uninstall-reinstall cycle on a development store regularly throughout development, not just before submission.
In the final weeks before you plan to submit, conduct a systematic audit of your app against every item on Shopify's review checklist. Go through the Common Rejections documentation in the Shopify developer docs and verify your app against each listed issue.
Test your app comprehensively on at least two different development stores. Go through every flow as a merchant would. Test edge cases deliberately — what happens when a merchant tries to access a feature they have not set up yet? What happens when an API call fails? What happens if a merchant grants your app permissions and then immediately navigates away?
Check your performance impact using Shopify's performance testing tools. If your app adds front-end code to storefronts, run a performance test before and after installation and verify the delta is acceptable.
Review your app listing with fresh eyes. Read it as a merchant who has never heard of your app. Is it immediately clear what the app does and who it is for? Are the screenshots current and representative? Does every link work?
Even with thorough preparation, some apps receive feedback requiring changes before approval. This is not a final rejection — it is a request for changes, and it is a normal part of the process for many apps.
When you receive this feedback, read it carefully and resist the temptation to fix only the explicitly listed issues. Shopify's reviewers note the issues they encountered, but they do not necessarily enumerate every issue in your app — they stop when they hit a blocking problem. Use their feedback as a starting point for your own deeper audit.
Fix every issue in the feedback comprehensively, test your fixes on a development store, and verify the original issue is fully resolved before resubmitting. Partial fixes that address the surface symptom without solving the underlying problem will generate another round of feedback.
Document the changes you make in response to each item in the feedback. This is not required by Shopify, but it helps you stay organized and ensures you have not missed anything.
When you resubmit, be aware that the reviewer may test different flows from the first review and identify new issues that were not tested in the initial review. This is part of the process. Treat each submission as a fresh, comprehensive test of your app against all requirements.
Passing the Shopify App Store review is not the finish line — it is the starting line. What happens next determines whether your app generates the installs, activations, and revenue you built it for.
Many developers treat the review process and the growth strategy for their app as separate concerns. In reality, they are deeply connected. The same qualities that Shopify's reviewers evaluate — a polished onboarding experience, a clean and functional UI, a clear value proposition, accurate listing copy, and strong merchant trust signals — are the exact same qualities that drive conversion and retention on the App Store.
An app that passes the review process because it has clean code, a complete listing, and a well-designed onboarding flow will naturally perform better in the App Store algorithm than one that barely scrapes through with the minimum required. Active store count, retention rate, and review velocity — the three most influential ranking signals in Shopify's App Store algorithm — are all downstream of the quality investments you make before and during the review process.
This means that preparing your app for review is not just a compliance exercise. It is a growth exercise. The work you do to get approved is the same work that will help your app rank higher, convert better, and retain more merchants after launch.
Before submitting your Shopify app, verify every item on this list:
Security and infrastructure
OAuth and authentication
GDPR compliance
Billing
"test": true) removed from all production charge requestsUninstall cleanup
Functionality and UX
Performance
App listing
Navigating the Shopify App Store review process successfully is just the first challenge. Once your app is approved, the real work begins: driving installs, activating merchants, retaining them, and growing your revenue.
Having worked with 20+ Shopify apps including IgnitePOST, ModeMagic, TrackiPal, Alert Me, Asklo, and ChargePay — from pre-launch planning through to scale — I have seen firsthand how the quality of your launch foundation affects every downstream growth metric. Apps that launch with a polished listing, a clear value proposition, and a well-designed onboarding flow consistently outperform those that rush to ship and optimize later.
If you are building a Shopify app and want support with your growth strategy — from App Store Optimization and keyword research to Shopify Search Ads and onboarding optimization — I can help you build the foundation that turns installs into revenue.
Learn more about Shopify App Growth consulting →
Shopify's App Store review process has a well-deserved reputation for being rigorous. But the requirements are public, the patterns of rejection are well-documented, and the fixes are almost always straightforward once you know what you are dealing with.
The developers who struggle most with the review process are those who discover the requirements at submission time. The developers who sail through — or at least move quickly from feedback to approval — are the ones who build around those requirements from the very first day of the project.
GDPR webhooks, Billing API compliance, proper uninstall cleanup, security headers, session tokens, performance impact, Polaris design compliance — none of these are technically challenging. They are infrastructure requirements. Build them in early, test them thoroughly, and the review becomes a confirmation of work you have already done rather than a list of changes you still need to make.
Your app deserves to make it to market. Make sure the technical foundation gives it the best possible chance to get there.
Veb is a Shopify App Growth Consultant with 6+ years of experience helping 20+ apps launch and scale on the Shopify App Store. His work spans App Store Optimization, Shopify Search Ads, onboarding strategy, and growth consulting for apps ranging from early-stage launches to established apps scaling toward exit. Get a free consultation →
Explore Big Moves Marketing Shopify App Growth services: