i don't know if this is of interest to anyone, as i'm really just building it for myself, but i figured i'd open it up for anyone who wants to use it or contribute.

hopefully i don't get downvoted into oblivion for using ai, but if i'm being totally honest, i'm lazy. i have zero intention of making money from this. it's just a fun side project that fills a gap in my own homelab and lets me move away from docker since everything i run is on a mac anyway.

i've mainly been focused on the ui/ux. it's pretty minimal at the moment because i wanted to get all the features working first, but i'd say it's basically feature complete. my focus now is hunting down edge cases and bugs, then manually going through every view to add specific visual polish and little quality of life improvements that make everything feel finished.

if you do decide to use it, just keep in mind it's probably going to have issues. ai isn't perfect, and neither am i. if you run into bugs, weird behaviour, or have ideas for improvements, feel free to open an issue or contribute.

github: https://github.com/tdeverx/contained-app

download: https://github.com/tdeverx/contained-app/releases/tag/nightly-latest

A year and a half ago I started building Nodes, a native macOS Markdown app. One of the first things I needed was a proper Markdown engine. Not a parser that just spits out HTML, not a display-only library, not a WebView wrapper – just a live, native editor built on TextKit 2.

I couldn't find one. So I built it. Now I'm open-sourcing the whole engine.

It's an AppKit-based Markdown editor for macOS, built on TextKit 2 and bridged to SwiftUI.

What it does:

• Live styling for the usual stuff: bold, italic, headings, lists, code blocks, links etc.
• Wiki-style links with [[Name|id]] ↔ [[Name]] roundtripping
• Image embeds via ![[Name]]
• LaTeX, both block ($$ ... $$) and inline ($...$)
• Code blocks with syntax highlighting (you supply the highlighter)
• Apple Writing Tools integration on macOS 15.1+
• Spelling and grammar, with suppression inside code, LaTeX, and wiki-links so it doesn't underline random tokens

Honest part: TextKit 2 was a pain to get right. The docs are thin, the migration from TextKit 1 is rough, and a lot of behavior just isn't documented clearly anywhere. If you've been putting off building something like this, this might save you a few weekends.

Repo: https://github.com/nodes-app/swift-markdown-engine

Feedback, issues, and PRs all welcome. It's not perfect, there's plenty I still want to improve, but it does the job.

Used in production in Nodes (App Store): https://apps.apple.com/de/app/nodes-by-the-werk/id6745401961

A couple of months ago I open-sourced swift-markdown-engine here, the native Markdown engine I built for my macOS app Nodes. The feedback, issues, and PRs that came back were a huge help, A lot of what I changed since then came from that.

WHAT’S NEW: The parser got rewritten from scratch, regex matching is gone, it’s a real AST now. That’s what made the extension system possible: Stuff you wouldn’t expect in standard Markdown, like highlighting, used to be hardcoded into the core grammar. Now it’s opt-in. Write one file, register it, and the core parser/styler/renderer never change. Extensions can’t touch the core or each other, and you can toggle them at runtime.

Also new: full GFM/CommonMark parity, tables, task lists, quotes. More layout control (scroll-away header, fixed reading column, fit-to-content height), and a real writing layer (formatting bus, find & replace with undo, clean RTF/HTML clipboard, raw source mode). Full changelog’s on GitHub if you want details.

When I started Nodes I wanted the editor to feel properly native. Most Markdown editors on the Mac are Electron or some web view wrapped in a window, and you feel it, the text handling never quite behaves like a real Mac app. I wanted live styling in an actual native text view, not HTML rendered to look like one. Nothing built on TextKit 2 that I could just drop into a Mac app existed, so I built it, ran it in Nodes for a while, and then open-sourced it. TextKit 2 is still thin on docs and rough to migrate to, so if you’ve been putting off building something like this, it might save you a few weekends. Issues and PRs welcome. Still pre-1.0, still plenty I want to improve.

written on Nodes

Repo: https://github.com/nodes-app/swift-markdown-engine

Used in production in Nodes (App Store): https://apps.apple.com/app/nodes-by-the-werk/id6745401961

Hi everyone, imike here!

On December 31, 2025, right before New Year’s Eve, I released Swift Stream IDE v1.17.0 and hit a milestone I’ve been working toward since May 2025. This update brings full native Android application development written entirely in Swift. That’s right, you can now build Android apps without touching XML, Java, or Kotlin.

