Over the past few months I've tried out a lot of different local models. I have my own kind of benchmark for them — a file with a detailed spec for a notes editor for Linux written in Rust. Syntax highlighting (not hard, it's available out of the box in the system component) and a preview panel that should render formatted text. Overall, it's pretty similar to my Swifty Notes app, but in Rust.

So, Qwen3.6-27B is so far the only model that's made it to the finish line. It worked for 3 days (not around the clock, only when I was at the computer and could guide it). Occasionally the model had issues with tool calls. Sometimes it couldn't edit a file and would just stop — I had to ask it to try again. Overall I'd give this part a 4 out of 5.

The most important thing is that the model didn't go in circles. Rust is a great choice here: if there's an error, the project simply won't compile. Combined with the fact that the spec requires writing tests first and then the code (Test Driven Development), a lot of issues get caught and fixed at the earliest stages. And here the model performed pretty well. It fixed errors fairly quickly, followed the instructions from the spec, and consulted documentation if it suddenly used a nonexistent API or just needed to check what was available. A solid 4 out of 5 here.

The model size is 17.5 GB. I downloaded it through LM Studio but ran it via llama.cpp — surprisingly, the performance there is significantly better, even though LM Studio supposedly uses llama.cpp under the hood. Maybe more recent versions of llama.cpp are just better optimized.

The model doesn't fit entirely into VRAM (I have 16 GB), so it ran partially on the CPU, which heavily impacted speed. This whole thing was eating 15.94 GB of VRAM and another ~12 GB of RAM at peak (when the context was nearly full). I set the context size to 64k — at first that was plenty, but towards the end, as the codebase grew, the model would compact the context fairly often. Still, overall it handled a task of this size.

I'd give the speed a 2 out of 5.

When the model reported that everything was done, I launched the app and saw raw HTML text in the preview panel instead of a rendered view. I had to ask the model to fix it, and after another hour and a half or two I got an acceptable result. That said, it's worth mentioning that this kind of thing happens all the time even with flagship models — large tasks rarely work on the first try and usually require revisions and clarifications.

Bottom line: Claude Code would've done this task in 20–30 minutes, and I'd probably spend another 20–30 minutes finishing things up. Let's round up to 1 hour. With Qwen3.6-27B it took about 20 hours of continuous work in total, roughly 3 full working days. Of course, most of that time you're just sitting there watching the model work. Generation speed on the preliminary tests Claude helped me run was 12–18 tokens per second on my hardware.

The speed difference is huge. The result is acceptable. A lot of the required functionality just doesn't work, but I blame the context size for that — it's hard for models to hold that much code in memory.

Still, I'm happy with the result. It gives me hope that programming with local models on regular hardware is feasible. A year ago even cloud models were making similar mistakes, and local models of this size were simply not suitable for programming at all. Maybe in another year progress will get us to the point where subscriptions won't be needed for small projects. And I really like the trend that open-source free models have already caught up with the flagships from OpenAI and Anthropic.

The story of a bug: async that never runs

In 1.2.0 I collapsed all dialogs (FileDialog, ColorDialog, FontDialog) onto async throws and dropped the callback variants — felt cleaner that way. A day later it turned out that inside a running GTK application (g_application_run), code like Task { @MainActor in await dialog.open(...) } simply never executes. Swift's default main-actor executor is DispatchQueue.main, and the GLib main-loop doesn't drive it. The process looks alive, no errors surface, the button clicks — but the file dialog never appears.

1.2.1 urgently restored the callback variants for FileDialog, and 1.2.2 closed the hole completely: callback overloads were added for every async API (Clipboard, ColorDialog, FontDialog, UriLauncher, Texture.load). The async variants stay — they're useful for tests and non-GTK contexts — but inside GTK signal handlers the callback form is now the recommended default. The long-term fix (a custom SerialExecutor on top of GLib) is deferred as a separate task.

1.2.0: what landed in the API

• Async image loading. Texture.load(from:) decodes anything GdkPixbuf supports — PNG, JPEG, GIF, WebP, TIFF, BMP — off the main actor. That's a superset of what the native gdk_texture_new_from_filename handles.
• Animated image playback. AnimatedImagePlayer drives frames from a GdkPixbufAnimation into a Picture widget, with start / stop / advanceFrame.
• Application.onOpen and Application.run(arguments:) — file-open activation for apps registered with the G_APPLICATION_HANDLES_OPEN flag.
• Runtime widget type checks. Widget.gtkType, isInstance(of:), and a stricter tryCast that now actually narrows the type instead of "successfully" casting any widget to anything.
• Isolated deinits on GObjectRef, GVariant and other wrappers — GObject release now always happens explicitly on the main actor, not on whichever random thread dropped the last reference.
• Minimum toolchain bumped to Swift 6.2 — isolated deinit is experimental in 6.1, and the release toolchain refused to enable it.

