AOT TypeScript via SWC + LLVM — native builds with no external JavaScript engine

Compile TypeScript to Native.
One Codebase, Many Targets.

Perry compiles TypeScript to native GUI and CLI apps for macOS, iOS, iPadOS, visionOS, tvOS, watchOS, Android, Wear OS, Windows, Linux, and Web/WebAssembly, with a separate HarmonyOS preview. Native binaries statically link the Perry runtime and GC; they do not require Node.js or an external JavaScript engine.

Get StartedView on GitHub
terminal

$ perry compile main.ts

Compiling main.ts...

✓ Example executable written: main (size varies by linked features)

$ ./main

Hello, World!

11 + preview
Documented targets + preview
35+
Native UI widgets
~3.2 ms
Measured runtime-only macOS hello
Store workflows
perry publish
Shipping in production

Real apps, compiled from TypeScript with Perry.

View all showcase projects
Mango

Native MongoDB GUI. ~7 MB binary, <1s cold start.

Hone

Native code editor with built-in terminal, Git, LSP, sync.

dB Meter

Real-time decibel meter with 60 fps live waveform.

{ }
Pry

Fast native JSON viewer — tree, search, keyboard shortcuts.

Why Perry?

The current compiler, runtime, UI, and tooling surfaces — with limitations called out

No External JS Engine

Native builds run without Node.js, Bun, Deno, or an external JavaScript engine installed. The Perry runtime and garbage collector are statically linked into each target-specific binary.

Fast Compilation

Direct TypeScript to native code compilation using SWC for parsing and LLVM for optimized code generation. No intermediate JavaScript.

Size Scales With Features

Hello world can be about 330 KB and Mango is published at about 7 MB. Applications that link the full standard library or optional V8 fallback can be much larger; size depends on target, imports, and build profile.

Cacheable Builds

Perry caches module objects and can pin a CPU baseline for portable output. Default host builds tune for the local CPU, and final binaries may contain platform UUIDs, timestamps, or signatures, so byte-for-byte cross-machine reproducibility is not promised.

Tracked Node.js APIs

Native implementations cover many familiar Node.js APIs across 53 tracked modules. Coverage is broad but not complete; use perry check and the published limitations for your project.

Real npm Packages

Many pure TypeScript and JavaScript packages compile natively. Packages that depend on unsupported dynamic or engine-specific semantics may need the optional embedded V8 fallback or may not work.

35+ Native UI Widgets

35+ native UI widgets map to platform toolkits including AppKit, UIKit, GTK4, Win32, Android SDK APIs, SwiftUI on watches, and a DOM/CSS bridge on Web/WASM. Availability varies by target.

Compile-Time Plugin System

Modules can compose at build time and statically linked dependencies can become direct native calls. Dynamic dispatch and runtime support remain where JavaScript semantics require them.

True Multi-Threading

Real OS threads with parallelMap, parallelFilter, and spawn. Mutable captures are rejected by default; SharedArrayBuffer and Atomics provide explicit shared-memory coordination, with documented typed-view caveats.

Compile-Time i18n

Automatic string extraction, CLDR plural rules for 30+ locales, and compile-time validation. Translations are baked into the binary; lookup cost depends on the generated catalog and call site.

Go deeper: how Perry compiles TypeScript to a binary, what makes it a TypeScript native compiler, and how it stacks up against Electron alternatives.

Native across documented targets

Eleven documented targets share Perry’s compiler and UI model. Web and WASM are aliases; visionOS, watchOS, and Wear OS have narrower core support, and HarmonyOS is a separate preview.

ma

macOS

AppKit

Broad support
iO

iOS

UIKit

Broad support
iP

iPadOS

UIKit

Broad support
vi

visionOS

UIKit (2D)

Core support
tv

tvOS

UIKit

Broad support
wa

watchOS

SwiftUI

Core support
An

Android

Android SDK

Broad support
We