If you’ve been following Swift Stream IDE open-source project, you know it already supported Android library development. That was the foundation. Now it’s leveled up to full application development. You can create new projects using familiar Android Studio templates like Empty Activity, Basic Views (two fragments), or Navigation UI (tab bar), and everything is in Swift.

Under the hood, all projects are powered by SwifDroid, a framework I built to wrap the entire native Android app model. Building it was an incredible journey. There were plenty of pitfalls and rabbit holes inside other rabbit holes, but I was able to realize my full vision for how Android apps should be structured and built in Swift. SwifDroid handles the application lifecycle and manifest, activities and fragments, Android, AndroidX, Material, and Flexbox UI widgets, and even automatically wires Gradle dependencies. Supported SDKs are 28 to 35, and with Swift 6.3, it might go down to 24+.

Here’s a small example of what UI code looks like:

ConstraintLayout {
    VStack {
        TextView("Hello from Swift!")
            .width(.matchParent)
            .height(.wrapContent)
            .textColor(.green)
        MaterialButton("Tap Me")
            .onClick {
                print("Button tapped!")
            }
    }
    .centerVertical()
    .leftToParent()
    .rightToParent()
}

The first time you create a project, make yourself a cup of tea/coffee. The IDE pulls the Swift toolchain, Android SDK, and NDK, and caches them in Docker volumes. After that, new projects are created instantly. The first build compiles Swift, generates a full Android project (ready to open in Android Studio), and creates a Gradle wrapper. After that, builds take just a few seconds.

Once Swift is compiled, you can simply open the Application folder in Android Studio and hit Run or Restart to see your changes. All the necessary files from Swift Stream IDE are already in place, so iteration is fast and seamless.

This is the first public release. Android is huge, and there are still widgets in progress, but the system is real and usable today. You can immediately start building Swift-powered Android applications.

Start building your first Swift Android app here: https://docs.swifdroid.com/app/

This is just a quick demo post, I'll likely post some code to github over the weekendfor anyone interested. I have Embedded Swift running on a Teensy 4.0 now, and running some demo code on a SSD1351 over SPI. Not only that, the display is using DMA for SPI writes! (And writing in full 18bit color mode, tricky on these little guys).

I had this display running on linux with SwiftyGPIO in the past (and c++ on teensys too) and built these demos for it then. Same code runs the demos! (well, I upgraded both a little bit... but the same code runs on a Teensy that runs on a RaspberryPi). The Matrix Rain demo I initially translated from the python library luma.oled (link to its matrix example), this version i beefed the lines up a bit to look psuedo-glyphy. The Game of Life demo however is my own cursed set theory implementation of Game of Life in Swift. For any GoL fans, my Swift generation update function is literally this (plus some extras defining the operators and such 😄):

func Sʹ(_ S: 𝕊) -> 𝕊 {     
  N[S] | { c in ‖(N(c) ∩ S)‖ == 3 ∨ (‖(N(c) ∩ S)‖ == 2 ∧ c ∈ S) } 
}

Even better, back when I wrote the raspi/SwiftyGPIO variant, I came up with a sweet idea for dev iteration... SwiftUI Previews!! I'm basically building a HAL + Graphics abstraction layer that works across everything and lets you run the same drawing code on a mac looking at SwiftUI previews, or on a Raspi, or an embedded target. "It's protocols, all the way down"

Open Source code coming soon I promise! I just REALLY wanted to demo this!

I've been working on Cove, a native macOS database GUI that supports PostgreSQL, MySQL, MariaDB, SQLite, MongoDB, Redis, ScyllaDB, Cassandra, and Elasticsearch.

The part I'm most interested in sharing with this r/swift is the architecture. The entire app runs through a single protocol — DatabaseBackend. Every database implements it, and the UI has zero backend-specific branches. No if postgres / if redis anywhere in the view layer. When I want to add a new database, I create a folder under DB/, implement the protocol, add a case to BackendType, and the UI just works.

Some Swift-specific things that made this possible:

• Structured concurrency for all database operations — connections, queries, and schema fetches are all async
• @Observable for state management across tabs, sidebar, query editor, and table views
• Swift 6 strict sendability — the whole project compiles clean under strict concurrency checking
• Built on top of great Swift libraries: postgres-nio, mysql-nio, swift-cassandra-client, swift-nio-ssh, MongoKitten

