Parity with TypeScript
The Python SDK is parity-bound to the TypeScript SDK — every feature the TS surface exposes will eventually be available in Python, because both speak the same language-agnostic Intermediate Representation.
Supported today (0.4.28)
define_intent(),define_view(),define_widget(), anddefine_app()param.*— every parameter type, includingoptionalanddefaultentitlements— list of entitlement identifiersinfo_plist_keys— list or dict form for Info.plist usage descriptionsis_discoverable— flag for Siri/Shortcuts discoverability- Multi-intent files — parse any number of intents from a single
.pyfile IntentIR.to_dict()— emits the exact camelCase JSON schema the TS compiler consumesIntentIR.from_dict()— round-trip IR JSON back into dataclasses- CLI:
axint compile,axint validate,axint eject,axint watch - MCP server: feature generation, suggestions, scaffold, compile, validate, schema compile, Swift validate/fix, and template browsing
- Native Swift generation for intents, views, widgets, and apps
- Native validator integration for Python-authored surfaces
Where TypeScript still leads
- Built-in prompts. TypeScript still ships the built-in MCP prompts first, while Python focuses on tool parity.
- Swift repair tooling. Python now exposes Swift validate/fix through the shared Axint bridge, but the canonical implementation still lives in the TypeScript compiler.
- Launch velocity. New compiler capabilities tend to land in TypeScript first, then backfill into Python once the IR and generator behavior settle.
Won’t ever support
- Arbitrary Python expressions as parameter values. The parser is
deliberately AST-only and never executes user code. If you write
param.string(compute_description()), the parser will flag AXP007 becausecompute_description()isn’t a string literal. This is a safety feature, not a limitation. - Runtime performance of
perform(). Axint is a compile-time tool — theperform()body never runs in Python. It gets transpiled to a Swift stub that you implement yourself.