1.2.3–1.2.5: conveniences and clipboard

Three small releases about reaching for CAdwaita less often for routine things:

• RGBA(hex:) — CSS color parsing: #RGB, #RGBA, #RRGGBB, #RRGGBBAA.
• IconTheme — a wrapper around gtk_icon_theme_get_for_display with addSearchPath(_:) for app-local icons.
• ApplicationFlags as an OptionSet: Application(id: "...", flags: [.handlesOpen, .nonUnique]) instead of raw bit masks.
• MainContext.drainPending() and pump(for:) — one-line replacements for the while g_main_context_pending { g_main_context_iteration } loop that every test suite kept reinventing.
• Paste interception. Widget.onPasteClipboard, the synchronous Clipboard.containsImage / containsFiles probes, async readTexture / readFiles, and Texture.encodedPNGData() — you can now intercept a pasted image in your editor and pipe it through your own import path, instead of letting GTK shove it in as text.
• Silencing GTK-CRITICAL spam from GtkScrolledWindow and misconfigured GtkDropTarget — an opt-in log filter plus the correct signatures for the ::enter / ::motion signals.

1.3.0: macOS as a development platform

The main news of the cycle. swift-adwaita now builds and runs on macOS 13+ on Apple Silicon. Linux remains the primary target platform, but you can now develop and test locally on a Mac without spinning up a VM.

• Install via Homebrew: brew install libadwaita gtksourceview5 pkgconf adwaita-icon-theme. Without adwaita-icon-theme, HeaderBar buttons and banners render empty — Homebrew doesn't pull it in transitively.
• Required environment variable: XDG_DATA_DIRS=/opt/homebrew/share, otherwise libadwaita can't find its GSettings schemas and aborts at startup.
• DemoAppLib — all 78 gallery examples now live in a separate library that downstream apps can link against directly. The DemoApp executable became a three-line shim.
• Xcode example in examples/macos/DemoApp/ — a minimal Xcode 16+ project that wraps the gallery as a regular .app bundle. Cmd+R, and it works.
• A parallel XCTest suite for macOS. swift-testing on Apple platforms inserts autorelease-pool transitions between tests that conflict with the Cocoa CFRunLoop sources installed by gtk_init — everything aborts on the second test. XCTest doesn't do that, and the same coverage runs there. Linux keeps using swift-testing. Result: 1181 tests / 0 failures on macOS.
• Three Apple-specific bugs that Linux/glibc happened to mask: Variant.stringValue returned nil for valid strings (a dangling pointer through g_variant_type_checked_); the localization helpers (localized, nlocalized) returned garbage when no translation was available (gettext returns the input pointer untouched, and the Swift→C bridge had already freed it); MediaStream.timestamp failed to compile because gint64 is long on Linux x86_64 but long long on Apple arm64.
• macOS CI job on macos-26 with Xcode 26.4.1 (Swift 6.3). Build only, no test runs: GitHub-hosted runners are headless, and GTK4-Quartz crashes without a WindowServer session.
• REUSE 3.3 license metadata — SPDX headers in every source file, reuse lint reports clean.

1.3.1: cleanup

A maintenance release with no API changes. I polished the paste-interception docs in the README, added adwaita-icon-theme to every macOS install snippet (stepped on it, wrote it down), and bumped the Xcode example's deployment target to macOS 26 so it matches what Homebrew now builds GTK4 against — otherwise the linker complains about every dylib.

What's next

The big unsolved problem is still the Swift Concurrency ↔ GLib main-loop integration. Right now you can't write Task { @MainActor in ... } from a click handler in a GTK app, and that's frustrating. The long-term plan is a custom SerialExecutor that routes work through g_idle_add_full instead of DispatchQueue.main. The callback APIs cover every practical scenario today, but a proper executor will need to be written eventually.

The project is open source under the MIT license. The source lives on GitHub, and the documentation with guides is here.

Star Fork

