---
title: "Swoole's AOT compiler is now TypePHP: PHP-syntax code that compiles to native binaries, beta by October 1"
description: "On June 18, 2026, the Swoole team publicly renamed their ahead-of-time PHP compiler to TypePHP, a separate strongly-typed compiled language with full PHP syntax compatibility, a dual static-compile / ZendVM-runtime engine, native Decimal / BigInt / BigFloat types, four strongly-typed C++-backed containers, uniform function call syntax, and direct C++ ABI calls into C, C++, Rust and Go static libraries. A beta is promised by China's National Day (October 1, 2026), with full source-code release to follow. We unpack the dual-engine design, the C++ ABI integration, the self-hosted compiler, what changes against KPHP, HHVM, PeachPie and FrankenPHP, and the open question Roman Pronskiy raised about where the language stops being PHP."
date: 2026-06-18
image: "/images/heroes/2026-06-18--typephp-swoole-aot-native-binary-php.png"
author: lschvn
tags: ["runtimes", "tooling"]
tldr:
  - "The Swoole team's ahead-of-time PHP compiler has been renamed to TypePHP and is being shipped as a separate strongly-typed compiled language, not a faster PHP. Beta is promised before China's National Day on October 1, 2026, with full source-code release to follow on GitHub at swoole/aot-compiler. The Swoole WeChat official account published the announcement on June 18, 2026, and Roman Pronskiy, head of PhpStorm at JetBrains, flagged the rename in an X article the same week."
  - "TypePHP's headline design is dual-engine: the main program is compiled to native machine code, but the ZendVM runtime is preserved inside the binary, so the compiled executable can load plain `.php` scripts through `require`/`include` at runtime. That keeps the entire PHP extension surface (curl, mysqli, PDO, Swoole, and self-written C/C++ extensions) and Composer autoloading working without modification. Performance is reported as tens to hundreds of times faster than interpreted PHP, and the output binary cannot be decompiled back to PHP source."
  - "Three new language features ship beyond PHP: native BigInt, BigFloat and Decimal for exact-precision scientific and financial math (so `0.1 + 0.2` is exactly `0.3`); four strongly-typed containers (`std::array`, `std::vector`, `std::map`, `std::unordered_map`) that replace the universal `array`; and uniform function call syntax, which lets you call any function as a method on any value, including built-in integers and strings, and add extension methods to existing types. The compiler itself is being bootstrapped in TypePHP the way the Go compiler is written in Go."
