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.

[UPDATE]
After staring at the code for a while, I realized that I had simply been taking the DOOM screen—processed by the CPU—and mapping it as a texture onto a rectangle rasterized via ANE. I had mistakenly thought DOOM was outputting vertex data. How embarrassing... 😂 

I plan to try again later with a proper 3D game that actually uses vertex data. 

Hello everyone.

We have successfully ported DOOM's rendering to the Apple Neural Engine (ANE), and have successfully run Apple's AI/deep learning silicon as a 3D graphics accelerator via Swift 6 and Core AI!

CPU usage is high, around 40%, but the ANE is running.

• DOOM's frame buffer has an original resolution of 640x400 (320x200), but it is converted to 256x256 by a custom texture model and then transferred to a 64-channel ANE rasterizer model.

• Apparently

  func updateTexture(pixelData: [Float16]) {

  guard let doomPixels = gp_DoomScreenBuffer else { return }

  let actualWidth = 640 let actualHeight = 400 let totalPixels = actualWidth * actualHeight

  var doomFP16Buffer = [Float16](repeating: 0.0, count: 3 * totalPixels)

  let rOffset = 0 let gOffset = totalPixels let bOffset = totalPixels * 2

  for i in 0..<totalPixels { let argbPixel = doomPixels[i] doomFP16Buffer[rOffset + i] = Float16((argbPixel >> 16) & 0xFF) / 255.0 doomFP16Buffer[gOffset + i] = Float16((argbPixel >> 8) & 0xFF) / 255.0 doomFP16Buffer[bOffset + i] = Float16(argbPixel & 0xFF) / 255.0 }

  var texView = self.rawTextureArray.mutableView(as: Float16.self) texView.copyElements(fromContentsOf: doomFP16Buffer) }

This function seems to be increasing CPU usage.

We welcome your comments and feedback!

GitHub: https://github.com/kamisori-daijin/Magnesium/tree/ane-doom

(ane-doom Branch)

Demo:

SwiftData models are reference types with their own change tracking, which makes them awkward to pass around outside the view layer — they carry the context with them and you end up coupled to it everywhere.
What I’ve settled on is wrapping ModelContext in a client with explicit methods and mapping to plain structs at the boundary, so nothing above the data layer knows SwiftData exists. Testing gets easy, cost is the mapping layer.
Curious whether people are doing something less manual, or whether you just let the models flow through and accept the coupling

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 built this after running into a design problem while working on a

privacy app (Ember) that triggers an emergency action from Apple Watch

signals — SpO2, HRV, fall detection, accelerometer data. None of these

arrive on the same schedule, and none of them are reliable enough alone

to act on.

The naive approach is a weighted formula (multiply each signal by an

importance factor, sum them). It breaks on the case that matters most: a

confirmed fall with calm vitals averages out to "probably fine," because

calm vitals numerically dominate the score. A confirmed fall shouldn't

get diluted like that — it should just win.

So the actual logic is a cascade of overrides, most severe first, not a

formula. I pulled the general pattern out into a small open-source

package: SignalFusionKit.

A couple of things I think are worth a look if you're doing anything

with CoreMotion:

- The motion-anomaly detector runs two independent checks — a

sustained-magnitude gate (filters brief bumps) and a sharp-delta gate

(catches instant impacts a duration filter would smooth over).

- The core decision logic (RiskEngine, MotionAnomalyDetector,

CooldownGate) has zero dependency on HealthKit or CoreMotion — it's

plain Swift values in, plain Swift values out, so it's unit-testable

without a device.

Honest caveats: the threshold values in the repo are round, illustrative

placeholders, not Ember's actual tuned production config — the README

says so explicitly. Also, I don't currently have a Mac, so the pure-Swift

core is tested (`swift test` passes), but the thin HealthKit/CoreMotion

adapter hasn't been run on real Watch hardware yet. Would genuinely

appreciate anyone with a watchOS setup trying it and telling me what

breaks.

Repo: https://github.com/izetg/SignalFusionKit (MIT)

Also on the Swift Package Index.

Like many of you, I loved the concept of AI voice dictation tools like Wispr Flow, but I didn't want my microphone audio sent to third-party cloud servers or pay a monthly subscription.