A few months ago @belbous was telling me about the AV1 video codec — how great it is. Recently I decided to experiment with it. Turns out my Ubuntu laptop has the right hardware — an NVIDIA GPU with support for hardware AV1 encoding via NVENC. This capability only arrived with the RTX 40 series: on the 30 series and older, NVENC can decode AV1 but not encode it — for that you're stuck with software on the CPU. Thankfully, it's all integrated into ffmpeg, ready to use.

With Claude Code's help, I dialed in the right settings using a handful of video files as test cases. The goal was to preserve quality while reducing file size. As a result, bitrate doesn't even appear in the configuration. What came out is a bash script that analyzes a video file with ffprobe and, depending on the resolution and color scheme, sets the CQ and other parameters.

Claude Code didn't just pick values at random: it ran several passes on a clip of video, compared the input and output files, pulled out frames, and evaluated the quality itself, even describing the scenes it was comparing — a footprint in the snow, a landscape with trees, Dexter's face 😁.

Initially, Claude Code based its approach on comparing three codecs — H.264, H.265 (aka HEVC), and AV1. The baseline assumption was: H.264 → H.265 yields about 50% compression, and H.265 → AV1 adds another ~30% at the same quality. That said, those 30% apply to software encoders (libaom, SVT-AV1) — hardware AV1 in NVENC runs many times faster, but at the same bitrate it loses to them in quality. I was mainly after disk space savings, so the tradeoff suited me.

On the side, I downmixed the audio to stereo with the Opus codec, since I'm going to be watching on a TV with regular (and pretty mediocre) stereo sound anyway, and I planned to play it from an iPad — which, historically, for some reason can't output 5.1 audio over HDMI (instead of sound, you get hissing).

The results are impressive. An episode of Foundation — 4K, HEVC, HDR — shrank from 10.2 GB down to 2 GB. Five times smaller! At visually the same picture quality. To be fair, though: the 5x compression here isn't pure AV1 efficiency so much as a consequence of the source having a very high bitrate (rips usually leave a generous margin). On files that are already compressed more tightly, the gains will be more modest.

A 45-minute episode took about 15 minutes to re-encode. For 4K video, that's very fast. And a 50-minute episode of Dexter in 1080p SDR re-encodes in just 5 minutes. Beautiful.

But there are downsides — out of the box, NVENC doesn't support HDR10+ or Dolby Vision, so that dynamic metadata gets lost during re-encoding. Regular HDR10 with static metadata passes through fine, so basic HDR is intact — the problem is only with the extended formats. There's some workaround where you encode that part separately and splice it back in afterward, but I decided not to bother — my TV isn't all that fancy, it wouldn't have displayed HDR10+ or Dolby Vision anyway. You could also use a different codec that does everything on the CPU — better quality there, and metadata is preserved — but then this same 4K episode would take many hours instead of 15 minutes. So it looks like I've landed on the perfect quality/time balance.

Today at an IT breakfast meetup I was singing the praises of Video Player — a video player from GNOME, formerly known as Showtime. As far as I understand, at some point it became the default video player, including in the latest version of Ubuntu.

I like its minimalism, it plays the files I need, and I appreciate that when you pick an audio track it shows the name of the translation (the dubbing studio) — for some reason not every player does this.

Got home, decided to compare it with other players, opened a file with HDR and Dolby Vision — looks like I praised it a bit too soon. In the screenshot, from top to bottom: Video Player (Showtime), Cine, and VLC.

All three render the colors differently. I think I'll switch to Cine. Judging by its repo, it's a fairly young video player. Like Showtime, it's also based on MPV and written in Python. It just develops more actively, updates ship more often, and — most importantly — the colors come out right. Showtime, as far as I remember, has had issues with HDR for years now, and updates only come out every three to six months.

VLC is a legend, of course — it can play just about anything that's playable — but the interface, in my opinion, has aged quite a bit. Time to make room for the new generation.

After shipping swift-adwaita, I've been focused on building a first app using it. Something simple, but handy for myself. So now the first app has been shipped.

Swifty Notes is a native GTK/libadwaita Markdown notes application for Linux written in Swift.

The desktop app is the primary experience: write, organize, and preview Markdown notes with native GTK widgets, autosave, remembered workspace state, and adjustable editor settings such as font size, wrapping, indentation, and appearance.

The included CLI works on the same file-backed notes so shell scripts, automation, and AI agents can safely inspect or update notes without a separate database or background service.

