Apps Break Free of the OS: Cutefish, SimRun, and the Blurring Desktop

When Apps No Longer Belong to a Specific Operating System

This week's newsletter features three intriguing projects: Cutefish, SimRun, and Mac Android Subsystem. They take different technical routes — some provide a runtime by reimplementing APIs and frameworks, some run apps built for emulators directly, and others hide a full virtual system in the background. But they all attempt the same thing: letting apps that originally belong to different operating systems appear naturally on the same desktop.

Cross-platform running is nothing new. From Wine to various virtual machines and emulators, developers have worked on this for decades. But developers are no longer satisfied with merely making apps "runnable." They want users not to care which platform an app originally came from. As features like standalone windows, Dock, Spotlight, clipboard, and system notifications gradually merge, the runtime begins to recede into the background, and the boundary between app and host system blurs.

AI is accelerating this process. In the past, reverse-engineering system APIs, replicating framework behavior, or porting complex runtime environments required significant time and manpower. Now, coding agents can handle a substantial portion of the exploration, implementation, and verification work, giving individual developers and small teams the chance to tackle projects that were previously unaffordable. The cost of breaking these boundaries is falling.

A question is emerging: If apps no longer depend so heavily on a particular operating system, how will we choose hardware in the future? In the past, an exclusive app or an irreplaceable software ecosystem could decide which device a user buys. As more apps can cross system boundaries, hardware design, performance, price, system experience, and even brand loyalty and personal preference may carry more weight in purchasing decisions.

Interestingly, this doesn't necessarily mean competition between platforms will weaken. On the contrary, whoever can integrate apps from other ecosystems more naturally and stably into their own system may gain new appeal. The focus of competition may gradually shift from "which apps I exclusively have" to "what kind of user experience I can provide for these apps."

Perhaps in the future, when choosing a device, we won't first consider which apps it can run, but rather ask ourselves how we actually enjoy using it.

This issue's content | Previous issue | All weekly issues

Recent Recommendations

Running Mac Apps on Cutefish

Running Windows apps on Linux is already commonplace, but running unmodified macOS apps directly on Linux sounds far-fetched. Cutefish is attempting exactly that. Instead of virtual machines or instruction emulation, it uses a compatibility layer called Reef to reimplement the Mach-O loader, Objective-C Runtime, and frameworks like Foundation, AppKit, Core Graphics, and SwiftUI, letting Mac apps run directly on a Linux desktop. This article shows the current compatibility results and candidly discusses performance issues, such as rebuilding the entire view tree on partial state changes and repeated redraws during scrolling.

Swift is steadily expanding its cross-platform capabilities, but many apps built with Swift still depend deeply on the Apple ecosystem's frameworks and are hard to port directly. Reef offers another possibility: rather than changing existing apps, it makes other platforms capable of running them.

Every iOS Haptic Pattern, With Code

iOS provides multiple haptic feedback APIs, but the capabilities and suitable scenarios of each mechanism differ. Alok Singh summarizes the usage of UIKit's Feedback Generator, SwiftUI's .sensoryFeedback, and Core Haptics, with code examples covering system preset patterns, custom haptic patterns, dynamic parameters, and AHAP files.

Because haptics cannot be experienced in the simulator, Alok also built Haptics Explorer, which lets developers compare haptic patterns directly on an iPhone and grab the corresponding Swift code.

AVFoundation Audio Ducking and Smooth Mixing Engineering Practice

In scenarios where background music and voice narration play simultaneously, simply adjusting the background music volume at the start and end of speech often produces jarring volume changes, and can cause a "pumping effect" with repeated fluctuations during natural pauses in speech. Snow Wu explains how to use asymmetric volume ramps — quickly lowering background music and slowly recovering it — and uses Generation Tokens with a delay window to avoid frequent volume changes caused by natural speech pauses. Compared with the code, the design thinking here is more valuable: audio state changes must match human auditory perception, and asynchronous events need coordination before they can become stable playback states.

The Dismantled NSHostingView Rebuilds a View Again

In mixed SwiftUI and AppKit development, if dismantleNSView in NSViewRepresentable has been called, does that mean the inner view will not be created again? Onevcat discovered a counterintuitive phenomenon: even when the outer Representable has entered the teardown process, the nested NSHostingView can still call the child view's makeNSView in a later layout transaction, causing the terminal Surface that had already been moved to Canvas to be snatched back by an invisible host.

The article fully records the process from version bisection, discovering the hidden connection between the .overlay badge and the reproduction of the issue, to building a minimal repro and confirming the nested Hosting View lifecycle problem. Ultimately, the author not only proactively removes the inner NSHostingView in dismantleNSView, but also improves the ownership rules for the shared Surface so it can be recovered from hosts that no longer display.