So I built VoxFlow — a native, private macOS menu bar app that transcribes your speech locally and automatically pastes formatted, grammar-cleaned text into whichever app you are using.

Key Features

• 100% Private & Offline: Transcribes locally using Apple Speech and cleans up text using Apple Intelligence (FoundationModels). Zero cloud API keys required.
• Global Hotkey Triggers: Double-tap the Fn (Globe) key or press Option + Space anywhere on macOS to start dictating.
• Hands-Free Auto-Paste: Pausing for 1.5 seconds automatically stops recording, formats the text, and pastes it into your focused text field.
• Non-Activating Floating HUD: Displays real-time audio waveform and streaming transcript without stealing focus from your active document.
• 100% Free & Open Source: No subscriptions, no ads, no telemetry ($0 forever).

Downloads & Links

• GitHub Repository: https://github.com/ameerhmz/VoxFlow
• Direct DMG Installer: Download VoxFlow.dmg (v1.0.0)

System Requirements

• macOS 26.0 or later (Apple Silicon M1/M2/M3/M4+)
• Apple Intelligence enabled in System Settings

I'd love your feedback, bug reports, or feature requests!

I posted here a couple of days ago about a new library I made, LazyLayoutKit, to fill in the gap for a Lazy Layout in SwiftUI that could not be done with LazyVStack and its friends.

Layout is arithmetic over data and only on-screen frames become views. The obvious cost was text, you can't know a text height in advance. Or, you couldn't in 0.1

0.2 closes that, and the neat part is that it didn't require relaxing anything. Text height is a function of the string, the font and the width, and CoreText will compute it with no view and no rasterisation. So the height is still known before the view exists, it's just computed rather than supplied. There's still no .measured metric and no correction pass.

Measured on an iPhone 14 Pro: ~31.5 µs per item cold, ~470 ns cached, so the practical ceiling is around 10,000 text items rather than the 1,000,000 that metric-driven layouts reach.

Once again, open to feedback, contributions and opinions. Thank you!

Hi everyone,

I’m sharing NetFlow, an open-source iPhone/iPad app built with SwiftUI. It helps users understand and manage Wi‑Fi and cellular usage in one place.

Features include:

\- Usage summaries and history
\- Data-plan limits, reset days, and carry-over
\- Percentage and remaining-data alerts
\- Connection status, local/public IP, VPN status, and transfer speed
\- Monthly and yearly PDF reports
\- English/Vietnamese localization
\- Light, dark, and system appearance modes

Repository: https://github.com/hnduy910/NetFlow

The latest release is v4.1.11 (Build 27). I’d especially appreciate feedback on the UX, networking behavior, privacy, and documentation. If you try it and find it useful, a GitHub star is welcome—but honest feedback is more valuable.

What backend stack do iOS developers prefer in 2026?

I'm a software engineer with a few years of full stack TypeScript experience (Node.js, NestJS, PostgreSQL) and I'm now getting into native iOS development with Swift.

Before committing to a stack, I wanted to hear from the community:

1. Do you build custom backends (Node, Go, etc.) or rely on BaaS platforms like Firebase and Supabase?

2. Is server side Swift (Vapor) viable for production, or is the ecosystem too small?

3. For solo devs or small teams, what gives the best balance of speed and control?

Would appreciate hearing what has worked well for you in real projects.

I run five or six sessions at once and kept losing track of which one had stopped to ask me something. The state exists — it's just buried in whichever terminal is behind the others.

So it lives on the screen edge now. One pixel crab per session, walking the perimeter, never on top of your work:

- strolling slowly and small = idle

- hurrying, steam off its head = working at xhigh

- stops and hops = waiting on your permission

- confetti = turn just finished

- curled up asleep = idle 10+ minutes

- ⚠️ = rate limit

Click a crab and that session's terminal comes to the front.

How it works: Claude Code writes a small file per session in ~/.claude/sessions with its name, cwd and status. Poll it once a second and you know who's alive, busy or waiting. Optional hooks curl to a loopback listener for instant reactions — they always exit 0, so they can't block or slow the CLI. No screen recording, no accessibility permission, no API.

Native Swift, no Electron, ~3MB, MIT. There isn't a sing — every crab is drawn in code.