Wear OS

Android SDK

Core support
Wi

Windows

Win32

Broad support
Li

Linux

GTK4

Broad support
We

Web / WASM

DOM/CSS bridge

Broad support

--target web and --target wasm are aliases

Ha

HarmonyOS

ArkUI

Preview

Separate preview; not included in the 11 documented targets

11 documented targets; HarmonyOS is listed separately as a preview. See the platform status guide

From Code to App Store

The perry publish command supports build, signing, packaging, verification, and submission workflows. Availability and prerequisites vary by platform and hosted-service configuration.

perry compileCompile & sign
perry publishPackage & submit
Stores & DownloadsApp Store, Play Store, direct
perry verifyVerify supported targets

Build & Sign

Create platform artifacts and use configured signing credentials. Apple, Android, and Windows workflows require their platform SDKs, accounts, and certificates.

Distribute

Prepare store submissions or direct-download artifacts for supported targets. Store acceptance and processing remain controlled by each store.

Verify

Run available launch and UI checks through Perry and Geisterhand. Test depth and target coverage depend on the selected environment.

Local compilation is free and MIT licensed. Check hosted-service availability → /publish

Framework Comparison

Perry’s native compilation model

Ahead-of-time machine code and real platform widgets, with an explicitly linked runtime and documented compatibility tradeoffs.

Designed for

  • ✓Ahead-of-time machine code through LLVM
  • ✓Real platform widgets where each target supports them
  • ✓No external Node.js installation or JavaScript engine by default

Tradeoffs to evaluate

  • –The Perry runtime and GC are statically linked; overhead is not “none”
  • –Perry implements a practical TypeScript and Node.js subset; some packages need the optional V8 fallback
  • –Platform capabilities and maturity differ across desktop, mobile, wearable, TV, and Web/WASM targets

Competitor-specific pages are dated and link to upstream documentation. View sourced comparisons

Write TypeScript, Ship Native

Use familiar TypeScript syntax and validate each API or package against Perry’s current compatibility surface.

hello.ts
// hello.ts
const greeting = "Hello, World!";
console.log(greeting);
 
// Output size varies with target and linked features
// No external JavaScript runtime installation needed!
$ perry compile hello.ts
Native binary

Published measurements

Current public results include wins, mixed results, and losses. Treat microbenchmarks as workload-specific measurements, not a universal speed claim.

MetricPerryNode.jsBun
Binary Size~330 KB hello world; ~7 MB MangoApplication plus an installed Node.js runtimeStandalone executable embeds the Bun runtime
Startup Time~3.2 ms*Engine boot and warmup; workload-dependentEngine boot and warmup; workload-dependent
Runtime DependenciesStatically linked Perry runtime + GCExternal Node.js runtimeEmbedded Bun / JavaScriptCore runtime
Memory OverheadWorkload-dependentWorkload-dependentWorkload-dependent

* Measured runtime-only macOS hello world on an Apple M-series host (5.0 → 3.2 ms after removing unused dynamic-library links). Application startup varies.

Full public suite: wins and losses

Perry 0.5.1355 · Node.js 22.23.1 · Bun 1.3.14 · Apple M1, 8 GB · 2026-08-08

Lower wall-clock median is better. Five complete process samples; correctness checks passed. Benchmark names and descriptions remain English technical identifiers.

BenchmarkPerryNode.jsBunResult
factorial
Modular accumulation
94 ms95 ms95 msWin vs both
method calls
Class method dispatch
9 ms10 ms8 msMixed
closure
Closure creation and invocation
47 ms49 ms49 msWin vs both
binary trees
Tree allocation and traversal
4 ms6 ms6 msWin vs both
string concat
String append loop
2 ms4 ms1 msMixed
prime sieve
Sieve of Eratosthenes
28 ms6 ms5 msLoss vs both
mandelbrot
Complex-number iteration
22 ms24 ms28 msWin vs both
matrix multiply
Matrix multiplication
85 ms33 ms33 msLoss vs both
JSON roundtrip
Parse and stringify ~1 MB JSON
184 ms380 ms220 msWin vs both
Raw benchmark artifactMethodology and caveats

