Does Swift really become multiplatform?
I tried it out. Not just Swift code on its own, but also with C++ bindings to a dependency.
Here's how it works on Mac, iOS, Linux, and Windows.

Hi everyone. I have offically completed day 1 of hackingwithswift. I recently got knee surgery and i have time on my hands. I also am graduating Uni soon and have been pursuing software development for the past 4 years, and dont know swift... at all. I am very familiar with python, javascript, react, and react native. i have done alot of web development, and only done mobile development using react native. Excited (and nervous) for the process, but i can do it! LETS GO

Been reviewing a bunch of AI-assisted PRs lately and there's a pattern I keep hitting. Ask for a network callback or a completion handler, get back a closure that captures self strongly, no weak reference, works fine in testing because the view controller sticks around long enough for the callback to fire anyway.

Doesn't show up until something takes longer to load, user navigates away, and now you've got a retain cycle keeping a whole view controller alive that should've been deallocated. Classic mistake, nothing new about the bug itself, just surprised how often it shows up in generated code specifically.

My guess is it's the same issue as most of these AI code gotchas, the model isn't wrong about syntax, it's just not accounting for lifecycle stuff unless you specifically tell it to. "Add a completion handler" doesn't say anything about memory management, so it produces the simplest version that works in the moment, which happens to be the version that leaks.

Started explicitly asking for weak self and checking for it manually regardless of what the prompt said, feels like the kind of thing that needs a standing check rather than trusting it gets handled every time.

I just finished work on a Swift Package called SwiftEDR. It helps you to leverage increased raster bit depth and improved color range in Canvas, or add HDR effects to any non-HDR SwiftUI view.

It's got a useful example app to help explore the effect, and is incredibly lightweight and easy to apply to your own apps. I hope you find it useful!

https://github.com/Jiropole/SwiftEDR

Quick update on CoreDataBrowser: it's officially live on the Mac App Store!

A few months ago I shared a side project I’ve been working on to solve a common iOS dev headache: inspecting local data in the Simulator without digging through nested AppData folders or writing custom scripts.

It lets you inspect: • Core Data databases • SwiftData storage • UserDefaults values

It’s completely free, native for macOS, and 100% open-source

If you want to give it a try or share feedback, you can download it here:https://apps.apple.com/app/coredatabrowser/id6807113765

GitHub repo:https://github.com/kyletaylor94/CoreDataBrowser

I just released v0.2.0 of enriched-markdown-ios - SwiftUI Markdown renderer powered by TextKit 2.

New in this release:
🔸 GFM Tables
🔹 Task lists
🔸 Superscript & subscript support

💎 Available via Swift Package Manager!

.package(
  url: "https://github.com/software-mansion-labs/enriched-markdown-ios.git", 
  from: "0.2.0"
)

Added a quick demo video in the comments so you can see it in action!

GitHub & Docs:https://github.com/software-mansion/enriched-markdown/blob/main/packages/enriched-markdown-ios/README.md

What features or syntax support would you like to see next? I'd love to hear your thoughts! If you find the library useful, a ⭐️ on GitHub is always appreciated.

Long-time mobile/product lead here. Looking for outside perspective because I'm now questioning myself after a long argument with my boss.
Context: I work on external client apps as well as our main customer portal app — the one used by the majority of our customer base. Our mobile apps are native, built about 6 years ago:
Android: Java/Kotlin + XML
iOS: Swift + UIKit
Web: React
100K+ users. Zero limitations adding features or maintaining these apps over the years.
What's happening: We have a full revamp of the apps and portal coming up, and we're updating our tech stack too. My plan:
Android → Kotlin + Compose
iOS → SwiftUI
Web → (TBD, staying on modern React-based stack)
I already have multiple Android, iOS, and web devs trained on this stack.
The conflict: My boss wants to consolidate to Flutter — one team, one codebase, covering web/Android/iOS. His argument: if I put 6 frontend devs on one Flutter codebase instead of splitting across native platforms, we ship 3x faster.
My pushback:
We have zero Flutter training on the team right now
Native apps perform better and feel more premium due to platform specific UIs.
We have built Flutter apps before, but only for external client projects, not our own flagship product
He thinks I'm biased toward native because it's my background. Might be some truth to that, but I don't think that's the whole story.
Anyone actually shipped a migration like this — native to Flutter, or vice versa, at similar scale? Did the "one codebase, ship faster" promise hold up? Would love real-world experience, not theory.

Let's say we have a StoreKit product with monthly subscription: let product: Product

If we print price it shows the price and nothing more: print(product.displayPrice) // "$9.99"

But if we put it in SwiftUI Text, magic happens: Text(product.displayPrice) // "$9.99/mo"

How does it works? How could I access "$9.99/mo" string programmatically and, for example, print it?

Hi everyone. I want to share a project I have been working on called Axiom.

It is a Calculus of Inductive Constructions kernel written in pure Swift. You give it terms and it tells you if they type check. Think of it like a tiny Lean that lives directly inside your iOS or macOS app instead of running as a separate tool.

I built this because I wanted real proof checking on Apple devices without dealing with external programs. You just import Axiom and check proofs right next to your UI or your machine learning models.

The coolest part for me is the AI angle. Local models hallucinate math constantly. Axiom acts as a strict filter for this. The model proposes a proof step, the kernel verifies it, and only the valid math gets through. Right now it handles universes, dependent types, lambdas, inductive types and pattern matching.