Another value of this article is showing an effective way to use AI agents in complex debugging. The agent doesn't just modify code; it builds a chain of evidence through repeated experiments, while the developer asks why at key points, avoiding ending the investigation prematurely once symptoms disappear.

How I Built Live Voice: One Tool Contract, Six Realtime Voice Providers

The difficulty of integrating realtime voice AI into an app lies not only in handling audio streams and model responses, but also in letting the model operate the app safely and reliably. Apoorv Darshan shares his experience building the Live Voice feature for the open-source app Fud AI (SwiftUI on iOS, Compose on Android): using a unified JSON tool contract to define 25 app operations, with iOS, Android, and Cloudflare Worker following the same interface, and separate adapters handling differences in audio formats, tool calls, and visual input among services like Gemini Live, OpenAI Realtime, xAI, and Qwen.

Apoorv categorizes tools into read, navigate, write, and destructive operations. Writes offer an 8-second undo window, and destructive operations require user confirmation; by default, normal writes also need confirmation.

Why Tuist Should Build the Harness on Top of Compute

A few months ago, Tuist co-founder Pedro Piñera was still skeptical about the trend of going all-in on remote development in The remote development mirage. But as he used Amp more deeply, he began to reassess that judgment. As Coding Agents can complete an increasing number of coding tasks independently, developers may no longer need to sit in front of a computer with an editor at all times. Mobile devices, voice interaction, and even Live Activities could become new development entry points.

In this article, Pedro proposes that as Compute becomes commoditized, Tuist should build its differentiator in the Coding Harness and developer experience on top of that compute. His earlier post The automation graph agents need discussed how to let agents determine follow-up test and validation tasks based on code changes; now he wants to combine those capabilities with remote computing resources, so development tools move from passively executing commands to actively understanding projects, organizing tasks, and verifying results.

When code editing is no longer the center of development activity, do we really need a smarter IDE, or an entirely new development environment?

Claude Code Occupies 39.6k Tokens Before the Conversation Starts

Where does Claude Code's context overhead come from? Using the /context all command shows the initial context usage before any prompt is entered. Besides system prompts and tool definitions, CLAUDE.md, Rules, Skills, and custom Agents can take up a large share, while MCP tools with lazy loading are not counted in the initial usage.

Hao Liu explains how to use /skill-doctor and /doctor prompt-audit to inspect rarely used Skills, duplicate rules, and outdated instructions, and suggests loading rules by file path and trimming CLAUDE.md. The author also reminds readers that context usage does not equal the actual cost per request; Prompt Caching reduces billing for repeated content. Instead of trimming based on intuition, measure your own environment first, then decide what is worth cleaning up.

Tools

SimRun: Run iOS Apps in Independent Mac Windows

Developed by Cyandev, SimRun is an interesting open-source experiment: without booting the full simulator or adding Mac Catalyst compatibility, you can run Xcode-compiled iOS simulator apps in standalone windows on macOS. For developers who need to repeatedly tweak SwiftUI or UIKit interfaces, this offers an alternative development aid.

The project also provides command-line, screenshot, view hierarchy inspection, and an experimental JavaScript automation interface, and supports running apps without showing a window, which is useful for writing inspection scripts or letting AI coding agents operate the app. Note that SimRun requires an Apple Silicon Mac, Xcode, and a simulator runtime, and demands that System Integrity Protection (SIP) is disabled.

Mac Android Subsystem: Let Android Apps Blend into the Mac Desktop

Somewhat similar to the previous project, the Mac Android Subsystem (MAS) by Harkhowalia tries to give Android apps a Mac-like experience: double-click an APK to install, each app gets its own window and Dock icon, works with Spotlight search, ⌘-Tab switching, Notification Center, and two-way clipboard.

MAS does not run Android apps directly; it uses LineageOS, QEMU, and the Apple Hypervisor Framework to run a full Android environment in the background, then streams the app screen via scrcpy into a standalone Mac window. The project is still in an early pre-release stage, requires an Apple Silicon Mac and macOS 15 or later, and does not include the Google Play Store or Google services.

Previous Issues

💝 Support and Feedback

If this issue helped you, please:

👍 Like — let more developers see it
💬 Comment — share your thoughts or questions
🔄 Share — help peers grow together

🚀 Expand Swift Horizons

📮 Email Subscription | weekly.fatbobman.com for exclusive technical insights

👥 Developer Community | Discord for real-time experience exchange

📚 Original Tutorials | fatbobman.com for Swift/SwiftUI best practices