Canvas component libraries

What it does

A container for reusable canvas components that other apps import and then track as a dependency. When you publish a new version, makers of the consuming apps are notified in Studio and can choose to take it. It's the supported way to share components — the older "import components from one app to another" feature is retired.

Key facts

Saving is not publishing. Only published versions reach consuming apps, and a version note attached at save time is what the consuming maker sees when deciding whether to update.
Consuming apps get updates two ways: a notification on opening the app in Studio, or Check for updates from the ellipsis next to the search box in the insert component panel.
Each component has an Allow customization setting, on by default. When it's on, a consuming maker can select Edit component, which copies the component locally and severs the link to the library. When it's off, the only way to change it is in the library.
Creating a local copy doesn't affect instances already placed from the library — those stay linked. Only instances of the local copy are detached.
A library referenced by any canvas app can't be deleted. You have to remove the component from the app first.
Screens inside a library are for testing only. Component libraries don't display in Power Apps Mobile.
Sharing works like sharing a canvas app, except for libraries created inside a solution — those can't use the sharing UI, and you share them with a security group using Set-PowerAppRoleAssignment with the CanEdit permission level.
Code components aren't supported inside component libraries.
You can't import components from a library saved locally as a file. It saves, and then refuses to import.

When to use / skip

Worth it as soon as more than one app needs the same header, navigation pattern, filter panel or confirmation dialog — which on any estate of more than three apps is immediately. The overhead is small and the payoff is that a change to the house header is one change. Skip it for one-off components inside a single app, and skip it if nobody will own the library, because an unowned library that drifts behind the apps consuming it is worse than duplication: it looks like governance and isn't.

Configuration decisions

Whether components allow customisation, which decides between flexibility for app makers and consistency you can actually enforce.
One library per estate, or one per domain — fewer is easier to govern, more is easier to version independently.
Whether libraries live inside solutions, which changes how you share them and how they move between environments.
The version note convention, because it's the only thing a consuming maker reads before deciding whether to update.
Who owns the library and approves changes, since a change ripples to every consuming app maker as a prompt.

Gotchas

Updates are pull, not push. Publishing does nothing to a consuming app until its maker opens it in Studio and accepts. Apps drift, and there's no report showing which version each one is on.
Edit component in a consuming app quietly makes a local copy and breaks the link. It reads like "edit"; it means "fork".
If you import an app and a library into a fresh environment for the first time and the app isn't on the latest component version, it won't receive updates. Subsequent imports do prompt correctly, which makes this hard to reproduce and easy to trip over during a go-live.
Solution-based libraries can't be shared through the UI. People try, conclude it's broken, and share the wrong thing instead.
No code components inside libraries, which surprises anyone building a "component library" mentally combining both kinds.

Consultant notes

Set up the library in the first sprint, before there are apps to retrofit. Extracting shared components from four finished apps is a rebuild dressed up as refactoring.
Give it an owner with a name, not a team. Libraries need someone who publishes deliberately and writes the version note.
Turn customisation off for anything that carries brand or navigation consistency. Leave it on for utility components where a local tweak is reasonable.
Warn the client that consuming apps won't update themselves. If they expect "change once, everywhere updates", the honest answer is that someone has to open each app and republish it.

Worth revisiting if code components become supported in libraries, or if update distribution ever becomes push rather than pull.