faq:
  - question: "What is TypePHP?"
    answer: "TypePHP is the new name for the Swoole team's ahead-of-time PHP compiler. It is being shipped as a separate strongly-typed compiled language whose syntax stays compatible with PHP, but whose runtime is native machine code plus an embedded ZendVM. The Swoole team announced the rename on the Swoole WeChat official account on June 18, 2026, and the GitHub repository is at swoole/aot-compiler. A beta binary is promised by China's National Day (October 1, 2026), and full source-code release is planned for after that date. The previous product name, Swoole AOT, is being retired."
  - question: "How is TypePHP different from a faster PHP?"
    answer: "TypePHP is not positioned as a faster PHP. It is a separate compiled language that uses PHP syntax and ships the ZendVM as a runtime component, not as the primary execution model. The main program is compiled to native machine code, and the compiled binary can additionally load plain `.php` scripts at runtime through `require` and `include`, which keeps the PHP extension surface, Composer autoloading, and existing C/C++ extensions working. Pronskiy frames it bluntly in his X article: the further TypePHP goes, the less it is PHP, which is the same trajectory Facebook took from HipHop to Hack to HHVM."
  - question: "Will my existing PHP code run on TypePHP?"
    answer: "Yes, in the sense that TypePHP preserves full PHP syntax compatibility and ships ZendVM as a fallback runtime. The compiled executable can `require` or `include` ordinary `.php` files at runtime and interpret them through the embedded Zend, so the same Composer autoloading, extension stack, and C/C++ extension code that runs on PHP 8.x should run inside a TypePHP binary without modification. The Swoole team's claim is 100% PHP ecosystem compatibility, including third-party Composer packages and self-written C/C++ extensions. The catch is that language-level features that are not in PHP (BigInt, typed containers, UFCS) only work in code that targets the TypePHP compiler."
  - question: "How is TypePHP different from KPHP, HHVM, PeachPie or FrankenPHP?"
    answer: "KPHP (VK, GPL-3.0, 1,500+ stars) is the closest prior art: it compiles a PHP dialect to C++ and ships native binaries, but it does not embed the Zend runtime, so unmodified `.php` files cannot be loaded at runtime. HHVM (Meta) started as a faster PHP and drifted into Hack, a separate language, which is the cautionary tale Pronskiy cites. PeachPie compiles PHP to .NET, with a different runtime model. FrankenPHP (11,000+ stars, MIT) is a modern PHP app server written in Go that can ship a standalone binary, but it embeds the PHP interpreter, not a compiled artifact. TypePHP's differentiator is the dual engine: statically compiled machine code plus an embedded Zend that can interpret unmodified PHP on the fly, with C++ ABI access as a first-class feature."
  - question: "Can I call C, C++, Rust or Go code from TypePHP?"
    answer: "Yes. TypePHP is built directly on the C++ ABI, and a TypePHP program can call into `.a`/`.lib` static libraries and `.so`/`.dll` dynamic libraries produced by C, C++, Rust and Go without writing a PHP extension. The reference examples in the swoole/aot-compiler repository ship a JNI bridge that calls Java through `jni.h` and `libjvm.so` (Java 25), a Tetris game whose graphics layer is implemented in C++ against SDL, and a Windows GUI hello world. The mechanism is a stub-file pattern: a C++ class inherits from `Box`, a PHP-side stub declares the C++ functions, and the compiler wires the call at compile time."
  - question: "What are the three new language features in TypePHP?"
    answer: "First, native BigInt, BigFloat and Decimal types for exact-precision arithmetic. With `use decimal_types;`, `0.1 + 0.2` prints `0.3` rather than the IEEE-754 `0.30000000000000004` you get in PHP. With `use bigint_types;`, `2 ** 80` prints `1208925819614629174706176` rather than overflowing to a float. Second, four strongly-typed containers: `std::array(type, size)`, `std::vector(type, [size])`, `std::map(ktype, vtype)`, and `std::unordered_map(ktype, vtype)`, which replace PHP's universal `array` with C++-backed typed structures. Third, uniform function call syntax, which lets any value receive a method call against any function (`$a = 2; $a->pow(80)->toString()->length();`) and lets user code register extension methods on built-in types."
  - question: "Is TypePHP actually open source yet?"
    answer: "Not yet. As of June 18, 2026, the swoole/aot-compiler repository on GitHub contains a README and example projects, and the releases page hosts closed-source test binaries for Windows x86_64, Linux x86_64 and macOS arm64, currently at v0.2.3. The Swoole team has committed to uploading the compiler source code after the October 1, 2026 beta. Pronskiy's X article flags the open question: the existing Swoole Compiler 3.2 is a commercial product sold through business.swoole.com, and an MIT-style open-source release for the AOT line has not been confirmed."
  - question: "What does 'self-hosted compiler' mean for TypePHP?"
    answer: "It means the TypePHP compiler is being written in TypePHP itself, in the same tradition as the Go compiler being written in Go. The first alpha TypePHP compiler was compiled using Zend PHP, then used to compile itself, and the Swoole team reports that in the current v0.2.3, the self-hosted-compiled binary and the Zend-PHP-compiled binary both pass the full unit test suite. Self-hosting is not just a stylistic point: it is a stress test on the new language features, because the compiler exercises the typed containers, BigInt arithmetic, UFCS, and C++ ABI calls in production code rather than in toy examples."
---

On the morning of June 18, 2026 (Beijing time), the Swoole team's official WeChat account published a one-screen announcement: the Swoole AOT compiler project has been formally renamed to **TypePHP**, a beta binary is promised before China's National Day on October 1, 2026, and the full source code will be uploaded to GitHub after that. The same week, Roman Pronskiy, head of PhpStorm at JetBrains and board member of the PHP Foundation, published an X article titled *"Swoole AOT is officially becoming TypePHP"*, observing that the team is now stating outright what they had only hinted at previously: this is a separate, strongly-typed compiled language, not a faster PHP interpreter. Both sources agree on the headline numbers. The interesting questions are all in the mechanism, and there is more mechanism than the WeChat post or the X article can fit.

