When a B2B SaaS founder asks us "what is a managed package?", they almost always mean "what's the smallest thing I have to ship to be on AppExchange?" This guide answers that, plus the next five questions they ask within the first hour: 1GP or 2GP, namespaces, the build commands, the upgrade rules, and what the security review wizard actually does for your release cadence. Every number here is sourced from the Spring '26 ISVforce Guide v66.0 (last updated April 30, 2026) and the December 2025 State of AppExchange dataset.

Pro Tip

TL;DR: A Salesforce managed package is the deployable, versioned, namespaced bundle of metadata that an ISV distributes through AppExchange. As of Spring '26, Salesforce explicitly recommends 2GP (Second-Generation Packaging) for every new app: source-controlled, sf CLI driven, scratch-org based, multi-package per namespace. The full lifecycle covers creation (Dev Hub plus namespace plus scratch org plus sf package version create), upgrades (patch / minor / major plus push upgrades), and the Self-Review Wizard that auto-approves version updates in minutes after the first security review pass. The top cause of security review failure remains missing CRUD and Field-Level Security enforcement on Apex DML and SOQL. AppExchange now hosts 6,233 apps from 3,668 developers (December 2025), and 50.65% of listings still have zero customer reviews, which means quality and discoverability matter more than raw shipping.

A managed package is the deployable unit of distribution for software on the Salesforce Platform. It's a versioned, namespaced bundle of metadata (custom objects, fields, Apex classes, Lightning Web Components, flows, permission sets) that installs into a customer's Salesforce org as a single atomic install. Only managed packages can be listed on the AppExchange. Unmanaged packages exist but are for one-time distribution of open-source samples and never appear on AppExchange.

The "managed" in managed package means the ISV controls the upgrade path. The customer cannot modify the package's Apex or metadata directly. When the ISV ships version 1.4, every customer's org receives the same code. This is what makes AppExchange viable as a procurement channel: enterprise buyers trust that the install they audited today is the install they'll be running in 12 months.

Pro Tip

Citation capsule: Definition and packaging model from the Salesforce ISVforce Guide v66.0, Spring '26 (PDF, April 30, 2026). AppExchange app counts from the State of AppExchange 2026 dataset: 6,233 apps from 3,668 unique developers as of December 2025.

Use 2GP. Salesforce's Spring '26 guide is unambiguous: "use 2GP to create new apps." 1GP is the legacy packaging model. It still works, but Salesforce has steered all roadmap investment into 2GP since 2022.

Source: Salesforce, 1GP vs 2GP Comparison and the Second-Generation Managed Packaging Developer Guide v66.0.

A namespace is a 1 to 15 character globally unique prefix you register in a Developer Edition Namespace Org. Every custom object, field, Apex class, and metadata component in your managed package is prefixed with the namespace, preventing collisions with the customer's org or with other installed packages.

If your namespace is 'acme' and you create an object called 'Invoice', the customer sees it in their org as 'acme__Invoice__c'. Their existing Invoice object (if they have one) is untouched. Without the namespace prefix, your package would conflict with every org that already has an Invoice object.

Namespace rules to keep in mind:

• The namespace is permanent. You cannot rename it once linked to a Dev Hub.

• The namespace org is a free Developer Edition, not your Partner Business Org.

• In 2GP, multiple packages can share a namespace, and you can share Apex methods across packages with the @namespaceAccessible annotation.

• Picking the namespace is a marketing decision. Use your brand abbreviation. Customers will see it in every Setup screen and field-level reference.

The full 2GP creation flow, from zero to release version, in 11 steps.

1. Provision a Partner Business Org (PBO) from the Partner Community at partners.salesforce.com. Free with active partnership.

2. Enable Dev Hub in your PBO. Setup > Dev Hub > Enable.

3. Create a Namespace Org (a free Developer Edition), register your namespace, then link it to your Dev Hub.

4. Initialize the project: sf project generate -n acme-app, then set 'namespace': 'acme' in sfdx-project.json.

