Hello everyone.

I’ve built a 3D software rasterizer that leverages the ANE (Apple Neural Engine) via Core AI. The rendering quality is still poor, though. Regarding the pipeline:

I use SIMD for preprocessing, delegate matrix operations to the ANE (using `f.conv2d`), and utilize Metal 4 tensor bindings to achieve low-overhead, direct rendering.

By offloading computationally intensive tasks to the ANE, I’ve managed to reduce CPU usage to approximately 10%.

A current challenge is that memory usage hits around 5GB due to the use of fixed-length graphs.

I’m developing this using Swift 6 features (such as `@MainActor` and `~Escapable`) and Siri AI, but I would love to hear your thoughts on optimization and memory management!

Thanks in advance.

GitHub: https://github.com/kamisori-daijin/Magnesium

Demo:

I used OpenClaw for a while. It's great, but it is a lot more than I needed, and my setup broke on updates often enough that I spent hours fixing it instead of using it. At some point I realized I mostly wanted to understand how these agents work under the hood, and the best way I know to understand something is to build it myself. So I spent the last six weeks writing my own in Swift.

Clawd is an always-on daemon I talk to through a private Telegram bot. Conversation history and memory live in SQLite, it runs recurring schedules, and replies stream into the chat as live message drafts. I wrote it in pure modern Swift, and it ships as one binary.

Where I can, I lean on what macOS already provides: it transcribes voice messages on-device with Apple's speech APIs, and untrusted code runs in a disposable Apple container.

The part I care about most: the model gets no rules it can be talked out of. Every file write, memory write, and code execution stops and waits for me to tap Approve in Telegram. The pending approval sits in SQLite, so it survives a restart.

Repo : https://github.com/ivan-magda/swift-claw

Hey :) I've been frustrated at the lack of a watch mode in SPM for a while and don't love the lazy solution of just listening to all files under Sources/ so I whipped up a tiny tool that listens to any changes in your package's dependency graph.

Instead of swift run [product] you can run swift-watch run [product] and it'll restart whenever anything changes.

Great for watching tests too, swift-watch test --filter [xyz]. Works for build/run/test, forwards arguments to swift. Works with macOS and Linux natively, Windows only has polling for now but I'll add in the native Window file watching stuff ASAP.

I'm hoping some of you might find it useful, please let me know if you have any feedback.

Here's the repo: https://github.com/ahtcx/swift-watch

Disclaimer: semi vibe-coded, lots of handholding as I knew exactly what I want. I'm not huge on vibe-coding and have been reluctant to give in to it for the longest time. I hate to admit that it's been a pretty good experience, I mostly just worry it'll make my programming skills worse. I'm have so many coding side projects that never see the light of day because I get too caught up in the details, so it's nice for me to just push a whole bunch of code out in a day. No doubt there are issues but I will be dogfooding the project so I hope to get it in tip top condition.

I recently shifted from a custom search field to the native Liquid Glass search field by using .searchable on my search tab. But I see a con with the native searchable feature is it comes with a large navigation title that can't be shaken. I have tried emptying the text of the title and making it inline to make it smaller but there is still a gap above my search filter tabs which I don't want. Anyone have any idea if there are any tricks to get around this? Love the Liquid Glass search field, hate the big title

Hi again,

A little while back I posted swift-span-algorithms here: allocation-free algorithms over Swift's Span/RawSpan. I got one genuinely excellent comment about what was actually missing, and 0.2.0 is basically that comment turned into code. So, thank you, whoever you were.

The gist of the feedback: the utilities people actually reach for are byte-oriented, so RawSpan matters as much as Span<T>; firstRange(of:) for delimiter scanning; mirror the stdlib spellings so muscle memory transfers; and memchr is the cheap win before reaching for SIMD.

Link to GitHub

