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've been messing with on-device AI stuff for Apple Silicon Macs and put together LocalLM Lab to make experimentation easier.

It started as a simple prompt interface as just a way to poke at Apple's on-device foundation model and see how it responds. Since then I've added an OpenAI API-compatible endpoint (localhost or external IP), so you can point existing tools/scripts at it like any other local model server.

Right now it's built on Apple's Foundation Models framework. With the new LanguageModel protocol Apple introduced this year, the framework isn't locked to Apple's on-device model anymore. Any provider that ships a conforming Swift package (local MLX models, Claude, Gemini, etc) should be a plug-in. I'm looking at wiring that up so LocalLM Lab isn't limited to just the built-in model.

It's a free download from thisbrain.ai/locallm

Let me know how you think LocalLM Lab should evolve. MCP? Model switching in the UI? Something else?

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 :)

Most voice input on Android - SpeechRecognizer.createSpeechRecognizer(context) calls — gets routed to Google's network-backed recognizer. I wanted that path to run locally, so I wrote one.

The service hooks the framework's SpeechRecognizer API. Once it's set as the default, any app calling createSpeechRecognizer(context) (no ComponentName) ends up in our pipeline and gets back transcription that never left the device. Pipeline is Silero VAD + Parakeet TDT v3 (114 languages, ~890 MB INT8) on ONNX Runtime with NNAPI.

Honest caveat: Gboard, Samsung Keyboard, and Google Assistant ship their own recognizers and skip the system default. So the default-IME voice button on most phones won't go through this. What does: accessibility tools, custom dictation UIs, and anything calling the framework API directly.

Models download on first use (~1.2 GB) via a foreground WorkManager job so it survives backgrounding. After that, fully offline.

Setup + demo APK: github.com/soniqo/speech-android

audio.soniqo:speech:0.0.9 on Maven Central

Library:

Happy to answer questions about the binder lifecycle, the foreground worker setup, or why SpeechRecognizer is such a tarpit of edge cases.

I combined apple weather data with radar data to get a more accurate view what my day looks like. Still looking into radar future-cast data, if anyone has advice on providers who can supply 6-8 hrs ahead.

https://testflight.apple.com/join/PUjCeSZP

Edit: TestFlight link^

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.

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]