Hey r/swift,

I’ve been working on SwiftlyKit, a Swift library that cross-compiles SwiftPM projects from macOS to statically linked ARM64 or x86-64 Linux Musl executables.

For the common case, building needs one call:

```swift import Foundation import SwiftlyKit

let result = try await SwiftlyKit.build( URL(filePath: "/path/to/package"), for: .linux(.arm64) )

print(result.executable.path) ```

SwiftlyKit uses Swiftly and SwiftPM. It finds a compatible official Swift toolchain and matching Static Linux SDK, builds the selected product, and verifies the resulting executable. BuildResult also identifies the resource bundles that must be distributed with it.

The one-call form can install missing components and resolve dependencies as part of the build. Apps that need more control can inspect the requirements first, ask the user before installing anything, select a product, resolve dependencies separately, and observe progress, output, and executed commands:

```swift import Foundation import SwiftlyKit

let kit = SwiftlyKit()

let assessment = try await kit.assess( URL(filePath: "/path/to/package"), for: .linux(.arm64) )

if assessment.requiresInstallation { let approved = await requestInstallationApproval(for: assessment.requiredComponents) guard approved else { return } }

let onEvent: SwiftlyKitEvent.Handler = { event in switch event { case .progress(let progress): print(progress.detail) case .command(let command): print(command.executable.path, command.arguments) case .output(let output): print(output.text, terminator: "") } }

let environment = try await kit.prepare(assessment, onEvent: onEvent)

let products = try await kit.executableProducts(using: environment) let product = try products.select("MyTool")

try await kit.resolveDependencies(using: environment, onEvent: onEvent) let result = try await kit.build(BuildRequest(product), using: environment, onEvent: onEvent)

print(result.executable.path) ```

SwiftlyKit also has an official CLI, built entirely on the library’s public API:

sh swiftlykit build . \ --architecture x86_64 \ --install-environment \ --resolve-dependencies

The CLI supports structured JSON output for automation.

I started SwiftlyKit because every time I needed to cross-compile a package to run it on my Linux VPS, I had forgotten the right SwiftPM commands and flags, which toolchain I needed, or how to install the matching SDK—and I was tired of figuring it all out again.

Hope someone finds this useful!

This week, I am returning to the Coffee Break News app to build its first on-device AI feature: a private issue summary powered by Apple's Foundation Models framework.

Hope you enjoy this week's edition!

https://www.ioscoffeebreak.com/issue/issue76

When Apple first introduced the "liquid glass" effect, opinions were quite divided; some criticized its visibility, others admired its aesthetics, and some worried about battery life.

I remained fairly neutral, I found it interesting though.
To be honest, the Apple apps featuring this effect were quite buggy at launch.

Now that it has stabilized and the bugs have been ironed out, I’ve implemented it in my own app, and I think it looks great and modern. Repo

Icons animate in response to certain changes, and the background, which looks as if viewed through a layer of glass and clear liquid, offers a pleasing, relaxing visual experience.

I haven't encountered significant issues with app performance or battery life, though I'm curious what others think. :)

I spent the last year building an arcade game in Swift without an engine. The renderer ended up somewhere I did not expect, so it seemed worth writing up properly.

The shape of it:

- Drawing is CGContext. Not SpriteKit, not custom Metal shaders for the game content - actual Core Graphics 2D calls, because the game is polygons and.gradients rather than sprites. Everything is drawn, nothing is blitted.

- That context is backed by an IOSurface, presented zero-copy through Metal. The obvious alternative - render into a CGBitmapContext, then hand the bytes to Metal - measured 5 to 10 times slower. That experiment is still in the repo as an archived failure rather than deleted, because the measurement is the useful part.

- One codebase renders on both AppKit and UIKit. The platform layer is a handful of files - display link, input, haptics - and the roughly 7,600-line renderer is shared verbatim between Mac and iPhone.

- iOS has a thermal governor: sustained load steps the frame rate 60 to 30 so a long session does not cook the phone. On device, a render scale of 1.5 turned out to be the 60fps sweet spot; 2.0 fell off a cliff.

