Liquid Glass was always going to be mandatory. Plan for forced migrations.Liquid Glass was always going to be mandatory. Plan for forced migrations.

By spring it was clear the Liquid Glass deferral flags were on a timer, and Apple was actively promoting the design language with updated gallery material. Anyone hoping to sit the redesign out was, as AppleInsider put it plainly, holding out hope.

The specific design is less interesting than the pattern, because the pattern repeats every few years and the cost is entirely determined by decisions you made long before.

Forced migrations are a tax on hard-coding

When a platform changes its appearance, the bill arrives in proportion to how many places in your codebase asserted what things look like.

An app that uses system components with semantic colours absorbs a redesign nearly for free. An app that hard-coded a hex value to match the old navigation bar has to find every one of them, and the compiler will not help.

That last part is what makes these migrations expensive out of proportion to their difficulty. Nothing fails to build. Nothing throws. The app launches, and a designer opens it on a beta device and starts a list. Every defect has to be found by a person looking at a screen, which is the slowest and least reliable way to find anything.

What actually breaks

In our experience the damage clusters into a short list, and it is worth knowing it before you go looking.

• Colours chosen to match a system surface. The system surface moves; your colour does not, and the mismatch is obvious.
• Fixed heights and offsets that assume system chrome. A navigation bar that grows by four points pushes a hand-positioned element into the wrong place on every screen that used it.
• Custom reimplementations of system controls. A bespoke segmented control does not follow the platform; it stays exactly as it was, which is how it starts looking dated.
• Image assets with chrome baked in. A background image that includes a drawn tab bar cannot be updated by changing a token.
• Store screenshots. They are marketing, not code, so nobody puts them on the engineering list, and they are the first thing a prospective user sees.

Find out what it would cost before you have to

You do not need the beta to estimate this. The audit is mechanical and takes an afternoon on a codebase of normal size.

• Count literal colours. Search for hex strings and for any colour constructed from raw numeric components. A handful is fine; a hundred tells you the answer already.
• Count custom controls. Anything that reimplements a system component is a screen that will need design attention rather than a token change.
• List screens with hand-positioned layout. Fixed constants near system chrome are where offsets go wrong.
• Check the asset catalogue for anything that draws interface rather than content.

The number worth reporting is screens, not lines. Nobody can act on four hundred and twelve colour literals. Everybody can act on knowing that eleven screens need a designer and the other forty do not.

The three habits that make it cheap

• Semantic colours over literal ones. `separator` survives a redesign; `#C6C6C8` does not.
• System components unless there is a written reason not to. Custom controls are a permanent liability paid in every OS cycle.
• One token layer. If a colour appears in more than one file, a redesign is a search-and-replace across an unknown surface.

None of that is exotic. It is the same advice given for years, and forced migrations are the moment the interest comes due.

The written reason matters more than it sounds. A custom control built because the system one genuinely could not do the job is a considered cost. One built because somebody preferred the look of it is a cost nobody agreed to, discovered years later by whoever is holding the migration.

A compatibility flag is a loan, not a fix

When a platform ships a redesign it usually ships a way to opt out for a release or two. Taking it is often the right call. Treating it as a decision rather than a default is what separates the teams who pay this once from the teams who pay it with interest.

The hidden cost is not the deferral itself. It is that nobody on the team ever sees the new appearance, so the work stays invisible until the release where it becomes mandatory and urgent at the same time. Meanwhile every screen built during the deferral is designed against the old look, which quietly adds to the bill.

The cheap counter is a branch with the flag turned off, run once a month on the current beta. Nobody ships it. Somebody looks at it, and the list stops being a surprise.

Sizing the work

Once you can see the new appearance, triage every screen into three buckets. The proportions vary, but the shape is consistent.

• Absorbs it. Built from system components, uses semantic colours, needs nothing. Usually most of the app.
• Needs adjustment. Spacing, a contrast problem, an offset that no longer lands. Hours, not days, and an engineer can do it alone.
• Needs a designer. Custom interface that now looks foreign next to everything around it. This is the bucket that decides the estimate.

Estimate the third bucket properly and add the first two as a flat allowance. Estimating screen by screen across an entire app produces a large number assembled from forty small guesses, and it is usually wrong in both directions at once.

Budget for it explicitly

For any app under long-term maintenance we now put a line in the annual plan for platform adaptation. Not a specific feature - just capacity, reserved, on the assumption that something will change.

Maintenance plans that assume nothing will change are not plans.

Clients accept this readily when it is framed honestly at the start. They accept it far less readily when it appears as an unplanned invoice in September.

The framing that works is ownership rather than insurance. An app on a platform you do not control has an annual cost of staying current, in the same way a building has an annual cost of staying weatherproof. A client who has understood that once does not need to be persuaded again each year, and the conversation moves to how much rather than whether.

If the reserved capacity goes unused, it becomes feature work. That has never been a difficult conversation.