Shopify App 的三种形态：公开分发、自定义分发与已停建的后台自建
“这是一个自己用的 App”并不能说明它是哪种形态。决定权限、认证方式、能否收费和以后能不能改的，是分发方式（distribution），不是开发者自己的用途描述。当前仍可新建的分发方式只有两种，第三种是已经停止新建的遗留形态。
三种形态的对照
| 公开分发 Public | 自定义分发 Custom | 后台自建（遗留） | |
|---|---|---|---|
| 是否还能新建 | 是 | 是 | 否 |
| 创建者 | 开发者，需通过审核 | 开发者或商家 | 商家在自己后台创建 |
| 安装范围 | 多家店铺 | 单店、同一 Plus 组织内的多店，或禁止转让的开发店 | 仅创建它的那家店 |
| 认证方式 | 嵌入用 token exchange，非嵌入用授权码流 | 同左 | 预先生成的 Admin API access token，不走 OAuth |
| 能否嵌入后台 | 可以 | 可以 | 不可以 |
| Billing API | 可用 | 不可用 | 不可用 |
来源：App distribution。自定义分发不能通过 Shopify 的计费系统向商家收费；需要走 Shopify 收款的商业应用只能选公开分发。
后台自建已经是历史形态
后台自建指商家在 Shopify 后台 Apps and sales channels → Develop apps 里直接建应用、直接复制一个长期有效的 Admin API access token，不经过 OAuth，也不嵌入后台。官方已将其标为遗留形态：Generate access tokens for admin-created custom apps 明确说明不能再新建这类应用，已存在的不受影响；帮助中心把界线定在 2026 年 1 月 1 日之前创建的应用仍可在后台管理，见About apps。
因此“商家自建的 App 就是在后台拿 token 的那种”属于过时认知。商家今天自建应用，走的是 Dev Dashboard，产出的是标准的自定义分发应用：配置文件里有 embedded、[access_scopes]、[auth]，认证仍是 token exchange 或授权码流。判断一个应用属于哪种形态，看它的配置与认证路径，不看是谁点的“创建”。
商家创建 ≠ 商家拥有开发权限
自定义分发应用属于创建它的那个组织。商家在自己的 Dev Dashboard 组织里建应用后，开发者要用属于该组织的账号操作；用组织外的账号执行 CLI 命令会因为不是该组织成员而被拒绝（实测记录，非官方文档条款）。接手这类项目时，先确认三件事：应用属于哪个组织、自己的账号是否在该组织内、应用绑定的是哪家店。
分发方式选定后不可更改
App distribution 声明分发方式一经选定不能更改。这意味着“先按自定义分发做，以后上架应用商店”不是一条可走的路径——需要改形态时只能另建应用并重新走安装与授权。选型时先回答：这个应用会不会装到第二家店？会不会通过 Shopify 向商家收费？两个问题任一为“会”，就不应选自定义分发。
一个必须处理的配置后果
商家只创建一个应用时，开发与生产共用同一个应用身份，而 application_url 在同一时刻只能有一个值。此时 automatically_update_urls_on_dev 必须设为 false，否则每次 shopify app dev 都会把商家实际看到的应用地址改写成开发者本机的隧道地址。官方对该字段的说明是：为 false 时 URL 不会在 dev 时被更新，并把这一取值列为生产应用的推荐值，见App configuration。
如果确实需要开发环境与生产环境互不干扰，正确做法是准备两套应用身份与两份配置，而不是依赖自动改写 URL。