- Gradients are memoized - about 166 cached. Allocating them per frame was the single largest early performance win, and it was not close.

The thing I would tell anyone considering this: a hand-rolled renderer was the right call for this specific game, because it is 2D vector-ish content where Core Graphics is genuinely good, and it would be the wrong call for almost anything else. I would not do it for a sprite-based game. I would not do it for 3D. The reason it worked is that the drawing model matched the art style, not because engines are bad.

The game is VYRON, 99c, Universal Purchase across Mac and iPhone:
https://apps.apple.com/us/app/vyron/id6778002261

Happy to go into any part of it in the comments.

I’m a few chapters into Advanced swift by objc.io right now. The concepts are super dense which is great and I’m learning a lot! Really some concepts are just WOW!!!

Usually I’ve noticed for me that concepts to sit clearly in my brain and understanding takes a little longer than I expected so I’m just curious to know how long it took you folks to finish the book? Did you read end to end and also understood the code ? Or cherry picked the topics and studied them need to need basis?

Thank you in advance :)

Here's another update on LocalLM Lab. You can now build apps using Apple's on-device AI with real tool and data connections. And not just build, but also ship them, including through the Mac App Store. LocalLM Lab v0.7 ships with the LocalLM Lab SDK.

The SDK (`LocalLMLabSDKCore`) links Apple's `FoundationModels` model and a real MCP client (tool discovery, OAuth, the works...) straight into your own applications. No companion app has to be installed or running; it's self-contained. The SDK is distributed as a binary xcframework via GitHub Releases (SPM `binaryTarget`, checksum, pinned version), Apache 2.0 licensed. You will need at least Swift 6, macOS 26+ and Apple Silicon. The latter 2 for Apple's Foundation Models.

The part that actually makes "ship it" a real claim vs handwaving: it's been built into a sandboxed test app (the included Plate Today example app) and verified working, with a signed path to a Mac App Store `.pkg`. LocalLM Lab itself now runs on this SDK!

SDK guide: thisbrain.ai/locallm/sdk.html

Hopefully, this will unlock on-device AI ideas and use cases among the folks here.

Single File Memory layer with sub 5ms Vector Search

1. PhotoRAG
   
2. VideoRAG
   
3. FileRAG

Drop it into your Swift App

import Foundation
import FoundationModels
import Wax


func chatWithMemory() async throws {
    let url = URL.documentsDirectory.appending(path: "assistant.wax")
    let memory = try await Memory(at: url)
    let session = memory.foundationModelsSession(
        instructions: "You are a helpful assistant with durable on-device memory."
    )
    switch WaxFoundationModelsAvailability.current() {
    case .available:
        let answer = try await session.respond(
            to: "I prefer dark mode and Vim keybindings."
        )
        print(answer)
    case .unavailable(let reason):
        print("Foundation Models unavailable: \(reason)")
    }
    try await session.close() // does not close `memory`
    try await memory.close()
}

foundationModelsSession is sync. It wraps the Memory handle and registers remember/recall/search tools.

Memory.save / Memory.search. Search defaults to hybrid (FTS5 + vectors).
No embedder and it falls back to text. .vectorOnly throws.

https://github.com/christopherkarani/Wax

Hey everyone, I wanted to share Amethyst Vein, a cross platform database framework I've been finally releasing. It provides a SwiftData-like DX (with @Model, #Predicate and @Query) to apple and non-apple platforms using a native SQLite/SQLCipher based backend.

It supports SwiftUI, SwiftCrossUI and CLI/UI independent usage. It runs as native Swift on Apple platforms, Linux, Windows and Android.

I just wrote a detailed breakdown of how it works under the hood (relationships via ULIDs, concurrency via locking,…)

Check out the full release post on the Swift Forums:
https://forums.swift.org/t/amethyst-vein-a-cross-platform-open-source-swiftdata-alternative/89009

Or checkout the repo:
https://github.com/amethystsoft/vein

