LightBites didn’t start as LightBites. It started as an accident inside LightCraft.

I was poking at the LightCraft code with a mundane, selfish goal: my photos live in a folder directory on my NAS, and I wanted a server-side version that could take that directory and sync it across my devices as a single LightCraft library. No re-importing, no copying photos around, just the folders I already have, available everywhere, on a machine I own.

While I was in there, I also started testing whether LightCraft could be ported to my iPhone. That experiment never got finished. I stopped, stepped back, and decided to do something narrower instead: take the photo engine that powers LightCraft and build a native UI layer on top of it using Swift. That’s how LightBites was born.

So the two projects split along a clean line:

  • LightBites became its own app, a native SwiftUI app for iPhone, iPad, Mac and even Apple TV (coming soon), still sharing part of the same code for the photo engine.
  • The server-side app stayed inside the LightCraft project, where it belongs, since it’s the piece that hosts a library rather than the piece you hold in your hand.

You can see that split in the code. The LightBites repo holds only the app: the Swift package, the Xcode projects, the share extension, and a small Rust crate whose job is to expose a C ABI (lc_*) that the Swift code calls into. What the app builds against comes from the public LightCraft repo — the Rust core, the egui apps and the server all live there, MIT OR Apache-2.0. The app repo is checked out inside a clone of the public fork, at apps/lightbites-swift/, so the public workspace’s apps/* glob picks the crate up and the core’s profiles and patch entries keep working. For a long time it was literally apps/lightcraft-ios-swift in the LightCraft repo; it became its own repository on 2026-10-19 and kept that history.

The server side

The server is the part I set out to build first, and it’s still the part I use most. It runs as one binary (or a Docker image), and your devices share one library — photos, edits, albums — downloading previews and originals as needed, on a machine you own. Photo folders already on the server, like a NAS share, can be part of a user’s library and are read in place: never copied or moved, shown on every device in their folders. An admin page in the browser handles users and devices.

On top of that I’ve been building an admin web UI of my own, where you can control the users, CPU and memory usage, storage and storage quotas, and run different AI/ML models to power search. I’ve been running it for a few weeks and it works really well so far, barely any issues. Hopefully I’ll get an initial beta out within the next few days.

Why they’re separate

The honest reason is that they grew up solving different problems. LightBites is a product: a native interface over the photo engine, closed source, with its own App Store builds, TestFlight, tours and CI. The server is infrastructure: it stays in the public fork so anyone can run it, and the changes I’ve made for it are meant to go back to the LightCraft project. If they’re not accepted there, I’ll fork it and release it as my own open source project either way.

The engine is the common ancestor. Everything else — the Swift UI on one side, the sync server on the other — grew out of the same core, from the same original experiment of trying to get my NAS photo folder to behave like one library everywhere.