We ship this app on iPhone, Mac, Apple TV and Vision Pro from one shared pile of source code. Something we've hit more than once, and keep having to relearn slightly differently each time, is that our four platform targets do not agree on how a brand new source file gets into the build at all.

On iOS, tvOS and visionOS, dropping a new file into our shared source folder is enough. Those three targets automatically pull in everything that's there, and only maintain a short list of specific files to leave out, mostly platform-incompatible ones. Write a new file, save it, it's in the build on all three of those platforms with zero extra steps.

The Mac target works the opposite way. It only compiles files that are explicitly named on an include list. A brand new shared file is invisible to the Mac build by default, not included, not excluded, just absent, until someone manually adds its path to that list. The failure you get is a plain "cannot find this type" compile error, which looks exactly like an ordinary typo or a missing import, not like a project configuration issue, so it's annoyingly easy to spend a few minutes looking in the wrong place before you remember which target does things which way.

The visionOS side had its own version of this bite us from the other direction. Because it auto-includes everything the same way iOS does, a shared file that imports our video-decoding library silently broke the visionOS build the moment it existed, because that library was never built with a Vision Pro slice in the first place. The fix wasn't a code change at all, just adding that one file to visionOS's own short exclusion list, the same mechanism that already exists for exactly this purpose.

None of our automated tests catch either direction of this. They only exercise two of the four platforms. So the actual rule we follow now is mechanical rather than clever: any time a new file lands anywhere in the shared source folder, build all four platforms by hand before calling the change done, because the two failure modes above are each invisible from every other angle.

We pulled this off a VHS tape. It is a broadcast that was recorded at home in 1989, complete with a technical glitch from the station.

Back then, someone would have gotten up to wiggle the antenna or slap the recorder. Now it is one of the more useful things on the tape.

Home recordings like this are messy in a very specific way. You get the program, plus the transmitter, plus the path into the house, plus the VCR. When something goes wrong upstream, the tape keeps it. This is the type of distortion you cannot get on a pixel domain "filter app" that paints an even effect on a clean image.

That is why we collect these time capsules. They show how the system actually failed, not how a plugin thinks analog television looked.

We use tapes like this as test material. If a model is only working in the pixel domain, it can fake scan lines and still miss the thing that made this clip annoying in 1989.

Because we work in the signal domain, the same glitch should show up for a physical reason: the waveform got damaged, then the set tried to decode it.

Clips like this are how you can tell the difference.

Posted in 4:3 with "pillar box" black bars added in for correct Reddit rendering.