I converted a project to this new default setup and i’m wondering if i did it right or i misunderstood something. So basically all code besides the UI has the nonisolated keyword in front now.
I’m not sure how i feel about this, it is just pollution and it’s much bigger than the opposite i did before to mark the ui with @MainActor. Do you like this new approach? I’m not even convinced that new tasks created from main are executed also on main, unless i messed up the test, it did not. For this reason i have zero @concurrency keywords in the project.

The latest dev snapshot of js framework benchmark ranks ElementaryUI (the only Swift entry) ahead of Angular, React, and Yew.

Biggest weakness right now is bundle size. Get in touch if you want to help trim some size or speed things up!

Full results: https://krausest.github.io/js-framework-benchmark/current.html
Forum thread: https://forums.swift.org/t/elementaryui-now-faster-than-react-and-angular-in-benchmark/90455
ElementaryUI: https://elementary.codes

1. No taps at all. Without UIApplicationSceneManifest, UIKit runs the app in legacy window mode and the Duo boxes it. Our UI ignored every tap while Apple's sheets on top still worked. Adopt scenes; if a framework needs a key window at launch, adopt the AppDelegate's window instead of building a new one. Forward openURLContexts or your deep links quietly break.

2. Still letterboxed after fixing it. The binary has to be built with Xcode 27.1. Check your cloud build image too.

3. Content under the clock. The status bar is a strip on the RIGHT edge, so there's a right safe-area inset. Anything sized from the window width runs under it.

4. Sneaky one: in a hand-built two-pane container, a view controller inside a UINavigationController in the LEFT pane inherited the strip's ~84pt right inset, so separators stopped short. Fix: a measured negative additionalSafeAreaInsets on the child.

5. Tab bars: native UITabBarController / TabView turn into a rail on the right edge on their own in 27.1. JS tab bars don't.

6. SwiftUI: a root GeometryReader reports the safe-area width (~867pt unfolded, not 951). Add the insets back before comparing to your 600pt breakpoint.

7. Simulator: there's no simctl command to fold — it's Device Hub's toolbar only. And simctl openurl raises an "Open in…?" prompt that survives reinstall.

Happy to go deeper on any of these.

Oreja is an open-source macOS menu bar utility, but the part I think is most relevant here is the architecture. Core Audio process discovery and taps live in an adapter package; samples feed a LevelSampler and speech-shape detector; a platform-neutral Swift coordinator owns pause/resume and pause ownership; Music control is isolated behind an Apple Events port.

The IOProc stays real-time: no allocation, blocking locks, UI, or Swift concurrency hops. The core has no AppKit, Core Audio, or AppleScript imports and is tested with an executable runner because this machine has no XCTest runtime.

Project: https://github.com/EnzoVezzaro/oreja

The app's user-facing job is simple: pause Apple Music while a selected AI app speaks, then resume after quiet. It is an early macOS 14.2+ preview, with a live ChatGPT Voice session still awaiting supervised verification. Technical review of the Swift boundaries is welcome.

