Public, custom and private Shopify apps: only two of these exist
The three-way comparison is everywhere and one of the three was removed in 2022. What each name means now, and how to choose between the two that are left.
GuideAugust 7, 20264 min read
Search for how to build a Shopify app and you will find the same three-way comparison table repeated across dozens of sites: public, custom, private. It is a good table. It has been wrong since 2022.
Shopify's distribution documentation is unambiguous. Private apps were "deprecated as of January 2022", and "as of January 20, 2023, all private apps have been automatically migrated and converted to custom apps." There are two distributions for a new app: public and custom. The Shopify admin option that once existed is explicitly "no longer available for new apps."
The name survives anyway, for a reason worth naming: merchants who were told in 2020 that they had a private app were never told it had been renamed. So "we need a private app" still arrives in briefs, and it usually means one of two quite different things.
What people mean when they say private app
Sometimes they mean custom. One store, not on the App Store, built for us. That is a custom app and the word is just out of date. Easy.
Sometimes they mean an old integration that still works. A script somewhere authenticating with credentials generated years ago. Those were converted in 2023 and the app still exists in the Partner Dashboard, but nobody in the current team knows where it is, what scopes it holds, or who owns the account it belongs to. That is not a naming problem, it is an inventory problem, and it is worth resolving before it becomes an outage.
Both are common. Asking "which store is it installed on, and can you show me it in the admin?" separates them in about a minute.
Scroll the figure sideways to see all of it
The two that exist
Public
Installed by any merchant from the App Store, after review. You get Shopify's distribution and billing, and you accept its requirements: OAuth done to spec, the mandatory compliance webhooks implemented, performance thresholds, a listing that has to be maintained, and a review cycle between you and every release.
Choose it when the app is a product. If more than one merchant you do not control will install it, this is the only option that works, and the App Store is doing real work for you: discovery, trust, and getting paid.
Custom
Installed on one store through a link generated in the Partner Dashboard, or across stores within a Plus organization. No review, no listing, no Billing API.
Choose it when the app is infrastructure for one business. You skip the review cycle entirely and you can write code that assumes your catalog rather than every catalog, which is where most of the savings actually come from.
The three things that decide it
Most of the comparison tables list a dozen rows. In practice three decide the answer, and the rest follow.
Who installs it. Merchants you do not control means public. There is no way around this one.
Whether Shopify collects the money. The Billing API is public-only. If your commercial model is a monthly charge on the merchant's Shopify invoice, the distribution is decided for you.
How many stores. One store is custom. Several stores in a Plus organization is still custom. Several unrelated stores is public — or several custom apps, which is a decision that looks cheap once and expensive on the third store.
Everything else — build tooling, framework, hosting, whether it is embedded — is the same for both. The distribution choice does not determine the architecture nearly as much as people expect.
The version of this question that actually matters
The public-versus-custom decision is usually easy once those three questions are answered. The decision that is genuinely hard, and that this comparison distracts from, is whether to build an app at all.
An app is the right shape when something has to live inside the Shopify admin, or has to run at a moment Shopify controls, or has to be installed by someone who is not you. When none of those hold, the same requirement is often better served by an integration that talks to the Admin API on a schedule, or by a Function if the requirement is really about pricing or checkout logic.
We have written that decision up separately, because it is the one that decides whether the project is worth doing — and the distribution question, once you get there, takes about five minutes. If you already know it is an app, custom and public are both work we do.