Building a Shopify app: what it takes and what the review process checks
What a public app on Shopify involves, from framework and billing to the review that decides whether merchants can install it.
The short answer
A public app on Shopify is a product, not a project: multi-tenant software that any store can install, billed through the platform, supported by you, bound by privacy obligations, with a listing that must pass review before merchants can find it and again after significant changes. The platform’s app framework provides the parts every app needs: authentication and install flow, billing, webhooks, admin interface components and extension points for the storefront and checkout. The app provides its own hosting, database, logic and support. Review checks that it works as described, handles the mandatory privacy webhooks, bills correctly, is secure, does not harm storefront performance and presents an honest listing. Most rejections are small, checkable things found by installing on a clean store and walking the reviewer’s path.
What a public app involves
| Area | What you build or provide | What Shopify provides |
|---|---|---|
| Install and authentication | The flow using the framework; per-store setup | The authentication protocol, session handling in the framework |
| Multi-tenancy | Data isolated per store; clean install and uninstall | Store identity per request |
| Billing | Plans, trials, usage charges, matching the listing | The billing API and merchant approval flow |
| Webhooks | Handlers for orders, products, app uninstalled, and the mandatory privacy topics | Delivery with verification |
| Admin interface | Screens built with the platform’s components | Component library and embedding |
| Storefront and checkout | Theme app extensions, functions, with minimal weight | Extension points |
| Hosting and data | Your own hosting, database, monitoring, backups | |
| Support and listing | Documentation, support channels, accurate listing, privacy policy | The listing and review |
Passing review
- Read the current requirements checklist before building; it changes.
- Test the install on a fresh development store exactly as a reviewer would: install, grant, onboard, use the main feature, bill, uninstall.
- Implement and verify the mandatory webhooks with the platform’s test tools, and confirm the app deletes what it is asked to delete.
- Match billing to the listing: plan names, prices, trials, what each includes.
- Measure storefront impact: any theme extension or script must be light and load only where used.
- Write the listing honestly: what it does, screenshots from the real app, working support contacts, a privacy policy.
- Run a security review: session handling, webhook verification, data isolation per store, secrets.
- Submit, respond to feedback quickly, and re-test the full path after every change.
After approval
Approval is the start of running a product: merchant support, monitoring across many stores, API version updates on the platform’s schedule, re-review after significant changes, privacy requests handled on time, billing reconciled, and a roadmap driven by merchant feedback. An app that passes review and is then neglected fails silently as APIs move on, and merchants uninstall. The business case for a public app includes years of that work.
What this means for you
Building a public app means building a multi-tenant product on the platform’s framework with your own hosting, billing through the platform, the mandatory privacy webhooks done properly, minimal storefront impact and an honest listing, then passing a review that installs and uses it like a merchant would. Test the reviewer’s full path on a clean store before every submission, and budget for the years of support and updates that follow approval. Done that way, the app is a business; done as a project, it is a listing that stops working.
Frequently asked questions
How is building a public app different from a private one?
A private app serves one store you control. A public app serves any store that installs it: it must be multi-tenant, handle installs and uninstalls cleanly, bill through Shopify, respond to the mandatory privacy webhooks, support merchants, keep a listing accurate, and pass review before and after changes. It is a product business, not a project.
What does the review process actually look at?
That the app installs and works as the listing says, that authentication and billing follow Shopify's rules, that the mandatory customer and shop data webhooks are implemented, that the app is secure and does not harm storefront performance, that the listing is accurate and complete with working support contacts, and that any theme or checkout extensions behave. Reviewers install and use the app; anything broken in that path is a rejection.
How long does review take and what causes delays?
Days to weeks per round, and each rejection adds a round. Delays come from install flows that fail on a fresh store, privacy webhooks that return errors, billing that does not match the listing, screenshots that do not match the app, and performance issues on the storefront. Testing the exact reviewer path on a clean development store before submitting removes most rounds.
Sources
- Shopify developer documentation: Best practices for apps in the Shopify App Store (accessed 2026-09-14)