The two source documents read together give a clearer picture than either one alone. The WeChat post is the official announcement and carries the technical claims in the team's own framing. Pronskiy's article is the read from outside, written by the person who runs the IDE most PHP developers use, and includes the framing correction that the rest of the industry is going to hear first: TypePHP is on the same trajectory Facebook took from HipHop to Hack to HHVM, and the question worth asking in October is not whether the binary runs faster than PHP, but whether the language is still PHP at all.

Before going deeper, the framing correction worth stating up front: TypePHP is not a new JIT for the Zend engine, and it is not a successor to the Swoole runtime. Swoole proper is the async, coroutine-based PHP extension that has been the de-facto high-performance runtime for PHP in China for the last decade, and it lives at swoole/swoole-src (18,890 stars, last pushed June 8, 2026). TypePHP comes from a different product line inside the same company, the Swoole Compiler, which has been sold commercially since the 3.x line as a PHP opcode encryption and obfuscation tool. Version 4.0 of that compiler is the one being renamed. The compiler is built on `swoole/phpx`, the team's C++ wrapper for the Zend engine API (856 stars, Apache-2.0, last pushed June 17, 2026), which is the same library that has powered the company's C++/PHP extension work for years. The rename is not a runtime story; it is a compiler story that happens to ship a runtime as a compatibility layer.

## The dual-engine design

The most consequential architectural decision in TypePHP is that the ZendVM is not removed. It is shipped inside the compiled binary as a fallback runtime. The WeChat announcement states this directly: the main program is statically compiled to native machine instructions, but the executable can still call `require` and `include` to load ordinary `.php` scripts at runtime, and those scripts are interpreted through the embedded Zend. The Swoole team calls this "dual-engine", and the immediate consequence is full PHP ecosystem compatibility. Composer autoloading works, the curl, mysqli and PDO extensions work, the Swoole extension works, and any self-written C/C++ extension that runs against PHP 8.x runs inside the TypePHP binary without recompilation.

This is the design choice that distinguishes TypePHP from every prior PHP-to-native compiler. KPHP, the VK project that is the closest analog, compiles a PHP dialect to C++ and produces native binaries, but it does not embed the Zend runtime, so unmodified `.php` files cannot be loaded at runtime and the extension surface is a curated subset. TypePHP keeps the full extension surface because it does not try to remove Zend. The compiled binary just uses native code for the hot path and falls back to interpretation when it sees a file it did not compile. The Swoole team has been working on this dual-engine architecture for years under the AOT branding, and the rename to TypePHP is in part an acknowledgment that this is now the project's defining property, not a transitional implementation detail.

The performance claim, tens to hundreds of times faster than PHP, refers to the compiled part of the program. Because the compiled output is native machine instructions with no interpreter in the loop, the type-specialized, inlinable, branch-predicted path of a tight loop will be as fast as the equivalent C++ code. The interpreted part, when the program chooses to load a `.php` script at runtime, runs at standard PHP speed, but the Swoole team argues that the bulk of the work in a typical application can be compiled ahead of time, with the dynamic parts reserved for the small surface area that genuinely needs to be dynamic (plugin loading, configuration scripts, third-party Composer packages that have not been recompiled). For a fully recompiled application, the dual engine is invisible. For a partially compiled application that still loads dynamic plugins, the engine is a safety net, not a regression.

There is a related claim worth taking seriously on its own terms: the compiled binary cannot be decompiled back to PHP source code. The WeChat post states this explicitly as a feature, framed around commercial software deployment. PHP's source visibility has always been a friction point for vendors who want to distribute closed-source applications, and the existing Swoole Compiler 3.2 sells opcode encryption and control-flow obfuscation precisely to address that gap. TypePHP does not encrypt opcodes; it produces machine code, which is intrinsically harder to reverse than bytecode. The commercial-IP framing of the project is not a side note; it is one of the two or three reasons the Swoole team has invested years in the compiler line.

## The three new language features

TypePHP is described as PHP-syntax compatible, but the language is not a strict subset of PHP. The Swoole team has added three feature areas that do not exist in PHP 8.x, and each of them is a real ergonomic or performance change for code written against TypePHP, not a marketing line.