• Create, rename, duplicate, export, and delete Markdown notes.
• Autosave edits, remember workspace state, and keep note-local image assets together with each note.
• Adjust editor font size and other writing preferences to fit different screens and workflows.
• Choose where notes are stored, including a cloud-synced folder, so the same plain files can stay in sync across devices.
• Import images with drag and drop and render Markdown with a native GTK preview instead of a web view.
• Use the CLI for JSON-friendly note automation from scripts, shell pipelines, and AI agents.

Swifty Notes for Linux is an open source project, source code is available on GitHub.

Star Fork

Swift Adwaita 1.1.0 has been released. I’ve been working on a first app built with this library, so I’ve extended it and fixed some bugs.

Highlights

• Added GtkSourceView integration with typed Swift wrappers for source editing, syntax highlighting, languages, and style schemes.
• Expanded widget APIs around popovers, windows, calendar compatibility, and runtime lifecycle handling.
• Improved release stability with better GLib main-loop integration, broader CI coverage, and additional regression tests.

Added

• SourceView, SourceBuffer, SourceLanguage, SourceLanguageManager, SourceStyleScheme, and SourceStyleSchemeManager.
• Typed identifiers for GtkSource languages and style schemes.
• A new source editor demo example.
• MainContext.task { ... }, task(after:), and task(every:) as cancellable GLib main-loop work handles.
• Async MainContext.run, yield, and sleep(for:) helpers for bridging Swift concurrency onto the GLib loop safely.
• Widget.unparent() and PopoverMenu.unparent().
• Convenience presentation helpers for Popover and PopoverMenu.
• Additional regression tests for widget/window parent-chain lookup and expanded coverage for source editing and media behavior.

Changed

• GtkWindow.present() now retains windows until close, making transient or locally scoped windows safer to use.
• Widget.window now resolves the containing window through the widget parent chain instead of assuming the GTK root is always a window.
• Calendar date handling now uses a GTK compatibility shim so the package builds cleanly across older and newer GTK versions.
• Documentation generation and hosted docs configuration were updated.
• CI now installs and tests with GtkSourceView 5 system dependencies.

Fixed

• Fixed deferred signal/user-data cleanup to release captured closures through the GLib main loop instead of Swift main-queue tasks, avoiding lifecycle issues in GTK applications.
• Fixed a common GTK scheduling pitfall by offering a Task-like API that stays on the GLib main loop instead of DispatchQueue.main.
• Fixed Swift 6.1 serialized suite visibility issues in the test suite.
• Fixed the popover/window regression tests to avoid GTK crash paths in CI while still validating the intended behavior.
• Fixed release documentation and installation instructions to include GtkSourceView 5 development packages.

Documentation and CI

• Added an API documentation link to the README.
• Updated installation instructions for Ubuntu/Debian and Fedora.
• Improved inline documentation consistency across the wrapper API.
• Extended CI coverage for documentation, formatting, and Swift 6.1 / 6.2 / 6.3 test runs.

This is an open-source project licensed under the MIT license. The source code is available on GitHub. Documentation with guides is available here.

Star Fork

This release focuses on Swift 6.3 compatibility, a substantial rewrite of the editor's highlighting pipeline, and much better responsiveness when editing very large HTML documents.

Added

• Added the HTMLEditorBenchmarks executable target for repeatable performance measurements.
• Added benchmark support for full-plan highlighting, overlap reuse, edit invalidation, visible-highlight remapping, and large-document local repaint paths.
• Added focused regression tests for:
  • planner cache reuse and document-scoped invalidation
  • invalid NSRange and UTF-16 edge cases
  • quoted and unquoted attribute value highlighting
  • visible highlight state remapping
  • block-based highlight coverage
  • large-document editing and scrolling policies

Changed

• Refactored the editor runtime into smaller focused components, including separate coordinator lifecycle, viewport, editing, policy, coverage, structural-range, and visible-highlight-state files.
• Refactored the syntax highlighter into planner- and builder-based components for clearer separation of scanning, planning, and application.
• Moved the editor to an adaptive runtime model that changes behavior based on document size instead of treating all HTML documents the same way.

Improved

• Greatly improved large-document editing performance with:
  • viewport-first highlighting
  • document-scoped planner caches and targeted invalidation
  • cached visible-range plans
  • block-based highlight coverage tracking
  • structural dirty-range alignment around edits
  • two-phase large-file editing with immediate micro-pass and deferred wider repaint
  • burst-coalesced edit repainting
  • scroll-idle semantic highlighting
  • deferred binding synchronization for large documents
  • allowsNonContiguousLayout enabled automatically in large-file mode
