Shopify App Development

Building a Shopify app is a different exercise from building a WordPress plugin or a one-off integration. Your code runs inside a merchant’s admin, wrapped in Shopify’s own interface chrome, authenticated through session tokens instead of cookies, and — if you want it listed publicly — reviewed against a checklist that fails apps for things as small as a slow install flow or a missing uninstall webhook. We’ve taken apps through that review enough times to know where submissions usually stall, and we build with that bar in mind from the first commit, not as a fire drill in week six.

Most of our work splits into two shapes. Public apps go through Shopify’s App Store: they need a working OAuth install flow, the compliance webhooks Shopify requires of every listed app (customers/data_request, customers/redact, shop/redact), and — if you’re charging for the app — the Billing API wired up correctly, whether that’s a flat recurring charge, usage-based billing tied to order volume, or a one-time charge for a setup service. Private and custom apps skip App Store review entirely and are built for one merchant, which means we can move faster and skip anything the review team would otherwise require. There’s no point building a full compliance webhook suite for an app only one store will ever install.

What’s in the build

For embedded apps — the ones that live inside the Shopify admin rather than opening in their own tab — we scaffold with the Shopify CLI and the Remix app template, which is what Shopify’s own tooling is built around now and what the CLI’s dev server, tunneling, and app configuration all expect. The interface is built in Polaris so it reads as part of the admin instead of a plugin bolted onto it, and App Bridge handles the embedding itself: session token auth, navigation, modals, and the resource picker that lets a merchant select products or orders without leaving your app’s context. Data access goes through the Admin GraphQL API — Shopify has been deprecating REST Admin endpoints in favor of GraphQL for a few years now, so any new app we build is GraphQL-first from day one rather than due for a rewrite the next time a REST resource gets sunset. Where an app needs to touch the storefront directly — custom product data, cart logic, a headless component — that’s the Storefront API instead, with its own token scheme and rate limits separate from the Admin API.

Webhooks carry the parts of the app that can’t wait for a merchant to open it: order creation, fulfillment updates, app/uninstalled so subscriptions and stored data get cleaned up on the way out, and the compliance webhooks mentioned above. We register these through the CLI’s app configuration file rather than clicking through the Partner Dashboard by hand, so the whole app — webhooks, scopes, extensions, billing plans — is defined in code and reproducible across dev, staging, and production instead of living in one person’s memory of what they clicked.

Standalone apps, which open in their own window rather than embedding in the admin, are simpler on the App Bridge and session-token front but still need the same OAuth and webhook handling underneath. We’ll tell you honestly which shape fits: embedded is the right default for anything a merchant should feel is part of their store’s daily workflow — inventory tools, order tagging, review widgets. Standalone makes more sense for something genuinely separate, like a reporting dashboard a merchant checks once a week.

Once the app works against a development store, we take it through App Store review ourselves: checking performance on a throttled connection, confirming the uninstall flow actually removes data, matching the listing copy to what the app does, and checking it against Shopify’s Built for Shopify criteria where an app qualifies. A mismatch between the listing and the actual app is one of the more common rejection reasons, and it’s an easy one to avoid if someone’s checking for it before submission rather than after a rejection email. After launch, Shopify ships a new API version every quarter — we keep the apps we build on a supported version rather than letting one run on a deprecated version until it breaks.

This is not the right service if what you actually need is checkout customization — Shopify Functions and Checkout UI extensions handle that without a full app wrapped around them — or if the workflow you’re automating lives entirely in the back office and never needs a merchant-facing screen, in which case a Shopify Flow recipe or an n8n automation against the Admin API costs less to build and maintain than an app does. That gets raised during scoping, before a proposal is written.