The first feature is native exact-precision arithmetic. PHP floats are IEEE-754 doubles, and the canonical example of the precision loss is `0.1 + 0.2` evaluating to `0.30000000000000004`. In TypePHP, importing `decimal_types` makes the default float literal a `Decimal` rather than a `float`, and `0.1 + 0.2` prints `0.3` exactly. Importing `bigint_types` does the analogous thing for integer literals, so `2 ** 80` evaluates to `1208925819614629174706176` rather than overflowing into a float as it would in PHP. The BigFloat type is the third member of the same family. The WeChat post presents these as the answer to scientific and financial computing use cases where floating-point error is unacceptable; the practical implementation appears to be a configurable literal-level switch rather than a wholesale replacement of the float type, which keeps the door open for code that genuinely needs the IEEE-754 path.

```php
use decimal_types;

function main() {
    $v1 = 0.1;
    $v2 = 0.2;
    // TypePHP: 0.3. PHP: 0.30000000000000004.
    echo $v1 + $v2;
}
```

The second feature is four strongly-typed containers. PHP's `array` is universal: it is both a list and a map, keys and values are untyped, and the same structure has to serve every collection use case. TypePHP replaces this with `std::array(type, size)` for fixed-size arrays, `std::vector(type, [size])` for dynamic arrays, `std::map(ktype, vtype)` for ordered maps backed by a red-black tree, and `std::unordered_map(ktype, vtype)` for unordered hash maps. The names and the underlying implementations are direct calls into the C++ standard library, which is the same strategy Phlex and other systems-language projects have used to get deterministic performance and predictable memory layout. The C++ standard library containers are also the reason the Swoole team can ship a self-hosted compiler: the typed containers are not a custom data structure with a custom memory model, they are a thin layer over `std::vector` and friends, and the compiler is small enough to write in TypePHP itself.

```php
// Key: string. Value: stdClass.
$map = std::map(complex_types::type_string, stdClass::class);
$map["key"] = new stdClass;
$map["key"]->data = "hello";
```

The third feature is uniform function call syntax, abbreviated UFCS, plus extension methods. The WeChat example is the cleanest way to see the idea. With UFCS, any value can receive a method call against any function:

```php
$a = 2;
// 2^80, to string, then length of that string.
echo $a->pow(80)->toString()->length();

$b = "hello world!";
// Split, then check if the resulting list contains "world".
$b->split(' ')->contains("world");
```

In standard PHP, calling `pow(2, 80)` returns an int (or a float on overflow), `toString()` is not a method, and `length()` is not a method on a string. In TypePHP, the compiler resolves `$a->pow(80)` to `pow($a, 80)`, `$a->pow(80)->toString()` to `toString(pow($a, 80))`, and so on, chaining the calls. This is a feature that exists in D, Nim, and (with caveats) Rust, and the practical effect is that adding new methods to existing types does not require extending the standard library, because any user-defined function can be called as a method. The companion feature, extension methods, lets a user declare `function int_to_bytes(int $num): string` and then call `$value->toBytes()` on an integer, with the compiler dispatching to the extension method when the type matches. The WeChat post includes the worked example:

```php
function int_to_bytes(int $num): string {
    return ($num / 1024) . 'Kb';
}

$value = 92160;
// Compiler matches int_to_bytes, prints "90Kb".
echo $value->toBytes();

var_dump($value->toBytes()->equals('90Kb'));
```

The three features together are the language design that makes TypePHP feel less like a PHP dialect and more like a small strongly-typed language that happens to share PHP's surface syntax. That is also the question Pronskiy is raising, and it is the one that will dominate the discourse around the project in October.

## The C++ ABI as a first-class feature

The decision to build the compiler on the C++ ABI, rather than on a PHP extension model, is the second architectural choice that changes what kind of project TypePHP is. The WeChat post makes the point directly: a TypePHP program does not need to be wrapped in a C/C++ extension to call into native code. It can link against `.a` and `.lib` static libraries, and load `.so` and `.dll` dynamic libraries, produced by C, C++, Rust, and Go, with no glue code beyond a stub declaration. The compiler wires the call at compile time, and the resulting binary calls the native code through the standard C++ calling convention.