• Improved highlight stability while typing in the middle of very large HTML by preserving visible overlay state and reducing repaint churn around the caret.
• Improved performance tuning and observability for large files with dedicated benchmark coverage and runtime probes.

Fixed

• Fixed compilation and concurrency issues needed for Swift 6.3 compatibility.
• Fixed several editor update-path issues related to coordinator state, highlighting tasks, and main-actor behavior.
• Fixed highlight regressions and edge cases involving:
  • partial tags
  • empty input
  • large payloads
  • attribute-value coloring
  • visible highlight loss during large-file editing
  • invalid or clipped visible ranges

Notes

• Full-document semantic highlighting is still used for smaller HTML inputs.
• Very large HTML inputs now automatically switch to a more conservative, performance-oriented editing mode to keep scrolling and typing responsive.

Try it on GitHub: https://github.com/makoni/HTMLEditor-SwiftUI

Star Fork

A project that I’ve always wanted to create: a library that enables the development of GNOME applications using Swift. While there are some similar libraries available, they appear to be incomplete or not actively maintained. Thanks to Vibe Coding, I managed to complete the project in approximately a week.

swift-adwaita is an imperative Swift 6 wrapper for GTK4 and libadwaita, built for creating native GNOME desktop applications on Linux.

It provides a modern Swift API over GTK and Adwaita with type-safe widgets, signals, property bindings, async operations, and ergonomic convenience helpers, while preserving the native behavior, styling, and feel of the GNOME platform.

• Native GTK4 and libadwaita application development in Swift
• Imperative API without a custom DSL
• Type-safe enums, signals, and property APIs
• Async/await support for common platform integrations
• Extensive widget coverage with a real demo application

Here’s a demo app built using swift-adwaita:

This is an open-source project licensed under the MIT license. The source code is available on GitHub. Documentation with guides is available here.

Star Fork

Highlights

• Refactored the internal request pipeline in CouchDBClient to use cleaner async/await-style flows and reduce duplicated response handling logic.
• Improved buffering and decoding paths for raw and typed requests, with a focus on safer EventLoopGroup execution and better performance in response processing.
• Expanded test coverage around EventLoopGroup-backed request execution, including raw and typed get, raw and typed find, attachment download, Mango index listing, and Mango query explanation.
• Refreshed user-facing documentation across the README, DocC articles, and tutorials.
• Updated documentation tooling for newer DocC workflows, including Markdown export support.

API and Behavior Improvements

• Added and refined EventLoopGroup support across more CouchDBClient request paths.
• Improved internal error-handling paths and response decoding behavior for CouchDB operations.
• Simplified request helper layering and reduced duplicated request/response processing code.
• Improved attachment-related behavior and accompanying tests.
• Added visionOS to supported platforms in the package manifest.

Documentation

• Fixed and refreshed README examples for CRUD and Mango query usage.
• Updated DocC landing pages to better reflect the current API surface.
• Corrected the Advanced Mango Query tutorial snippets to match the current typed query API.
• Corrected Vapor tutorial examples.
• Fixed Hummingbird tutorial package setup and dependency snippets.
• Updated buildDocs.sh to support:
  • configurable output and hosting base path
  • static hosting content embedding
  • experimental Markdown output
  • Markdown manifest generation
• Added a post-processing step in buildDocs.sh that injects a relative Markdown link into generated DocC HTML pages.

Tooling and Dependencies

• Updated package dependencies in Package.resolved.
• Updated the Ubuntu build workflow Swift version matrix.

CouchDB Client on GitHub | Documentation with examples and tutorials.

Star Fork

Actioneer 1.0.8 focuses on making live GitHub Actions monitoring more reliable while using the GitHub API more efficiently.

Highlights

• In-progress workflow runs now keep refreshing while they are still active, so expanded jobs and steps stay current before the run finishes.
• Expanded run details are more stable and easier to read, with clearer badges, preserved job context, and contiguous step numbering.
• Workflow status badges are now translated more consistently across the app's supported languages.
• Background refresh is lighter on the GitHub API, reducing duplicate requests and helping preserve rate-limit headroom.

Technical improvements

• Fixed several live-refresh lifecycle issues in the detail pane so switching repositories or rebuilding rows no longer disables the active refresh loop.
• Removed duplicate initial jobs fetches caused by rerender races around freshly expanded runs.
• Reduced unnecessary polling pressure by tightening selected-repo refresh ownership and job-refresh reuse.

