Building a Shopify App for the App Store: Lessons Learned
23 February 2026 · 4 min read
Building custom Shopify apps for individual merchants is a large part of my work. Building a public app for the Shopify App Store is a different proposition entirely. The code is similar. Everything else — the review process, the support burden, the commercial model — is different.
I went through this process recently. Here's what I learned.
The review process is thorough
Shopify's app review team is serious. They test your app across different store configurations, check for performance issues, verify your data handling practices, and assess the user experience against their guidelines. This is a good thing — it keeps the app store quality higher than most — but it means your first submission will almost certainly come back with feedback.
Common rejection reasons I encountered or heard about from other developers: requesting API scopes you don't actually need, not handling app uninstallation cleanly, storing customer data without adequate explanation, and UI patterns that don't follow Polaris guidelines.
My advice: read the app requirements documentation thoroughly before you start building, not after. The requirements aren't onerous, but they do influence architectural decisions. Requesting only the scopes you need, for example, should shape your data access strategy from day one.
Polaris and App Bridge aren't optional
If your app has an admin interface, it needs to use Polaris (Shopify's design system) and App Bridge (the library that embeds your app within Shopify's admin). This isn't a suggestion — it's a requirement for app store approval.
Polaris is well-built and the component library covers most common UI patterns. But if you're used to building interfaces with your own design system or a library like Tailwind, the adjustment takes time. You're working within Shopify's visual language, and certain layout decisions are made for you.
The Remix app template that Shopify provides gets you started quickly. It handles authentication, session management, and App Bridge integration out of the box. I'd strongly recommend starting from this template rather than building your own auth flow.
The commercial model needs thought
Shopify takes a revenue share on app subscriptions. The current model charges 0% on the first million dollars in app revenue annually, then 15% after that. For most independent developers, the 0% tier is where you'll live for a while.
Pricing a public app is harder than pricing custom development. Too high and merchants won't install it. Too low and you can't sustain the support burden. Look at comparable apps in the store and price competitively, but don't race to the bottom. A well-built app that solves a genuine problem can charge £50 to £200 a month and retain merchants for years.
Free plans attract support tickets from merchants who aren't invested in the tool. A free trial followed by a paid plan filters more effectively than a permanent free tier.
Support scales faster than you expect
Every merchant who installs your app is a potential support ticket. They'll find edge cases you didn't test. They'll use your app alongside other apps that create conflicts. They'll have store configurations you didn't anticipate.
For a custom app serving one merchant, support is a conversation. For a public app serving five hundred merchants, support is a job. Build your app with good error messages, clear documentation, and a sensible onboarding flow. Every minute you invest in self-service support saves hours of manual support later.
Automated error tracking (Sentry or similar) and usage analytics are essential. You need to know when something breaks before merchants tell you. You also need to know which features are actually used so you can prioritise development.
API versioning matters more
Custom apps can target a specific API version and update on your schedule. Public apps need to support multiple API versions because Shopify's deprecation timeline means different merchants may be on different versions during the transition period.
In practice, always target the latest stable API version and handle deprecation warnings proactively. Shopify gives you reasonable notice before breaking changes — the Editions releases are a good time to review what's changed — but you need to be paying attention. Set calendar reminders for API version release dates and deprecation deadlines.
Testing across store types
Your app needs to work on Basic, Shopify, Advanced, and Plus plans. It needs to handle stores with five products and stores with fifty thousand. It needs to work for stores selling physical goods, digital products, and services. It needs to handle multiple currencies and languages if applicable.
Set up test stores on different plans. Shopify's Partner programme gives you development stores for free. Use them. The bugs you find in testing are far cheaper than the ones merchants find in production.
The real lesson
Building the app was enjoyable — it's what I do. The lesson was that a public app is a product, not a project. It needs ongoing development, support, marketing, and commercial management. If you're building one, treat it like a business from day one, because that's what it becomes.
Need help with this?
If you're working on something related and could use an extra pair of hands, I'm available for project work. No obligation — just a conversation.
Get in touch →