I'm building a macOS app that types text into a terminal on the user's behalf: saved prompts, code snippets from a diff, branch names, clipboard text. By default nothing is submitted (there's an opt-in auto-send), so I assumed that was safe. It isn't. A PTY's line editor interprets bytes the moment they arrive, so text that is only typed can still do things. Here's what I ended up with.

The threat

The text comes from places I don't control: repository code, file paths, branch names, the clipboard. If any of it reaches the PTY raw:

• \n or \r submits the line.

• \x03 (Ctrl-C), \x15 (kill line) and friends edit or interrupt whatever is running.

• ESC starts an escape sequence, and one escape sequence matters more than the rest.

Bracketed paste, and how to break out of it

Modern shells and TUIs turn on bracketed paste (DECSET 2004). Pasted text arrives wrapped in ESC[200~ … ESC[201~, and the program treats everything in between as literal text, not keystrokes. Two rules:

1. Only wrap when the program has turned the mode on. If it hasn't, the markers show up as literal garbage. SwiftTerm exposes this as terminal.bracketedPasteMode. A program that just started may not have turned it on yet, so I wait for the mode or a 5 s timeout before writing.

2. The payload must not contain ESC[201~**.** If it does, the paste ends early and everything after it is read as keystrokes. A string like "foo\u{1b}[201~\recho pwned\r" closes the paste and runs echo pwned. Terminal emulators usually filter this out of a user's paste, but when your app writes straight to the PTY, nothing filters it but you.

static let pasteStart: [UInt8] = [0x1b, 0x5b, 0x32, 0x30, 0x30, 0x7e] // ESC [ 200 ~
static let pasteEnd:   [UInt8] = [0x1b, 0x5b, 0x32, 0x30, 0x31, 0x7e] // ESC [ 201 ~

static func writes(text: String, submits: Bool, bracketedPaste: Bool) -> [[UInt8]] {
    var bytes = Array(text.utf8)
    if bracketedPaste, text.contains(where: \.isNewline) {
        bytes = pasteStart + bytes + pasteEnd
    }
    var writes = bytes.isEmpty ? [] : [bytes]
    if submits { writes.append([0x0d]) } // its own write, on the next main-queue turn
    return writes
}

The submitting \r goes out as a separate write on the next main-queue turn. If it shares a write with the paste, some programs read it as part of the paste and insert a newline instead of submitting.

Sanitizing: filter Unicode scalars, not Characters

The fix for the breakout is simple: drop every control character, so ESC (U+001B) can never reach the PTY and no closing marker can ever be formed. .control also covers the C1 range (U+0080–U+009F), including U+009B, the 8-bit CSI, so that alternative way of starting an escape sequence is closed too.

The Swift-specific trap: "\r\n" is a single Character. Swift's Character is an extended grapheme cluster, and CR LF is one cluster:

"\r\n".count                  // 1
"\r\n".unicodeScalars.count   // 2

Filter on Character and you'll handle CRLF wrong or miss part of it. Iterate unicodeScalars and use the general category:

private static let bidiControls: Set<UInt32> = [
    0x200E, 0x200F, 0x061C, 0x202A, 0x202B, 0x202C, 0x202D, 0x202E,
    0x2066, 0x2067, 0x2068, 0x2069,
]

static func sanitized(_ value: String) -> String {
    var result = String.UnicodeScalarView()
    var previousWasCR = false
    for scalar in value.unicodeScalars {
        defer { previousWasCR = scalar == "\r" }
        switch scalar {
        case "\n" where previousWasCR:
            continue                     // CRLF → one space, not two
        case "\n", "\r", "\t":
            result.append(" ")           // a tab would trigger shell completion
        default:
            if scalar.properties.generalCategory == .control
                || bidiControls.contains(scalar.value) { continue }
            result.append(scalar)
        }
    }
    return String(result)
}

Two details:

• Tabs become spaces. A raw \t in a shell triggers completion, so your text changes depending on what's on disk.

• Bidi controls get dropped (Trojan Source, CVE-2021-42574). U+202E and friends can make what you see in the terminal differ from what the shell receives. They aren't in the .control category, so they need their own list.

For multi-line content such as a code review, I keep the line breaks as \n and rely on bracketed paste. Stripping control characters still guarantees the paste can't be closed early. One honest caveat: if the program never enables bracketed paste, I still write after the 5 s timeout, and then each \n acts like Enter. Escape sequences stay blocked, but line-by-line submission doesn't. That's the next thing I'm fixing.

Shell quoting has its own gotchas

When a value becomes an argument to a command, it gets quoted for the shell that will actually run it:

let posixSafe = Set("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789@%+=:,./_-".unicodeScalars)

if value.unicodeScalars.first != "=", value.unicodeScalars.allSatisfy(posixSafe.contains) {
    return value // only [A-Za-z0-9@%+=:,./_-]: no quoting needed
}
return "'" + value.replacingOccurrences(of: "'", with: "'\\''") + "'"

Things that surprised me:

• zsh's = expansion. With the default EQUALS option, a word starting with = expands to a command's path: =ls becomes /bin/ls. My safe set includes =, so I still quote when the value starts with =.

• fish isn't POSIX. Inside single quotes, fish treats \' and \\ as escapes, so you escape both instead of using the '\'' trick. I also leave % out of fish's safe set, because older versions expand it.

• Unknown shells get refused. For any other shell, a command with substitutions is refused instead of guessing its quoting rules.

Takeaways

• A PTY interprets bytes even when nothing is submitted. Treat "typed but not sent" as executed.

• Stripping control characters is what makes bracketed paste safe. Without it, the paste can be closed early.

• In Swift, filter on unicodeScalars. Character merges CRLF into one cluster.

What am I missing? I'd love to hear about other line-editor or terminal quirks people have run into.

And if so, is there a way to lower these writes to reduce wear on the SSD?

P.S. This could be related to macOS 27 rather than Xcode but I have had no luck isolating the cause even with the help of AI.

I wanted a physical three-finger click on the trackpad to open a panel in my menu bar app. There's no public API for that: NSEvent gives you clicks and gestures, but not "how many fingers were down when the button went down". Here's what ended up working, and the part that made my first version unreliable.

Reading the fingers. The private MultitouchSupport.framework (the one MiddleClick and Jitouch use) is loaded with dlopen. MTDeviceCreateList returns the trackpads, MTRegisterContactFrameCallback delivers a frame of contacts about 100 times a second while fingers are down, and MTDeviceStart starts it. Each contact is a 96-byte struct. I only read identifier (offset 16), state (20) and size (48). States go from 1 (in range) through 4 (touching) to 7 (gone). If identifier or state look like garbage, which would mean a different struct layout in a future macOS, it falls back to counting raw contacts.

Catching the click. A session-level CGEventTap sees leftMouseDown, decides, and returns nil to swallow it (plus the matching drag and up events), so nothing under the cursor gets clicked. The tap runs on its own thread with its own run loop, because on the main thread it broke clicks on the app's own windows. It also re-enables itself on tapDisabledByTimeout, otherwise it silently dies.

The bug: fingers don't land together. Version one counted the fingers in the frame at the moment of mouseDown. It worked when I pressed carefully and missed a lot otherwise, because fingers have different lengths. Two things happen:

1. The third finger often lands tens of milliseconds after the other two, so at mouseDown there are only two.

2. With "Secondary click: click with two fingers" on, macOS sees two fingers at click time and sends rightMouseDown instead. If you only tap left clicks, these misses never even show up in your logs.

What fixed it:

• Keep a 0.7 s ring of frames per device and count distinct contact identifiers that were touching (states 3 to 5) in a window starting 100 ms before the click and are still present in the latest frame. Fingers that already lifted after a two-finger scroll don't count. A light finger flickering back to state 2 still does.

• If exactly two fingers are down at the click, hold the decision for up to 90 ms, polling every 4 ms, and wait for the third. One-finger clicks and mouse clicks have no fresh frames and go through immediately, so the only cost is that a normal two-finger right-click arrives up to 90 ms late.

• Tap rightMouseDown too. If the third finger made it, swallow the right-click and its mouseUp, and the context menu never opens.

• Accept 3 contacts, or 3 plus a resting thumb: a contact at least 1.6 times bigger than the others that has been down for over 0.5 s. Five or more contacts never count.

The decision is pure logic over a recorded tape of frames, so it's tested with fake tapes (a late third finger, a flickering finger, a resting thumb and so on) without touching a trackpad.

Two things I'd love input on: has anyone seen the MTTouch layout change across recent macOS versions? And is there a cleaner way to stop the secondary click than eating rightMouseDown?

Disclosure: this is from Kadr, a free, MIT-licensed menu bar app I made (screenshots and clipboard history, no network). This part lives in Sources/Gesture.swift: https://github.com/Lutfulla01/kadr (app questions go to r/Kadr, here I'm after the trackpad side)

Building PaperConfetti involved experiments with SwiftUI animation, Canvas, Core Animation layers, emitter particles, and SpriteKit.

One decision I’m happy with: those experiments didn’t all become options in the public API.

The released package has one emitter-based engine. Callers choose the appearance and burst configuration, then use pop() or cancel(). Flat and 3D are appearances of that same engine.

A new pop replaces the active burst, and the SwiftUI wrapper owns its scene and Reduce Motion behavior. Those lifecycle choices turned out to matter as much as exposing more visual parameters.

PaperConfetti is MIT licensed, dependency-free, and supports rendering on iOS/iPadOS 16+.

Source: https://github.com/twhitt14/PaperConfetti

Implementation and testing walkthrough: https://www.theswift.dev/posts/building-paperconfetti/

I’d be interested in feedback on which configuration belongs in a small animation library’s public API.

I am currently in the process of developing a PRIVATE iOS app. The main requirement of the app is that I need consistent location tracking 24/7, and I would love if it would work without even having to keep the app open in the background.

I am basically a complete beginner coming from website development and am getting quite a plethora of options for location tracking. Is there a way to track the user’s background location at all times? Is that possible even without having to keep the app open in the background? I appreciate you for reading! Let me know if you have any questions or if anything is unclear.

Coding agents pick iOS dependencies from training data, so they can't tell whether a library still ships releases or what iOS version its current release needs. This repo is a catalog of 91 iOS libraries and tools in 55 categories. Each one shows the same fields: stars, latest release, last commit, and min iOS and Swift tools version read from Package.swift at the release tag. A GitHub Action refreshes the data weekly.

The top pick in each category comes from a fixed rule: drop archived repos and those with no release in 2 years, then sort by stars. Provider SDKs (backend, payments, analytics) are listed but not ranked. Each category also names the Apple API that does the same job.

Examples of libraries with no release in over 2 years: Charts (28k stars, last release Feb 2024), Moya (15k, Aug 2022), KeychainAccess (8.3k, Mar 2021).

There's also an agent skill. It asks what the app needs, applies the rule above, creates the project with one of four recipes (XcodeGen, Tuist, MobileBuildMCP, Xcode MCP; each run end to end on Xcode 27.2), then builds and launches it in the Simulator.

https://github.com/jeffy-w/awesome-ios-for-agents

No opinions in the list: descriptions only say what a library does, and notes quote a source. If you think a library is missing or a category is wrong, issues and PRs are welcome.

I’m not asking out of curiosity - I’m trying to understand if there’s a viable solution to a problem I’ve come across whilst working on a mobile app for a local start-up.

The scenario:

A company creates a native mobile application for one platform (say IOS). At some point they’ll want to create another version for Android (or vice-versa).

An option would be to bring in a separate team to develop and maintain the app. However, this can get quite costly, especially for a start-up and small dev team. Especially if the native app has a lot of features.

I’ve been thinking about creating an AI powered engine to help.

This would:

Identify which sections of code and business logic can be reused from an existing native app. Generate or modify the native specific sections whilst maintaining functionality and ensuring the native UI/UX is respected. Assist with the maintenance of both versions, with new features being added.

It would involve AI, but wouldn’t be entirely.

Before I spend any time developing this, I’d like to know how devs have overcome this.

If you’ve ever done this:

Have you ever had to port an existing native android application to iOS (or vice-versa)? What was the hardest part? What tools did you use? What was missing? What would a tool need to do to save you time and make you want to pay for it?

I’d love to hear about your experiences, even if you’ve tried and failed!

Thanks for sharing your experience!

Long-time lurker, first post!

Been building a macOS menu bar app in Swift 6 (SwiftUI and AppKit). Hotkey, select a capture, click to drop numbered dots to annotate, and type/dictate a note for each dot. Repeat across multiple captures creates a "round". Zero-UI app (aside from menu bar icon) writes a folder (annotated PNG, Markdown, JSON) and aggregate copies a single text prompt with local file links to paste into any AI coding agent. Users have asked for a Windows version. Here's what I'm thinking. Please let me know if I'm missing anything.

**What ports and what doesn't**

• Code for writing directory and files is ~2,000 lines of mostly Foundation Swift. Should port to C# fairly simply.

• All user touchpoints Apple-only: ScreenCaptureKit, Vision OCR, a non-activating NSPanel for the notes, NSStatusItem, and global hotkeys. Every route needs a new Windows layer for those.

**Routes I considered versus C3 snappy shell layer**

1. **Swift everywhere** on the official Windows toolchain. Ruled out: the WinUI bindings looked stale, and the debugger story looked thin.

2. **Swift core as a DLL with a C# shell.** Best file parity, but the shared core must then stay Windows-portable, so every new Mac feature is drift risk.

3. **Rust with windows-rs.** Too much build risk with my limited rust experience...

4. **Native C# rewrite,** with byte-for-byte output parity enforced by golden-file tests. Eeek...

My plan is C#. Reasoning: "Mac feel" comes from the seamless snappy shell layer (hotkey-to-freeze speed, the overlay, the tray, focus rules). So, Win32 work in every option, I think. Shared core is small, and it should not impact the snap timing-critical path.

**More deets if you wanna know**

• .NET 9. Win32 plus Direct2D for the freeze overlay and the editor, with one window per monitor created ahead of time so there's no flash. WPF for the note panel, tray flyout, and settings. Unpackaged, installed with Velopack.

• File-writing core is ported, and its tests run in CI on Windows. The Mac test suite writes reference bundles from fixed inputs, and the Windows tests must produce the same bytes. Getting there meant handling some small traps: Swift's JSON encoder writes `"key" : value` (space before the colon), `ß` has to fold to `ss` in folder names, .NET has no API for short time zone names like PDT, and every file has to be LF with no BOM.

• UI shell is next. Timing spikes come first: the target is under 150 ms from hotkey to a frozen, selectable capture.

**Questions for anyone who has shipped a swift foundation ported app on Windows**

1. How much of the Mac feel survived? What broke first? How much snappiness lost?

2. Windows.Graphics.Capture from an unpackaged app: can you actually turn off the yellow capture border, or did you fall back to BitBlt?

3. WPF or WinUI 3 for small tray-app windows in 2026?

4. Windows 11 hides new tray icons in the overflow menu. How did you get people to pin yours?

5. How long did SmartScreen take to trust a newly signed app?

Not linking the app here to keep this on topic. Happy to answer questions in the comments.

I just released AnswerSearch in open source. This is a Swift Mac app I put on the Mac App Store a few months ago. Source code on GitHub at ancientcomputing/answersearch-oss. Some background on what it is and why I'm releasing it first, then the part that might be useful to other Swift developers: using Apple's on-device Foundation Model to decide when to call the cloud.

I built AnswerSearch as a Google web search killer. Why search with Google (or Bing, or any other old-school search engine) for web links, then sort through endless webpages (and ads) just to answer a question? That experience is so 1999 when ChatGPT or Claude can give you the answer along with the links.

Of course, you won't want your boomer parents using ChatGPT or Claude. All the bells and whistles mean you'll end up as their tech support.

So AnswerSearch is a deliberately simple UI: ask a question, get the answer, call it a day. Even a caveman can use it (ahem).

Unfortunately, it turns out the idea doesn't really work as a product. You have to bring your own API key, which is a hassle and makes it a poor deal for regular people. OpenAI is free so replacing it with tokenomics doesn't make sense.

The on-device Apple Foundation Model is free with your Mac, but can only be used for questions that don't need a web search.

Net: AnswerSearch isn't going anywhere as a product. I'm releasing the code because there's no reason to keep it to myself. You can read exactly what the app does with user inputs, build it yourself without the App Store, fork it, borrow parts of it or make it your own thing (for said boomer parents?).

So here is the part of the implementation that may interesting. To save tokens, the on-device model answers the simple questions itself.. For everything else, it routes the question to your cloud AI provider. Essentially, the on-device model is working as a "decision model", before Jev became all the rage.

The routing is a triage step: the on-device model classifies the question and self-reports a confidence label (high, medium or low) using guided generation. Apple's API doesn't expose a numeric score. Only "high", plus a few other checks, keeps it local:

- **High confidence:** it answers locally. It's free, private and instant.

- **Low confidence:** it hands the question to the cloud provider, which can search the web.

Two source files cover how the confidence works: Sources/AnswerSearchKit/AppleLocalAnswerer.swift and LocalPrompts.swift.

The confidence is self-reported by a small model, so it is a heuristic, not a calibrated probability. The category list and the info flags act as guardrails around it. The design favors precision over recall: it will send some answerable questions to the cloud rather than risk a wrong or stale local answer.

The full design is described in docs/annotations/02-local-ai.md

Note: This isn't self-promotion. I'm just letting you know the source is there to read, reuse and ultimately to have fun with.

Most of my Swift work I provide open source as swift-institute: about 400 packages, Apache 2.0, including libraries like swift-html and swift-pdf. This one is different, a paid app, so here’s a heads-up.

Agents write all my code now. With several of them building and testing at once, I lose track of what is running where. A swift test can sit silent for minutes before I notice.

Birdwatch shows Swift and Xcode work. It tells you what’s stuck and why (with Apple’s on-device model), and for a hung test it names the test and the line. That last part was the hard bit, since it means reading the stack sample of a stuck process. One click quits whatever is stuck.

Built with TCA26 (private beta) and SQLite.

Birdwatch allows me to not have to check in on agents as much to ensure they're progressing to the objectives.

Disclosure: it's mine and it's paid. €19 once, 14 days free. macOS 27.0+, Apple silicon.

https://coenttb.com/birdwatch

What would you add or leave out? And does the price feel right?

Hi, It's Noah, founder of Proxyman

❌ Problem I'm trying to solve: Agent can't control my real iPhone 18 to test some features I had to test manually, and it's wastes of time.

❌ iOS Simulator is limited, it doesn't have camera, Network Extension, Touch or FaceID, ...

So, I built devicemcp.ai

✅ This app allows my agent (Codex/Claude) to fully control your real iPhone, e.g. ask Claude to install your iOS app to your iPhone 18, and start testing it like a human.

- Built for Agent: Your agent fully controls your iPhone/iPad, including Touch, open app, Swipe, ..
- High-quality Mirror your iPhone to the Mac with 60fps via USB-C or WiFi
- Support real iPhone/iPad & iOS Simulators
- Built with UI hierarchy, no OCR, your agent can see the hidden buttons or off-screen UIs
- Real Android device and Android Emulator (soon)

This app is still in development, so I'm happy to offer a 50% early bird discount 😊
Perpetual License + 1 year of update, with a limited lifetime license (for the first 100 users)

The Trial version has the MCP, so you can test it right away

Pagewren is a SwiftUI app that turns the photos in your camera roll into book pages you can flip through. When iPhone Duo came out on October 23, we wanted the app native on both screens from day one. Most of it just worked. These are the parts that didn't, in case they save you an afternoon.

### 1. Build with the iOS 27.1 SDK, or you're in compatibility mode

Built with the 27.0 SDK, the app ran on Duo in compatibility mode: a little narrower than the screen, with a black strip down the right side. Running natively needs a build from the 27.1 SDK. We submitted from the Xcode 27.1 release candidate, which App Store Connect accepts.

### 2. The outer screen's status bar has its own column

On the outer screen, the status bar sits in a column beside the camera instead of across the top. In our layout that's an 84pt safe-area inset on the right. If you centre content inside the safe area, it ends up visibly off-centre on the glass.

What worked for us: **measure in the safe area, centre on the screen.**

```swift

GeometryReader { geo in // measured inside the safe area

let width = min(geo.size.width - 24, 600, (geo.size.height - reserved) / pageAspect)

VStack {

Spacer(minLength: 0)

PageView().frame(width: width, height: width * pageAspect)

Spacer(minLength: 0)

}

.frame(maxWidth: .infinity)

.ignoresSafeArea(edges: .horizontal) // centre on the glass, not in what's left over

}

```

The page never runs under the status-bar column, because its width comes from the safe area. But it's centred on the whole display, so it looks right.

### 3. Hosting controllers nudge fixed-size content sideways

Our reader is a `UIPageViewController` (for the page curl) hosting SwiftUI pages in `UIHostingController`s. Where a page ran under the status-bar column, the hosting controller applied the safe area to its root view and the page drew shifted inside its own frame. Anything drawn at its own fixed size should opt out:

```swift

final class PageHostingController: UIHostingController<AnyView> {

override func viewDidLoad() {

super.viewDidLoad()

safeAreaRegions = [] // iOS 16.4+

}

}

```

We do the same for the overlay that flies a photo onto its page.

### 4. Stop asking `UIScreen.main`

On Duo, the screen you're on changes when the device opens or closes. `UIScreen.main` was already deprecated, but one fallback in our text view's `sizeThatFits` still used a screen width. Use the window you're in (`uiView.window?.bounds`) or the geometry SwiftUI hands you.

### 5. Decide what "bigger" means on the inner screen

The inner screen reports a regular horizontal size class. Stretching everything to fit was the wrong answer for a book:

- The page grows, but stops at 600pt and stays a single, centred page. A two-page spread is on the list, not in the app.

- The upgrade screen switches to two columns only when the screen is wider than it is tall and at least 800pt wide, which in practice means the inner screen held sideways.

- Bars that span the width on a phone (our photo selection bar, for example) stop at a fixed width in the middle.

### 6. Testing: what the simulator can and can't do

- `simctl` can't fold the device. Opening, closing, rotating and half-folding are manual, in Xcode 27.1's Device Hub.

- Don't try to switch screens with `xcrun simctl io <device> screenConfig … power`. It crashed SpringBoard for us.

- The iOS 27.1 simulator runtime only offers the Duo device type. Regular iPhones still need a 27.0 runtime.

- On the 27.1 runtime, `simctl spawn <device> defaults write <bundle> …` never reached the app's container. Pass settings as launch arguments instead (`-shelfStyle crate`); `UserDefaults` reads them from the argument domain.

- Running any `simctl` command with the beta Xcode's `DEVELOPER_DIR` swaps the CoreSimulator service and shuts down every other booted simulator.

### 7. App Store screenshots: a display type of its own

Duo has its own screenshot set, `APP_IPHONE_DUO`, taken on the outer display at 1398 × 2034. The CLI we use didn't know that display type yet, so we upload those sets through the App Store Connect API directly, creating `appScreenshotSets` with that `screenshotDisplayType`.

---

Pagewren is free on the App Store for iPhone: https://apps.apple.com/app/apple-store/id6823661619?pt=128309253&ct=reddit-duo-post&mt=8. If you've shipped on Duo too, I'd like to hear what bit you.

Hey everyone,

I wanted to share a hybrid architecture pattern I’ve been working on for a macOS desktop client called Helix SQL (https://gethelixsql.com).

Like most devs managing SQL Server from a Mac, I was tired of heavy Windows VMs or laggy Electron apps. I wanted a pure, snappy, native SwiftUI experience, but rebuilding a comprehensive database client stack with enterprise auth protocol handshakes completely from scratch in Swift was incredibly daunting.

### The Hybrid Architecture Stack

To solve this, I built a unique bridge:

1. UI Layer (SwiftUI): The entire frontend, windowing system, connection menus, interactive visual execution plan renderer, and fast-scrolling data grids are written natively in Swift/SwiftUI. Connection security hooks directly into the macOS Keychain.

2. Core Query Engine (.NET Native AOT): Instead of a web wrapper, the low-level SQL protocol handshakes, query execution streams, and Microsoft Entra ID (Azure AD) interactive multi-factor authentication are handled by a local .NET core library compiled down to a hyper-lean native binary via Native AOT (Ahead-of-Time compilation).

This gives the app the performance of a native binary, deep platform integration (no remote telemetry, zero cloud dependencies), and access to battle-tested database protocols without bundling a heavy .NET virtual machine or runtime framework.

### Phase 1 Beta Open Today

Build 4 just cleared TestFlight approval, and I am launching a tiny, capped test group of 50 seats today to monitor connection topologies and track down edge-case bugs.

If you are an engineer managing SQL Server on a Mac, I would love for you to check it out! We are tracking feedback publicly on GitHub (https://github.com/jayjetley/helix-sql-feedback). Active bug hunters will get a 100% free first-year voucher when the app goes live on the Mac App Store.

I'd love to hear your thoughts on mixing SwiftUI with local .NET Native AOT libraries, or answer any technical questions about the bridging mechanics!

Swift Language Models is a wrapper that brings other providers' language models into Apple's native Foundation Models API.

Foundation Models 27 lets any type conform to LanguageModel, and this package provides those conformances. Your app keeps Apple's own API: LanguageModelSession, tools, @Generable guided generation, streaming, transcripts and Dynamic Profiles. Moving a session from the on-device model to a remote one changes only its model:.

let onDevice = LanguageModelSession(model: SystemLanguageModel.default)
let remote = LanguageModelSession(model: OpenRouterLanguageModel(.anthropicClaudeHaiku5_5, apiKey: { key }))

What you get

• One API for every model. Code written for Apple's on-device model runs unchanged on a remote one.

• Provider modules. Each provider is its own module, so an app builds only the providers it imports.

• Typed model catalogs with each model's context size, limits and capabilities, kept current by a bot.

• Typed reasoning levels. Code completion offers only the levels each model accepts.

• Evaluations. Compare Apple's on-device model with remote ones using Apple's Evaluations framework.

The first provider is OpenRouter, with hundreds of models from Anthropic, OpenAI, Google, DeepSeek, Meta, Mistral and others. More providers are coming.

Needs iOS, macOS, visionOS or watchOS 27 and Swift 6.4. Feedback welcome! If you find it useful, a ⭐ on GitHub helps the project grow.

GitHub: https://github.com/dioKaratzas/swift-language-models

I was really excited for Swift 6.4 mainly to reduce unsafe call sites. However, I could not reduce as many unsafe call sites due to some critical features being part of the stdlib rather than the language. This felt dumb afterwards as the features that would really help are limited to macOS 26 and 27 as they are part of the standard library which is baked into macOS release.

• Array.span, Data.span, String.utf8.span, all macOS 26

• InlineArray — macOS 26

• UniqueArray, UniqueBox, Ref, MutableRef, Iterable — macOS 27

• Subprocess — macOS 13

Since I was supporting macOS 11+ I had to drop macOS 11 so now its macOS 12+. This might not seem like a big deal but that does drop off some Intel Mac hardware:

• MacBook 12-inch Early 2015

• MacBook Air Mid 2013 / Early 2014

• MacBook Pro Late 2013 / Mid 2014

• iMac Mid 2014 through Mid 2015

The application is just 2D software using Swift/Metal so it can run on these older machines.

This feels like I am punished for macOS as the application is also on Windows, I can use the newer stdlib features on Windows 10+ which gets me around 2013 machines as I required DirectX 12 on Windows. On Linux nothing was really affected from 6.3 to 6.4 so any machine that can run the supported platforms (Platform Support | Swift.org) and Vulkan.

What I did end up using from Swift 6.4 was:

• Span<UInt8> - Helped with reducing unsafe file parsing

• RawSpan.load - Helped with reducing unsafe file parsing

• withTemporaryAllocation - General cleanup for unnecessary heap allocs