Category: Swift

My Digital Kingdom

I built an Apple TV app for a practical reason: I wanted to manage my home media setup from the couch. What it became was so much more.

my_digital_kingdom4

My “Digital Kingdom” is a collection of machines that each do one job well: the Apple TV is the control center, the Windows server manages media, and the Mac has become a shared AI appliance providing local Qwen, Whisper, and MCP services across my network.

At home I have three Apple TVs, a small always-on Windows mini PC that acts as a media server, and a Mac that handles local AI jobs. The more I used that setup, the more annoying it became to walk back to a computer just to search for something, move files around, attach subtitles, or check whether the server was running out of space.

BiffDownload started as a simple Apple TV front end for that media server. It has evolved into the keys to the “kingdom”: a Swift tvOS app, a Python API on Windows, a Python AI helper API on macOS, and a Linux machine that uses the Mac’s MCP and local AI services.

This is a follow-up to my earlier post, Local AI is Saving Me $, where I wrote about using local AI to process my personal photo and video archive. That post was mostly about cost and long-running AI jobs. This one is about the product layer around my home media setup: the Apple TV interface, the local APIs behind it, and the subtitle workflows that now run across machines on my LAN.

The Basic Idea

BiffDownload is not a replacement video player. I still use VLC on Apple TV for playback over DLNA/UPnP. BiffDownload is the control panel to manage the media.

From the Apple TV remote I can:

  • Search for media
  • Queue downloads to a chosen folder
  • Watch transfer progress
  • Browse and manage files on the server
  • Search for existing subtitles
  • Attach subtitles to videos
  • Generate new AI subtitles locally
  • Check server status and disk usage

The important part is that all of this happens from the TV. No remote desktop session. No laptop on the couch. No walking over to the media server for routine tasks.

Apple TV Demo

For the demo video, I used TPB AFK: The Pirate Bay Away From Keyboard (2013), a Creative Commons licensed documentary released by filmmaker Simon Klose. I chose it because it is legal to download and is widely available, making it good for demonstrating a download operation visually.

TPB AFK: The Pirate Bay Away From Keyboard (2013) Copyright Simon Klose | tpbafk.tv Licensed under CC BY-NC-ND 3.0

https://creativecommons.org/licenses/by-nc-nd/3.0

The Three Main Pieces

The system currently has three main services.

Apple TV App

The front end is a native tvOS app written in Swift. It is designed for the Apple TV remote, so the UI has to be clear from across the room and work well with focus navigation instead of a mouse or touch screen.

The app talks to the Windows API over the local network. It does not know how to run ffmpeg, talk to aria2, search OpenSubtitles, or mux subtitle tracks directly – those all happen on the Windows media server where the media library lives. It sends requests, polls job status, and presents the current stage to the user.

That separation made the app much easier to evolve. The Apple TV app can stay focused on workflow and feedback while the server handles the messy media operations.

Windows Media Server API

The Windows mini PC is the always-on machine. It runs the main Python API and owns the media library.

That API handles:

  • Search integration
  • Download queueing
  • File and folder operations
  • Transfer status
  • Disk information
  • Subtitle search through OpenSubtitles
  • Subtitle muxing
  • Audio extraction for AI transcription
  • Calling the Mac AI helper service

The API wraps these Windows command-line tools into simpler endpoints that the Apple TV app can use.

ProjectHomepage / DownloadPurpose
aria2https://aria2.org/High-performance command-line download manager supporting HTTP(S), FTP, SFTP, BitTorrent, and Metalink.
Prowlarrhttps://prowlarr.com/Indexer manager for Sonarr, Radarr, Lidarr, Readarr, and other *Arr applications.
Jacketthttps://github.com/Jackett/JackettTranslates searches from hundreds of torrent trackers into a standard Torznab API.
Subliminalhttps://subliminal.readthedocs.io/Python library and CLI for automatically finding and downloading subtitles from multiple providers.
FFmpeghttps://ffmpeg.org/Industry-standard multimedia toolkit for converting, transcoding, streaming, filtering, recording, and processing audio/video. Supports virtually every major media format.
MKVToolNixhttps://mkvtoolnix.download/Suite of tools for creating, inspecting, splitting, merging, editing, and modifying Matroska (MKV) files without re-encoding. Includes the popular mkvmerge and MKVToolNix GUI.