The reference examples in the `swoole/aot-compiler` repository demonstrate what that looks like in practice. The `examples/jni` directory contains a complete JNI bridge: the C++ side includes `<jni.h>` and `<phpx.h>`, links against `-ljvm`, and exposes a small set of `jni_init`, `jni_find_class`, `jni_new_object`, `jni_call`, `jni_get`, `jni_set` functions to the PHP side. The PHP side instantiates a Java `Hello` object, calls a `greet` method on it, reads and writes its `name` and `age` fields through the JNI reflection API, and prints the results. The `project.yml` for the example lists the JDK 25 include paths and the `-Wl,-rpath` flag that points at the JVM shared library. The example compiles and runs against an unmodified OpenJDK installation.

The `examples/tetris-sdl` directory goes further. The game logic (board state, piece rotation, line clearing, scoring, game-over detection) is implemented in TypePHP, and the SDL graphics calls are implemented in C++ against the `cpp-src/tetris.cc` source file. The C++ side defines a `TetrisBox` class that inherits from `Box` (the C++ base class in `phpx` for objects exposed to PHP), and the PHP side holds a `mixed $game` reference that points at a `TetrisBox` instance. The C++ layer manages the SDL window, the rendering loop, the keyboard event handling, and the UTF-8 rendering for the Chinese-language documentation. A `tetris.stub.php` file declares the C++ functions and types so the TypePHP compiler can resolve the calls. The `examples/win32-hello` directory does the equivalent for the Win32 API: a console hello world, a GUI hello world with a window class and a message loop, and a third variant that demonstrates the project's Windows configuration layer. The `examples/tetris-win32` directory is the Windows-native port of the SDL Tetris example.

The pattern is the same in all four cases. The C++ side implements the platform-specific or performance-critical code, the TypePHP side implements the application logic, and the stub file is the contract between the two. There is no PHP extension involved. The compile step is `php bin/compiler.php build examples/tetris-sdl` (or the equivalent against the `bin/compiler.php` shipped with the closed-source binary), and the output is a Windows `.exe` that can be double-clicked. This is the same architectural pattern that Flutter uses to expose platform APIs, and the same pattern that allows a Rust application to call a C library through `extern "C"`. The novelty is doing it from PHP-syntax source code, with the PHP-side calling convention resolved by the compiler, and with the Zend runtime shipped alongside the compiled code for fallback.

The phpx library that makes this work is worth knowing about on its own terms. `swoole/phpx` is a C++ wrapper for the Zend engine API that has been in the Swoole ecosystem since 2017 (it predates the AOT compiler by years), and it is what makes the C++ integration ergonomic. Without phpx, the C++ code that exposes a class to PHP would have to manage Zend reference counting, type coercion, and the call-stack dance manually, which is exactly the friction that has historically made PHP extension development a specialist activity. With phpx, the C++ code reads like normal C++ that happens to interact with PHP-style objects. The AOT compiler's `Box` class is a phpx primitive, and the JNI example's `using namespace php;` line is what makes the C++ side feel like a peer of the PHP side. The same library is what the existing Swoole extension is built on, and the AOT compiler is the natural extension of the team's investment in C++/PHP interop.

## How TypePHP compares to KPHP, HHVM, PeachPie, FrankenPHP and RoadRunner

The PHP ecosystem has had half a dozen serious attempts to make the language faster, and TypePHP is the most recent. Each of the prior projects made a different trade-off, and the trade-off TypePHP makes is the most ambitious and the most risky.