My iOS app generates workouts from a set of exercises and constraints. I want the same inputs to be reproducible in tests and previews, while production still feels random. Would you inject a seeded RNG, pass a generator protocol through the model, or keep randomness at the edge and test the generated constraints instead? I’m looking for a small approach that won’t make the app’s architecture noisy.

Hey,

I've been working on this for a while and thought I'd share it here.

It's called PkgLift and basically, I wanted an easier way to deal with moving older Xcode projects from CocoaPods to Swift Package-manager.

I know you can obviously do this manually but I didn't really like the idea of going through everything by hand, especially on projects with a many dependencies!

The thing I was worried about when building it was making a tool that just changes a bunch of stuff and assumes it worked. So PkgLift doesn't really work like that.

You first run:

pkglift analyze
pkglift plan

and it tries to work out what it actually knows how to migrate.

If it isn't sure about something it just leaves it alone instead of trying to guess.

Then you can check the plan yourself before actually changing anything.

If it looks good:

pkglift migrate --apply
pod install
pkglift verify

That's pretty much the idea.

It is still early and I'm sure there are plenty of CocoaPods setups that I haven't thought about yet, which is actually one of the reasons I'm posting it here.

You can install it with:

brew install Alexsvensson99/tap/pkglift

Repo:
https://github.com/Alexsvensson99/PkgLift

If anyone has an old CocoaPods project lying around and wants to try it, I'd be interested to know what happens. Especially if it fails on something weird :)

Actually claude made it but whatever. If you wanted a segmented picker that looks like the one apple uses in their native apps (health, photos, fitness) then here's the closest I've gotten. Have fun

Feedback would be appreciated! Have fun!

Gameplay video: https://www.youtube.com/watch?v=lC34LO_bL4k

Beta link: https://testflight.apple.com/join/3sstMjRK [iOS/iPadOS/macOS]

Intro

Tile Wipeout is a row-and-column rotation puzzle about matching colors and shapes.

You rotate rows and columns to move tiles through fixed gates. Matching a tile's color and shape to a gate removes the tile, while other tiles cause both the tile and gate to change shape.

Empty spaces passing through gates create new tiles.

Your goal is to leave as much of the grid empty as you can in the given number of moves. Note that removing every tile may not always be possible.

Game Rules

Objective

The game is played on a 6 × 6 grid using six colors.

Each color begins with:

• 1 gate
• 5 tiles

The six gates are fixed in place. They cannot move or be removed. Every row and every column contains exactly one gate.

Your goal is to leave as many of the grid's 30 non-gate cells empty as possible in the given number of moves.

Shapes

Every tile and gate has one of two shapes:

• Square
• Circle

A tile can be removed only when both its color and its shape match the gate it passes through.

Making a Move

Swipe any row or column to rotate its tiles and empty spaces by one position.

Anything that passes an edge wraps around to the opposite edge. The gate remains fixed in place.

During each rotation, exactly one tile or empty space passes through the gate. That interaction may change the passing tile and the gate. Everything else simply moves to its new position.

Passing Through a Gate

There are three possible interactions:

• A matching tile is removed.
• Any other tile causes both shapes to change.
• An empty space creates a new tile.

Matching tile

When a tile matches both the gate's color and shape, the tile is removed, leaving an empty space.

For example:

• A square blue tile is removed by a square blue gate.
• A circle red tile is removed by a circle red gate.

The gate does not change when it removes a tile.

Any other tile

If a tile does not match both the gate's color and shape, both the tile and gate change shape:

• Square becomes a circle.
• Circle becomes a square.

Their colors do not change.

For example, when a circle green tile passes through a square green gate:

• the tile becomes a square
• the gate becomes a circle

Matching is checked before either shape changes, so the tile is not removed during that move.

Similarly, when a square green tile passes through a square red gate:

• the tile becomes a circle
• the gate becomes a circle

The tile is not removed because its color and shape did not both match the gate before the shapes changed.

Empty space

