From C++, Swift, and Python to Rust & CQRS: The Multi-Language Evolution of LogViewer

If you have ever had to debug a production outage while watching a multi-gigabyte log file churn through hundreds of thousands of lines per second, you know the feeling: your log viewer is your window into the soul of your application.

When that window stutters, freezes, or eats 4 GB of RAM just to render plain text, it turns a stressful incident into a frustrating nightmare.

Over the past two years, LogViewer has undergone a remarkable multi-language journey. Before arriving at our current high-performance Rust and egui architecture, we evaluated and benchmarked multiple technology stacks—from our original C++/Qt codebase to native Swift/SwiftUI and Python evaluation spikes.

In this deep dive, I want to take you through the complete engineering story across our development stages: why I moved from language to language, how a backend database pattern (CQRS) solved our UI performance bottlenecks, how our new accessibility and AI features work, and how automated scans from RepoLens keep our supply chain secure.

Act I: The Multi-Language Evaluation Story

Building a lightweight, cross-platform desktop log viewer sounds simple until you test it against a 10 GB log file streaming 50,000 lines per second. Over the life of LogViewer, we evaluated four distinct language stacks:

 ┌──────────────────────┐      ┌──────────────────────┐      ┌──────────────────────┐      ┌──────────────────────┐
 │  1. C++/Qt Baseline  │  ──► │  2. Swift / SwiftUI  │  ──► │  3. Python           │  ──► │  4. Rust + egui      │
 │  (Original Engine)   │      │  (Mac Native Spike)  │      │  (Scripting Spike)   │      │  (Current Rewrite)   │
 └──────────────────────┘      └──────────────────────┘      └──────────────────────┘      └──────────────────────┘

1. The Original C++ & Qt Baseline

My journey began in C++ using the Qt framework (preserved in our internal archives). Qt provided cross-platform UI widgets, mature INI-based settings, and a rich C++ ecosystem. In version 0.50, I even added a dynamic C++ plugin architecture with machine-learning validation (plugin_validation.dat).

The Problem: The C++/Qt engine relied on QPlainTextEdit, which tried to load entire log files or large string buffers directly into memory. Opening a 2 GB log file froze the UI thread, spiked RAM usage to over 3 GB, and caused input lag whenever high-velocity log appends triggered Qt widget repaints. Furthermore, bundling the massive Qt runtime libraries bloated binary downloads.

2. The Native macOS Experiment: Swift and SwiftUI

To get standard Apple Human Interface Guidelines (HIG) aesthetics, I built an internal prototype in Swift and SwiftUI to test pure Apple platform performance.

The Good: Unmatched native macOS look and feel, instant integration with AppKit windowing, and smooth macOS system typography.
The Dealbreakers:
1. Lack of Cross-Platform Portability: LogViewer's core target audience includes macOS, Linux, and ChromeOS (Crostini). Swift on Linux remains cumbersome for desktop UI development, violating our cross-platform mandate.
2. Virtualisation Limits: SwiftUI’s ScrollView and LazyVStack struggled when rendering 100,000+ dynamic text lines without dropping back to complex NSTableView bridges and manual POSIX file descriptor polling.

3. The Rapid Iteration Experiment: Python

I also prototyped a Python implementation (evaluating PySide/PyQt, Tkinter, and terminal UI frameworks like Textual) to test fast parsing logic.

The Good: Unbeatable prototyping speed for regex pattern matching and string handling.
The Dealbreakers:
1. The Global Interpreter Lock (GIL): Python’s GIL prevented seamless multithreaded file indexing while keeping the UI responsive under heavy append streams.
2. Memory & Startup Overhead: Python's interpreter cold start was noticeable, RAM consumption scaled poorly, and packaging self-contained cross-platform single binaries via PyInstaller was fragile and heavy.

4. The Web / Electron Alternative (Discarded Immediately)

I briefly evaluated browser-based web wrappers (Electron/Tauri/Local Web UI). I discarded them immediately: launching a 200 MB Chromium process just to display plain text logs violates everything a lightweight utility tool should be.

Act II: The Winner — Rust & egui

In mid-2026, I launched a greenfield rewrite of the application. I selected Rust for the core engine and egui (an immediate-mode GUI framework) for the interface.

Why Rust and egui Win

Memory Safety Without Garbage Collection: Rust guarantees memory safety and data-race-free concurrency at compile time. We get C-level execution speed with zero risk of use-after-free or null pointer crashes.
Immediate-Mode UI (egui): Unlike traditional retained-mode UI frameworks (like Qt or SwiftUI) that maintain heavy widget trees in memory, egui repaints only what is visible on screen. It is lightweight, blazingly fast, and compiles into a tiny native binary without external runtime dependencies.

Bringing CQRS to Desktop Log Virtualisation

In my previous post on scaling MacAppUpdater with CQRS, I discussed Command Query Responsibility Segregation (CQRS) separating the system that writes data from the system that reads data.

We applied that exact same architectural pattern to our desktop log engine:

 ┌──────────────────────────────────────────────────────────┐
 │                    LOG FILE ON DISK                      │
 └────────────────────────────┬─────────────────────────────┘
                              │
                    Background Thread (Write)
                              ▼
 ┌──────────────────────────────────────────────────────────┐
 │         COMMAND MODEL: logviewer_engine Indexer          │
 │   • Scans byte offsets & line boundaries in background   │
 │   • Keeps lightweight 64-bit line offset table in RAM    │
 └────────────────────────────┬─────────────────────────────┘
                              │
                     Query API (Read Only)
                              ▼
 ┌──────────────────────────────────────────────────────────┐
 │           QUERY MODEL: egui Virtualised Viewport          │
 │   • Measures exact line height (TextStyle::Monospace)    │
 │   • Fetches ONLY visible lines (e.g. lines 10,000–10,040) │
 │   • Zero whole-file memory loading                        │
 └────────────────────────────┬─────────────────────────────┘