5. Create a scratch org: sf org create scratch -f config/project-scratch-def.json -a dev01

6. Build features in the scratch org and pull metadata: sf project retrieve start -o dev01

7. Create the package: sf package create -n AcmeApp -t Managed -r force-app -v devhub

8. Create a beta package version: sf package version create -p AcmeApp -k InstallKey -w 30 -c

9. Install the beta in a fresh scratch org using the 04t... Subscriber Package Version Id. Test every feature, every permission set, every flow.

10. Promote the beta to release: sf package version promote -p AcmeApp@1.0.0-1

11. Submit for AppExchange security review through the Partner Console. Pay the $999 fee for paid apps ($0 for free).

Pro Tip

Source: Commands and flow from the Salesforce 2GP Developer Guide.

Managed packages use a major.minor.patch.build version format. The rules of what you can change at each level are strict, because every customer's org runs the same version of your code.

By default, customers install upgrades when they want. ISVs can also push upgrades: send a specific version to selected subscriber orgs without subscriber action. Push upgrades are available for 2GP managed packages and are the right tool for security patches and bug fixes you cannot wait on customers to install.

If version 1.3 turned out to be broken, you don't have to live with it forever. Declare an ancestor in sfdx-project.json to skip 1.3 and ship 1.4 as if it descended directly from 1.2. Ancestry is a 2GP-only feature.

This is the most important workflow for any ISV planning a normal SaaS release cadence.

The AppExchange Security Review is brutal on first submission: 6 to 9 weeks of waiting plus the high probability of failure. But after that first pass, Salesforce introduced the Self-Review Wizard in March 2023 that auto-approves most version updates in minutes.

The implication: once you've cleared the first review, you can ship monthly like any normal SaaS product. The bottleneck moves from Salesforce back to your own engineering velocity. For a B2B SaaS founder, this is the unlock that makes AppExchange a real distribution channel and not a one-time export.

Pro Tip

Source: Salesforce, AppExchange Security Review Wizard.

Per the Salesforce Developers Blog (August 2023, still current), the top vulnerabilities are dominated by a small set of pattern mistakes. The ranking we see at Appnigma across customer security review reports:

For a deeper dive on each, see our 2026 security review guide and the security review checklist.

Three structural changes shape how managed packages work in 2026.

Pro Tip

Connected App mandate decision matrix: Does your managed package include a Connected App whose Consumer Key you control? Then PKCE + refresh token rotation + static IP allowlist required by May 11, 2026. Does your install guide instruct the customer to create their own Connected App in their org? Then the mandate does not apply to you. Source: Aquiva Labs, Connected App Security Mandate.

The traditional answer was no. You hired Apex engineers ($150,000+ per year, each) or contracted a PDO ($80,000 to $300,000 for the first listing). For a B2B SaaS company chasing an enterprise deal that requires AppExchange, that's brutal math.

In 2026, the answer is yes if your code is generated against Salesforce's secure coding standards from the start. Most security review failures come from a small set of pattern mistakes (the ones in the table above), and those are exactly the patterns an AI-native managed-package generator can enforce by default.

At Appnigma AI, every generated 2GP managed package includes:

• 'with sharing' declared on every Apex class touching user data

• WITH SECURITY_ENFORCED on every SOQL query, or Security.stripInaccessible when dynamic

• Bind variables in every dynamic query, no string concatenation

• Output encoding applied in Visualforce, template binding in LWC

• Named Credentials for every external endpoint, no hardcoded secrets

• Auto-generated package.xml, sfdx-project.json, namespace-prefixed metadata

• Solution Architecture Document scaffold pre-filled from the package metadata

• Test class generation targeting 75%+ coverage with positive, negative, bulk, and permission patterns

The output is 2GP by default. Companies shipping this way: Warmly, Hyperbound, Pylon, Avoma, UserEvidence, Aline, Alguna, Salesbricks, and Seam AI. None of them hired a Salesforce dev team.

Pro Tip

Generate a 2GP managed package in 60 seconds. Type a prompt. Get a namespaced, security-review-ready package with the right Apex patterns from the first build. Book a demo.

