Applications are not packages.Let me repeat.Applications are not packages.This is a common misconception due to the (too) often blurring of concepts and terminology. Packages and applications are different and distinct things, so it's important to understand what those words mean (to MSIX).Packages and Applications Are Different ThingsAn application is distributed via a package. That's not the same as being the package.A package is a unit of distribution and deployment. You can install a package, or update a package, or remove a package. You can't install half a package, or remove part of a package. A package that's broken or corrupted is said to 'lack package integrity' and cannot be installed or used until repaired (though it can be removed).What Is an Application?An application is more abstract.Windows knows about processes, threads, windows, files and other types of resources. But before MSIX, there was no 'application' construct that Windows could reason about.You may look at a system and see applications everywhere, but to the operating system there were simply collections of resources that may or may not be related.This is the classic "I know it when I see it" problem.So we solved it by creating a definition: concrete enough for the OS to understand and manage, yet flexible enough to encompass the wide variety of application architectures Windows developers have created over the years.In the simplest case, an application runs as 1 process. Thus, a process with process ID 123 is the application. The install-time definition and runtime manifestation are essentially in a 1:1 relationship.Another design uses multiple processes to implement a single application. If an application needs an out-of-process (OOP) WinRT server, there might be two processes at runtime: app.exe and winrtserver.exe.This model can scale to many processes. For example, modern web browsers typically have one process responsible for the UI and and a forest of additional processes handling rendering, networking and other work.Regardless of the number of processes involved, they have a common characteristic: a 1:N relationship between the application and its runtime processes.There's also the opposite design, where multiple applications run in a shared process1 - an N:1 application-to-process relationship.Windows never had a strict definition of what an application is, so the OS had no way to determine which resources belonged to an application or how they should be managed as a single unit.So we taught it.Application IdentityA packaged application has an identity: a logical construct that uniquely identifies a user-facing application regardless of its implementation details.Or if you prefer: Application identity uniquely identifies the collection of windows, processes, resources, and functionality that form a single user-facing program, regardless of how that program is implemented.For packaged applications, this identity is represented by ApplicationUserModelID (also known as 'AppUserModelId' or 'AUMID'). This string allows Windows to associate resources with a particular application.So how does Windows understand what an application is? An application is a collection of windows, processes and other resources tagged with the same ApplicationUserModelID.So what is an 'ApplicationUserModelID'? An 'ApplicationUserModelID' is an identifier used to tag the collection of windows, processes and other resources that make up an application.An application is a collection of resources with the same AUMID. Why are those resources part of an application? Because they share the same AUMID.A circular definition.But it did solve the "I know it when I see it" problem. Now we have a concrete definition software can understand and reason over.Which brings us back to the original point: packages and applications are different concepts.A package is a deployment artifact.An application is a user-facing construct identified by its AUMID.Packages distribute applications.2Applications are not packages.1 Adobe Flash games could run multiple applications in the same process. .NET Application domains were a similar concept: multiple applications sharing a single process.2 Packages don't necessarily contain applications. Framework and Resource packages cannot declare applications. Main and Optional packages can declare anywhere from zero to one hundred applications. But if you have a packaged application, it is defined and distributed by a package.