Actioneer for Linux has translations available in numerous languages, including Russian, Spanish, French, Portuguese (Brazil), Hindi, Simplified Chinese, Arabic, Bengali, Urdu, German, and Dutch.

It also includes a built-in crash reporter, which you can copy and paste the report or open an issue on GitHub. Additionally, there are some tweaks and improvements made under the hood.

There were a bunch of updates of Actioneer for Linux recently, which I forgot to post here. Here's what's new in these updates:

1.02

• Faster and smoother UI with refreshed repo/workflow lists and improved scrolling behavior.
• New run filtering controls with better caching, so switching filters is instant and doesn’t reload data.
• Better workflow auto-refresh and run status updates, including fewer duplicate fetches.
• Notifications are more reliable across Snap/Flatpak, with improved icon handling and fallbacks.
• Improved sandboxed credential storage using the secret portal for Snap/Flatpak.
• Offline-friendly cache persistence for workflows, runs, and jobs.
• Packaging and CI updates across Snap, Flatpak, and AppImage for better compatibility.
• Dependency updates and stability fixes.

1.03

• Job logs now render ANSI colors, grouped workflow sections, and clearer command/output formatting.
• Aligned timestamps and command prefixes improve scanability, with stronger error highlighting.
• Packaging CI refreshed with multi-arch updates for AppImage/Snap/Flatpak builds.
• Dependency updates and demo log refreshes for improved accuracy.

1.04

• Handle expired job logs (HTTP 410) with clearer messaging instead of a broken view.
• Strip BOM markers in job logs so first-line timestamps render correctly.

1.05

• Manual workflow triggers now support workflow_dispatch inputs with dynamic parameter fields.
• Dependency updates for ryu, unicode-ident, and zmij.

Recently, I've been playing with Clawd / Moltbot / Openclaw bot. Of course, it ended up with asking it to write some code. Since I'm running it in a VM with Ubuntu Linux, I've been playing with developing some apps for it. And at some moment, I realised that I'm sending screenshots of an app, but each time I have to do it manually.

So I decided to automate that part. I tried some console apps for Linux that promised they can do screenshots, but none of them worked for me for some reason.

So I decided to write my own. I picked Rust, and Openclaw did some research for me about how it should be done. It ended up with a console app that uses the FreeDesktop Screenshot portal. It required creating a .desktop file so I could see that Gnome permission request and click Allow. That is required just once, so now I've automated it.

That's a pretty cool thing to be honest, which I already tried with an iOS app using UI tests - the AI agent just runs UI tests, gets screenshots from a report, analyzes them, and understands what is wrong with the app UI.

I pushed the app to GitHub and published a release with binaries, .deb, and .rpm packets for arm64 and amd64. And it got a nice automatic installation script. Since I made it using Openclaw, I called it Claw Screenshot.

Check it out: https://github.com/makoni/claw-screenshot

AppMetric version 1.14.0 has been released.

New

• Settings window with a "Launch at login" toggle.
• Updated app icons for Liquid Glass.

Improvements

• Faster and more stable updates: parallel requests with backoff during rate limits, while respecting the daily quota.
• Popovers now adapt to their content.
• Improved date formatting in charts.

The first update for Actioneer has been released. Here's what's new:

• Workflows refresh in the background so newly-dispatched runs appear automatically.
• Reduced API usage and fewer rate-limit hits with ETag-based caching — lists load faster and your quota lasts longer.
• The app remembers the repository you were viewing between launches.
• Better diagnostics and reliability for smoother everyday use.

Follow updates on X: https://x.com/ActioneerCI

This week I've released a new version of CompareShots. Nothing special, just updated the user interface to support Liquid Glass. Also, sharing the result image will not capture UI elements anymore.

Hard to believe, but this year CompareShots turns 10 years old. Time runs fast.

Actioneer is a native GNOME desktop client for GitHub Actions. It combines a GTK4/libadwaita interface with a Tokio-powered API client so you can browse repositories, inspect workflow runs, watch job logs, and receive notifications without leaving your desktop.

Key features

