Privacy set the ship date.

Bloomberg reported on 26 July 2026 that Apple's smart glasses have slipped again, with a reveal now expected at WWDC in 2027 and a release late that year. The interesting part is not the slip. Hardware slips. The interesting part is the stated reason: privacy, described by Mark Gurman as priority number one for the teams building the thing, and the specific design options reportedly on the table because of it. Glasses with no camera at all. Glasses with a full camera system that can analyse what it sees but cannot record photos or video. Software that stops recording if somebody tampers with the indicator light.

Read that list again. Every item is a hardware or firmware decision. None of them is a settings toggle, a consent screen, or a paragraph in a policy document. That is the whole story, and it is one we recognise, because it is the argument we have on installation projects roughly once a quarter.

The camera is not the feature

Put a camera in a public space and you have made two products at once. One is the thing you meant to build, which counts people, tracks a gesture, reads a room, triggers a scene. The other is a surveillance device, whether you wanted that or not, because the sensor does not know the difference and neither does the person standing in front of it.

The temptation is to solve the second product with words. A sign on the wall. A line in the privacy notice. A promise that footage is deleted after thirty days. All of that is worth doing and none of it changes what the box is capable of at three in the morning when nobody is watching it. Capability is what people actually respond to, and they are right to.

"

If the hardware can record, the policy is a promise. If the hardware cannot record, the policy is a fact.

Sensing without recording

The pattern Apple is reportedly weighing is the one we would push for on almost any camera-bearing install: let the sensor see, do not let the system keep. Frames go into a processing step on the device, the step emits a number or an event, and the frame is gone before anything else in the stack could have written it down. A people counter emits a count. A gesture surface emits a gesture. Neither needs to emit a face.

• 01Process on the device. A frame that never leaves the enclosure cannot leak from a server you forgot you were paying for.
• 02Emit events, not images. Design the interface between the sensor and the rest of the system so that pictures are not a valid output.
• 03Make the indicator physical where you can. A light the software controls is a promise. A shutter, or no lens at all, is a guarantee.
• 04Write down what the box cannot do, not only what it will not do. That is the sentence a client can repeat to their legal team and to the public.

It costs something. On-device processing needs a part with enough headroom, which is a bill of materials conversation rather than a cloud subscription, and it makes some future feature harder because you deliberately threw away the data that feature would have wanted. That trade is the point. You are buying a system nobody has to be reassured about.

What we take from it

The delay is being read in some places as Apple being slow. We read it as a company finding out that the privacy model was load-bearing and could not be retrofitted once the industrial design was frozen. When the lens is in the frame and the storage is on the board, every remaining option is a policy, and policy is the weakest material you can build a product out of.

So the lesson is about sequence more than ethics. Decide what the hardware is physically able to capture at the same time you decide what it looks like, because that decision closes doors quietly and permanently. On our own work it means the privacy question belongs in the first sketch of an installation, next to power and mounting, not in the handover pack. It is a cheaper conversation in week one than in month twenty five, and unlike most of the constraints we design around, this one is being watched by everybody who walks past.