When publishing a mobile app, one term often appears late in the process — sometimes too late:
Publisher-of-Record (PoR).
It sounds administrative, but in reality, it defines who is legally, financially, and operationally responsible for the app.
Misunderstanding this concept has caused many startups unnecessary friction, delays, and even account shutdowns.
This article explains what Publisher-of-Record really means — and why it matters more than most founders expect.
What Is “Publisher-of-Record”?
The Publisher-of-Record is the entity officially responsible for an app in the eyes of platforms like Apple and Google.
That entity:
-
Owns the developer account
-
Appears as the publisher name in app stores
-
Is responsible for compliance, payments, taxes, and legal obligations
-
Bears responsibility for policy violations or disputes
In short:
The Publisher-of-Record is the party the platform holds accountable — not your developers, not your agency, not your hosting provider.
Why App Stores Care About Publisher-of-Record
App stores operate at global scale.
They need a single, clearly identifiable party to hold responsible for:
-
User data handling
-
Privacy compliance
-
Payments and subscriptions
-
Refunds and chargebacks
-
Legal complaints
-
Policy violations
If something goes wrong, the platform does not investigate internal arrangements.
It contacts — or penalizes — the Publisher-of-Record.
Common Misunderstandings
❌ “Our development agency is the publisher”
This is one of the most common and risky assumptions.
If an agency publishes the app under their account:
-
They legally control the app listing
-
They control updates and certificates
-
They receive platform communications
-
They may control monetization setup
Recovering ownership later can be painful and time-consuming.
❌ “We’ll fix it after launch”
Changing Publisher-of-Record after launch is not trivial.
It may require:
-
App transfer approvals
-
New legal documentation
-
User impact considerations
-
Temporary removal from stores in edge cases
Planning it correctly from day one is far easier.
Who Should Be the Publisher-of-Record?
In most cases, the Publisher-of-Record should be:
-
The company that owns the product
-
The legal entity behind the brand
-
The entity responsible for revenue and compliance
For example:
-
A startup → the startup company
-
A corporate app → the corporation
-
A solo founder (early stage) → the founder personally (temporarily)
At Blue Ember Studios, we strongly recommend that clients own their own developer accounts, even when we manage publishing on their behalf.
Publisher-of-Record vs Developer vs Owner
These roles are often confused:
| Role | Responsibility |
|---|---|
| Publisher-of-Record | Legal & platform responsibility |
| Developer | Builds and maintains the app |
| Product Owner | Defines vision and roadmap |
One entity can play multiple roles — but they are not automatically the same.
Financial & Tax Implications
The Publisher-of-Record:
-
Receives app store payouts
-
Is responsible for platform fees
-
May be subject to VAT, sales tax, or withholding tax
-
Must handle refund and subscription disputes
This has real accounting and compliance consequences.
Choosing the wrong Publisher-of-Record can complicate:
-
Revenue reporting
-
Tax filings
-
Investor due diligence
What Happens If You Get It Wrong?
Potential consequences include:
-
Loss of control over the app listing
-
Delays in updates or hotfixes
-
App store account disputes
-
Legal ambiguity over ownership
-
Forced migrations under pressure
These issues rarely appear immediately — but when they do, they’re disruptive.
Best Practices (Simple & Safe)
-
Decide Publisher-of-Record early
-
Create developer accounts under your own entity
-
Grant agencies access, not ownership
-
Document roles clearly in contracts
-
Treat publishing as a legal decision, not a technical one
Final Thought
Publisher-of-Record is not a technical checkbox.
It’s a governance decision.
Understanding it early protects:
-
Your product
-
Your revenue
-
Your users
-
Your future flexibility
In app development, clarity of ownership is just as important as clarity of code.

