Kanora

But the longer I've worked on it, the more Kanora has become a deliberate technical project too: a chance to build a serious, long-lived Apple-platform app that touches the awkward corners of the stack, and to do it as a solo developer without cutting corners.

My background is iOS, so a big part of this is learning macOS properly. Not Catalyst. A real macOS target with its own constraints and expectations: windowing and menus, sandboxed file access, long-running imports, background work, and all the little details that make desktop apps feel solid. I went into this thinking “it's just SwiftUI”, but the moment you start doing things like CD ripping, file-based libraries, and system integrations, you quickly find out how different the Mac really is.

The app itself is intentionally complex in the way real apps are: large Core Data stores, metadata editing workflows, performance on big libraries, an audio pipeline with AVFoundation and AirPlay, and a UI that has to stay responsive while work happens in the background. It's the kind of project where architecture matters because you don't get to “rewrite it later” every time a new feature idea shows up.

Kanora is also where I'm pushing AI-assisted development to the limit. I use Claude Code, OpenAI Codex, and Cursor constantly, mostly to speed up the unglamorous parts of building a product: scaffolding screens, tightening types, refactoring subsystems, exploring APIs, and turning vague ideas into concrete plans. The useful work is rarely “write code for me” and more often “help me reason about trade-offs, surface edge cases, and move through iterations faster”.

The hard part is keeping it productive. With a project this size, token budgets and context limits are real constraints. So I've been building an AI-native workflow alongside the app: tighter module boundaries, better naming, focused prompts, reusable “skills”, and guardrails that keep changes small and reviewable. If a prompt needs the entire codebase to work, it's already too late. The goal is to get consistent, production-quality output without the feature-factory chaos.

Honestly, Kanora is only feasible for me because AI tooling exists in its current form. Not because it removes the need to think, but because it reduces the cost of doing the right thing: exploring alternatives, writing the first version of something boring, validating assumptions, and iterating toward a clean design. The end result I'm chasing is simple: a native music library tool that feels focused, fast, and maintainable. The process is the interesting part.