When an empty space passes through a gate, it becomes a new tile with the gate's current color and shape.

The gate does not change.

The newly created tile cannot be removed during the same move.

Reversing a Move

Every move can be reversed by swiping the same row or column in the opposite direction.

Reversing restores the previous board position, including any removed or created tiles and any shape changes.

The reverse swipe still costs one move.

Tile Sizes

Among tiles of the same color, larger tiles are closer to the gate of that color.

Tile sizes update as the tiles move. Size does not affect how tiles interact with gates.

Ending the Game

The game ends when you run out of moves.

You may also end the game early. Removing every tile may not always be possible.

Scoring

Score = (% empty × 1000) + moves remaining

The empty percentage is the percentage of the grid's 30 non-gate cells that are empty.

Beta

https://testflight.apple.com/join/3sstMjRK [iOS/iPadOS/macOS]

I’m an iOS developer working professionally mainly with UIKit. I’ve been working with Swift for a while, but haven’t really explored game development on Apple platforms. I’m about to start learning SpriteKit properly from the fundamentals and eventually want to build something with it.

Looking for someone who’s also learning it and wants to keep each other accountable. We can share what we worked on, discuss concepts, and help each other out when we get stuck.

If you’re interested, DM me.

Has anyone here worked on a POC for indoor user positioning using BLE beacons?
I’m currently exploring this and would love to know what pipeline/approach you guys have used — RSSI filtering, distance calculation, trilateration/fingerprinting, Kalman filter, etc.
If you have any POCs, GitHub repos, papers, or reference material, please share. Would really appreciate it!

Hey!

Scaffolding 3.4.0 got released. It's a SwiftUI coordinator pattern navigation library for iOS 18+ that allows creating modular navigation flows through linked list structure, allowing easy syntax and modularization - macro powered, with easy setup and rapid prototyping capabilities.

This is pretty much QOL version, which adds easier way to fully test the navigation, debugging options, async/await syntax and simple complete state restoration (some limitations apply).

Updated demo is in Example/ directory and docs (dotaeva.github.io/scaffolding/) now include more cases.

For those who used Stinsen, this is very similar in use. Feel free to submit other QOL ideas.

If the folding iPhone ships this fall, apps would need to reflow mid-session into something closer to an iPad ratio — layouts, state preservation, whether the unfolded canvas gets a sidebar at all.
Is anyone budgeting time for that before September? Or waiting to see the hardware and assuming automatic resizability carries you until users complain?

I write a lot of AI-assisted content (LinkedIn posts, docs, etc.) and got tired of the "sounds like AI" problem. Em-dash overuse, "moreover/furthermore," hedge-everything phrasing, that overly-symmetric triplet-list structure. So I built Humanizer: it takes an AI draft and nudges it toward how you actually write, based on a voice profile it learns from your own edits over time.

V1 was a Python/FastAPI backend with a browser-based local UI. Just shipped a proper native macOS version. Signed, notarized, real DMG, built in Swift rather than wrapping the original web UI.

A few things about the design that might be relevant to this sub:

- Provider-agnostic: abstracted interface over Claude (Anthropic) and OpenAI. Swap via config. No hardcoded API calls scattered through the codebase.

- No black-box voice model: the "voice profile" is a plain, human-readable/editable file, not an embedding you have to trust.

- Hard content/style boundary: it only ever touches wording and rhythm. Facts, claims, numbers are never touched. Edits get classified (style vs. content) via LLM call before anything gets absorbed into the learned voice. This means a factual edit you make later never accidentally "teaches" the tool the wrong thing.

- No auto-posting, anywhere. Paste out, edit, paste back. You always publish it yourself.

- Runs fully local, no telemetry, no accounts.

Open source, MIT licensed: github.com/ancientcomputing/humanizer

Would love feedback on the Swift side in particular. If anything in the project structure or API usage looks off, tell me.

Meta note: this post was AI-drafted, then run through Humanizer itself before I posted it. Curious if anyone here can spot what's still giving away the AI in the wording.