Package types and benefits

A package is a container that holds your application components, such as Custom Objects, Apex code, Apex Triggers, Visualforce pages, Lightning Components, and so on. This makes up your application. While there are other ways to move components between Salesforce orgs, a package provides a container that you can use for your entire application or to deliver optional features by leveraging so-called dependent packages.

There are two types of second-generation packages – managed and unlocked. Unlocked packages also result in the installation of components in another org; however, the metadata can be readily modified or even deleted by the administrator of that org. While they can be used for upgrades, changes made in an installation org will be overwritten. Given these attributes, they are not particularly ideal from a support perspective, which also makes managed packages more appropriate for ISVs distributing their application to multiple customers. Moreover, unless you use managed packages, the Apex code that you write is also visible for all to see, so your intellectual property is at risk unless you use managed packages.

The features and benefits of managed and unlocked packages

This book was inspired by building packaged applications for distribution on AppExchange, as an ISV developer. However, many of the practices and tips equally apply to building robust and scalable applications within a growing or enterprise-size organization using packages. Where aspects are applicable to one or the other types of development this will be called out.

Managed packages have the following features, which are ideal for distributing your application as an ISV. The org where your application package is installed is referred to as a subscriber org since users of this org subscribe to the services your application provides:

• Intellectual Property (IP) protection: Users in the subscriber org cannot see your Apex source code, although keep in mind code sent to the client when you use LWC, Visualforce pages, or Static Resources will be visible. If this is a concern for your JavaScript code, you may want to consider using a minify process to partially obscure such code.
• The naming scope: Your component names are unique to your package throughout the utilization of a namespace. This means that, even if you have object X in your application, and the subscriber has an object of the same name, they remain distinct. You will define a namespace later in this chapter.
• The governor scope: The code in your application executes within its own governor limit scope (such as DML and SOQL governors, which are subject to passing a Salesforce security review) and is not affected by other applications or code within the subscriber org. Note that some governors, such as the CPU time governor, are shared by the whole execution context (discussed in Chapter 4, Apex Execution and Separation of Concerns), regardless of the namespace.
• Feature management: Allows you to enable, disable, and track the use of features you create in your application.
• Analytics: Allows you to receive anonymous data from Salesforce relating to the use of components such as pages and objects in your application. You can use this information, for example, to monitor the adoption of new features you release.

There are other benefits to managed packages, but these are only accessible after becoming a Salesforce partner and completing the security review process; these benefits are described later in this chapter. Salesforce provides ISVforce Guide (otherwise known as the Packaging Guide), in which these topics are discussed in depth – bookmark it now! The ISVforce Guide can be found at https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/.

The following features are applicable to both unlocked and managed packages:

• Upgrades and versioning: Once subscribers have started using your application, creating data, making configurations, and so on, you will want to provide upgrades and patches with new versions of your application.
• Explicit Dependency Management: Second-generation packages offer a robust, explicit way to manage dependencies between packages.