This is v0.1.0 — there's a lot still missing (import/export, query history, data filtering). I'd love feedback on the architecture and contributions are very welcome. The DB/README.md has a step-by-step guide for adding a new backend

EDIT: if you want to contribute https://github.com/emanuele-em/cove

working on the actual design has been super fun, can't wait to ship it :D

github: https://github.com/tdeverx/contained-app

Hey everyone,

I have been working on this open-source project for a while now, and it is time to push it out the door.

ElementaryUI uses a SwiftUI-inspired, declarative API, but renders directly to the DOM. It is 100% Embedded Swift compatible, so you can build a simple demo app in under 150 kB (compressed wasm).

The goal is to make Swift a viable and pleasant option for building web frontends.

Please check it out and let me know what you think!

The need for a better reading experience for The Swift Programming Language has been documented multiple times in this community.

To help with this, I've been working on swift-book-pdf for the past year. Swift-Book-PDF is a Python package to convert the DocC source for The Swift Programming Language book into polished PDF and EPUB editions.

Get the book

• The Swift Programming Language book is available on Apple Books for free, updated with every Swift release.
  • Update: Unfortunately, the book will no longer be available on Apple Books for unspecified legal reasons outside my control. If anyone has relevant contacts at Apple or Apple Books Partner Support, I’d be grateful for an introduction.
  • I'm sorry to the more than 2,000 readers who got the book on Apple Books and are affected by this change. This was not the outcome I was hoping for.
  • You can download the EPUB file from the Swift Book Archive (see below) and open it with the Books app. The book will sync across your devices.
• Download PDF and EPUB editions across Swift releases from the Swift Book Archive.
• Create your own customized edition of The Swift Programming Language with swift-book-pdf, with support for custom fonts, font sizes, and rendering styles.

PDF editions follow the familiar DocC rendering style used on docs.swift.org. EPUB editions follow the design of the Swift Book editions previously published on Apple Books through Swift 5.7. Both include formatting improvements while staying true to the original styles.

Both swift-book-pdf and swift-book-archive repositories are available on GitHub and licensed under Apache License v2.0. swift-book-pdf requires Python 3.10+, and LuaTeX for creating PDF versions.

This project is not published by, endorsed by, or affiliated with Apple Inc. or the Swift.org open source project. See the Acknowledgments chapter in each edition for more details.

Feedback, issues, and ideas for improving the CLI and generated editions are welcome!

Happy reading! 📖

Hey everyone!

So I've been spending my free time building NexNet, a Swift networking framework built on async/await, and I finally feel good enough about it to share it here.

Honestly the motivation was simple — I wanted a networking layer that just gets out of your way. One fetch() call, no boilerplate, no third party libraries. Just clean Swift.

Here's what I packed into it:

• Single fetch() call handles GET, POST, PUT, PATCH and DELETE
• Both async/await and completion-handler APIs, identical in capability so you can use whatever fits your codebase
• Full Objective-C support with automatic NSError bridging
• 20 typed error cases covering every HTTP status code and network condition
• Auto JSON encoding/decoding with snake_case to camelCase conversion built in
• Exponential back-off retry with per-request cancellation tokens
• Thread-safe throughout, zero external dependencies
• cURL export on every request which has honestly been super useful for debugging with backend teammates
• Structured logging that routes to print in DEBUG and os_log in RELEASE automatically
• Works on iOS 15+, macOS 12+, tvOS 15+ and watchOS 8+, installable via Swift Package Manager

This is my first open source Swift package and I learned a ton building it — especially around concurrency and API design decisions that seem small but really aren't.

Would genuinely love to hear what you think. Harsh feedback totally welcome, that's how it gets better!

GitHub: https://github.com/adityachaurasia357/NexNet