This is also where most of the orchestration happens. For example, when the Apple TV app asks for AI subtitles, the Windows API extracts the audio, sends it to the Mac API, receives the .srt, validates it, and then creates a new video copy with the subtitle track embedded.

Mac AI Helper API

The Mac runs a separate Python helper API for local AI work. For subtitles, it runs MLX Whisper on Apple Silicon. It also exposes local AI services backed by Qwen models, plus MCP services that Claude and Codex can use from other machines on my network.

The reason for splitting this out is simple: the Windows mini PC is great as an always-on file and download server, but the Mac is much better for local AI inference. Rather than force one machine to do everything, the Windows service sends the audio over the LAN and lets the Mac do the transcription work.

For a full-length movie, the Mac can usually generate subtitles in about 5 minutes—longer if the audio is in a non-English language and it triggers translation. That is fast enough for the way I use it, especially since the whole job can be started from the Apple TV and left alone.

The same Mac service layer is also useful outside the Apple TV workflow. Claude and Codex sessions running on other machines can reach back to the Mac for local model access, transcription tools, and MCP-backed utilities. That makes the Mac more like a shared AI appliance on the LAN than a single-purpose subtitle box. For example, my Linux machine can use MCP to keep repository documentation—such as README files—in sync with Obsidian notes stored in a vault on the Mac.

Two Subtitle Paths

Subtitles are one of the biggest reasons this project became useful. I have two different subtitle workflows now: a normal online subtitle search path and a local AI generation path.

OpenSubtitles Search

The first path uses the existing subtitle ecosystem. From the Apple TV app, I can select a video and search for matching subtitle files through the Windows API. The server uses subliminal to query OpenSubtitles, download a matching .srt, and then mux that subtitle into a new video copy.

That workflow is usually the best option when a good subtitle already exists. It is faster than AI transcription, and it avoids generating text that someone has already created and synced.

The Apple TV app treats this as a normal media-management task:

  1. Pick a video.
  2. Search for subtitles.
  3. Choose a result.
  4. Ask the server to attach it.
  5. Play the new copy in VLC.

This is the boring path—and that’s exactly why it matters. If OpenSubtitles has a good match, I do not need AI at all.

Local AI Subtitle Generation

The second path is for videos where I cannot find a good subtitle. That is where the Mac helper service comes in.

From the Apple TV, the AI workflow looks simple:

  1. Choose a video.
  2. Start AI subtitle generation.
  3. Watch the stages update.
  4. Review the result.
  5. Use the new subtitled copy.

Behind the scenes, the Windows API does a lot more:

  1. Probe the video with ffprobe.
  2. Extract a compact audio file with ffmpeg.
  3. Send the audio and source duration to the Mac API.
  4. Run MLX Whisper on the Mac.
  5. Receive the generated SRT file.
  6. Validate the subtitles.
  7. Mux the subtitle track into a new MKV copy.

The Apple TV app now shows the major stages in that pipeline:

  • Extracting audio
  • Uploading audio
  • Generating subtitles
  • Receiving subtitle file
  • Checking quality
  • Merging video

The result is that subtitle search and subtitle generation live side by side. The normal subtitle service is the first choice when it works. Local AI is the fallback when no good match exists.

Why the API Spec Became Important

One thing that made this project manageable was keeping API spec documents up to date.

The Windows API has a Markdown spec that describes the endpoints, request bodies, responses, job states, and examples. The Mac API has its own spec too, covering the local AI services, Whisper transcription endpoints, subtitle generation behavior, and the helper features used by other machines.

Those specs became the contracts between the Apple TV app, the Windows media server, and the Mac AI service. As I added features, I updated the specs and used them to keep the Swift app and both Python APIs aligned.

That mattered a lot because I was using AI coding tools across different parts of the system. Claude and Codex were used on macOS, Windows, and Linux to build it all. The Mac API also provides local Qwen-based AI services and MCP tools that Claude and Codex can use while running on other machines, so the documentation has to describe not just app endpoints, but also the shared AI services available on the network.

A Cool Agentic Coding Moment

One of the moments that really changed how I think about AI-assisted development happened while building this project.

From a single terminal window, Claude or Codex wasn’t just editing one codebase. It was coordinating work across my entire local development environment.

A single request could:

  • Modify the Python media server running on the Windows mini PC.
  • Update the Python AI helper API running on the MacBook Pro.
  • Add new Swift models, networking code, and UI to the Apple TV app.
  • Update the shared Markdown API specifications.
  • Build and test each component before moving on to the next.