Get Started

Install Perry and start compiling TypeScript to native executables

1Installation

terminal
$ npm install -g @perryts/perry

Recommended cross-platform install. Native targets still require the relevant platform SDK and linker; run perry doctor after installation.

2Usage

Verify the toolchain
perry doctor

Checks the compiler, linker, SDK, and target setup

Compile a file
perry compile main.ts

Compiles main.ts to a native executable

Custom output
perry compile main.ts -o myapp

Specify the output executable name

With V8 runtime
perry compile main.ts --enable-js-runtime

Enable V8 for JavaScript npm package compatibility

Check compatibility
perry check ./src

Validate TypeScript code for native compilation

Feature Support

Tested surfaces and known partial areas — not a blanket claim of complete TypeScript or Node.js compatibility

Core Language

  • ✓Numbers (f64 + selected unboxed representations)
  • ✓Strings (UTF-8)
  • ✓Booleans
  • ✓Arrays
  • ✓Objects
  • ✓BigInt (fixed 1024-bit)
  • –Proxy
  • –eval / runtime-generated code

Functions

  • ✓Function declarations
  • ✓Arrow functions
  • ✓Default parameters
  • ✓Rest parameters
  • ✓Closures
  • ✓Higher-order functions
  • ✓Async / await
  • –Runtime-computed dynamic import

Classes

  • ✓Classes and constructors
  • ✓Private fields (#)
  • ✓Static methods / fields
  • ✓Getters / setters
  • ✓Inheritance and super
  • –Decorators and reflection
  • –Dynamic prototype manipulation
  • –Weak references / finalizers

Type System

  • ✓Type annotations
  • ✓Local type inference
  • ✓Generics / specialization
  • ✓Interfaces
  • ✓Union types and guards
  • –Runtime type validation

Standard Library

  • –fs / path / os
  • –crypto
  • –Buffer and streams
  • –http / http2 / net / tls
  • –child_process / worker_threads
  • –WebAssembly global
  • –~97% Node suite · 53 modules
✓Tested in the current implementation–Partial

“Partial” means the API or syntax exists with documented gaps. Exact behavior changes as parity work lands. Read the current limitations

~50 Native Packages and Node APIs

Many popular packages and Node APIs have native implementations. Coverage is package- and feature-specific; perry check and the compatibility documentation are the source of truth.

Database

mysql2pgmongodbbetter-sqlite3ioredis

Security

bcryptargon2jsonwebtokencrypto

HTTP

httphttpsaxiosnode-fetchwsnodemailer

Data Processing

cheeriosharpzliblodash

Date & Time

dayjsmomentdate-fnsnode-cron

Utilities

uuidnanoidslugifyvalidatordotenvrate-limiter-flexible
Import the package normally. Perry selects a native implementation when one is available, otherwise compilation may use another supported path or report a limitation.

How It Works

From TypeScript source through SWC, Perry HIR, LLVM, and the linked runtime

TypeScript.ts files
SWC
ParserFast parsing
HIR
TransformMonomorphization
LLVM
CodegenMachine code
ExecutableFrom ~330 KB; varies by features

Want to know how the compiler works under the hood? Compiler internals

Deep dive: TypeScript on LLVM — monomorphization, NaN-boxing, and why Perry left Cranelift.

Perry-adjacent project · Pre-1.0

A place for Perry code to rest and run.

Coop turns a directory of Perry-compatible TypeScript into a native application library and serves it over HTTP, while the Perry runtime and standard library are supplied once per machine.

  • ✓Shared runtime providers
  • ✓One worker per deployment
  • ✓Deploy, inspect, and roll back
Explore CoopView source