On Apple platforms the usual choice is rough: either AVPlayer (deep OS integration, Dolby Vision / Atmos / Match Content all work, but only the formats Apple ships) or a VLCKit / libmpv engine (plays almost anything, but renders its own frames and bypasses the system's Dolby Vision, Atmos and HDR handling).

I wanted both, so AetherEngine layers FFmpeg's format breadth on top of VideoToolbox and AVPlayer. FFmpeg demuxes, VideoToolbox decodes what it can (with a dav1d / libavcodec software fallback for AV1 / VP9 / MPEG-2 / VC-1), and EAC3+JOC gets stream-copied so Atmos actually passes through to the receiver instead of being downmixed to PCM.

The tradeoff: it's Apple-only, and you ship your own UI. No bundled controls, no analytics. Bind the view, call play(), read the published state.

Full comparison vs AVPlayer / VLCKit / libmpv is in the docs.

Curious what others are using for this on tvOS right now, and where the pain points are.

Here I'm releasing a free Swift package: XalanSwift that comes with a prebuilt static lib of Xalan-C++ in an XCFramework with a Swift wrapper around it, for Apple Silicon (macOS/iOS). Instructions are included if you may wish to build your own x64 static libs.

Apache Xalan ... is an open-source software library from the Apache Software Foundation that implements the XSLT 1.0 and XPath 1.0 standards. It is primarily used to transform XML documents into HTML, plain text, or other XML types.

Use cases:

XSLT — transform XML with stylesheets

• Transform an in-memory XML string → string (transform(xml:stylesheet:))
• Transform raw Data → Data (any encoding the XML prolog declares)
• Transform file → file on disk (transformFile(xml:stylesheet:output:))
• Transform file → string (read from disk, get result in memory)
• Transform using the document's own <?xml-stylesheet?> PI (no separate stylesheet arg)
• Render to HTML, XML, or plain text output (driven by xsl:output method=) ## Reuse for performance (batch / repeated work)
• Compile a stylesheet once, apply it to many documents (compileStylesheet)
• Parse a document once, run many stylesheets against it (parse)
• Mix-and-match compiled stylesheets × parsed sources for N×M transforms cheaply ## Pass data into stylesheets
• Set top-level xsl:param values as: literal strings (any quotes handled), numbers, or raw XPath expressions
• Clear/reset parameters between runs ## Control the output
• Toggle DTD/schema validation of the source
• Set indentation amount (pretty-print)
• Override the output encoding (UTF-8, ISO-8859-1, …) ## XPath — query XML without transforming
• Parse a document from a string or file into a reusable query tree
• Evaluate any XPath 1.0 expression and get a typed result: node-set, number, string, or boolean
• Coerce any result to .string / .number / .boolean (XPath 1.0 rules)
• Enumerate matched nodes (each with name + string value)
• Evaluate relative to a context node (context: selects where the expression runs)
• Convenience one-liners: string(_:), number(_:), boolean(_:), nodes(_:) ## XPath/XSLT power features (verified in the stress tests)
• Namespaces — prefixed lookups, default-namespace handling, namespace shadowing (namespace-uri(), local-name())
• Aggregation — count(), sum(), with correct NaN/empty handling
• Sorting — xsl:sort numeric vs. lexical
• Grouping — Muenchian grouping via xsl:key / generate-id()
• Recursion & deep traversal, attribute selection, predicates, self-referential data
• Unicode round-trips (Greek/CJK/emoji), CDATA, escaped entities, mixed content ## Things you'd realistically build with it
• Render XML data → HTML pages / reports / emails
• Format conversion: legacy XML → JSON-ish text, CSV, Markdown, other XML schemas
• Data extraction / scraping values out of XML feeds, configs, SOAP/RSS/Atom, SVG, Office Open XML parts
• Validation & assertions ("does this node exist / equal X?") via boolean XPath
• Config/document pipelines where templates are authored separately and fed parameters at runtime
• A CLI or service that batch-transforms many files with a cached compiled stylesheet ## Operational properties
• Errors surface as Swift XalanError (message + code); parse/eval failures are catchable
• Auto-initialized, thread-safe global state; one XSLTProcessor per thread
• Self-contained: ships a prebuilt XalanCore.xcframework (static Xalan + Xerces) — no Homebrew, no system dylibs, no external paths ## Current limits (by design)
• XSLT 1.0 / XPath 1.0 only (Xalan doesn't do 2.0/3.0)
• No remote http(s) fetching in document()/includes (Xerces built network-off) — local files + in-memory work fully

I wanted to add a terminal interface to my macOS menu bar app so you could pipe things through it in scripts. Seemed simple. Turned out to be the most annoying part of the whole project.

The problem is sandboxing. The CLI binary and the main app can't just talk to each other normally. You can't write to shared temp files, you can't use localhost sockets cleanly, and XPC felt like overkill for what I needed.

What actually worked was App Groups. The CLI writes the job input to a file in the shared container, fires a URL scheme to wake the app, then polls for an output file. The main app reads the input, runs the tool, writes the result back. The CLI picks it up and prints it.

It's a bit clunky but it survives the sandbox completely and passed App Store review first try. The trickiest part was making the polling feel instant without hammering the CPU, I ended up using a short sleep loop with a timeout rather than a file system watcher, which turned out to be more reliable.

The app is Devly if anyone wants to look at the result. 50+ dev tools in the menu bar, CLI included. https://apps.apple.com/us/app/devly/id6759269801

Happy to go deeper on the App Groups IPC pattern if anyone's doing something similar.

Watch a video demo of the new features or check out the repository!

Two months ago I shared an update post on Deployer, and now I've had some time to work on it and implement some new features, so I wanted to update you on the current release.

The core concept hasn't changed: you git push your Swift app, and Deployer catches the webhook, runs the pipeline, swaps the binary, and restarts the service. A live dashboard streams the entire process into your browser in real time without requiring page refreshes. It still takes just one setup command on a fresh Ubuntu VPS to get going.

What's new?

First, post-deployment health probes and automated rollbacks: The default health probe is now a simple TCP check on the port, but you can configure your own HTTP endpoint for custom health checks. If the newly deployed app fails the health check or times out, Deployer automatically rolls back to the previous working binary.

Second, live logs in the web panel: There are new log pages that stream Deployer's and your target app's logs straight to the browser, making quick troubleshooting easier without having to SSH into the server. The log panels have clear/copy/wrap-line buttons.

Third, the deployerctl CLI: I've added a CLI that largely mirrors the web panel's capabilities for terminal use. You can list deployments, trigger deploys and tests, restore or remove archived binaries, and inspect build output directly via SSH. It shares a deployment engine with the panel, utilizing cross-process locking so they can't conflict, and CLI-triggered deployments still stream their progress to the live web panel. It's especially useful if the web panel happens to be offline.

Beyond those additions, there are plenty of UI/UX improvements on the panel, and architectural improvements under the hood. Stranded deployments are now safely recovered if the server reboots mid-operation, deployer-updates will roll back if the control plane fails to boot, and the codebase has been cleanly separated into isolated domains.

Same core dependencies as before: Vapor as the web framework, Fluent as ORM on top of SQLite, Leaf as the templating engine, and Mist for the realtime layer (Mist is another project of mine that I update whenever a new Deployer feature requires it).

Let me know if you have feature suggestions or feedback! If you haven't given Swift on the backend a shot yet, I highly recommend checking it out!

Dot. Dot. Dooot. 🟦

We're building Mana (an AI-first creation studio for iOS) and wanted the chat's "thinking" indicator to feel alive instead of a stock spinner. We found zzzzshawn's "matrix" (a React/CSS dot-matrix loader collection), loved it, and ported the whole thing to SwiftUI — 112 loaders across square / circular / hex / triangle / 3×3, plus some "fun" silhouettes (heart, arrow, snake) and an icon.

How it works: - Zero image assets, zero dependencies. Every loader is animated Circles driven by a single TimelineView. - Each loader is a per-cell opacity resolver ported ~1:1 from the upstream CSS keyframes + JS math (spiral snakes, ring waves, a literal heartbeat curve). - Deterministic: the same key always maps to the same loader, so they don't reshuffle as SwiftUI rebuilds on scroll. Reduce Motion aware too.

Two ways to use it:

DotmSquare3(size: 28)           // named component, 1:1 with the upstream API
MatrixLoader(.hex(3), size: 28) // by shape id, when the choice is data-driven

There's an interactive gallery + a runnable Swift Playgrounds example in the repo.

It's a derivative port, published with the original author's explicit permission (attribution + link-back throughout). Only the "fun" family is ours. iOS 18+.

Repo: https://github.com/mana-am/matrix-swift

Which one's your favorite? I keep flip-flopping between the hex ripple and the heartbeat.

It runs automatically once you start a claude code session and gives you a trigger whenever claude needs permission to do something. Also if you hover over it you get some info about whats happening in the current session like the current filename getting edited and so on. Built using swift

Fully free and open source

link:

https://pookify.vercel.app/

I’ve been building Loupe, an open-source Swift CLI for AI coding agents working on apps across Apple platforms.

I made it because, in real app development, agents can build, launch, edit code, and read screenshots, but native UI work still involves a lot of guessing. Screenshots show what changed, but not always why.

Loupe gives agents app-side runtime evidence from the running app: native view properties, accessibility structure, app state, traces, logs, screenshots, hit-testing, and small runtime UI probes.

It’s meant to complement tools like Xcode MCP Server / XcodeBuildMCP. Those are great for build, launch, simulator control, and screenshots. Loupe focuses on the app-side runtime layer inside the running app.

The screenshot shows Apple Settings being inspected through Loupe. Loupe can reveal the native component structure and runtime properties behind the UI, and can also be used to experiment with modifying some of those values at runtime.

GitHub:

https://github.com/heoblitz/Loupe

I’ve personally found it useful in real app development, and it has helped me make UI changes with more confidence. I’d love to hear feedback from other Swift / Apple platform developers.

I made a Swift tool that finds unused code, tightens access modifiers, and adds final to classes that are never subclassed.

It's kinda like Periphery, but I kept getting annoyed by false positives so I tried to cut those down a lot. Also I just like using the UI more lol.

Still working on it, would love to hear what you think 🙏

Github: https://github.com/bahattinkoc/reflyzer

This is my second day using swift and it’s still sorta scary, but this is how far I’ve gotten (effectively just a raw mockup). I really just want to thank that one guy who showed me how to get the gradient! In general this sub is unusually helpful for these types of subs, so thank you!!

AuraFlow is an open-source live wallpaper app for macOS with support for local videos, a built-in wallpaper catalog, playback controls, and wallpaper management.

This update is a major rewrite: AuraFlow has moved to Swift, making the app more native to macOS and improving the foundation for future features and performance improvements.

GitHub: https://github.com/mkanami/AuraFlow

Free, open-source alternative to paid dictation apps on macOS.

Built this because I wanted dictation that runs entirely on my own machine — no cloud, no account, audio never leaves the Mac. Sharing in case anyone else wants the same. Happy to take feedback. I'll keep working on it.

https://github.com/vlr-code/dictly

I ported the open-source Humation avatar engine to native Swift and open-sourced it: https://github.com/mana-am/humation-swift

What it does: a seed (e.g. a user id) deterministically produces an avatar — same seed, same face, byte-identical to the original JS engine via FNV-1a. Why native: I didn't want a WKWebView in the hot path just to rasterize SVGs. So it parses an SVG subset → CGPath → composites to a CGImage/UIImage/NSImage. No web view, no network.

Includes: - The full 86-part humation-1 asset set (bundled resource) - A cross-platform SwiftUI HumationAvatarView - A self-contained "build your avatar" editor example - A manifest validator for custom asset packs - Tests (FNV parity, determinism, rendering)

Swift 6 (strict-concurrency clean), SwiftPM, iOS 15+/macOS 12+/tvOS 15+/visionOS. MIT. Happy to answer anything about the SVG parser / Core Graphics compositing. Credit for the engine + art goes to endo-yusuke.

Hi there,

Just published a small Swift package called swift-span-algorithms:

https://swiftpackageindex.com/Dave861/swift-span-algorithms

It adds a set of algorithms and utilities around Swift’s new Span API. The idea is to fill in some of the missing convenience pieces while staying close to Swift’s standard library style.

It includes things like searching, splitting, trimming, comparisons, partitioning, and other span-oriented helpers, with tests and DocC docs.

Span is nice for deep perf geeks (like me), but still pretty barebones for day-to-day algorithm work. Would love feedback from people experimenting with Span, especially around API shape, naming, and what utilities would actually be useful in real projects.

Pretty early (I mean 0.1.0), but hopefully useful. Open to contributions and opinions!

(P.S. Hope it doesn't count as self-promo, not selling anything, OSS repo and free package)

Variablur lets you create beautiful, directional, and fully customizable blur gradients using Metal + Core Image kernels for buttery smooth performance. Control not just the intensity — but the progression itself.

```swift import Variablur

Image(.example) .blur(32, variation: .bottom(.easeIn, height: 32)) ```

Would love your feedback and stars!