The Command Model (logviewer_engine): A high-speed background thread continuously scans the file on disk, indexing byte offsets and line boundaries into a compact line index table. It never loads full text strings into memory; it only tracks line start/end offsets.
The Query Model (Virtualised Viewport): When viewing a 10-million-line log file, egui does not request or render the whole document. Instead, it dynamically determines how many lines fit on screen based on display resolution, window size, scale factor, and font line-height metrics. The engine then returns only the slice of lines currently visible in the viewport (e.g., lines 10,000 to 10,040).

The Result: You can open a 10 Gigabyte log file in under 10 milliseconds. LogViewer consumes less than 15 MB of RAM, stays silky smooth at 60 FPS while scrolling, and never locks up the UI.

Act III: Next-Gen Features & Internal Prototypes

Beyond raw engine speed, our internal development iterations allowed us to introduce features designed for real-world developer workflows and inclusive design:

1. Apple Crash Log AI Analyser

Analysing raw Apple .ips crash logs or crash reports can be cryptic. During our recent feature development, we introduced a dedicated crash report parser. You can paste or drag an Apple crash log into LogViewer, and our local AI analyser parses the thread stack traces, highlights the crashing thread, isolates binary offset symbols, and provides clear, actionable recommendations on how to resolve the underlying bug.

2. Accessible Typography & Colour-Blind Palettes

Accessibility is often an afterthought in developer tools. We built a dedicated Accessibility Pack directly into LogViewer Settings:

Intel One Mono (Default Monospace): Built by Intel with low-vision developers in mind. Zeroes, capital Os, ones, lowercase Ls, and uppercase Is (0/O, 1/l/I) stay visually distinct.
Atkinson Hyperlegible Mono (Low Vision): Developed by the Braille Institute of America to maximise character legibility for low-vision readers.
OpenDyslexic Mono (Dyslexia): Features weighted bottoms and unique letter shapes to increase readability for developers with dyslexia.
Colour-Blind Palette Presets: Colour blindness is a vision palette issue, not a typeface issue. LogViewer includes curated Wong and Tol palette presets for Deuteranopia, Protanopia, and Tritanopia. Warnings and errors never rely on colour alone—they pair distinct colour tones with clear text tokens ([ERROR], [WARN]) and icons.

Act IV: Keeping Code Healthy — How RepoLens Protects the Pipeline

Building a high-performance desktop app is only half the battle; maintaining code quality and supply-chain security is the other.

In my workflow, I use RepoLens (vksvicky/RepoLens), an automated code review and security scanner built right here as part of the CycleRunCode Club.

RepoLens combines Fast Brain static analysis engines (gitleaks, semgrep, osv) with Slow Brain deep LLM reasoning (qwen2.5-coder:32b). When I ran RepoLens across the LogViewer codebase, it provided immediate, high-leverage value:

Real-World Audit Findings

Catching Vulnerable Supply-Chain Dependencies: RepoLens flagged critical RUSTSEC advisories in third-party crates (such as paste [RUSTSEC-2024-0436] and ttf-parser [RUSTSEC-2026-0192]). This allowed me to update or replace vulnerable dependencies before shipping to users.
Complementing Human Code Review: While our human code reviews focused on runtime UI focus and AppKit event loops, RepoLens analysed whole-repo security posture (scoring 80%), architecture (79%), and reliability (55%).
Preventing Data Leaks: RepoLens scanned all embedded resources and tests to ensure no local keys, internal paths, or unformatted plist environment variables leaked into release binaries.

Multi-Language & Architecture Comparison

Here is how our four language explorations stack up side-by-side:

Pros, Cons, and Where I Stand Today

The Pros

Blazing Performance: Instant startup, instant search, and zero lag on multi-gigabyte log files.
Inclusive by Design: First-class support for low-vision and dyslexic developers, paired with colour-blind safe palettes.
Security-First Architecture: Hardened by RepoLens scans and backed by Rust's strict compiler guarantees.
Fair Licensing: Sold as a clean, stand-alone desktop product with automatic updates via MacAppUpdater and LemonSqueezy—no mandatory cloud subscriptions.

The Cons & Intentional Trade-offs

No Font Ligatures: I explicitly excluded programming ligatures (like turning != into ≠). In a log viewer, exact character bytes must match what is written on disk.
Not a Terminal GUI Replacement for lnav: If you want SQL query engines inside your terminal TTY, lnav remains fantastic. LogViewer is built specifically for users who want a clean, windowed desktop experience on their second monitor.

The Road Ahead

LogViewer is currently in private development, but I plan to make the core BareTail-class engine open-source on GitHub in the near future. As part of our roadmap, I will be separating the advanced Pro features (LogViewerPro) into a distinct offering, which will introduce regex search filters, JSON document inspectors, and advanced log session persistence.

Rebuilding LogViewer through C++, Swift, Python, and finally Rust was a massive engineering journey, but applying CQRS principles to desktop text virtualisation and enforcing strict security scanning via RepoLens has given us a foundation that will scale effortlessly for years to come.

Stay tuned for our upcoming release builds! As always, if you want to follow along with our software development deep-dives, book updates, and project releases, be sure to subscribe to the newsletter.