What a Shopify custom app actually is
Not a smaller public app, and no longer the thing called a private app. What custom distribution gives you, what it costs you, and the two limits people find out about late.
GuideAugust 6, 20264 min read
A custom app is a Shopify app that is distributed to one merchant instead of to the App Store. That is the entire definition, and almost every practical difference falls out of it.
It is worth being precise, because the vocabulary here changed and a lot of writing did not. Shopify's distribution documentation lists two options for a new app: public, installed across many stores after App Store review, and custom, installed on a single store — or on multiple stores within a Plus organization — with no approval step. There is no third option any more. Private apps were deprecated in January 2022, and on 20 January 2023 every private app that still existed was automatically migrated and converted to a custom app. If someone is offering to build you a private app today, they are describing something Shopify removed three years ago.
What custom distribution actually changes
The obvious answer is "no review", and that is real — no listing, no screenshots, no rejection cycle. But three quieter differences matter more once the app is live.
It is yours. A public app has to work for every store that installs it, which means every assumption has to be configurable and every edge case handled generically. A custom app can assume your catalog, your fulfilment rules, your ERP's peculiar CSV. Most of the cost of app development is generality, and custom distribution lets you not pay for it.
Nobody else's roadmap governs it. The most common reason merchants outgrow an App Store app is not that it lacks a feature — it is that the feature they need is on somebody else's backlog, behind other people's priorities, forever. A custom app moves that decision inside your organization.
Distribution is a link, not a listing. You install it from a URL generated in the Partner Dashboard. That is convenient and it is also the first constraint people run into.
Scroll the figure sideways to see all of it
The two limits people find out about late
One store, unless you are on Plus. A custom app installs on a single store. If you are on Plus, it can install across stores in the same organization. If you run three separate storefronts on standard Shopify — a common shape for a brand with regional stores — a custom app does not span them. You either build one per store, move to Plus, or accept that the app talks to each store through the API from outside rather than living inside all three.
No Billing API. Custom apps cannot charge through Shopify. For a merchant building their own tool that is irrelevant. For an agency or a vendor planning to sell the same app to several clients, it means invoicing them directly and, more importantly, it means the App Store's distribution and trust are not part of the deal. If you are building something to sell, you want public distribution, and you want to know that before you write the auth layer, not after.
What it does not change
This is where teams get caught. Custom does not mean informal.
OAuth still applies. Access scopes still apply, and asking for more than you need is still how you end up rewriting later. The mandatory compliance webhooks — customer data request, customer redact, shop redact — still apply, and Shopify still expects them to be implemented rather than acknowledged. API versioning still applies: versions are released quarterly and supported for a year, so an app nobody maintains will break on a schedule you can predict but not avoid.
The thing that is genuinely lighter is review. Everything else about building on the platform is the same work.
How to tell whether custom is the right shape
Three questions, in this order.
Who installs it? One merchant — yours — means custom. Many merchants you do not control means public, and that is a product, not a project.
Does it need to charge? Through Shopify billing, it must be public. Invoiced directly, custom is fine.
Does it need to be in the admin at all? This is the one people skip. A lot of what gets scoped as "a custom app" is really a scheduled integration that nobody needs to look at: a nightly inventory sync, a feed generator, an order router. That does not need an embedded interface or an install flow — it needs a service that talks to the Admin API and a place to see whether it ran. Building it as an app because "app" was the word in the brief adds an admin surface, an OAuth flow and an install step to something whose real requirement was a log.
When the answer to all three genuinely points at custom, it is an excellent shape: private, specific, and free of the review cycle. That is the work we do. When it does not, building the app anyway is the most expensive way to find out.