That's super cool, congrats on releasing it ! It's a feature that some people periodically ask me to add in Aerial, but I never got to it. Piping from yt-dlp to AVFoundation is definitely the way to go.
I was gonna warn you about a bug in macOS 15+ where your screensaver stays around after you go back to the desktop, but for some reason your code seems to avoid that issue. I'm not quite sure how, as you don't hook stopAnimation or any event apart from the deinit. But it works, so, massive kudos, I'll have to try and understand why !
So fyi, the way you hook it there is what makes the preview flicker in System Settings.
You check if the screen is locked, and if not, kill the host. But screen is not locked in System Settings. So basically, you're killing the host process every 2 seconds (and macOS, at least in Tahoe, restarts it, it doesn't in previous macOS versions).
That's also what causes your issues with "Options" not working (because you killed the instance that was linked to that button). The way we workaround it usually is to hook a system event.
Ha, you do the exit trick too then, I just missed it.
FYI that works 99% of the time, but for some people it sometimes crashes (because we exit our host container - legacyScreenSaver.appex - and sometimes if you do it at a wrong time things just hang).
> Disclaimer: This project was entirely vibe-coded. I've never written Swift before in my life
Something I've wondered - but not had much empirical evidence for - is if entirely vibe-coded projects are difficult to maintain. I, too, don't know swift so I cannot look over the codebase to gauge this. I am curious if any swift savants out there can weigh in.
Furthermore, I will follow the project and keep an eye out for patches/discussions and try to discern any friction and/or loss in momentum because it is difficult to work with (e.g. more bug/feature tickets than PRs, etc.). I am aware it might fizzle out on its own, irrespective of the quality of the codebase. This will be a curious exercise for me. This may be my first empirical data on this topic - sadly on vibe-coded & maintainability, not the project itself.
I think they're just as maintainable as any other legacy app you might encounter. As in, it can be hard. But it's doable. And it depends on the team that made it (AI + the human).
> is if entirely vibe-coded projects are difficult to maintain
Vibe coding is too “Hail Mary” to me, but if you’re into it, I would think the best way to do that is by giving a LLM the git history of the project with each commit contain the prompt that created it and, if a human tweaked things, requiring that human to provide a good commit comment.
Then, you could give a LLM the git repo, instructions on what change you want to see, and have it create the next commit.
> requiring that human to provide a good commit comment.
Is this enough? Personally, I have a what very well may be a bad habit of mine that doesn't necessarily check git commit messages. When I'm working in a code base, I just never think about scrolling through those hoping to find where this bit of code was changed. I'd much rather have comments in the code itself. It seems better to me to save the maintainer time and effort. Maybe I've just taken too seriously the idea of "assume the maintainer after you will be a serial killer that knows where you live. don't make them angry by being lazy"
I've had success vibe-coding things that, I would imagine, make up more of the training dataset - more common. When I try to do more specific Linux systems programming it is pretty trash, especially with newer languages.
Interesting approach using AVFoundation for the video playback. I've worked with streaming video on macOS and found that AVPlayer can be quite memory-hungry when handling multiple streams. Have you considered using VLCKit instead? In our testing, VLCKit used about 40% less memory and handled network interruptions more gracefully.
One potential enhancement would be to add support for adaptive bitrate streaming (HLS/DASH). Most live streams nowadays offer multiple quality levels, and automatically switching based on available bandwidth/CPU makes a big difference in reliability. The AVPlayerItem.preferredPeakBitRate property gives you basic control, but implementing a full ABR solution with VLCKit gives much finer-grained control over quality transitions.
Also curious about your strategy for handling screen sleep/wake cycles. We found that AVPlayer instances sometimes get stuck in a bad state after sleep, requiring a full teardown and reinit. Using notification observers for NSWorkspaceDidWakeNotification helped catch and recover from these cases.
idk if any of y'all ever used https://satelliteeyes.tomtaylor.co.uk/ but I was a big fan. such that i now have my own process of keeping my wallpaper updated w/ various city webcams. throw in some noise/desaturation and you've got an _aesthetic_
anyway, this is about a screensaver not a wallpaper and i think there is cool potential with video streams as screensavers
AVFoundation is pretty cool. You can whip out a simple audio/video player in a couple dozen lines of code. It was one of my first macOS apps/prototypes.
It will probably go the opposite way though in the future. People will list when AI wasn't used in the loop, like how "sent from my iphone" was both a status signal and a request for leniency when it comes to spellcheck.
It's still a habit of mine. I have 2 external monitors on my desk connected to my laptop. One of them is a bit older LCD, but still functions well for purpose. It has a fun little quirk where when it first turns on there are a few vertical lines of a solid color until it has "warmed up" and the lines disappear after a few minutes. By using a screen saver when I get up and lock the screen, I don't have to wait for that screen to warm back up. At night, it does eventually turn off the screen saver after my timeout, but at least it's not every time I return to the desk.
Also, from a time long ago in a galaxy far away where we had production CRTs that were color calibrated, we would not turn them off either. They had a saver mode as well by running a not quite black signal to them, but not enough to burn in phosphors. It was even meant to "even" out some of them.
So because I'm that old that has used CRTs for such a long part of my life, screen savers will always be just part of the routine.
As much as I disliked open plan offices, I did enjoy trolling my coworkers with fake blue screen of death and kernel panic screensavers. Windows 95 "Pipes" also got a lot of nostalgic shoutouts when I used that for a while.
nothing because that is a screen saver. but yeah you're right, it's probably mostly people who just want to see a visualization? i'd never argue screensavers are a logical choice lol
I was gonna warn you about a bug in macOS 15+ where your screensaver stays around after you go back to the desktop, but for some reason your code seems to avoid that issue. I'm not quite sure how, as you don't hook stopAnimation or any event apart from the deinit. But it works, so, massive kudos, I'll have to try and understand why !
look at the animateoneframe function, there's the workaround
You check if the screen is locked, and if not, kill the host. But screen is not locked in System Settings. So basically, you're killing the host process every 2 seconds (and macOS, at least in Tahoe, restarts it, it doesn't in previous macOS versions).
That's also what causes your issues with "Options" not working (because you killed the instance that was linked to that button). The way we workaround it usually is to hook a system event.
You can check https://github.com/AerialScreensaver/ScreenSaverMinimal
Look for handleWillStopNotification and com.apple.screensaver.willstop
FYI that works 99% of the time, but for some people it sometimes crashes (because we exit our host container - legacyScreenSaver.appex - and sometimes if you do it at a wrong time things just hang).
Something I've wondered - but not had much empirical evidence for - is if entirely vibe-coded projects are difficult to maintain. I, too, don't know swift so I cannot look over the codebase to gauge this. I am curious if any swift savants out there can weigh in.
Furthermore, I will follow the project and keep an eye out for patches/discussions and try to discern any friction and/or loss in momentum because it is difficult to work with (e.g. more bug/feature tickets than PRs, etc.). I am aware it might fizzle out on its own, irrespective of the quality of the codebase. This will be a curious exercise for me. This may be my first empirical data on this topic - sadly on vibe-coded & maintainability, not the project itself.
However this project is so simple it's more akin to a script. Really not that hard to grasp despite not knowing swift.
Also vibe coded an android tv version and used this codebase as input ;)
https://github.com/hauxir/androidtv-live-screensaver
Vibe coding is too “Hail Mary” to me, but if you’re into it, I would think the best way to do that is by giving a LLM the git history of the project with each commit contain the prompt that created it and, if a human tweaked things, requiring that human to provide a good commit comment.
Then, you could give a LLM the git repo, instructions on what change you want to see, and have it create the next commit.
Is this enough? Personally, I have a what very well may be a bad habit of mine that doesn't necessarily check git commit messages. When I'm working in a code base, I just never think about scrolling through those hoping to find where this bit of code was changed. I'd much rather have comments in the code itself. It seems better to me to save the maintainer time and effort. Maybe I've just taken too seriously the idea of "assume the maintainer after you will be a serial killer that knows where you live. don't make them angry by being lazy"
https://simonwillison.net/2025/Oct/7/vibe-engineering/
for me it's working on a thing, and then linting, type checking, running tests. and even then thoughtfulness still required
My supposition is that the better documented a language, the easier it would be for the LLMs.
Or is it the opposite: The more obtuse a language, the more StackOverflow questions, the easier it is for LLMs to work with.
One potential enhancement would be to add support for adaptive bitrate streaming (HLS/DASH). Most live streams nowadays offer multiple quality levels, and automatically switching based on available bandwidth/CPU makes a big difference in reliability. The AVPlayerItem.preferredPeakBitRate property gives you basic control, but implementing a full ABR solution with VLCKit gives much finer-grained control over quality transitions.
Also curious about your strategy for handling screen sleep/wake cycles. We found that AVPlayer instances sometimes get stuck in a bad state after sleep, requiring a full teardown and reinit. Using notification observers for NSWorkspaceDidWakeNotification helped catch and recover from these cases.
Excellent, advertising-free live streams to choose from here:
https://www.youtube.com/@MontereyBayAquarium/streams
I often turn on the kelp forest (sound muted) as a pleasing backdrop on my living room TV, but they're all pretty neat.
- https://www.youtube.com/watch?v=V8mIPhfrMug
- https://www.youtube.com/watch?v=PnpcdnZhztI
idk if any of y'all ever used https://satelliteeyes.tomtaylor.co.uk/ but I was a big fan. such that i now have my own process of keeping my wallpaper updated w/ various city webcams. throw in some noise/desaturation and you've got an _aesthetic_
anyway, this is about a screensaver not a wallpaper and i think there is cool potential with video streams as screensavers
Also, from a time long ago in a galaxy far away where we had production CRTs that were color calibrated, we would not turn them off either. They had a saver mode as well by running a not quite black signal to them, but not enough to burn in phosphors. It was even meant to "even" out some of them.
So because I'm that old that has used CRTs for such a long part of my life, screen savers will always be just part of the routine.