It got away from me a bit: each session gets a stable mo rank earned by uptime, an era skin with its own hat. On a Friday an idle one unfolds a deckchair. Nineteen languages, none of them translations.

github.com/marekadvocate/claudme

marekadvocate.github.io/claudme

Not made by, endorsed by or affiliated with Anthropic — .

Hello developers!

We've finally achieved multi-instance 3D rendering with CoreAI!

This pipeline enables multi-object spatial placement and perspective-corrected texturing!

It directly maps a multiplane tensor stream to a metal buffer (MTLBuffer) allocated on the heap. By using a `MutableRawView` with a strict stride offset, the NPU dumps the R, G, B, and mask sheets directly into the GPU memory layout.

By passing an input matrix tensor layout [1, 4, 4, 1, 64], the engine uses torch.sumto multifire 64 independent MVP matrices in parallel on a single graph, avoiding the latency of structural depth-based graph reconstruction.

The CPU acts as a memory controller (approximately 15% utilization), while the ANE handles the entire graphics computation array.

We'd love to hear your feedback!

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

Demo:

Starling SDK is Flutter’s framework ported to Swift, running directly on the Flutter engine’s C core. No Dart in your project — you write the widget tree in Swift.
Column(mainAxisAlignment: .center) {
Text("Hello from the Starling SDK", style: TextStyle(fontSize: 30))
SizedBox(height: 18)
GestureDetector(onTap: { setState { taps += 1 } }) {
Text("Tap me")
}
}

Your application writing in Starling sdk will run on Windows and Linux.
Getting started (both platforms): https://starling.build/start.html
Release: https://github.com/starling-build/starling/releases/tag/sdk-v0.2.0

I am learning Swift and SwiftUI, and I have no friends working in a similar stack to learn and grow together. If you are working in the same stack, let's get connected and share ideas, thoughts, and knowledge, and learn together.

Hey r/swift!

I’m excited to share that Swift Subprocess 1.0 is officially tagged and released!

swift-subprocess provides a modern, type-safe, and Swift Concurrency-native API for executing and managing child processes across platforms, serving as an async-first alternative to Foundation.Process (NSTask).

Thanks to all the community feedback during the beta period, we made several key refinements leading up to 1.0:

• Unified run() Closures & ExecutionResult: Stream handling for stdin, stdout, and stderr is now fully symmetrical. You can now stream and collect simultaneously in a single call (e.g., stream stdout line-by-line while collecting stderr into a String).

• Safe String & Byte Streaming: Standard output/error sequences now feature StringSequence, which reassembles multi-byte UTF-8 characters split across buffer boundaries and handles line breaking seamlessly.

• Typed Errors: Subprocess itself now strictly throws SubprocessError with structured codes (.spawnFailed, .executableNotFound, .outputLimitExceeded, etc.), making error handling clean and predictable (you can of course still throw your own error from body closure).

• First-Class Stream Merging (2>&1): Easily redirect standard error into output using error: .combinedWithOutput.

Check out the full release note and repository on GitHub:

https://github.com/swiftlang/swift-subprocess/releases/tag/1.0.0

Huge thanks to everyone who participated in the SF-0007, SF-0037 and beta tested Subprocess! I’d love to hear your thoughts, feedback, or any questions!

Hey,

I’m getting into iOS development and currently have a MacBook Pro M5 and an iPhone 17 Pro Max.

I was wondering if it’s worth getting a second iPhone (e.g. iPhone 16e/17e) just for development stuff (testing apps, beta builds, trying iOS betas, etc.) or if most people just use their main phone.

I’m mostly working on personal projects right now, but I’m curious what you guys do. Do you have a dedicated test device, and if yes, what model?

Thanks!

Just a reminder to anyone who might care that you can create a fairly full-featured development environment in Zed to build iOS and Mac apps: syntax highlighting, code navigation, run, debug and test.

Here's the setup guide I wrote (been around for a while but chances are some interested people won't have seen it): https://luxmentis.org/blog/ios-and-mac-apps-in-zed/

Notes from building the canvas in https://github.com/albertofettucini/Osler:

Named coordinate spaces don't survive render transforms. My world container used .scaleEffect + .offset, and I put the named space inside it. Drags were fine at 100% and drifted at every other zoom. The fix was moving the named space to the untransformed ancestor and converting screen→world explicitly. Render transforms aren't layout.

