Both unmanaged and managed packages are container formats Salesforce uses to bundle metadata — Apex classes, objects, fields, flows, layouts — for distribution from one org to another. The differences matter because they change who owns the code after install, and whether the publisher can push updates later.
Side-by-side
| Unmanaged package | Managed package | |
|---|---|---|
| Source visibility | Fully open and editable in the target org | Locked — Apex is hidden, most components are read-only |
| Upgrades | One-shot install. New version = new package, components duplicated. | Publisher can push upgrades; subscribers stay on a version line. |
| Namespace | None (or your dev namespace, stripped on install) | Permanent namespace prefix (acme__MyObject__c) |
| Typical use | Sharing sample apps, internal org-to-org migration, open-source templates | AppExchange products, ISV distribution, paid apps |
| Governor limits | Counts against the subscriber org’s limits | Has its own separate limits pool (huge benefit for ISVs) |
| Listing on AppExchange | Allowed for free apps only | Required for paid apps and security-reviewed listings |
Why the choice matters
Once an unmanaged package is installed, the metadata is yours. You can rename fields, edit Apex, delete classes — the original developer has no ongoing control. That’s fine for one-time templates but disastrous for a product you want to support: every customer’s copy diverges, and there’s no single “the app” to patch.
A managed package is the inverse contract. The publisher owns the source forever, the subscriber org sees a sealed black box, and the publisher can ship new versions that flow into every subscriber org. This is the only practical way to run a commercial AppExchange product, which is why every paid listing has to be managed.
Second-generation packaging (2GP)
If you’re starting fresh in 2026, the modern answer is Second-Generation Packaging (sfdx force:package:* and now sf package). 2GP managed packages still produce a locked, namespaced artifact, but the source of truth is your Git repo rather than a “packaging org”. Most ISV teams have migrated away from 1GP because 2GP plays cleanly with CI/CD, branches, and version-controlled metadata.
What interviewers want to hear
Mention three things and you’ve shown depth:
- The ownership model — unmanaged is forked-on-install, managed is leased.
- Namespacing — managed packages get a prefix, which means subscribers can’t accidentally collide with
MyObject__c. - Upgrade story — managed packages can be patched and version-upgraded; unmanaged can’t.
Verified against: Metadata API Developer Guide — Package Versions, ISVforce Guide. Last reviewed 2026-05-17 for Spring ‘26 release.