Why Air is Mac-Only (For Now)

When we started building Air, we faced a decision that every software company encounters: build for one platform deeply or build for multiple platforms quickly. We chose the first option, and it has made all the difference in the product we were able to create.

The Cross Platform Temptation

The fastest way to build a desktop application today is to use web technologies wrapped in a framework like Electron. You write your app once using HTML, CSS, and JavaScript, and it runs on Mac, Windows, and Linux. Many popular applications take this approach, from Slack to Visual Studio Code to Discord.

The appeal is obvious. Instead of maintaining three separate codebases, you maintain one. Instead of learning three platform-specific APIs, you use familiar web technologies. Instead of hiring specialists for each platform, you hire web developers. The math seems to favor cross platform development by a wide margin.

We could have built Air this way. We have the technical skills, and it would have gotten us to market faster. But when we looked at what we wanted Air to actually do, we realized that cross platform development would prevent us from building the product we envisioned.

What Native Development Enables

The core promise of Air is that you can control your Mac using your voice. Not just dictate text, but actually send messages, create calendar events, take notes, and organize files. To deliver on this promise, we need deep integration with the macOS operating system.

Consider what happens when you say "send a message to Sarah that I am running five minutes late." To fulfill this request, Air needs to access the Messages app, find your conversation with Sarah, compose a new message, and send it. This requires using Apple's native automation frameworks that are only available to apps written in Swift or Objective-C.

An Electron app has no way to access these capabilities. At best, it could open the Messages app and pre-fill a compose window. You would still have to manually click send. That extra step might seem minor, but it undermines the entire value proposition of a voice assistant. The point is to eliminate manual steps, not add new ones.

Real System Integration vs Clipboard Hacks

Native macOS development gives us access to the same APIs that Apple's own applications use. EventKit lets us read and write to Calendar with full support for recurring events, attendees, alerts, and time zones. The Messages framework lets us send iMessages that appear in your normal conversation threads. Finder automation lets us move and rename files with proper undo support.

Cross platform applications that claim similar features usually implement them through clipboard hacks. They generate the text of a calendar event and copy it to your clipboard. They compose a message and paste it into a new window. They provide instructions for file operations that you have to execute yourself. These workarounds create friction and unreliability.

We wanted Air to actually do things, not generate instructions for you to follow. That required native development.

Native Performance and Resource Usage

Another advantage of native development is performance. Electron applications embed a full copy of the Chromium web browser and Node.js runtime. Even a simple Electron app uses 200 to 300 megabytes of RAM just sitting idle. Complex Electron applications can use significantly more.

Air uses approximately 50 megabytes of RAM in typical usage. This is possible because we use Swift and AppKit, which are designed specifically for macOS and optimized by Apple's compiler team for Apple hardware. We do not carry the overhead of a general purpose web browser.

This efficiency matters for a utility that runs all day in the background. You should not have to think about whether your voice assistant is consuming too many resources. It should just be there when you need it and invisible when you do not.

Native User Interface and Experience

macOS has distinct design patterns that users expect from well-built applications. The way windows behave, the appearance of buttons and controls, the integration with system features like Dark Mode and Notification Center. Native development lets us match these expectations precisely.

Our floating panel uses Apple's native vibrancy effects that respond to the content behind it. When you activate Air, the panel appears with the same translucent material effect you see in Spotlight or the Dock. This is not a CSS approximation of the effect. It is the actual rendering pipeline that Apple uses for system components.

We integrate with the macOS menu bar in the standard way. Our notifications use the native Notification Center. Our keyboard shortcuts follow Apple's conventions. Every interaction feels like it belongs on a Mac because it is built with Mac-native technologies.

Hardware Optimized Audio Processing

Voice input quality depends heavily on audio processing. Background noise reduction, echo cancellation, level normalization: these algorithms can make the difference between accurate transcription and frustrating errors.

macOS includes hardware-tuned audio processing that is optimized for each Mac model. Apple engineers have measured the acoustic characteristics of every MacBook microphone array and calibrated the system audio processing accordingly. When you use the native audio APIs, you automatically benefit from this optimization.

Cross platform audio libraries cannot access these optimizations. They use generic algorithms that work reasonably well across all hardware but are not tuned for the specific microphones in your Mac. The result is lower quality audio input and higher error rates in speech recognition.

The Philosophy of Doing One Thing Well

Our decision to focus on Mac comes from a philosophy of doing one thing exceptionally well rather than many things adequately. We believe that a native Mac app with deep system integration provides more value than a cross platform app with shallow integration, even if the cross platform app runs on more devices.

This philosophy extends beyond just the technical implementation. By focusing on Mac users, we can design specifically for how Mac users work. We can integrate with the apps they actually use. We can respect the conventions and expectations of the Mac ecosystem. We are not trying to find the lowest common denominator across three different platforms.

What About Windows and Linux Users

We regularly hear from people who want Air on Windows or Linux. We understand the demand and we are not ruling out other platforms forever. But if we do expand to Windows, it will be with a Windows-native application built from the ground up. We will not simply port the Mac app or wrap it in a cross platform layer.

Building a truly native Windows experience would require significant investment. Windows has its own automation frameworks, its own audio processing pipeline, its own design conventions. To deliver the same quality experience on Windows that we deliver on Mac, we would need to build a second product, not just adapt the first one.

For now, our focus remains on making Air the best possible voice assistant for Mac users. We would rather serve one platform exceptionally than serve three platforms poorly.