Sketch Library updates silently dropping symbol overrides — which structures survive?

Short answer: overrides survive a library update when the overridden layer still exists with the same internal identity inside the updated symbol. They are dropped when the layer they target was deleted, replaced, or restructured — even if a new layer has the same name. There is no built-in impact preview, and rollback is only practical at the file level. Everything below reflects general Sketch behavior, not a documented guarantee; the matching mechanics are internal and have shifted between releases, so verify on your exact version before trusting this in production.

1. Which structural changes drop overrides

Sketch does not match overrides by layer name or position. Each overridden layer in a document instance is tied to a layer identity inside the library symbol. On update, Sketch tries to re-resolve those identities against the new symbol definition:

• Renaming a layer: typically safe. Identity is not name-based, so a rename alone usually keeps overrides.
• Adding layers: safe. Existing overrides point at other layers that are untouched.
• Reordering layers: safe, for the same reason — position is not the match key.
• Deleting and recreating a layer with the same name: drops overrides. The recreated layer is a new identity; the override's target no longer exists.
• Re-parenting or moving a layer into/out of a group: risky. If the layer's path within the symbol changes, the override may fail to re-resolve. Treat this as dropped until tested.
• Nested symbol swaps inside the library symbol: the riskiest change. Overrides applied to a nested instance (its text, colors, or further nested swaps) are lost if that nested instance is removed and replaced rather than edited in place.

The practical rule for library authors: edit layers in place, never delete-and-recreate, and never replace a nested symbol instance when you can swap it via an override-compatible mechanism instead.

2. Is preservation deterministic per version?

Within a single Sketch build, the behavior is deterministic — the same document plus the same library update produces the same override outcome every time. What is not guaranteed is that the matching rules stay identical across Sketch versions, because the identity mechanism is an undocumented implementation detail. So "deterministic per version" is the right mental model: pin the version, verify, then roll out.

A verification protocol that takes under an hour:

1. Build a canary document containing instances of your most-overridden symbols: text overrides, color/fill overrides, image overrides, and nested symbol swaps.
2. Apply the candidate library update to a copy of that document on the exact Sketch build your team runs.
3. Diff which overrides persisted. Repeat with each structural change isolated (rename, add, reorder, delete/recreate, nested swap) so you know which library edits are safe, not just whether this update was.
4. Record the Sketch version alongside the results; rerun the canary after any Sketch upgrade before the next library release.

3. Preview and rollback

There is no supported preview of override impact. The update dialog lists changed components but does not show which document overrides will reset. Your realistic options:

• File-level rollback: keep both the library and consuming documents under version control (git works with .sketch files, though diffs are opaque), or use Sketch Cloud document version history. If an update resets overrides, revert the document file.
• Staged rollout: update one pilot document first, inspect it, then push the library version to the team. This substitutes for a preview.
• Library-side discipline: since destructive edits are what cause data loss, enforce the "edit in place" rule in library review — it is cheaper than any rollback.

One missing detail that would change this advice: whether your documents live in Sketch Cloud or as local files. Cloud documents give you version history as a rollback path; local files need git or manual snapshots, which changes how you should stage the rollout.