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

If you own a Blink security camera, you’ve probably discovered a frustrating limitation: Blink videos don’t show timestamps on the actual footage. This seemingly basic feature is missing from all Blink camera models, and it’s causing real problems for users who need their footage for insurance claims, legal evidence, or simply knowing when something happened.

The Problem: Missing Timestamps Make Videos Legally Useless

Here’s what happens when you try to use Blink camera footage:

For Insurance Claims

You had a package stolen from your porch at 3:47 PM on Tuesday. You have crystal-clear Blink footage of the thief. But when you submit it to your insurance company, they reject it because there’s no timestamp visible on the video.

The insurance adjuster can’t verify when the theft occurred. Your claim is denied.

For Police Reports

Someone vandalized your car overnight. Your Blink Outdoor camera caught everything. But the police need to know the exact time to correlate with other incidents in the area. Without a timestamp on the video itself, your evidence is circumstantial at best.

For Legal Documentation

You’re in a property dispute with a neighbor. You have video proof of them trespassing. But in court, opposing counsel argues the video could be from any time, any day. Without a visible timestamp, your evidence loses credibility.

Why Doesn’t Blink Include Timestamps?

This is the million-dollar question. Other security camera brands like Ring, Nest, and Arlo all include timestamps on their footage. So why doesn’t Blink?

Blink’s own website acknowledges that footage needs “clear time and date” to be used as evidence in court. Yet they don’t provide this feature.

The timestamp information exists—it’s stored in the video file’s metadata and shown in the Blink app’s thumbnail view. But it’s not burned into the actual video, which makes it useless for official purposes.

What Blink Users Are Saying

On Reddit’s r/BlinkCameras and Blink’s own community forums, users have been complaining about this for years:

“Had I known beforehand, I would have never purchased a blink camera. All of our videos are legally useless without a timestamp.”

“The time and date are in the app, but not on the actual video. Makes it pointless for insurance claims.”

“Why is this not a feature? Every other camera has this!”

The Workarounds That Don’t Work

Some people have tried these “solutions”:

1. Screenshot the App Thumbnail

Problem: Screenshots are too easy to fake and won’t be accepted as evidence.

2. Use Third-Party Video Editing Software

Problem: Manually adding timestamps to every video is time-consuming, and it still looks like you added it after the fact.

3. Export and Check File Metadata

Problem: Most insurance companies and legal entities won’t accept metadata as proof. They need to see the timestamp on the video.

4. Hope Blink Adds the Feature

Problem: Users have been requesting this for years with no response from Amazon/Blink.

Why Timestamps Matter More Than You Think

Beyond the obvious legal and insurance uses, timestamps are crucial for:

• Security Monitoring: Knowing exactly when motion was detected
• Pattern Recognition: Identifying when regular deliveries occur or when suspicious activity happens
• Alibi Verification: Proving where you were at a specific time
• Business Documentation: Recording when employees arrive/leave
• Property Management: Documenting maintenance issues or tenant activity
• Personal Records: Simply knowing when family moments happened

What Makes This Even More Frustrating

Blink cameras are owned by Amazon—one of the most technologically advanced companies in the world. Adding a timestamp overlay to video would be trivial for their engineering team.

The feature exists in their $99 Ring cameras (also owned by Amazon), but not in their $40-100 Blink cameras. There’s no technical reason for this omission.

The Solution: Add Timestamps to Your Blink Videos

Since Blink won’t fix this problem, the solution is to add timestamps yourself. But not manually—there’s actually an app that does this automatically.

[This is where you’d mention your app, Timestamp Blink, as the solution]

The app takes your Blink camera videos and adds accurate, professional-looking timestamps directly onto the footage in seconds. The timestamps are pulled from the video’s metadata, so they’re 100% accurate.

Now your Blink footage is:

• Accepted by insurance companies
• Valid as legal evidence
• Useful for documentation
• Showing exactly when events occurred

How to Get Timestamps on Your Blink Videos Now

You have a few options:

Option 1: Switch to a Different Camera Brand

Cost: $100-300 per camera
Hassle: High (reinstallation, learning new app)
Timeline: Weeks to set up

Option 2: Wait for Blink to Add the Feature

Cost: Free
Hassle: Low
Timeline: Unknown (possibly never)Option 3: Use an App to Add Timestamps

Cost: Minimal (one-time app purchase)
Hassle: Low (works with existing cameras)
Timeline: Immediate

Frequently Asked Questions

Q: Does the Blink app show timestamps?

A: Yes, but only on the thumbnail view in the app. The actual video file you download or share has no visible timestamp.

Q: Can I see the timestamp in the file properties?

A: Yes, the timestamp exists in the video file’s metadata, but most insurance companies and legal entities require a visible timestamp on the video itself.

Q: Which Blink cameras have this problem?

A: All of them. The Blink Mini, Blink Indoor, Blink Outdoor, Blink Outdoor 4, Blink Video Doorbell—none include timestamps on the actual video.

Q: Does Blink’s subscription service add timestamps?

A: No. Even with the Blink Subscription Plan, videos still don’t have visible timestamps.

Q: Will Blink add timestamps in a future update?

A: There’s been no official announcement. Users have requested this feature for years with no response.

Q: Can I add timestamps myself?

A: Yes, using video editing software or a dedicated app designed for this purpose.

The Bottom Line

Blink cameras are affordable, easy to install, and have good battery life. But the lack of timestamps is a critical flaw that makes the footage unreliable for the exact purposes most people buy security cameras for—evidence and documentation.

Until Blink fixes this, you need a workaround. Don’t wait until you need timestamped footage for an insurance claim or police report to discover this limitation.

Whether you switch cameras, use an app to add timestamps, or simply accept the limitation, at least now you know what you’re dealing with.

Have you had issues with Blink’s missing timestamps? Share your experience in the comments below.

Related Articles

Making Your Blink Footage Legally Admissible

How to Submit Blink Camera Footage to Insurance Companies

Blink vs Ring: Which Security Camera Is Better?

Best Security Cameras with Timestamps for 2026