macai: a native macOS chat client whose fork path depends on one Info.plist key

A fork that skips one build setting uses the default CloudKit container

iCloud sync is the feature that separates the two build paths, and the configuration is a single key in the property list. The instructions for a fork or custom build run to five steps: create a CloudKit container in your own Apple Developer account, enable the iCloud capability for the target and add that container, update the `CloudKitContainerIdentifier` value in `macai/Info.plist` to your own container ID, make sure the app's bundle identifier matches the one registered for that container, and remove the compile flag described below.

The last line of that section is the one to notice: if `CloudKitContainerIdentifier` is missing, the app falls back to the default container.

A default container is a container that belongs to whoever registered it, not to the person running the build. So the failure mode of skipping step three is not a disabled feature, it is a build pointed at somebody else's CloudKit namespace with your own chats inside it. The page states the fallback without warning, which makes it the single most important sentence for anyone shipping their own build of this app.

For the record, the same section notes that the app works normally without iCloud entitlements, with chat, API services and personas all functioning, and only sync unavailable.

Debug builds have iCloud switched off by one compiler condition

Contributors without an Apple Developer account are the reason for a flag called `DISABLE_ICLOUD`, and it lives in the Swift compiler's active compilation conditions. The stated purpose is to simplify development setup and avoid CloudKit signing problems.

Enabling sync in a debug build is described as a three-step edit: open the target's Build Settings, find `SWIFT_ACTIVE_COMPILATION_CONDITIONS` or Active Compilation Conditions, and remove `DISABLE_ICLOUD` from the value so only `DEBUG` remains. After that, entitlements and signing still have to be configured.

Release builds do not carry the flag, so sync is on by default there. That asymmetry is the source of a common confusion: a feature absent in a developer's build is not a bug, it is the default.

Two entitlements files ship for this purpose, `macai/macai.entitlements` for the full build and `macai/macai-no-icloud.entitlements` for a build without the capability, and choosing between them is a one-field change in the project settings.

The unsigned build is four build settings and one target

Building without a developer account is documented twice, once through the Xcode interface and once on the command line. The command line version is the useful one, because it is copyable and it shows exactly which four settings differ:

xcodebuild -scheme macai \
  -configuration Debug \
  CODE_SIGN_IDENTITY="-" \
  CODE_SIGN_ENTITLEMENTS="macai/macai-no-icloud.entitlements" \
  DEVELOPMENT_TEAM="" \
  CODE_SIGNING_ALLOWED=NO \
  build

The identity becomes a dash, the team is empty, signing is disabled outright, and the entitlements file switches to the one without the iCloud capability. `CODE_SIGNING_ALLOWED=NO` alongside a signing identity is belt and braces, and harmless.

The interface route asks for the same entitlements value plus a signing certificate set to Sign to Run Locally. Both routes require the project file to be present, and it is: `macai.xcodeproj/` is committed at the root of the repository rather than generated.

One consequence of `CODE_SIGNING_ALLOWED=NO` is worth stating plainly. A build produced this way will not run on another machine without further signing, so it is a development build and not a distribution artefact.

No telemetry, with one exception written in the parentheses

The feature list describes macai as private and secure, with no telemetry or usage tracking by macai, and then qualifies it in the same bullet: Apple may collect anonymized telemetry when iCloud Sync is enabled.

That exception is correctly placed. It names the party that collects, which is Apple, and the condition under which it applies, which is the sync feature, and it separates that from the app's own behaviour. A reader who only reads the bold part would come away with the wrong impression, so it is worth knowing that the caveat is in the same sentence.

The same section describes the app as macOS-native and lightweight, user-friendly with a simple setup and a minimalist light and dark interface, and feature-rich with vision, image generation, search, reasoning, and import and export. iCloud sync is listed separately, keeping chats, messages and settings aligned across devices.

Contributions are invited through the issues page, with the advice to check it before filing. Alongside that is a funding request tied to a single maintainer, with the stated reason that the support allows more focus on the project. The licence is Apache-2.0 in a separate licence file.

Eight provider families, one settings tab, and an Expert mode

The provider list is the product. macai is described as supporting ChatGPT, Claude, xAI Grok, Google Gemini, Perplexity, Ollama, OpenRouter, and almost any OpenAI-compatible API, and each commercial one gets a documentation link for finding its token, with a note that most services offer free credits on a new account.

The local path is spelled out as six steps. Install Ollama, follow its guides, choose a model with llama3.1 or llama3.2 recommended, pull it from a terminal with `ollama pull <model>`, then in macai's settings open the API Service tab, add a new API service in Expert mode, and select the Ollama type. Then select a model, set a default AI Assistant, and save.

Expert mode is the part that matters for anyone configuring this by hand, since it is the only place the provider type is chosen. The instructions for it contain a stray quotation mark, in a phrase that reads as selecting the type Ollama with a closing quote and no opening one, which is a small sign of how little editing this list has had.

A local model on Apple silicon is the case the project points newcomers at when they do not want to pay for tokens, with dozens of open models named as available.

A notarized universal binary, a cask, and macOS 14 as the floor

Two install paths, both one line each. The manual route is the latest universal binary from the releases page, notarized by Apple. The package manager route is a cask, `brew install --cask macai`.

The system requirement is macOS 14.0 or later, with both Intel and Apple silicon named as supported, which is what the universal binary is for. Nothing else is required: no runtime to install, no companion daemon, and no dependency manifest in the repository.

That last point is corroborated by the root of the tree, which holds the Xcode project, the application directory, a unit test directory and a UI test directory, plus a formatting configuration, an icon asset stored as a single Icon Composer file, a credits file and the licence. There is no package manifest for Swift Package Manager and no vendored dependency directory, so the app is built against system frameworks only.

Two test targets in a project of this size is the more surprising entry. Unit tests and UI tests both exist, and the workflow badge in the header points at a workflow file named for Swift and Xcode.

Two releases two days apart, then seven months of silence

The release history is short and uneven. v2.4.0 was published on 2026-01-14 and v2.4.2 on 2026-01-16, two days later, with no v2.4.1 among the recent tags. Then v2.4.3 on 2026-08-16, seven months after that.

The last push to the default branch is 2026-08-16 at 19:53 UTC and v2.4.3 was published at 20:03 the same evening, ten minutes later. So the newest tag is essentially the current state of the branch rather than a snapshot some weeks behind it, which is the friendlier arrangement.

The page states its own status in one line: the project is in the active development phase. Nothing on the page dates that claim, and the seven-month gap before the latest release is the only signal available about its pace.

For anyone tracking this project, the practical consequence is to check the version in the app against the tag before filing anything, since the January releases are old enough that a report about current behaviour may describe a build that no longer exists. The issues count is 44 on 76 forks, which for a project of this size is a fairly active queue rather than a neglected one.

Editorial conclusion

macai suits someone who wants a small native window over several providers instead of a web tab per vendor, and the install options are the easiest part: a notarized universal binary or a Homebrew cask. Two things to check before building it yourself. Debug builds have iCloud sync disabled by a compiler flag, and turning it on for a fork means creating your own CloudKit container and setting its identifier, because the documented fallback when that key is absent is the default container rather than no container. Second, the release line moved twice in two days in January and then not at all for seven months, so check the version you are running against the tag you mean. The project also describes itself as in active development and asks for funding from a single maintainer, which is worth weighing against how quickly the default branch is moving.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. Renset/macai on GitHub