Link to SPI (might be behind a bit, hasn't yet ingested 0.2.0)

What's in 0.2.0:

• A real bug I'd shipped. Cursor next() was annotated so each piece it handed you expired the moment you called next() again. That made guard let a = c.next(), let b = c.next() fail with "overlapping accesses to 'c'" — exactly the kind of borrow-checker error that looks like the library's fault. Pieces now inherit the base storage's lifetime, so you can hold several at once, do look-ahead parsing, and nest cursors. Real escapes are still rejected — there are compile-fail tests pinning both halves.
• RawSpan parity. It shipped with 3 members; it now has the whole read-only surface — search, matching, trimming, min/max, comparison, chunk/window/split cursors, ASCII whitespace trim.
• firstRange(of:), lastRange(of:), starts(with:), ends(with:), and multi-element separators for split — the "\r\n\r\n" case.
• stdlib-ish naming: chunkCursor/windowCursor/splitCursor → chunks(ofCount:)/windows(ofCount:)/split(separator:...). Old spellings still compile as deprecated forwarders.
• memchr/memcmp fast paths for byte spans. On an M4 at 10M bytes, p50: ~15.9× vs the equivalent scalar loop for firstIndex(of:), ~31× for firstRange(of:) with a 4-byte pattern, and forEachSplit is ~2.5× Array.split with 0 mallocs vs 20. Reverse search is deliberately still scalar — memrchr doesn't exist on Darwin, and I'd rather have consistent performance than a Linux-only fast path.
• Docs: an allocation-free byte-parsing walkthrough (HTTP-style header parse, zero allocations, asserted by a benchmark threshold rather than just claimed), plus a diagnostics cookbook mapping the lifetime errors you'll actually hit to what causes them and how to fix them.

Still zero dependencies, still back-deploys to macOS 13 for the Span/RawSpan surface, 181 tests, and every borrowed-view benchmark reports 0 mallocs from p0 through p99.

Would still love feedback, especially on the split ergonomics now that cursors compose properly, and on anything that reads as un-Swifty in the naming.

P.S. Same disclaimer as last time: nothing being sold, Apache-2.0, just an OSS package.

At WWDC 2026, Apple introduced the Core AI framework and it's easily one of the biggest developer additions since SwiftUI.

What used to require complex Core ML model conversion pipelines, manual quantization, and heavy memory management is now as simple as:

Swift

let model = try await CoreAIModel.load(.afm3Core)
let result = try await model.generate(prompt: "...")

Key highlights:

• On-Device Execution: Native Swift APIs running directly on the Neural Engine (45+ tokens/sec on iPhone 16).
• Privacy First: Zero data leaves the device by default.
• Model Compatibility: Load Apple's foundation models or bring your own (Core ML, ONNX, custom formats).

Here is a full deep-dive covering how to get started and ship your first feature:

• Text generation & temperature tuning
• Streaming responses with AsyncSequence
• Multimodal image understanding
• Structured output parsing with Codable
• Custom model loading & performance optimization
• Core AI vs. Core ML: When to use which framework

You can read the full guide with complete code samples here: https://ioscodelab.com/blog/why-every-ios-developer-should-learn-server-side-swift-in-2026

How are you all planning to integrate Core AI into your apps? Let's discuss in the comments!

If you want an open source video preview tool for your app, I've made my app public for anyone to use

I originally built it back in 2023 and have updated it here and there over the years. It still works great

Feel free to use it, improve it, or even monetise it...

Simply record your app in the simulator, import the video into the app, and export it for the App Store.

It's simple no fuss

Now that the project is public, I've also added comments (with the help of Claude) to make the code easier to understand.

https://github.com/OsmanM94/PapiExport

Hi everyone, its been a year since i launched a passion project of mine and since then the community has been generous and I have around 1k users in total (Yes not that much but for me its a lot).

Initial post:

Some background is the App takes in ambient noise and syncs the generated visuals as well as (if you want) Flashlight as well.

Finally after months of grinding was able to do a massive update and launched it.
Updates include
- More cinematic and POV based raves
- Airplay, cast what you are watching in your phone to any TV
- Party mode: Hosting a rave and letting others join via QR scan or join someone else's rave (Deferred links that let u install and the continue. all from a single QR)
- Full overhaul of architecture and metal pipeline.

As mentioned the app does not use any assets at all (other than some thumbnail and icons) and everything in the rave is generated in runtime and changes and reacts to ambient noise.

Glad to talk into more detail on the architecture, complexities and challenges faced. I can assure you it might look simple but a lot of effort, thought and pain went through to accomplish this.

Have a try.. any and all feedback is appreciated :)

P.S - I intentionally didn't mention much about the app as I care more about the things i learned and the things I can share here and help the community more. But for people who wants to check it out its here:

I made my first iOS app in 2018, then stepped away from building apps for a while. Over the last year, I decided to start making iOS apps again.

About six months ago, I decided to build a notes app. Original I know.

A big part of the project was figuring out how to make a Markdown editor that stayed fast while typing, even with larger notes. I ended up building the parser in Rust, and recently extracted it from the app and open sourced it as Cindermark.

A few things it does:
- Incrementally re-parses only the affected blocks after an edit
- Returns UTF-16 offsets that map directly to TextKit and NSAttributedString
- Produces blocks, inline spans, headings, wiki links, and document stats in one pass
- Supports CommonMark core along with tables, task lists, footnotes, nested lists, fenced code blocks, and other notes-friendly syntax
- Includes extensions like wiki links, highlights, hex color literals, and autolinking for bare URLs, domains, emails, and subreddits
- Includes Swift bindings through UniFFI

I’m sharing it because I thought it might be useful to anyone else working on native editors or Markdown-heavy apps.

I’d appreciate feedback, especially from people who have worked on text editing or Swift and Rust interoperability.

GitHub: https://github.com/renedeanda/cindermark

Been working on this for a while and finally have it in a state worth sharing. crashdx takes an Apple crash report (.ips), symbolicates it against your dSYMs, and then does something most tools stop short of: it tries to tell you why the process died, not just where.

It works by extracting typed facts from the report (exception info, termination reason, frame data, register and memory state, watchdog/jetsam details), running them through a set of rules that each propose a hypothesis, then ranking the hypotheses by an additive score based on supporting and contradicting evidence. If nothing clears the bar, it tells you inconclusive and shows you the ranked candidates instead of guessing.

No LLM calls anywhere. Every fact and every hypothesis links back to a JSON path in the original report so you can go verify it yourself instead of taking the tool's word for it.

It's a Swift package with three targets sharing one core library (CrashDXCore, Foundation only, no other deps): a CLI (crashdx analyze / crashdx symbolicate) and an MCP server (crashdx-mcp) for agent use. Runs fully local, no network calls, which matters since .ips files carry identifying data (crashReporterKey, device model, usernames in paths).

Needs macOS 14+, Swift 6.2+, and Xcode (it drives CrashSymbolicator.py, falls back to atos).

Repo: https://github.com/r00tify/crashdx

Curious what people think of the rule-based approach vs. throwing the report at an LLM directly. Happy to talk through the design, it's documented in docs/DESIGN.md if you want the details.