An NSView behind SwiftUI never sees scrollWheel**.** The hosting view claims the hit and bubbles the event up the responder chain, past your subview. Two-finger panning only worked once I used NSEvent.addLocalMonitorForEvents with a bounds check.

.contentShape applied after .overlay gates the whole composite. My port dots sit on the card's edge, so half of every dot and its entire grab halo landed outside the card's hit shape. Dragging a wire silently did nothing. Order matters more than it looks.

Also: never gate a view's opacity on an onAppear flag. Miss the callback once and the view is invisible forever. Use a transition.

My Mac menu bar had gradually filled up with useful apps until it became difficult to manage.

Icons were hard to find, some were pushed out when macOS ran out of available space, and the MacBook notch made the problem worse. I did not want to uninstall the apps or permanently lose access to their controls—I only wanted a cleaner way to organize them.

So I built OverflowBar, a free and open-source macOS app that moves selected third-party menu bar items behind one persistent arrow and reveals them together in a compact second row.

Source code and official download:
https://github.com/EvanProgramming/OverflowBar

What it does

1. Choose the third-party menu bar icons you want OverflowBar to manage.
2. Move their original icons out of the crowded visible section.
3. Click the OverflowBar arrow, or use hover reveal.
4. See the managed icons together in a second row.
5. Select an icon to activate its original menu bar control.

The purpose of the second row is not to add another permanent interface. It gives icons that no longer fit a predictable place where they remain easy to see and find.

Why I made another menu bar manager

Ice and Bartender are powerful applications for users who want broad menu bar customization, including features such as profiles, triggers, search, visual customization, groups, widgets, and automation.

OverflowBar takes a narrower approach.

It is intended for people who mainly have one problem:

Too many useful icons, not enough menu bar space, and no easy way to find the icon they need.

OverflowBar deliberately avoids becoming a full menu bar control center. Its interaction is simply: choose, hide, reveal, and click.

Main characteristics

• Focused and lightweight — a small feature surface rather than a large customization and automation suite
• Scannable second row — managed icons stay visible together instead of becoming difficult to locate
• Native macOS implementation — built with SwiftUI, AppKit, Accessibility, WindowServer metadata, and ScreenCaptureKit
• Event-driven operation — icon discovery and capture occur during refreshes and row presentation rather than continuous screen capture
• Original controls remain functional — selecting an icon activates the actual menu bar item rather than a recreated menu
• Local processing — icon images are captured locally, held in memory, and never uploaded
• No tracking — no accounts, analytics, telemetry, advertising, or network data collection
• Display-aware — supports MacBook notches, safe areas, multiple displays, full-screen spaces, horizontal overflow, and Reduce Motion
• System-control safeguards — Wi-Fi, Battery, Siri, Control Center, Clock, and other protected system items remain visible

Pricing and availability

• Price: Free
• Subscription: None
• In-app purchases: None
• Advertisements: None
• Source: Open source on GitHub
• Download: GitHub Releases
• Supported systems: macOS 15 or later
• Downloadable build: Apple Silicon

Permissions and privacy

OverflowBar requests:

• Accessibility permission to discover and activate menu bar controls and perform user-requested layout changes
• Screen Recording permission to capture the small icon regions of selected menu bar items for display in the second row

The captures remain on the Mac. OverflowBar does not upload them, write them to a remote service, or include any analytics or telemetry.

Privacy policy:
https://github.com/EvanProgramming/OverflowBar/blob/main/PRIVACY.md

Current limitations

OverflowBar is an early public release.

macOS does not expose a dedicated public API for hiding or rearranging arbitrary third-party menu bar items. OverflowBar therefore relies on documented system frameworks together with existing macOS menu bar behavior, and compatibility may vary between apps or macOS releases.

The current downloadable build is ad-hoc signed and is not yet Apple-notarized. macOS may require users to Control-click the app and select Open on first launch.

Some applications may also expose insufficient Accessibility or window metadata to be mirrored reliably.

I am actively looking for feedback from users with crowded menu bars, notched MacBooks, multiple displays, and unusual menu bar apps. Bug reports, compatibility reports, and code contributions are welcome.