A managed package is the deployable unit of distribution for software on the Salesforce Platform. It is a versioned, namespaced bundle of metadata (objects, fields, Apex classes, Lightning Web Components, flows, permission sets) that installs into a customer's Salesforce org as a single atomic install. Only managed packages can be listed on the AppExchange.

1GP (First-Generation Packaging) is the legacy model where the package's metadata lives in a single packaging org. 2GP (Second-Generation Packaging) uses source control as the source of truth, scratch orgs for development, the sf CLI for automation, and supports multiple packages per namespace. Salesforce's Spring '26 guidance is explicit: use 2GP for every new app.

Provision a Partner Business Org, enable Dev Hub, register a namespace, initialize an sf project with that namespace, develop features in a scratch org, run sf package create followed by sf package version create to produce a beta, install the beta in a fresh test org, then sf package version promote to release. Finally submit for AppExchange security review through the Partner Console.

Managed packages use a major.minor.patch.build version format. Patches can only fix bugs. Minor and major versions can add features but must preserve backward compatibility. ISVs can push upgrades directly to subscriber orgs without subscriber action via push upgrades, available in 2GP. After your initial security review pass, version updates are auto-approved in minutes via the Self-Review Wizard.

Yes. AI-native generators like Appnigma produce 2GP managed packages with the secure coding patterns Salesforce requires (with sharing, CRUD/FLS enforcement, bind-variable SOQL, output encoding, Named Credentials) applied from generation time. The output is 2GP by default, namespaced, and includes auto-generated test classes targeting 75%+ coverage. Customers including Warmly, Hyperbound, Pylon, Avoma, and Salesbricks shipped managed packages without hiring Apex engineers.

A namespace is a 1 to 15 character globally unique prefix registered in a Developer Edition Namespace Org. Every custom object, field, Apex class, and metadata component in a managed package is prefixed with the namespace, preventing collisions with the customer's org or other installed packages.

Initial security review takes 6 to 9 weeks for a first-time submission, plus 1 to 2 days for pre-queue validation. Resubmissions after fixing findings take 2 to 3 weeks. After the initial pass, version updates are auto-approved in minutes through the Self-Review Wizard, unless the update adds new sensitive objects, new callouts, or significant architecture changes.

Three changes shape 2026 managed package work. First, Salesforce's Spring '26 ISVforce Guide v66.0 (April 30, 2026) explicitly recommends 2GP for every new app. Second, the Connected App and External Client App security mandate took effect May 11, 2026, requiring PKCE, refresh token rotation, and static IP allowlists for any ISV-owned Connected App distributed inside a managed package. Third, Chimera DAST was retired June 16, 2025, so partners must run OWASP ZAP, Burp Suite, or Qualys against the demo org.

This pillar is the build hub. The companion reads:

• The 2026 Salesforce ISV Partner Program guide. Tiers, costs, ISV vs OEM, and the path to becoming an ISV.

• How to list on Salesforce AppExchange (2026). The full 6-stage lifecycle, 12-month cost breakdown, and revenue share mechanics.

• The 2026 Salesforce security review guide. Fees, timeline, what they check, and the top 10 failure causes.

• The security review checklist. Line-by-line what reviewers look for.

• How to build a managed package without code. The no-code path Appnigma customers take.

• Salesforce Partner Business Org explained. Where you'll build everything.

• Salesforce ISVforce Guide v66.0 Spring '26 PDF (April 30, 2026)

• Second-Generation Managed Packaging Developer Guide v66.0

• Salesforce, 1GP vs 2GP Comparison

• Salesforce, Why Switch to 2GP

• Salesforce, Push a Package Upgrade for 2GP

• Salesforce, Patch Versions for 2GP

• Salesforce, AppExchange Security Review Wizard

• Salesforce Developers Blog, Top 20 Vulnerabilities in AppExchange Security Review

• State of AppExchange 2026 (sfapps.info)

• Aquiva Labs, Connected App Security Mandate (May 11, 2026)