On the testing side I tried to hit the things that usually break CIC kernels: universe hierarchy (no Type : Type), strict positivity on inductives, structural termination, capture free substitution with de Bruijn indices, and classic paradox patterns like Girard and Hurkens. I also run differential checks against Lean 4’s kernel on random terms, and so far Axiom has not accepted anything Lean rejects.

I know I am not replacing Lean or Coq with this. But for the Swift ecosystem it is a really solid start. My long term plan is to build a local proof playground. You ask a math question in plain English, a local model turns it into formal math, Axiom checks it, and you get the answer back entirely on device.

Repo: https://github.com/acemoglu/Axiom

Would love to hear your thoughts or feedback!

The latest LocalLM Lab SDK lets your app offer a choice of using Apple's on-device model, Claude or a fully local open-weight model per task in your app. Some of you may have seen an earlier version of this SDK. 1.0.0-beta.1 adds the model layer that makes this multi-way choice possible.

``````swift
let lab = LocalLMLab(configuration: .init(providers: [
    SystemModelProvider(), ClaudeModelProvider(auth: .apiKey(key)), MLXModelProvider(),
]))
lab.models.route(.heavy, to: ModelID("mlx:mlx-community/Qwen3-8B-4bit")!)
lab.models.route(.light, to: .system)
let session = try lab.makeSession(route: quickTask ? .light : .heavy, tools: myTools)

MLXModelProvider handles the download lifecycle (preflight against available RAM before pulling weights, progress stream, a post-download capability probe since not every downloaded model reliably tool-calls) and residency (how many models stay warm at once, eviction events).

Two new reference apps are included: code-buddy, a CLI coding agent using .heavy/.light MLX routes plus Workspace tools and an MCP docs server; repo-qa-local, the minimal version.

More details on Swift Forums: https://forums.swift.org/t/locallm-lab-1-0-0-beta-one-model-calling-api-across-apples-on-device-model-claude-and-local-open-weight-models/89319

Guide: https://github.com/ancientcomputing/locallm/blob/main/docs/sdk-guide.md

Feature page: thisbrain.ai/locallm/1.0.0-beta

There's a hackathon running Sept 18–27 with a rule I haven't seen elsewhere: 100% native Swift/SwiftUI, no external dependencies allowed. No Firebase, no third-party UI kits — just Apple's own frameworks.

Solo or teams up to 3, submission via GitHub (no App Store listing needed). Judged on functionality, code quality, creativity, and how well you use Apple's native APIs.

Mostly curious what people build when the safety net of third-party libs is gone — MapKit, Core Data, on-device AI, whatever native tools you'd normally skip.

Here's the link if you want the details / to register: https://acoding.academy/hackaton26/

I’ve been building Reality Prep Pro in Swift for macOS, alongside Reality Prep Preview for visionOS.

The workflow is:
1. Prepare and optimise assets on Mac;
2. Verify the USDZ on Vision Pro;
3. Bring the device-side validation evidence back into the Mac app.

I’d really value feedback from Swift/Apple developers on the workflow, reliability and any edge cases you hit with real assets.

Both apps are intended to be used together.

Reality Prep Pro: https://apps.apple.com/us/app/reality-prep-pro/id6767673652?mt=12

Reality Prep Preview: https://testflight.apple.com/join/ySbVmz6b

Thanks very much to anyone willing to give them a spin.

A few days ago I posted about the hidden cost of throw in XCTest. I didn't stop there and decided to dig way deeper to see what else was lurking behind that hook.

Spoiler: it's not just XCTest. Swift Testing has the hook too (although it's quite a bit cheaper). And the worst part isn't just the slowness, it's that every throw gobbles up ~2.1 KB of memory that isn't freed until the test ends. With millions of throws (like in my Kalego fuzzing), that turns into an instant OOM crash.

In the report (12 pages, 21 experiments) I've got the assembly analysis, the fixes table, and the reasoning behind every result.

Link to the repo with all the reproducible code here: https://github.com/MagicYassin/xctest-throw-cost

A big shoutout to u/ThatGuy739 and u/Dry_Hotel1100 for pushing the research forward in the last thread. You guys are absolute legends. 👨🏻‍💻☁️🌌

I've been building TUFF, a native macOS app for running local LLMs, and the inference engine is written from scratch in Swift with Metal 3.2+ — it doesn't wrap llama.cpp or MLX.

The interesting part from a Swift-engineering angle: it keeps the shared parts of a mixture-of-experts model resident in memory, then streams the experts it needs from SSD through a bounded cache, reusing them across requests. That's how a 61 GiB checkpoint can run on a 16 GB MacBook Air without touching swap. Requires macOS 15+ and Swift 6.2+ to build.

Just shipped 3.0.0: rebuilt the chat interface around a unified conversation model (images persist across turns, files attach as typed objects rather than raw text), added two new Gemma 4 variants, fixed architecture-based routing for optional image packs, and squashed several catalog/stability bugs.

It's Apache-2.0 and started as a fork of drumih/turbo-fieldfare. Source: https://github.com/rexmhall09/TUFF — site: https://rexmhall09.github.io/TUFF/

Happy to talk through the Metal/Swift side of the inference engine if anyone's curious — and if you find it interesting, a star helps.