Tinycast added 1,076 GitHub stars in the September 16 snapshot behind this story. The interesting part is what those stars are rewarding: a native macOS launcher that can ingest Raycast extension bundles and render them in SwiftUI. Tinycast's last recorded compatibility run found that 114 of 147 view commands across 37 installed extensions booted and rendered, although the project's own extension documentation says that measurement predates its OAuth work and needs to be run again.
The bridge makes switching launchers a less binary decision. Tinycast does not ask a Raycast user to discard every third-party command and rebuild a workflow from scratch. It copies already-built extensions from a local Raycast installation, can search extension registries, and accepts a folder produced by ray build. That migration path is the most consequential feature in a project that also includes clipboard history, file search, window controls, notes and optional AI chat.
The compatibility layer is the product
Raycast extensions arrive as CommonJS bundles that expect React, the @raycast/api package and parts of Node. Tinycast supplies its own versions of those interfaces inside JavaScriptCore, the JavaScript engine already shipped with macOS. The extension's React tree becomes JSON, crosses a Swift bridge, and is drawn as native SwiftUI rather than as a browser surface. The implementation notes describe a roughly 200 KB generated runtime with React 19, a reconciler, API shims and selected Node polyfills.
That design has a practical consequence for an existing Raycast user. Tinycast can scan both the stable and beta Raycast directories, then copy package.json, compiled command files and assets. It leaves behind node_modules and source maps. Importing those built bundles needs no package manager, network request or local Node installation, according to the extension installation documentation. A registry install can still require a package manager when Tinycast has to build from source.
Settings move through a separate route. Tinycast reads the RAYCFG3 export format used by Raycast 2.x, asks the user for the passphrase and maps supported settings into its own stores. The import specification says older Raycast 1.x exports and the intervening Raycast X beta format are no longer accepted. Tinycast also refuses to fetch the export passphrase from the macOS Keychain, even when Raycast generated and stored it there. The user has to supply it.
Native code changes the cost profile
Tinycast is written mainly in Swift and uses SwiftUI with AppKit for its windows and system access. The repository advertises zero third-party app dependencies, no Electron and a target of less than 100 MB of RAM. That memory ceiling is a contribution rule rather than an informal goal: the contributor guide requires idle and peak measurements on pull requests, plus leak testing that returns memory to baseline after the palette closes.
The native shell does more than launch applications. It can query Spotlight for folders selected by the user, keep searchable clipboard text and images, run Apple Shortcuts, manage windows, execute named shell commands and store Markdown notes. The README also lists a calculator, snippets and quicklinks. This breadth creates an obvious risk of turning a small launcher into a resident bundle of background services, which is why the project's fixed memory budget is worth tracking release by release.
Extension support introduces the largest standing exception. When a command runs, Tinycast creates a private JavaScriptCore context on a serial queue. Starting another command tears down the previous context, and only one command can run at a time. The runtime design says the JavaScript engine remains in memory until the user leaves the command. Extensions are off by default, so a fresh installation pays none of that cost until the switch is enabled.
AI follows the same opt-in posture. Chat is disabled on first launch, its history database is not created while disabled, and provider credentials are stored in the login Keychain. Tinycast can use Apple Intelligence on device, an installed Codex, Claude or OpenCode command, or a user-configured API connection. The AI provider documentation says installed command routes reuse their existing login and do not expose their credential files to Tinycast.
Privacy rests on switches you can inspect
A launcher sits close to sensitive material, especially once it watches the clipboard and receives Accessibility permission. Tinycast says it has no telemetry and is offline by default. Its security policy treats any network access without consent, or access that continues after consent is withdrawn, as a high-severity issue. That is a testable security boundary in the public code, rather than a broad privacy label with no stated failure condition.
Clipboard history is the exception to the default-off pattern. It ships enabled, stores records in SQLite under Application Support and closes the database when switched off. The clipboard design document says files are referenced at their original paths rather than copied, while captured images use storage owned by the app. Accessibility permission is requested when Tinycast needs to paste or expand text into another application. Anyone handling passwords or customer data should decide whether persistent clipboard history belongs on that Mac before treating local storage as sufficient protection.
Raycast extensions carry a different trust boundary because they are third-party code. Enabling them prompts for consent; disabling them stops the active command, destroys its JavaScript context and clears installed extension rows from the launcher. Tinycast's extension invariants say the enabled state is excluded from settings backups, preventing an imported configuration from turning code execution on. That safeguard does not review an extension's behavior. Users still need to decide which bundles they will run.
Compatibility still has hard edges
The 114-of-147 result is promising, but it is a project measurement from one real Raycast setup rather than a universal compatibility score. Tinycast lists several missing surfaces: menu-bar commands cannot open, WebSocket has no polyfill, and streaming HTTP bodies arrive as one completed chunk. Raycast services for AI, browser extensions and window management have no local equivalent. The unsupported-features table also says extensions that depend on Raycast's OAuth proxy will fail when the provider does not support PKCE directly.
Those gaps explain why the migration bridge is more interesting than a claim of drop-in replacement. A command built around lists, forms, local storage, clipboard access or ordinary HTTP requests has a plausible route. A command that needs sockets, Raycast's hosted services or deep streaming behavior may stop at the shim. Tinycast's extension notes expose those seams down to process behavior and API calls, making it possible for an extension author to identify the missing layer instead of treating every failure as an opaque launcher bug.
Setup asks for visible trust
The current stable release is 0.10.23, published on September 13, while 0.11.1-beta.96 followed on September 15. Stable and beta require macOS 26 or later; the macOS 15 build is listed as no longer maintained. More importantly, Tinycast is self-signed. Its release page says a direct DMG will be blocked by macOS quarantine until the user clears the flag, while the recommended Homebrew route asks the user to trust the project's tap.
The stable install is short, but both lines in the project's release instructions deserve to be read before they are pasted into a terminal:
brew trust --tap abue-ammar/tinycast
brew install --cask abue-ammar/tinycast/tinycast
Homebrew clears quarantine during that route. A direct download instead requires xattr -dr com.apple.quarantine "/Applications/Tinycast.app". Our review of Tinycast covers the setup reality for readers deciding whether that extra trust step fits their machine. The project's security scope calls self-signing a known condition and supports only the current stable and beta channels for vulnerability reports.
A narrow contribution gate protects the premise
Tinycast's public code is under AGPL-3.0, but contribution is deliberately controlled. A code pull request needs a linked issue marked approved; an automation closes the pull request if that approval is missing. Visual changes require a side-by-side before-and-after video, and contributors must report memory numbers. The contribution rules also warn that a clean patch can be declined when a feature is judged too costly for the app's size target.
That gate will be tested by the attention now arriving at the repository. More users bring extension requests, missing APIs and pressure to widen the feature set. The next useful evidence is concrete: a fresh compatibility run after the OAuth additions, a stable release containing the current beta work, and a distribution path that reduces the self-signing burden. Watch whether Tinycast can improve those three areas while keeping extension execution opt-in and memory below its stated ceiling. That will tell us more than the next thousand stars. The release history provides the public record for that test.