• Browse your GitHub repositories and view Actions workflows and recent runs quickly.
• Inspect run status (success, failure, queued, in progress) with clear badges and counts.
• View job logs: download and preview run logs for quick troubleshooting.
• Dispatch workflows, cancel running workflows, and re-run failed runs directly from the app.
• Favorites and quick search let you focus on the repositories and workflows that matter most.
• Desktop notifications for run completions and failures so you never miss important results.
• In-memory caching and efficient refresh make the app responsive while respecting GitHub rate limits.
• Secure authentication using OAuth, tokens are stored securely in keyring.

Acntioneer for Linux is an open source project, source code is available on GitHub.

Star Fork

Actioneer — a lightweight macOS app for developers and DevOps engineers who want fast, reliable access to GitHub Actions from the desktop.

Key features

• Browse your GitHub repositories and view Actions workflows and recent runs quickly.
• Inspect run status (success, failure, queued, in progress) with clear badges and counts.
• View job logs: download and preview run logs for quick troubleshooting.
• Dispatch workflows, cancel running workflows, and re-run failed runs directly from the app.
• Favorites and quick search let you focus on the repositories and workflows that matter most.
• Desktop notifications for run completions and failures so you never miss important results.
• In-memory caching and efficient refresh make the app responsive while respecting GitHub rate limits.
• Secure authentication using OAuth (PKCE); tokens are stored securely in the macOS Keychain.

Privacy & security

We only request minimum GitHub scopes required for the features you use. Authentication uses OAuth PKCE and tokens are stored in the macOS Keychain. We do not send your logs or tokens to third-party servers without your explicit consent. See the app’s Privacy Policy for details.

Getting started

Sign in with your GitHub account (OAuth), grant the requested scopes, and the app will list your repositories and workflows. For CI/CD administrators and individual developers alike, Actioneer makes monitoring and simple management of GitHub Actions fast and convenient.

Follow updates on X: https://x.com/ActioneerCI

A new version of CompareShots has been released. It's a simple app I wrote years ago to compare two images.

The new version 1.6 has been rewritten in SwiftUI. And I've implemented a couple of ideas from app reviews that a user suggested.

What's new:

• Choose your view: Easily switch between aspect fill and aspect fit with a new button.
• Move your images: In aspect fill mode, use two fingers to reposition images for the perfect comparison.
• Faster setup: Select up to two images at once for side-by-side comparison.
• Expanded language support and improved accessibility.
• Various bug fixes and performance enhancements for a faster, more reliable app.
• Various bug fixes and performance improvements.

Spent some more time on HTMLEditor for SwiftUI. There are significant performance improvements in the new version 1.0.3 (thanks to Claude Code).

Try it on GitHub: https://github.com/makoni/HTMLEditor-SwiftUI

Recently, I've implemented a feature that I wanted to add to the CouchDB Swift client for a long time. It's Mango Queries support. Finally, it is done in 2.3.0. Feels like the last remaining big feature.

Changelog:

• Introduced a robust and type-safe MangoQuery API for building complex selectors, projections, sorting, and pagination in CouchDB.
• Added support for specifying indexes via useIndex in queries to optimize performance.
• Added first-class support for uploading, downloading, and deleting document attachments (files/images).
• Comprehensive Attachments API test suite ensures reliability for file operations.
• Added models and API for creating, listing, and managing Mango indexes (MangoIndex, IndexDefinition).
• Tutorial and code samples for creating indexes are now included in documentation.
• Added support for CouchDB Mango _explain endpoint via MangoExplainResponse to inspect how queries are executed and which indexes are used.

CouchDB Client on GitHub | Documentation with examples and tutorials.

Star Fork

This website is working on Vapor - a server-side Swift framework. It's pretty old, popular, and well known.

I’ve used it for a few years already and always liked that it's fast and doesn't require a lot of memory on the server.

I'm keeping all dependencies up to date. But recently I've noticed that the website started to eat a lot of memory. It starts with about 20 mb of memory usage, but after a few weeks, I found that it ate about 750 mb on the server.

That's a lot for such a simple website, so I started digging. After reviewing the site code (which I didn't change for a long time), I couldn't find any issues (and AI agents too).

I use Leaf - a template engine from the Vapor team to render HTML. And there was an open issue on their GitHub repo describing exactly the same problem.

So I've asked Copilot to help me debug what's wrong. Pretty quickly, it added some new tests to my fork that did a lot of renders in a cycle. And leak util found retain cycles. So I fixed that with some weak annotation, but during the review of my PR, a maintainer suggested to just use unowned.

And that's it. 2 lines of code fixed memory growth. It's hard to believe, but after a few hours since the deploy, the website still takes only 2 mb of memory. So I'm very proud of myself today.

