FredCam: A 3D Printer Camera Viewer for iOS - A Tutorial
Fred is our Bambu Lab P2S 3D printer, and we don’t like having to run Bambu Handy just to see the camera. How could we not throw Claude Code at the problem to get a tidy little app - and a programming lesson - both at the same time?
FredCam is a small iOS/iPadOS app that streams the printer’s camera over the local network. The interesting part is that the stream is RTSPS — RTSP over TLS — with a self-signed certificate, which turns out to be surprisingly hard to connect to with standard iOS tooling. AVPlayer won’t bypass certificate validation. One solution is KSPlayer, which wraps FFmpeg and exposes its tls_verify: 0 option.
Six Swift files, about 650 lines of code.
The tutorial
The interesting thing about building this wasn’t just making the stream work (KSplayer pretty much takes care of that) — it was everything around it: choosing the right dependency, understanding what you’re signing up for license-wise, bridging UIKit into SwiftUI, modeling app state cleanly. The app is small but dense with real-world decisions.
This was written up as a 10-section tutorial aimed at programmers who know how to code but haven’t spent much time in Swift or iOS.
The sections:
- Preface & Orientation — What FredCam is, what you'll learn, the six-file map
- The RTSPS Problem — RTSP, TLS, self-signed certs, and why standard players fail
- XcodeGen and Swift Package Manager — Code-first project definition, SPM dependency resolution
- KSPlayer — Dependencies and Licenses — GPL v3, FFmpeg's LGPL, what open-source licenses mean for your iOS app
- Data Model and Persistent Settings — ObservableObject, @Published, UserDefaults
- App State — The StreamState Machine — Enum-driven state machines, @StateObject, @Binding
- Bridging UIKit and SwiftUI — UIViewRepresentable, the Coordinator pattern, delegate callbacks
- Low-Latency Streaming Options — KSPlayer/FFmpeg avOptions, TCP transport, buffering tradeoffs
- Adaptive Layout, PiP, and System Permissions — verticalSizeClass, stable view identity, Picture-in-Picture, Info.plist
- Future Directions and License Considerations — Distribution concerns, alternatives to KSPlayer, what to fix before shipping
Section 3 on licenses ended up being one of the more interesting parts to write. Claude initially assumed KSPlayer was MIT-licensed — it’s not, it’s GPL v3, which is very different. (Bad Claude!) That’s a significant difference if you ever want to distribute the app, and it changes the analysis of what you’re committing to when you take the dependency. For personal use, no issue. For anything you want to ship to others, you have real choices to make.
How it was built
Built with Claude Code, same as the spectrum analyzer and Minecraft tutorial. The app came first — a focused session of asking questions, making decisions, and iterating. The tutorial came after, as a way of organizing and sharing what the process surfaced.
Why do this?
I’m making these tutorials - or, perhaps, I should say I’m having them made. Regardless, I’m reading them myself. Maybe I won’t be the only one learning something here, and hopefully I’m still learning a bit more than just how to craft prompts. I still want to believe these are tools for learning as much as for producing. Building is more fun when it’s a learning process, isn’t it?