2GP vs 1GP Managed Packages: What's the Difference?

If you're building an AppExchange app, you need to package it. Salesforce offers two ways to do that: first-generation (1GP) and second-generation (2GP). They both produce installable managed packages. The difference is how you build and maintain them.

Managed vs unmanaged

Before diving into 1GP vs 2GP, it helps to know the two main package types.

Managed packages are the standard for AppExchange. Your code is protected — customers can't see or modify it. You control upgrades and can deprecate components. You get a namespace for your org. This is what you use when you're distributing a product to many customers.

Unmanaged packages are more like open-source. You distribute metadata and code, but once installed, the customer owns it. They can edit it, delete it, or break it. No automatic upgrades. Unmanaged is useful for sharing templates, sample code, or internal tools that admins will customize. Unmanaged packages don't support 1GP or 2GP — they're a different distribution model.

The rest of this article is about managed packages and the two ways to build them.

What is a managed package?

A managed package bundles your Apex, Lightning components, custom objects, and configuration into a single unit you can list on AppExchange and install into customer orgs. The customer gets a working install; you keep your code protected and deliver updates through the platform. You need a namespace (reserved for your org) and a way to create versions. That's where 1GP and 2GP come in.

1GP: The packaging org model

1GP uses a packaging org — a dedicated Salesforce org where your package lives. You develop there, create versions through the UI, and that org is the source of truth. One namespace per package. Versioning is manual: you create a new managed-released version in Setup, and that's it. CI/CD is awkward because you're pushing changes into an org, not pulling from Git.

It works. Most of AppExchange was built this way. The tooling is mature and well-tested. If you're used to developing in the Salesforce UI, 1GP feels familiar. The downside is that it doesn't fit modern DevOps workflows — you can't easily version from branches, run tests in isolated environments, or integrate with automated pipelines.

2GP: The source-driven model

2GP uses a Dev Hub and Salesforce CLI. Your source of truth is Git. You create packages from the command line, version from any branch, and deploy to scratch orgs for testing. Multiple packages can share the same namespace, so you can decompose a large app into smaller modules. Dependencies between packages are explicit. CI/CD is straightforward — you're just running CLI commands in a pipeline.

2GP also enforces 75% code coverage when you create a version. Tests run in a clean scratch org, not a packaging org that's accumulated years of config. That means your tests actually validate the package in isolation.

The trade-off: 2GP requires a shift in workflow. You need to be comfortable with the CLI, version control, and scratch orgs. If your team is already doing Git-based development, it's a natural fit. If not, there's a learning curve.

The practical differences

Modularity. With 1GP, if you want to split your app into multiple packages, each needs its own namespace and packaging org. That's a lot of overhead. With 2GP, you can have several packages under one namespace — a core package plus optional modules, for example. Customers can install only what they need.

Versioning. 1GP lets you create versions sequentially from the packaging org. 2GP lets you create versions from any point in Git history. You can branch, release from different branches, and manage version ancestors — similar to semantic versioning in other ecosystems.

Testing. With 1GP, tests run in your packaging org. That org might have stale data, custom config, or accumulated cruft. With 2GP, each version is built in a fresh scratch org. If your tests pass, they're validating the package as it would actually install — not a pre-configured environment.

Migration from 1GP to 2GP

Until recently, moving from 1GP to 2GP was painful. Customers often had to reinstall. As of Summer '25, Salesforce released Package Migrations — a feature that automates the conversion and handles customer orgs without breaking them. If you're on 1GP and considering a move, it's now feasible.

Salesforce recommends 2GP for all new managed package development.

If you're evaluating apps, not building them

You can't usually tell from the AppExchange listing whether an app is 1GP or 2GP. Both install the same way. The packaging generation is an implementation detail.

That said, packaging can indirectly affect what you get. 2GP tends to support better CI/CD and testing, which *can* mean more frequent releases and fewer upgrade issues. But it's not a guarantee. A well-maintained 1GP app can be more reliable than a poorly maintained 2GP app. Many mature, stable apps on AppExchange are still 1GP. The packaging model is one factor among many — vendor track record, support quality, and feature fit matter more. If you're curious, you can sometimes infer from release notes or vendor documentation whether they've migrated, but it's rarely worth making a decision on packaging alone.