From my perspective, I was still working in a single terminal window. Behind the scenes, the AI was making coordinated changes across three independent codebases running on different computers, communicating through well-defined APIs.

Tools In The Stack

The system uses a mix of regular media tools and local AI tools.

Apple TV

  • Swift
  • tvOS
  • Xcode

Windows Media Server

  • Python
  • aria2
  • Prowlarr
  • Jackett
  • subliminal
  • OpenSubtitles
  • ffmpeg
  • ffprobe
  • MKVToolNix / mkvmerge
  • PowerShell for service management

Mac AI Service

  • Python
  • MLX Whisper
  • Local Qwen AI services
  • MCP services for Claude and Codex
  • Apple Silicon
  • Local network API calls

Development

  • Claude
  • Codex
  • Markdown API specs
  • Generated HTML API test pages

Alien Barrage — Building an iOS Game with AI

Built with Swift, SpriteKit, and an AI-assisted workflow (Claude + Codex)

This week I released a new game on the App Store: Alien Barrage. The project took about three months to build and ultimately grew into a roughly 20,000-line Swift/SpriteKit game.

While AI tools played a major role in accelerating development, the project still required significant engineering work: planning systems, designing gameplay, testing, debugging, integrating platform services, managing the AI workflow, and continuously refining the experience based on iteration and feedback.

The game itself was inspired by the classic arcade shooters I grew up playing. I combined elements I enjoyed from several games, added my own mechanics and pacing ideas, and let the gameplay evolve naturally throughout development. In many ways, Alien Barrage became both a technical experiment and a throwback to the arcade era.

Why I Chose Native iOS Development

I considered building the game in Unity, but ultimately decided to use Apple’s SpriteKit framework and develop the project natively in Swift.

Part of that decision was practical: I wanted to build more directly against modern Apple-native frameworks and services, including:

  • Swift and Xcode workflows
  • SpriteKit
  • Game Center leaderboards and achievements
  • In-App Purchases
  • Native App Store deployment
  • Localization pipelines

The game and App Store content were ultimately translated into 14 languages.

Coming from years of cross-platform development using Xamarin, .NET MAUI, React Native, and Adobe AIR, I wanted to push further into modern native Apple development and build more directly against platform-native frameworks and tooling.

Development with AI

The project was developed using a custom AI-assisted workflow built primarily around Claude and Codex.

Rather than treating AI as a “one click app generator,” I approached it more like structured pair programming. I directed architecture, gameplay systems, feature planning, debugging, testing, iteration, and project organization, while AI accelerated implementation and repetitive development tasks.

One of the biggest lessons I learned was that workflow design matters just as much as prompting.

Phase-Based Development

Before writing production code, I used AI to help generate a full phase-based development outline for the game.

Each phase had:

  • a clearly defined goal
  • implementation scope
  • testing criteria
  • isolated Git branches
  • completion checkpoints

The workflow looked something like this:

  1. Plan a phase
  2. Scope prompts tightly
  3. Let AI implement the feature
  4. Review and test manually
  5. Refine edge cases
  6. Merge the branch
  7. Move to the next phase

This created a surprisingly clean development history with structured progression and meaningful commit messages.

No production code was generated until the overall structure of the game had been planned first.

What Actually Worked

Model Switching (Claude ↔ Codex)

I frequently switched between Claude and Codex depending on context limits, reasoning quality, or implementation drift.

This ended up having several unexpected advantages:

  • reduced long-context degradation
  • lower overall cost
  • forced re-grounding between phases
  • improved planning discipline

Different models also had different strengths depending on the task.

Human Validation Loops

AI would implement a feature and then stop, often providing testing instructions or validation steps.

I reviewed, tested, and refined features continuously rather than allowing large unverified code changes to accumulate.

That tight feedback loop helped keep the project stable even as the scope grew.

Git Discipline

Each phase was isolated into its own Git branch before being merged back into the main project.

That structure made experimentation safer and kept development organized as the game evolved.

AI Beyond Coding

AI was used for more than gameplay implementation.

The workflow also included:

  • asset generation
  • image processing
  • sound integration
  • video generation
  • documentation generation
  • command-line automation