Morale: contribute to the open-source project that you use.

For my own purposes, I wanted to add a spell checker to one of my apps. It should check the text and automatically correct it. Built-in macOS writing tools work fine for English, but don’t work for Russian.

So after it's done, why not share it?

https://github.com/makoni/YaSpellChecker

A few months ago, I wanted to add a text editor to one of my apps with HTML syntax highlighting. I tried a couple of libs that I found on GitHub, but none of them really worked for me. Mostly, they are too heavy and try to do everything. And in the end, they are glitchy and buggy.

So inspired by vibe coding, I made my own. It works fine for me and doesn't try to be an IDE or a real code editor. Just a simple SwiftUI view with a text editor with syntax highlighting. Colors are customizable with a simple struct.

Try it on GitHub: https://github.com/makoni/HTMLEditor-SwiftUI

Couchdb Swift client lib

There are 2 new releases of couchdb-swift library. Copilot kindly added more unit tests to the library to cover more use cases. Mostly failures. I still had to tweak a lot manually, but it gave me some ideas. So I've added more error handling in these 2 recent releases. Also, it found a couple of minor bugs and fixed them, reviewed my PR, and suggested some improvements. Far from being perfect yet, but still pretty impressive.

Release Informer Bot for Telegram

At some moment, I found that Copilot Agent is available for my account, and I can simply start with an issue on GitHub, assign it to the agent, and see what it will do. I've started with a request to update the README for Release Informer Bot with some nice details about how it works and how to set it up.

After the agent finished the updated README, it gave me another idea. Setting up might be automated. So I've opened Visual Studio Code and asked the Copilot agent to add automatic creation of the required database and set it up with the required CouchDB indexes.

It also did a good job, but it still required some manual tweaks and changes. And during that, it led to one more release of the CouchDB client lib because I wanted to rely on a proper "not found" error.

It's hard to tell how much time Copilot saved me. But definitely a lot. Including my favorite automatic string translations. Hopefully, that will inspire me to ship more.

AppMetric version 1.13.0 has been released. Now on Swift 6, I've slightly tweaked the UI and removed the popover opening on launch (except for the first launch) — I concluded that it was rather annoying, especially if the app launches automatically after a reboot. Also added localization for several new languages.

Recently, I’ve released a few new versions of the CouchDB client for Swift. The latest version is version 2, and it includes several key changes:

• Updated the minimum required Swift tools version to 6.0.
• Adopted Swift Concurrency. CouchDBClient has been updated to be an actor.
• Renamed the library from couchdb-vapor to couchdb-swift to better reflect its purpose as a general CouchDB client for Swift, beyond Vapor-specific use cases.
• Made some changes to the initializer. Instead of passing a lot of parameters, it now accepts a Config structure.
• You can pass your own HTTPClient instance to be used in the client.
• Added translations for error messages.
• Introduced a dedicated tutorial for integrating CouchDBClient with the Hummingbird server-side framework.
• Added a shutdown() method to properly release resources associated with the HTTPClient.

CouchDB Client on GitHub | Documentation with examples and tutorials.

Star Fork

In the previous article, I've explained how to add a Strings Catalog to a Swift package to support localizations. Now, we'll try to translate it into more languages.

Recently, I've been working on a Swift Package with some strings that I wanted to localize. Apple's documentation on this topic seems to be a bit outdated. The documentation still suggests using language-specific directories for localizing resources and strings.

But, at WWDC 2023, Apple introduced String Catalogs. It's much more handy - just a JSON file that Xcode can fill with all the strings that need to be localized. Most of the examples you can find are about apps, not packages. So, I've spent some time trying to figure out how to use String Catalogs in a Swift package.

My Mac is using 2 folders to store apps: one is in the user folder ~/Applications, the second is the system applications folder at /Applications.

One day I created a search filter in Finder and saved it to have all the available apps in one place, also did put it to the sidebar in the Favourites section.

But also I love to have a shortcut in the Dock. So I've added a grid here too. It worked as I expected until I updated to macOS Sequoia and tried the iPhone Mirroring app once. Now the grid shows some apps from my iPhone too:

An interesting thing is that only Dock's grid shortcut shows the apps from my iPhone, but not the search in Finder.

And here comes the funny part - that's what you'll see if you will try to launch an app from your iPhone:

macOS 18.0 or later? Really? I wonder if that's some feature planned for a future macOS update. Will see :)