**KPHP** ([VKCOM/kphp](https://github.com/VKCOM/kphp), 1,515 stars, GPL-3.0, last pushed June 18, 2026) is the closest prior art. KPHP compiles a PHP dialect to C++, then runs the C++ through a system compiler to produce a native binary. The resulting program is dramatically faster than interpreted PHP, and the project has been production-grade at VK's scale for years. The trade-off KPHP makes is the same one every PHP-to-C++ compiler makes: it does not embed the Zend runtime, it does not support the full PHP extension surface, and the dialect is a strict subset of PHP with typing annotations. Code that runs on KPHP is a KPHP program, and code that does not is not portable. KPHP's GitHub is actively maintained, and the project remains the strongest evidence that a compiled PHP is technically viable at scale. TypePHP's differentiator against KPHP is the dual engine and the C++ ABI integration, both of which KPHP explicitly does not have.

**HHVM** ([facebook/hhvm](https://github.com/facebook/hhvm), 18,632 stars, NOASSERTION license, last pushed June 18, 2026) is the cautionary tale Pronskiy is invoking. HHVM started as the HipHop compiler, an internal Facebook project to make PHP faster, and ended as the runtime for Hack, a separate language that forked the PHP syntax in incompatible ways. The PHP community spent a decade arguing about whether Hack was still PHP, and the practical answer is that it is not. The type system, the standard library, and the language extensions are all separate. The HHVM project is still maintained, but its primary use case is now running existing Hack code at Meta, not running PHP code from the wider community. Pronskiy's point is that the trajectory from "fast PHP" to "separate language" is a well-trodden path, and TypePHP is on the early part of that path. The rename from "Swoole AOT" to "TypePHP" is, in his reading, the moment the project commits to the language fork.

**PeachPie** ([peachpiecompiler/peachpie](https://github.com/peachpiecompiler/peachpie), 2,480 stars, Apache-2.0, last pushed June 9, 2026) compiles PHP to .NET, with the runtime hosted on the CoreCLR. The advantage is full access to the .NET ecosystem, the disadvantage is the same dialect problem as KPHP, plus a runtime dependency on .NET. PeachPie is the strongest option for organizations that are already .NET shops and want to consume PHP libraries, but it is not a candidate for general PHP acceleration. TypePHP and PeachPie are not direct competitors; they target different deployment stacks.

**FrankenPHP** ([php/frankenphp](https://github.com/php/frankenphp), 11,156 stars, MIT, last pushed June 15, 2026) is the modern PHP application server, written in Go on top of Caddy. FrankenPHP embeds the PHP interpreter, supports the early-hints HTTP feature, and can be packaged as a standalone binary that contains PHP and the application together. The performance gains over PHP-FPM are substantial, and the operational story is much simpler than running PHP behind nginx. FrankenPHP is not a compiler; it is a server. The comparison with TypePHP is "faster runtime" versus "compiled binary", and the two are solving different problems. FrankenPHP is what you reach for when you want to deploy existing PHP applications faster; TypePHP is what you reach for when you want to write new code in a strongly-typed language that looks like PHP.

**RoadRunner** ([roadrunner-server/roadrunner](https://github.com/roadrunner-server/roadrunner), 8,472 stars, MIT, last pushed June 17, 2026) is a PHP application server and process manager written in Go. RoadRunner keeps PHP-FPM as the worker process but replaces the front-end web server with a Go binary that handles requests, static files, and WebSockets natively. The architecture is hybrid: PHP is interpreted, Go is compiled, and the boundary is well-defined. RoadRunner is the closest analog in spirit to TypePHP's dual engine, except the boundary in RoadRunner is between two processes, not between two execution models inside the same binary.

The differentiators that make TypePHP distinct from all of these: the dual engine, the C++ ABI as a first-class feature, the typed containers, the BigInt/BigFloat/Decimal types, UFCS, and the self-hosted compiler. The dual engine is the only one that requires an embedded Zend runtime, and the C++ ABI integration is the only one that treats native interop as a primary capability rather than an extension API. The other features (Decimal, typed containers, UFCS) are independent of the PHP-syntax question, and they would be valuable in any language. The question TypePHP will have to answer in October is whether the language features are the point, or whether the PHP syntax is the point. The current announcement suggests the language features are the point and the PHP syntax is the surface area, which puts the project on the language-fork side of Pronskiy's dichotomy.

## The release state in mid-June 2026

As of the announcement date, TypePHP is in a pre-beta state. The `swoole/aot-compiler` repository on GitHub was created on May 11, 2026, the v0.1.0 release shipped the same day with a Windows x86_64 binary (43 MB), a Linux x86_64 binary (726 KB), and a macOS arm64 binary (1.6 MB). The v0.2.3 release on June 15, 2026 shipped updated Windows (52 MB) and Linux (2 MB) binaries. The release assets are closed-source prebuilt binaries; the repository itself contains only the README and the example projects. The README describes the project as the commercial Swoole Compiler product line: version 3.2, the existing commercial product, "encrypts and obfuscates PHP opcode bytecode, employing control-flow obfuscation, junk instructions, variable obfuscation, function-name obfuscation, virtual machine protection, code flattening, SCCP optimization, and other techniques to compile PHP source code into encrypted binary bytecode". Version 4.0 is the new AOT compiler, described as "compiles PHP code directly into binary instructions, producing native executables or dynamic libraries for platforms such as Windows, Linux, and macOS". The documentation link in the README points at `doc.swoole.com/@aot-compiler/`, which 404s at the time of writing (the page returns "知识管理 404 文档不存在或已被删除", a Chinese-language 404 page), suggesting the documentation is being migrated in parallel with the rename.

The v0.1.0 and v0.2.3 binaries are the "test versions" the WeChat post invites readers to download. The Swoole team's claim is that in v0.2.3, both the self-hosted-compiled compiler and the Zend-PHP-compiled compiler pass the full unit test suite, which is the milestone that lets them promise a beta in October. The five commits visible on the `main` branch are dated between May 11 and May 19, 2026, with commit messages focused on the JNI extension support, the initial scaffold, and the README. The release cadence between v0.1.0 (May 11) and v0.2.3 (June 15) implies a fairly active development period, but the absence of commits to `main` since May 19 suggests the post-rename work is being done on a feature branch or in a private mirror that will be made public after the source release.

The open-source question is the one Pronskiy flagged. The WeChat post uses the phrase "全面开源" (fully open-sourced) for the post-National-Day release, but the existing Swoole Compiler is a commercial product, and the README of the `swoole/aot-compiler` repository explicitly links to `business.swoole.com/compiler.html`, the commercial sales page. The WeChat post itself closes with an invitation to add the "识沃客服" (Twosee customer service) WeChat account for developer discussion, which is the company's commercial go-to-market channel. The reasonable reading is that the open-source release will be a community edition, with a separate commercial product sitting on top of it for production deployment, encryption, and support, the same model HHVM used when it was open-sourced. Pronskiy's exact phrasing in his X article is that "open source doesn't mean free, but I take it that's the implication", which is the right level of uncertainty to carry into October.

## The Pronskiy critique and the language-fork question

Roman Pronskiy's framing is the read the rest of the industry is going to receive first, because Pronskiy is the head of PhpStorm at JetBrains, the IDE most professional PHP developers use, and the board member of the PHP Foundation, the non-profit that funds the people who keep the language itself alive. He is not a neutral observer, but he is also the most informed neutral observer who is not on the Swoole team. His X article frames the rename in three sentences that are worth reading as a unit: "While generics are failing the vote, here's a continuation of the Swoole AOT compiler story (wrote about it earlier). It is now officially renamed to TypePHP. They mentioned this briefly last time, but now saying it outright: it is a separate strongly-typed compiled language." The first sentence is the underrated one. The PHP RFC for generics in the language itself was failing the vote at the same time TypePHP was being announced, which is the kind of timing coincidence that the Swoole team did not need to engineer but did benefit from. The second sentence is the news. The third sentence is the framing.

His "what else is cool" section is the positive read. The three features he highlights (native Decimal, typed containers, UFCS) are exactly the features the Swoole team is leading with, and Pronskiy's reaction ("Whaaaat?! You could do that all along??") is the reaction the team is hoping for. UFCS in particular is the kind of feature that delights developers the first time they see it and then becomes a tool they reach for automatically, and the extension-method companion is the part that makes the feature composable with existing code.

His "but" is the read the industry will pay attention to. Pronskiy draws the line directly: "The further it goes, the less it's PHP. We've seen this before: Facebook made 'fast PHP' → it turned into Hack → a separate language → the ecosystem split → and here you are." This is the core argument, and it is the argument that will be made by every PHP framework maintainer, every hosting provider, and every developer who has already decided that PHP is a non-negotiable constraint on their stack. The Swoole team is in the position of needing to answer that argument, and the answer is going to have to be more substantive than "we have a dual engine".

There are two ways the answer can go. The first is that the dual engine holds: every PHP application continues to run inside a TypePHP binary, and the language features are opt-in extensions that never break PHP compatibility. The Swoole team's stated claim of 100% PHP ecosystem compatibility is the bet, and v0.2.3 with the self-hosted compiler passing unit tests is the first evidence that the bet is on track. The second is that the language features become the default and the PHP compatibility becomes the legacy mode, the way Hack went from "PHP with type annotations" to "a separate language that happens to be parseable as PHP". The rename from "Swoole AOT" to "TypePHP" is the early signal that the second path is at least plausible, because the team is no longer framing the project as a compiler for PHP, but as a language in its own right.

The October release will be the inflection point. If the source code is released under a permissive license (MIT, Apache-2.0, or similar), if the documentation describes TypePHP as a separate language and the existing Swoole AOT as the compatibility shim, and if the language features are presented as primary rather than opt-in, the project is on the language-fork path. If the source is released under a source-available license, if the documentation keeps TypePHP inside the PHP ecosystem framing, and if the language features are presented as opt-in extensions, the project is on the compatibility-layer path. The binary releases and the WeChat post both lean toward the language-fork path. The actual license terms, when they appear, will confirm which way the team is committing.

## What to watch

The next signal is the source code release on the `swoole/aot-compiler` repository. The Swoole team has committed to uploading the source "国庆节后" (after National Day, which is October 1, 2026), and the license terms attached to that upload are the single most important data point. A permissive license (MIT, Apache-2.0, BSD) signals that the team is committing to the language-fork path with the existing PHP ecosystem as the migration target. A source-available license (the BSL, the SSPL, the Business Source License, or a custom Swoole commercial license) signals that the team is committing to the language-fork path with a commercial product sitting on top, the way HashiCorp and Elastic have done.

The second signal is the documentation at `doc.swoole.com/@aot-compiler/`, which 404s at the time of writing. When the documentation goes live, the way the project is framed will confirm or contradict the WeChat post's language-fork framing. Look specifically for whether the documentation calls the project a "compiler for PHP" or a "compiled language with PHP syntax compatibility", and whether the language features (Decimal, typed containers, UFCS) are presented as core or as opt-in extensions.

The third signal is the `phpx` library. The Swoole team's C++ wrapper for the Zend API has been Apache-2.0 licensed since 2017, and it is the foundation of the AOT compiler's C++ ABI integration. If the AOT compiler is released under a permissive license but the phpx library is moved to a different license, or if phpx is forked into a separate project for the open-source community, that is a signal about the boundary between the open-source and commercial products. The current `swoole/phpx` repository has 856 stars and is actively maintained, and the C++ wrappers it provides are exactly the wrappers a third-party developer would need to build their own C++/TypePHP bridge.

The fourth signal is the broader PHP community reaction. The PHP Foundation has not yet issued a statement on the rename, and the silence is itself a signal. The Foundation funds the people who maintain the PHP language itself, and a separate compiled language that uses PHP syntax is a competitive development for the Foundation's narrative of PHP as a single evolving language. The Foundation's response, when it comes, will clarify whether the Foundation sees TypePHP as a healthy addition to the PHP ecosystem (the way Swoole proper has been treated for years) or as a fork that needs to be either absorbed or set in opposition. Pronskiy's article is one read; the Foundation's eventual response will be the institutional one.

The fifth signal is adoption in the Chinese PHP community. The WeChat official account post is the first move; the customer service invitation at the end is the second. The Swoole team has a deep network in the Chinese PHP community through the existing Swoole runtime, the PHP Foundation's Chinese members, and the broader PHP-China conference circuit. If the October beta lands and the Chinese PHP community picks it up the way they picked up Swoole in 2014, the project has a real base. If the community treats it as a curiosity and waits to see whether the language features survive the inevitable compatibility problems, the project has the same future as KPHP: technically excellent, niche adoption, long-term maintenance by the original team.

The last signal is the compiler's real-world performance. The "tens to hundreds of times faster than PHP" claim is the headline number, and it has not yet been independently verified. The Swoole team's own benchmarks, presumably forthcoming with the source release, will set the baseline. Independent benchmarks from outside the team, especially on the typical web-application workloads (request handling, database queries, JSON serialization, template rendering), will determine whether the performance story holds in production. The dual engine complicates the benchmark story, because the same binary can be configured to run in fully-compiled mode, fully-interpreted mode, or a hybrid of the two, and the relative performance of the three modes is the number the ecosystem will use to make the build-vs-buy decision.

The October release is the date. Between now and then, the most useful thing a PHP developer can do is download the v0.2.3 binary, build the `examples/tetris-sdl` or `examples/jni` example against it, and form a personal read on whether the language features are worth the trade-off. The Swoole team has made the test version available precisely to seed those early reads, and the discourse around the project in October will be shaped by what the early adopters find.