Tools like ImageMagick and ffmpeg were integrated into the workflow with AI assistance, alongside ChatGPT for image generation and other production tasks.

    Me vs. Me + AI

    Realistically, I probably would not have had the time to build a project of this size entirely on my own within a few months while balancing everything else.

    What AI changed for me was not the need for engineering judgment—it changed the speed of execution.

    The combination of:

    • real-world software engineering experience
    • mobile development background
    • architecture planning
    • debugging ability
    • product direction
    • and AI-assisted implementation

    turned out to be extremely effective.

    To me, the process felt less like “AI replacing programming” and more like advanced pair programming with a very fast collaborator.

    Cross-Platform vs. Native Development

    For years I leaned heavily into cross-platform development.

    My background includes:

    • Xamarin
    • .NET MAUI
    • React Native
    • Adobe AIR

    The biggest advantage was always efficiency: one codebase and one primary skill set for multiple platforms.

    But AI-assisted development changes that equation somewhat.

    Recently I’ve been focusing heavily on native apps in Swift and Kotlin while using AI-assisted workflows to accelerate implementation, experimentation, and iteration.

    That has made native development significantly more appealing than it once was.

    My AI Coding Journey

    I started experimenting seriously with AI coding tools in 2025 using Codex and later Claude.

    Since then, I’ve:

    • rebuilt my Xamarin-based iOS app TimesX in native Swift
    • integrated Apple Intelligence-powered content generation into TimesX
    • replaced the original Xamarin version on the App Store
    • created a native Android version in Kotlin optimized for Chromebooks
    • built supporting websites and tooling
    • developed Alien Barrage using Swift and SpriteKit
    • experimented with Apple TV and Mac OS native applications for personal use

    In just a few months, I’ve been able to build and ship substantially more software than I could previously as a solo developer.

    I’ll admit it: I’m hooked on AI-accelerated development.

    Not because it removes the need for engineering—but because it amplifies what experienced developers can accomplish.

    Final Thoughts

    One thing this project reinforced for me is that AI is most powerful when paired with real development experience.

    Architecture decisions, debugging, testing, workflow design, platform knowledge, and product direction still matter enormously.

    AI simply compresses the distance between idea and execution.

    For experienced developers willing to adapt, that combination feels less like a threat and more like a significant advantage.

    web site
    app store page

    TimesX 2026, now with AI

    TimesX is the multiplication practice app that helps kids master their times tables — now with AI-generated word problems that run completely offline. See everything TimesX can do →

    What’s New?

    A decade after TimesX was first released, the 2026 version receives a full rewrite in native Swift, along with a major new feature: AI-generated word questions.

    There is a clear industry trend toward empowering handheld devices with artificial intelligence, visible across personal computers, phones, and wearables such as Meta glasses. Apple began including NPUs (Neural Processing Units) in its chips starting with the M1 (Macs and iPads) and later the A17 Pro (iPhone 15 Pro). This enabled new AI capabilities on iOS devices—such as face detection and image classification—but also introduced support for an on-device Large Language Model (LLM ), similar in concept to ChatGPT.

    How Does This Affect TimesX?

    Since its creation, the app supported only two question types: Multiple Choice and Type the Answer. With the 2026 rewrite, a third question type—Word Questions—has been added.

    This rewrite made it easier to access Apple’s on-device LLM directly in code. On supported hardware, TimesX can now generate fresh word questions for every quiz using Apple Intelligence. An important benefit for security-conscious parents is that the AI runs entirely on-device and does not require an internet connection. Once installed, TimesX can operate completely offline.

    What About Devices Without Apple Intelligence?

    For devices that do not support Apple Intelligence, TimesX includes a pre-generated bank of word questions. The AI feature can also be disabled in Settings, in which case the app will always use the question bank instead.

    What Else Is New?

    Dozens of refinements have been made across layout, imagery, and usability. Some of the most impactful improvements are on the Error Counts screen.

    Imagine a child using TimesX to practice multiplication tables across dozens of short tests each day. The app tracks questions that have been answered incorrectly at least twice and surfaces them on this screen. The update adds visibility into how many times each question has also been answered correctly.

    When a child starts a Test from the Error Counts screen, the quiz is built entirely from these problem areas. Over time, as accuracy improves, a happy face appears next to questions that have been answered correctly more often than incorrectly—clear feedback that focused practice is paying off.

    Conclusion

    If you—or someone you know—has a child in elementary school where multiplication tables are part of the curriculum, TimesX offers a more focused and adaptive practice experience than traditional methods or most existing apps.

    More detail on the website: