June 9, 2026 · Rob Roy

I have a problem that every trail camera owner knows. Pull the cards, slot them into the Mac, open the folder — and stare down 500 images of wind-blown grass, shadows, and the occasional deer backside. Sorting them manually takes an hour. Most of that hour is deleting blanks.

This week I built something to fix that. It’s called camtriage, it runs entirely on my Mac with no cloud API, and on its first real run against my SD cards it sorted 511 images in about three minutes of my actual attention. Here’s what it found and where I think this is going.

The Problem With Game Cam Data

A motion-triggered camera doesn’t know the difference between a white-tailed deer and a branch moving in the wind. It fires on both. On a good month in Maine, maybe 15% of images actually contain an animal worth looking at. The rest are false positives — IR triggers from heat shimmer, shadows crossing the lens, a squirrel that was gone before the shutter fired.

The standard workflow is manual triage: click through every image, delete the blanks, move the interesting ones into folders by species. It works, but it scales terribly. A serious hobbyist or wildlife researcher running multiple cameras can pull thousands of images a month.

I’d been thinking about this problem since I started working on HomesteadAI — a suite of privacy-first, on-device AI tools for Mac. The game cam problem felt like a natural fit. Local processing, structured output, sensitive personal data (your property, your wildlife patterns) that has no business going to a cloud API.

The Stack

camtriage uses two models:

Google SpeciesNet — an open-source wildlife classifier trained on over 65 million camera trap images from around the world. It runs as a batch job: hand it a folder, it classifies every image to species level and returns confidence scores. Geographic priors (I set country=USA, state=ME) improve accuracy by down-weighting species not plausible in Maine.

Apple Foundation Models — for behavioral annotation. Once SpeciesNet identifies a species, Apple’s on-device language model generates a one-sentence behavioral note: what the animal is likely doing, and whether the timing is unusual. This runs through the new apple-fm-sdk Python package announced at WWDC 2026 this week, completely on-device, no API key.

The behavioral annotation uses a grounded species behavior table rather than asking the model to recall facts — which it does unreliably. I tell it that raccoons are nocturnal, then ask it to describe behavior. The model reasons, it doesn’t recall.

What Three Cards Found

I ran camtriage against three SD cards this afternoon. Combined results:

Card 1 — wildlife corridor camera, deep woods placement:

  white-tailed deer      15
  wild turkey            12
  domestic cat            7   ← all IR night images
  virginia opossum        4
  eastern gray squirrel   3
  northern raccoon        1

467 of 511 images were blank or low-confidence. The tool filtered them automatically.

Card 2 — driveway/trail entrance camera:

  wild turkey            17
  white-tailed deer      11
  human                   5   ← daytime, near driveway
  vehicle                 5   ← daytime
  woodchuck               1
  northern raccoon        1

The human and vehicle detections were correctly skipped — daytime activity near the driveway is normal. If any of those humans had been detected at night, the tool would have flagged them as alerts with a separate folder.

Card 3 data pending — running now.

Two things jumped out immediately. First, the seven domestic cat detections on Card 1 were all IR night images — cats hunting on the same trails as the turkeys and deer. That’s useful information for a homestead. Second, the two cards tell completely different stories about camera placement. Card 1 is a wildlife corridor. Card 2 is an access point. The species distribution makes that obvious at a glance.

The Accuracy Story

Before building camtriage I tested two approaches against a labeled test set of 56 images across 12 species — deer, fox, bobcat, turkey, raccoon, crow, cat, squirrel, skunk, woodpecker, opossum, birds.

SpeciesNet: 91.1% accuracy. It correctly identified bobcat (distinguishing it from domestic cat in several cases), got every fox right, and sorted turkeys cleanly even from awkward angles.

Gemma 4 12B (general vision LLM): 38.2% accuracy. It called foxes “bears” repeatedly, labeled raccoons as coyotes, and identified a domestic cat as a dog. Not because it’s a bad model — it’s excellent — but because it has never been trained on Maine IR game cam images at dusk. Domain-specific models win decisively for domain-specific tasks.

This is one of the core lessons of the HomesteadAI project. The right model for the job beats the largest model every time.

The Alert System

Not all detections are equal. A deer on the trail is interesting. A mountain lion, an unknown dog, or a human on your property at 2am is something you want to know about immediately.

camtriage has a two-tier alert system:

Always-alert labels — mountain lion, black bear, wolf, unknown dog. Any detection at any confidence above threshold copies the image to an _alerts/ folder and flags it at the top of the summary.

Context-sensitive alerts — the more interesting case. A human detected during the day near the driveway camera is normal. A human detected at night is not. The tool reads the EXIF timestamp, computes time-of-day (dawn/daytime/dusk/night), and alerts only when the timing matches a configured rule:

alert_if:
  human:        [night, dawn]   # trespasser
  domestic cat: [night]         # predator behavior

This means the seven IR cat detections from Card 1 would now trigger alerts — cats active at night on wildlife corridors is worth knowing about, especially with ground-nesting turkey in the same area.

What Apple Announced This Week

The timing of this project turns out to be interesting. WWDC 2026 was today. A few things Apple announced matter directly:

Foundation Models is now multimodal. The on-device model can now accept image input alongside text. Vision annotation — passing the actual game cam image to Apple FM for visual reasoning — requires macOS 27 Golden Gate (shipping fall 2026). Today on macOS 26 Tahoe, only text annotation works. When Golden Gate ships, the behavioral annotation layer gets significantly richer because the model can actually see what it’s describing.

The LanguageModel protocol. Apple introduced a standard Swift interface that Apple Foundation Models, Claude, and Gemini all implement. One API, swappable models. For the eventual native Mac version of camtriage, this is the architecture — write against the protocol, let the user choose the model.

macOS Golden Gate drops Intel. Apple Silicon only from here. Every machine in the HomesteadAI target market has unified memory and a Neural Engine. The hardware assumption that makes local AI viable is now universal.

Where This Goes

Near term: Run more real cards. Refine the confidence threshold based on real false positive rates. Add video support — game cams produce companion video clips for the same trigger events as stills, and I’m handling that by matching timestamps rather than processing video frames directly.

Fall 2026: When macOS 27 ships, add image input to the Apple FM annotation layer. A behavioral description that can actually see the image will be significantly more useful than one working from species name and time of day alone.

Native Mac app: The Python prototype validates the concept. The production version is Swift — SpeciesNet replaced by Apple FM vision (or DeepFaune New England, a 97%-accurate classifier specifically trained on northeastern North American species), the annotation layer using the LanguageModel protocol, a species review UI before any images are copied. The target is a HomesteadAI product that any Mac user can run without touching a terminal.

SmartFiler integration: The underlying pattern — classify, sort, flag anomalies — is exactly what SmartFiler does for documents. The game cam feature slots into SmartFiler as a v2.0 capability once the Apple FM vision layer is available. One app, one purchase, expanding capability.

The Project

camtriage is open source, MIT licensed, and on GitHub. It runs on Mac, Linux, and Windows — the core pipeline is cross-platform, Apple Foundation Models annotation is a Mac enhancement.

github.com/robroy/camtriage

If you run trail cameras and have a pile of SD cards you’re dreading, give it a run. The configuration is a single YAML file — set your country and state, adjust the species behavior table for your region, define your alert labels. The defaults are tuned for the northeastern US.

Feedback welcome. Particularly interested in hearing from people running cameras in other regions — the species behavior table is currently Maine-centric and needs contributions from the community.

Rob Roy builds privacy-first, on-device Mac and iOS apps under the HomesteadAI brand. This post is part of an ongoing series on local AI for practical homestead and outdoor applications.

If you’ve spent any time building RAG applications, you know the drill. Before your app can do anything useful, you need a pipeline: extract text from PDFs, chunk it, run it through an embedding model, store the vectors somewhere. If you’re lucky, you’ve got a Python environment that isn’t broken. If you’re not, you’re debugging dependency conflicts at 11pm wondering why you wanted to do this.

I built CorpusKit Studio because I wanted to build RAG-powered iOS apps and I didn’t want a Python pipeline in the loop.

What It Does

CorpusKit Studio is a native Mac app. You drag in a PDF. The app extracts the text, chunks it, generates embeddings using an on-device Core ML model, and exports a signed .corpus bundle that any CorpusKit iOS app can consume directly.

No Python. No API keys. No data leaving your machine.

That last part matters more than it sounds, especially if you’re working with sensitive documents — legal filings, medical records, proprietary research. The embedding step, which normally means sending your text to an external API, happens entirely on your Mac using Apple’s Neural Engine.

The Technical Decisions Worth Talking About

PDF extraction via PDFKit

The obvious choice for a Mac app, and it mostly just works. The edge case worth knowing: some PDFs are image-based scans with no extractable text layer. CorpusKit Studio checks for this and warns you if the page character count is suspiciously low. OCR is outside scope — I’m not going to bundle a third-party OCR engine when there are good dedicated tools for that job. Extract the text first, then bring it into the app.

Running MiniLM on Core ML

This was the interesting part. MiniLM-L6-v2 is the embedding model that’s become a standard for RAG applications — small, fast, good quality for retrieval tasks. Getting it running natively on macOS via Core ML meant converting the model and implementing the WordPiece tokenizer in Swift, which doesn’t exist anywhere off the shelf.

The result: embedding a typical PDF runs in seconds on Apple Silicon. The Neural Engine handles it efficiently and the model is identical to what the iOS CorpusKit apps use, which matters for consistency between where you build the corpus and where you query it.

NSDocument architecture

I used NSDocument as the foundation rather than building a custom persistence layer from scratch. That decision gave me File > Open Recent, autosave, and document versioning essentially for free. It’s one of those AppKit decisions that feels like overhead until you realize how much work it saves.

Cosine similarity search via Accelerate

No vector database. The corpus sizes I’m targeting — a few hundred to a few thousand chunks from a typical book or document — don’t need one. Accelerate’s vDSP handles cosine similarity over that scale trivially fast. Adding a vector DB dependency would introduce complexity with no real benefit at this scale.

The Part That Isn’t Just Engineering

There’s a piece of CorpusKit Studio that goes beyond the mechanical pipeline: the curator layer.

Raw text extraction treats every chunk as equal. But if you’ve actually read the document, you know that’s not true. Some passages are central to the subject. Others are footnotes, boilerplate, chapter openers that don’t contain useful retrieval content.

CorpusKit Studio lets you read the source document inside the app, highlight passages, and rate their importance. Those curator signals travel with the exported corpus. When the iOS app retrieves results, importance ratings can influence ranking. Eventually — as apps accumulate usage data — real retrieval signals (which chunks actually led to good conversations) can feed back into the corpus weighting.

The idea is that a corpus curated by someone who actually understands the content should outperform one that was just mechanically chunked. That’s the bet.

It Teaches You How RAG Actually Works

Something I didn’t fully anticipate: CorpusKit Studio turns out to be a genuinely good way to understand retrieval-augmented generation at a mechanical level.

Most developers interact with RAG through an API or a framework that hides the steps. You send text in, you get responses back, and the middle is a black box. That’s fine for shipping product, but it means you’re guessing when something doesn’t work — when results are irrelevant, when the model seems to miss obvious answers, when response quality is inconsistent.

CorpusKit Studio makes the whole pipeline visible. You can see exactly how your document gets chunked. You can adjust chunk size and overlap and immediately see how the boundaries change. You can run a query against your corpus and see the ranked results — with cosine similarity scores — before any LLM is involved. That score tells you whether retrieval is finding the right passages. If it isn’t, you know the problem is in the corpus, not the model.

When you highlight a passage and mark it as high importance, you’re making a decision about signal vs. noise that a pure pipeline never asks you to make. When you run a test query and see a mediocre chunk ranking above a better one, you learn something real about how embedding similarity works — and you can fix it by adjusting your chunking strategy or adding more representative content.

If you’re learning RAG or trying to build intuition about why your retrieval quality varies, building a corpus in CorpusKit Studio is more instructive than reading about it. The feedback loop is immediate and concrete.

What’s Coming

CorpusKit Studio is coming to the Mac App Store. The product page is live now at robroy.online if you want to read more about what it does.

If you’re building RAG applications on Apple platforms and you’ve been tolerating the Python pipeline, I’d be curious what your setup looks like. Drop me a line at contact@robroy.online.

CorpusKit Studio is a Mac app that builds semantic search corpora from PDF documents using on-device Core ML embeddings. Learn more →

Rob Roy · robroy.online · April 2026

A few weeks ago I asked a simple question: could I take a small language model and teach it about one specific domain?

That question led me through a full modern AI engineering stack — retrieval-augmented generation, embedding models, on-device inference, Core ML conversion, Apple Foundation Models — and eventually to a working iOS app that runs entirely on the device with no network calls. Along the way I changed direction several times, discarded entire architectures, and learned what actually matters versus what just sounds impressive in a roadmap.

This is a record of the journey, including the parts where I was wrong.

The project

The app is called Big Book via LLM. It provides a private, on-device conversational interface to the 1939 first edition of the Alcoholics Anonymous Big Book — a text that is firmly in the public domain in the United States. The app retrieves relevant passages from the text in response to user queries and generates warm, concise responses grounded in those passages. Every answer cites its source. Nothing leaves the device.

The project had three honest goals from the start:

Learn the current AI engineering stack deeply enough to be professionally fluent in it. Build something that might serve a community I care about. Produce work that demonstrates real capability, not just familiarity with buzzwords.

Commercial scale was never the primary goal. That turned out to matter, because it freed me to make good technical decisions instead of defensive market positioning.

Starting with the wrong architecture

My first instinct was to bundle everything into the app. Download a small LLM, index the Big Book corpus, run inference locally, ship it. Privacy would be the pitch. On-device would be the differentiator.

That architecture started falling apart almost immediately.

The first problem was model size. Phi-4 Mini quantized to Q4 is about 2.3 GB. Apple’s On-Demand Resource system caps individual asset packs at 512 MB. The workaround was splitting the GGUF file into chunks and downloading both, but the real issue surfaced first: a 2.3 GB download before the user sees any value is a terrible first experience. Most users abandon apps in the first 60 seconds. A progress bar is not an experience.

The second problem was memory. A 2.3 GB model needs roughly 3 GB of RAM to load with overhead. iPhones with 4 GB of RAM physically cannot run it. That cut off iPhone 12 and 13 users — a significant slice of exactly the demographic most likely to benefit from this app.

The third problem was stability. llama.cpp integration via Swift bindings involved C++ interop, manual KV cache management, and a class of bugs that don’t exist in pure Swift. I spent days chasing hard crashes before realizing the architecture was fighting the platform.

The lesson: elegance on the developer’s MacBook is not the same as elegance on the user’s iPhone.

Changing direction

I made three architectural changes in quick succession, each one forced by a problem I should have anticipated:

Switched from Phi-4 Mini to Gemma 3 1B. Smaller model, more devices supported, smaller download. Response quality for RAG is largely driven by the retrieval layer, not the model’s raw capabilities — the LLM is primarily framing retrieved passages rather than generating from scratch. A 1 billion parameter model does this task surprisingly well.

Replaced llama.cpp with Apple Foundation Models. When iOS 26 shipped with native on-device LLM support, the entire custom inference stack became unnecessary. No download, no GGUF files, no C++ bridge, no ODR splitting. A single Swift API that uses the Neural Engine directly. The tradeoff was setting iOS 26 as the minimum deployment target, which sounds restrictive but according to Apple’s data covers 66% of all active iPhones and 74% of devices from the last four years. The users I’d exclude were mostly on hardware that couldn’t run the app well regardless.

Built a Mac companion app to handle corpus preparation. My original workflow used Python scripts that only I could run. That’s a workflow for exactly one person. I built CorpusKit Studio as a native Mac app that accepts PDFs, chunks them, generates embeddings via Core ML, lets curators highlight important passages, tests retrieval live, and exports a deployable corpus bundle. No terminal required. No Python. Same code patterns as the iOS app, same embedding model, consistent results across both.

The RAG architecture that worked

With the right pieces in place, the final architecture is conceptually simple:

A corpus is prepared by CorpusKit Studio on a Mac. The Big Book PDF goes in. PDFKit extracts the text. A chunker splits it into overlapping 200-word segments with metadata preserved. A Core ML converted version of all-MiniLM-L6-v2 generates a 384-dimensional semantic embedding for each chunk. Important passages get curator importance weights set via a highlighting interface. The whole thing exports as a bundle containing chunks.json and embeddings.npy.

The iOS app bundles this corpus along with the same MiniLM Core ML model. At query time: the user’s question is expanded using a domain-specific vocabulary dictionary (“step 4” becomes “searching and fearless moral inventory personal housecleaning list resentments fears”), embedded using the same model that created the corpus, compared against all chunk embeddings via cosine similarity, weighted by chapter and importance, and the top three chunks are retrieved. Those chunks are assembled into a prompt with a tight three-part response structure. Apple Foundation Models streams a warm, brief response. The UI renders the response text alongside passage cards showing the specific cited sentences.

End to end, a query takes about 800 milliseconds on an iPhone 15 Pro. No network. No server. No user data leaving the device.

Three design decisions I’d make again

The three-part response structure. Rather than letting the LLM generate whatever it wanted, I constrained responses to: one sentence acknowledging what the person is bringing, one sentence pointing to where the book addresses it, and one question that opens reflection. Under 50 words total. This makes the app feel like a thoughtful companion rather than a chatbot. The text is just connective tissue — the UI renders actual book passages as citation cards.

Sentence-level citation extraction. Chunks are 200 words because that’s what works for retrieval. But showing 200 words as a citation is overwhelming. At display time, I embed each sentence within the retrieved chunk and show only the single most relevant sentence with its page number. “Resentment is the number one offender. — Big Book, p. 64” is more useful than a paragraph of context the user didn’t ask for.

Treating authority as a first-class concept. Not every document in a library is equally authoritative. In law, the Constitution outweighs a law review article. In recovery, the Big Book first edition outweighs commentary. CorpusKit Studio lets curators set authority weights per corpus, stamped into every chunk at export time. The iOS app multiplies similarity by authority, so a passage from a primary source wins over a loosely relevant passage from a secondary one. This encodes domain expertise directly into retrieval rather than hoping the model figures it out.

Three decisions I got wrong first

I initially wanted the app to rely on a local Flask server for embeddings during development. This worked in the simulator but created a dependency that couldn’t ship to actual users. I should have prioritized Core ML embedding conversion from day one rather than using it as a placeholder.

I tried to bundle the model inline with the app. Apple’s ODR system and memory constraints made this painful. The real answer was either a smaller model that fits within reasonable constraints, or Apple’s own Foundation Models when available. Fighting the platform on model delivery was wasted effort.

I considered competing with NotebookLM on features. That would have been a losing strategy. Google’s free, works-everywhere tool wins on raw capability. What my app can offer that theirs cannot is specialization — domain-tuned query expansion, citation-first UI, crisis awareness appropriate for recovery literature, a warm tone deliberately shaped for the community it serves. General tools cannot credibly be all things to all domains. Specificity is defensible.

What I learned about RAG

The retrieval layer matters more than the model. A well-tuned retrieval pipeline with a mediocre LLM outperforms a great LLM with naive retrieval. I spent a disproportionate amount of time on chunk size, overlap, chapter weights, query expansion, and importance scoring — and that’s where most of the quality came from.

Domain knowledge encoded as data beats domain knowledge expected from the model. Rather than hoping the LLM knows that “step 4” means a moral inventory, I wrote a query expansion dictionary. Rather than hoping it weights the Constitution higher than a law review article, I stamp authority weights directly onto chunks. The model does not need to be an expert in your domain if your retrieval layer already is.

Evaluation is the hardest part. It’s easy to build RAG that returns something. It’s hard to know whether it returned the right thing. I built a verification script that runs a set of representative queries and prints the retrieved chunks with scores. Watching those scores move as I tuned chunk size and chapter weights was how I actually knew the system was improving. Without that feedback loop, you’re flying blind.

What I learned about shipping on-device AI

iOS 26 and Apple Foundation Models changed the calculus significantly. Before iOS 26, shipping an on-device LLM meant downloading gigabytes and managing memory pressure yourself. After iOS 26, it’s a Swift API. For anyone building in this space today, that transition is the single most important development.

Core ML conversion has sharp edges. The coremltools package has known issues with Python 3.13, requires specific coremltools versions that support various model architectures, and the documentation assumes you already know what you’re doing. The path that worked for me was Python 3.11, direct PyTorch-to-CoreML conversion skipping ONNX entirely, FP16 precision, and verifying cosine similarity above 0.999 between the PyTorch reference and the converted Core ML output before trusting anything.

Privacy is not automatically a competitive advantage but it is table stakes for certain domains. Generic users don’t care much about where their queries go. Users dealing with recovery, therapy, legal issues, medical information, or any topic they consider sensitive care a great deal. Choosing domains where privacy matters makes on-device architecture valuable. Choosing domains where it doesn’t makes on-device architecture expensive and complicated with no upside.

Where this goes next

CorpusKit Studio is the more interesting long-term product than the iOS app. It’s infrastructure — a tool for producing deployable RAG corpora from any PDF, with curator controls for importance, authority, and query expansion. The same engine that produces the Big Book corpus can produce a corpus from any closed body of text. Recovery literature, legal documents, medical education, sacred texts, personal libraries.

The iOS app is one consumer of the output. The Mac app is the workshop. The corpus bundle is the portable artifact that connects them. A publisher, a clinician, a sponsor, a curator — none of them needs to touch a terminal to produce a high-quality RAG corpus. That accessibility is what turns this from a personal project into something potentially useful to other people.

I plan to release the Big Book corpus package publicly under a permissive license. The corpus derivation is my work; the source text is public domain; the resulting index is something any CorpusKit-compatible application can consume. The recovery community should have access to this kind of tool, and one app cannot reach everyone — but a well-made corpus can work inside any tool that knows how to read it.

The skills this built

I was explicit with myself at the start that one of the goals was professional skill development. Working through this project end-to-end, I can now credibly speak to:

Retrieval-augmented generation architecture: chunk sizing, overlap, embedding model selection, vector similarity search, query expansion, chapter and importance weighting, evaluation methodology.

On-device LLM inference: model quantization tradeoffs, memory constraints on mobile devices, llama.cpp integration, Apple Foundation Models, Core ML model conversion from PyTorch, FP16 precision considerations.

Production iOS development with AI: SwiftUI architecture, async token streaming, Core ML integration, proper error handling around AI pipelines, the difference between simulator and device behavior, iOS 26 Foundation Models API specifics.

Product decisions in the AI space: when to use RAG versus fine-tuning, how to handle crisis scenarios in sensitive domains, the tradeoffs of closed-source versus open models, cloud versus on-device architectures, the actual versus perceived value of privacy-first design.

The deeper lesson is that doing this work is different from reading about it. I could have spent the same weeks watching tutorials and finished with less real understanding than I got from hitting actual problems and solving them. The errors — the crashes, the zero-vector embeddings, the Python version mismatches, the Core ML conversion failures, the response length that wouldn’t shorten — were where the learning lived.

A note on direction changes

Looking back, I changed direction in significant ways roughly five times across this project. Each time it felt like a setback. Each time it was actually the right call.

Changing direction is often treated as a failure mode. In software it usually is not. The information you have at the start of a project is always incomplete. The information you have three weeks in is substantially better. Refusing to incorporate new information out of commitment to a plan is a worse outcome than revising the plan honestly.

The original architecture had Phi-4 Mini running via llama.cpp with ODR-split GGUF files, a Flask embedding server during development, and a Python corpus pipeline that only I could run. The final architecture has Apple Foundation Models, Core ML embeddings, a Mac app that any curator can use, and a corpus format designed for portability. The final version is dramatically better than the original plan — and I could not have arrived at it without starting somewhere and paying attention.

Rob Roy is an independent iOS developer based in Maine. His work and contact are at robroy.online.

After nearly four decades in systems administration and DevOps — including stints at IBM and Disney — I’ve managed a lot of infrastructure. Racks of servers, sprawling networks, machines spread across time zones. The tools we used were powerful, expensive, and designed for teams.

Then I left enterprise. Now I run a home lab with a handful of Linux boxes, a NAS, a Raspberry Pi or two, and a Mac Mini acting as a server. Nothing exotic. But the same problems I had at IBM still show up at 11pm when something goes quietly offline and I’m nowhere near a desk.

I wanted one app on my iPhone that could tell me what was happening on my network. Not a cloud dashboard with per-seat pricing. Not a terminal emulator with no context. Something purpose-built for the person who runs a small fleet of machines they actually own.

So I built Netsolver.

The problem with existing tools

Enterprise RMM tools — NinjaRMM, ConnectWise, Atera — are genuinely excellent if you’re managing hundreds of endpoints for paying clients. But they start at per-agent pricing that makes no sense for eight machines in your basement. The onboarding alone assumes you have an IT team.

On the other end, there are SSH clients. Good ones. I’ve used them for years. But an SSH client is a blank terminal. It doesn’t know what’s on your network, it doesn’t alert you when something goes down, and it doesn’t integrate with the rest of your phone.

There’s a gap between “full enterprise RMM” and “just SSH.” That gap is exactly where most home lab operators and small businesses live. That’s what Netsolver is for.

What it does

LAN scanning that actually tells you something

When you open Netsolver, it scans your local network and finds every device. But it doesn’t just list IP addresses — it probes each host for running services. SSH on port 22. SMB on 445. DNS on 53. RDP on 3389. MySQL on 3306.

The result is an immediate picture of your network. You can filter hosts by detected service — tap “SSH” and see every machine you can log into. Tap “RDP” and see your Windows boxes. This is information I used to piece together from nmap output and spreadsheets. Now it’s on my phone in seconds.

SSH with saved commands

Connecting to a host takes one tap. You can run any command and see the output. But where it gets useful is saved commands — per-host shortcuts for the things you run all the time. df -h / to check disk. uptime to see load. systemctl status nginx to check a service.

On iPad, saved commands sit in a persistent panel alongside the terminal. On iPhone, they live in a strip above the keyboard. No more retyping the same commands every session.

Agent deployment and monitoring

This is where Netsolver goes beyond an SSH client.

You can deploy a lightweight monitoring agent to any Linux or Mac host directly from the app. One tap — Netsolver connects via SSH, uploads the agent, and installs it as a system service. The agent phones home and starts reporting CPU, memory, and disk usage.

You set the thresholds. CPU above 85%? Disk above 90%? The agent fires a push notification to your iPhone via APNs. No polling, no background refresh, no battery drain. The server tells your phone something is wrong.

Alerts that actually do something

Here’s the part that genuinely surprised me when I built it.

iOS Shortcuts integration means an alert isn’t just a notification — it can trigger an action. When a monitored host hits a CPU threshold, Netsolver can fire a Shortcut. That Shortcut can send you a message on a specific channel, log the event to a spreadsheet, kick off a webhook, or run any automation you’ve already built on your phone.

I’ve worked with monitoring systems that cost thousands of dollars a month and didn’t have this kind of flexibility. The fact that it’s available to a home lab operator for the price of an iOS app still seems remarkable to me.

What I learned building it

This is my first production iOS app after 37 years of infrastructure work. A few things surprised me.

The hard part wasn’t the network code. LAN scanning, SSH, SFTP — this is the stuff I know. The hard part was SwiftUI. Specifically, building an adaptive layout that works well on iPhone and iPad and adapts gracefully when the user rotates, changes window size, or uses split view. Apple’s NavigationSplitView is elegant once you understand it, but it took me a while to understand it.

Privacy-first design is harder than it sounds. I wanted zero cloud, zero account, credentials in the Keychain only. That’s the right decision for an app that handles SSH keys. But it means solving problems that cloud sync would solve for free — like keeping inventory in sync across your iPhone and iPad. SwiftData with CloudKit private database turned out to be the right answer, but getting there took research.

The Shortcuts integration was genuinely fun. I’ve been writing automation scripts my whole career. Hooking into iOS Shortcuts and watching a server alert trigger a cascade of phone-side automation felt like two worlds I care about finally talking to each other.

Who it’s for

Netsolver is built for three kinds of people:

Home lab operators running 3–10 machines. You have a NAS, a Pi or two, maybe a repurposed desktop. You want to know they’re up, and you want to SSH in without hunting for credentials.

Small business owners with a handful of servers or sites to watch. You don’t want to pay enterprise RMM pricing for eight machines. You want a native iOS app that just works.

Freelance developers and web designers who SSH into client servers regularly. You want saved commands, SFTP access, and a way to know immediately if a client site goes dark.

Coming soon

Netsolver is in final development. The core is working: scanning, SSH, SFTP, agent deployment, APNs alerts, and Shortcuts integration. I’m working through the UI polish and App Store submission process now.

If you run a home lab or manage a small fleet of machines, this is being built for you.

I’ll post an update here when it’s available on the App Store. In the meantime, you can find my other apps and development work at robroy.online.

Rob Roy is an indie iOS and macOS developer based in Maine with 37 years of software development experience, including DevOps and systems administration roles at IBM and Disney.

## Overview

The `DebugHelpers.swift` file provides debug logging macros that are completely removed during release builds, ensuring zero performance impact in production.

## Features

– **Zero runtime cost in release builds** – All debug code is stripped at compile time

– **Simple API** – Drop-in replacement for `print()`

– **File and line tracking** – Optional detailed logging with source location

– **Debug assertions** – Catch issues early in development

## Usage

### Basic Debug Logging

Replace `print()` with `DLOG()`:

“`swift

// Old way (appears in release builds):

print(“User logged in:”, username)

// New way (stripped from release builds):

DLOG(“User logged in:”, username)

“`

### Debug Logging with Source Location

When you need to know exactly where a log came from:

“`swift

DLOG_TRACE(“Error occurred”)

// Output: [ViewController.swift:42] Error occurred

“`

### Debug Assertions

Catch programming errors during development:

“`swift

DASSERT(user.age > 0, “User age must be positive”)

// Only fires in DEBUG builds

// In release: completely removed

“`

## API Reference

### `DLOG(_ items: Any…, separator: String = ” “, terminator: String = “\n”)`

Basic debug print that works exactly like Swift’s `print()` but only in DEBUG builds.

**Parameters:**

– `items` – Values to print

– `separator` – String to separate values (default: ” “)

– `terminator` – String to end the line (default: “\n”)

**Example:**

“`swift

DLOG(“Processing”, itemCount, “items”)

“`

### `DLOG_TRACE(_ items: Any…, file: String = #file, line: Int = #line)`

Debug print with file and line number information.

**Parameters:**

– `items` – Values to print

– `file` – Source file (automatically captured)

– `line` – Line number (automatically captured)

**Example:**

“`swift

DLOG_TRACE(“Unexpected state”)

// Output: [MyView.swift:127] Unexpected state

“`

### `DASSERT(_ condition: Bool, _ message: String = “”, file: String = #file, line: Int = #line)`

Debug-only assertion that crashes the app if condition is false.

**Parameters:**

– `condition` – Boolean condition to check

– `message` – Description of the assertion

– `file` – Source file (automatically captured)

– `line` – Line number (automatically captured)

**Example:**

“`swift

DASSERT(array.count > 0, “Array should not be empty”)

“`

## How It Works

The macros use Swift’s `#if DEBUG` preprocessor directive:

“`swift

func DLOG(_ items: Any…) {

    #if DEBUG

    print(items)

    #endif

}

“`

When you build for release (without the DEBUG flag), the compiler completely removes all code inside `#if DEBUG` blocks. This means:

– No runtime overhead

– No string allocations

– No function calls

– Zero bytes in the binary

## Setting Up in New Projects

### Option 1: File Template

1. Create the template directory:

“`bash

mkdir -p ~/Library/Developer/Xcode/Templates/File\ Templates/Custom/Debug\ Helper.xctemplate

“`

2. Copy the template files to that directory

3. Restart Xcode

4. New file → Custom → Debug Helper

### Option 2: Code Snippet

1. In Xcode, select the `DebugHelpers.swift` code

2. Right-click → Create Code Snippet

3. Set completion shortcut: `debughelpers`

4. In any project, type `debughelpers` + Enter

### Option 3: Manual Copy

Simply drag `DebugHelpers.swift` into your new project.

## Best Practices

### DO:

– Use `DLOG()` for temporary debugging during development

– Use `DLOG_TRACE()` when you need to track execution flow

– Use `DASSERT()` to catch programming errors early

– Remove debug statements once issues are resolved

### DON’T:

– Don’t use for production logging (use OSLog or a logging framework)

– Don’t log sensitive information (even in debug builds)

– Don’t use as a permanent logging solution

## Benefits Over `print()`

| Feature | `print()` | `DLOG()` |

|———|———–|———-|

| Works in DEBUG | | |

| Works in RELEASE | | (intentional) |

| Runtime cost in release | Yes | Zero |

| Binary size impact | Increases | None |

| String evaluation cost | Always | DEBUG only |

## Migration Guide

### Finding print statements to replace:

“`bash

# Find all print() calls in Swift files

grep -r “print(” –include=”*.swift” .

“`

### Replace with DLOG:

“`swift

// Before:

print(“Loading data…”)

print(“Items:”, items.count)

print(“Error:”, error.localizedDescription)

// After:

DLOG(“Loading data…”)

DLOG(“Items:”, items.count)

DLOG(“Error:”, error.localizedDescription)

“`

## Advanced Usage

### Custom Debug Helpers

You can extend the pattern for specific needs:

“`swift

#if DEBUG

func DLOG_NETWORK(_ url: URL, _ response: HTTPURLResponse?) {

    print(“ Network: \(url)”)

    if let status = response?.statusCode {

        print(”   Status: \(status)”)

    }

}

#else

func DLOG_NETWORK(_ url: URL, _ response: HTTPURLResponse?) {}

#endif

“`

### Conditional Compilation Flags

Check your build configuration:

– Xcode → Target → Build Settings → Swift Compiler – Custom Flags

– DEBUG should be in “Other Swift Flags” for Debug configuration: `-D DEBUG`

## Troubleshooting

### “DLOG is showing in release builds”

Check your build configuration:

1. Select your target

2. Build Settings → Swift Compiler – Custom Flags

3. Debug configuration should have `-D DEBUG`

4. Release configuration should NOT have `-D DEBUG`

### “Cannot find DLOG in scope”

Make sure `DebugHelpers.swift` is included in your target’s compile sources:

1. Select the file in project navigator

2. File Inspector → Target Membership

3. Check your app target

## Performance Notes

In DEBUG builds, these macros have the same performance as `print()`.

In RELEASE builds:

– **Zero CPU cost** – Code doesn’t exist

– **Zero memory cost** – Strings not allocated

– **Zero binary size** – Completely stripped

Example binary size comparison on a real project:

– With 100 `print()` statements: +8KB

– With 100 `DLOG()` statements: +0KB i

I’ve been building websites for over two decades — starting with hand-coded HTML long before WordPress existed, and growing with the web ever since. Alongside my app development work, I take on web design projects for small businesses that need a real web presence without a big agency price tag.

Why I Do This

Same reason I build free apps for the recovery community — I like helping people. Small business owners are usually great at what they do and deserve a website that reflects that. What they don’t always have is the time, budget, or technical background to make it happen. That’s where I come in.

A recent example is Flying Moose Alchemy, a unique art and craft business I built a site for. Every business has its own story — the job is making sure the website tells it.

WordPress, So You Stay Independent

Every site I build is on WordPress, and that’s a deliberate choice. A lot of web designers hand you a finished site and then you’re dependent on them for every small change. I don’t work that way. WordPress means you can log in and update your own content — add a new product, change your hours, post an announcement — without calling anyone or paying for a simple edit. You own your site and you can run it yourself.

Twenty years of working with WordPress also means I know it well enough to build something clean and fast, not just something that technically works.

For Businesses That Are a Little Different

I’m particularly drawn to unique small businesses — the ones that don’t fit a template. Cookie-cutter sites work fine for cookie-cutter businesses. If what you do is distinctive, your website should reflect that. I take the time to understand what makes your business worth talking about and build something that actually communicates it.

Affordable by Design

I’m a solo developer working lean, which means my overhead is low and I can offer real value at a price that makes sense for a small business. You’re not paying for a sales team, account managers, or a fancy office. You’re paying for two decades of experience and someone who actually cares whether your site works for you.

If you’re a small business owner thinking about a new site or a redesign, get in touch at contact@robroy.online. I’m happy to talk through what you need before you commit to anything.

Not every app I build is about solving a technical problem. Sometimes it’s about giving something back.

12and12 is a free iOS app that puts daily recovery readings right on your home screen and lock screen as widgets. No subscriptions, no ads, no catch. I built it because the recovery community has given a lot of people — including people I care about — something invaluable, and this was a way I could contribute something back using the skills I have.

What It Does

The app provides home screen and lock screen widgets with daily readings drawn from the 12 Steps and 12 Traditions. The idea is simple: keep your recovery front and center throughout the day, right where you’re already looking. You don’t have to open an app, navigate a menu, or remember to check in. The reading is just there.

Why Widgets

A lot of recovery apps ask you to open them daily, which adds friction. Widgets work differently — they’re part of your phone’s background, something you see naturally as you go about your day. A brief reminder on your lock screen when you pick up your phone in the morning costs nothing and takes no effort. That low friction felt right for something meant to support a daily practice.

It’s Completely Free

There’s no paid version, no premium tier, no in-app purchases. 12and12 is free because that’s the point. Recovery communities are built on people helping people without expectation of anything in return. This app is my version of that.

How to Get It

12and12 is available now on the App Store for iPhone. After you download it, add a widget to your home screen or lock screen through the standard iOS widget menu — press and hold your home screen, tap the + button, and search for 12and12.

Download 12and12 on the App Store

If it’s useful to you or someone you know, I’m glad. That’s enough.

When I started building SmartFiler, I decided to use Claude Code throughout the development process. Not as a curiosity, but as a real part of my workflow. I’m an indie developer — solo, no team — so anything that moves the needle on speed matters. After shipping the app, here’s what I actually found.

What Claude Code Is (Quick Version)

Claude Code is an AI coding assistant you run from the command line. Unlike a chatbot you paste code into, it operates directly in your project — reading files, writing code, running commands. It’s aware of your actual codebase, not just whatever snippet you hand it.

Where It Really Helped

Getting a Prototype Running Fast

This is where Claude Code genuinely impressed me. I could describe what I wanted — a file organizer with rule-based sorting, duplicate detection, batch renaming — and get a working prototype up and running much faster than I would have alone. Not perfect code, but running code. For a solo developer trying to validate an idea quickly, that’s valuable. The early momentum it created was real.

Algorithms

Some of the more specific algorithms in SmartFiler — the SHA-256 duplicate detection, the fuzzy filename matching — Claude Code handled well. Give it a clear problem with defined inputs and outputs and it produces solid, correct implementations. I didn’t have to spend hours digging through documentation or working out the logic from scratch. Describe the problem clearly, review the output carefully, and you’re in good shape.

Where It Fell Short

Architecture — Don’t Trust It Here

This is the big one. Left to its own devices, Claude Code does not naturally write modular, maintainable code. It tends to produce code that works but is tangled — logic that belongs in separate modules ends up in one place, responsibilities bleed across files, things get hard to follow fast. On a small prototype that doesn’t matter much. On a real app you’re going to maintain and extend, it matters a lot.

My fix: I explicitly prompted it to rewrite sections in the most modular form possible. That instruction has to come from you — it won’t volunteer it. Once I started treating “make this more modular” as a standard part of my workflow, the output got significantly better. But you have to know to ask.

It Needs Guidance, Not Just Requests

The mental model that helped me most: Claude Code is a skilled contractor, not a senior architect. If you hand a good contractor a clear spec, they’ll execute it well. If you ask them to figure out the structure of the whole project, you’ll get something that technically works but probably isn’t how you’d have done it yourself. The guidance still has to come from you.

The Most Valuable Use I Found

Code review — but not the way you might expect. I reviewed the code myself, identified what needed improving, and then directed Claude Code to make specific changes based on my assessment. As a solo developer you don’t have a teammate to bounce ideas off, so having something that can execute your improvement suggestions quickly is genuinely useful. The critical thinking still came from me. Claude Code handled the implementation.

My workflow became: write or generate code → review it myself → direct Claude Code on what to fix or improve → repeat. That loop worked well, and it kept me in control of where the codebase was heading.

My Honest Take for Indie Developers

Claude Code is a real productivity tool, not just hype — but it’s not a shortcut to skip thinking about your software. The developers who will get the most out of it are the ones who already know what good code looks like and can evaluate what it produces. If you’re experienced enough to recognize when it’s going sideways, it’ll speed you up considerably. If you’re not yet at that point, it could just as easily lead you in a bad direction faster.

For SmartFiler, it accelerated the early stages significantly and helped me punch above my weight as a solo dev. I’ll use it on my next project. But I’ll be the one making the architectural decisions.

SmartFiler is currently under App Store review. You can read more about it on the product page. If you’re an indie developer using AI tools in your workflow, I’d be curious what you’re finding — drop me a line at contact@robroy.online.

I just submitted SmartFiler to the Mac App Store, and I’m pretty excited about this one. It’s a file organization tool for macOS that I built because every alternative I tried was either too complicated, too aggressive with your files, or just didn’t fit the way I actually work.

Here’s what it does.

Find Duplicates — by Name or by Content

SmartFiler can scan a folder and find duplicate files two ways: matching filenames, or matching actual file content using SHA-256 hashing. The content match is the one you want — it catches files that got renamed but are still identical copies taking up space. You review everything before anything gets deleted, and when you do delete, it goes to Trash, not gone forever.

Smart Buckets

This is my favorite feature. You define rules — by filename, path, or extension — and SmartFiler sorts your files into named folders automatically. Set up a bucket for invoices, one for screenshots, one for project files. You drag to reorder priority, toggle buckets on and off, and nothing moves until you say go.

Similar Files

Fuzzy filename matching that surfaces files that are probably related — like report_2025.pdf and report_2026.pdf. You control how loose or strict the matching is with a slider. Useful for cleaning up versioned files that accumulated over time.

Auto-Organize by Pattern

Point SmartFiler at a messy folder and it analyzes the files and suggests groupings — by file type, date, numbered sequences, or common name prefixes. You review the suggested groups, check or uncheck what you want, preview the changes, then organize. No surprises.

Filename Cleaner

Batch rename files to strip out special characters, fix spacing, change case, or apply a regex pattern. If you’ve ever downloaded a folder of files with names like IMG_20240315_094512_FINAL_v2 (1).jpg, you know why this exists.

Built Around Preview First

Every operation in SmartFiler shows you what’s going to happen before it happens. You can cancel long-running scans at any time. Deletions go to Trash. I built it this way on purpose — file operations are the kind of thing where you really don’t want surprises.

SmartFiler is currently under review at the Mac App Store. I’ll post the link here as soon as it’s live. In the meantime, you can check out the product page for more details.

If you’ve got feedback or questions, drop me a line at contact@robroy.online.

Document everything. Prove anything.

For Homeowners

When dealing with property damage, theft, vandalism, or disputes, keep all your evidence organized and ready to share.

• Security camera footage
• Photos & documents
• Insurance claim reports
• Timestamped notes
• Professional PDF exports

For Developers

Track bugs with structured reports — severity, steps to reproduce, expected vs. actual behavior, and environment details.

• Bug ID & severity tracking
• Steps to reproduce
• Expected vs. actual behavior
• Environment details
• Screenshot attachments