Benchmark proof

Buyer-proof benchmark evidence that Axint keeps Apple-native workflows smaller, easier to review, and easier to decide on before ship

The examples below are computed from source that ships in the page HTML. They show how a compact Axint definition compares with the Swift an agent or developer would otherwise need to generate, inspect, and regenerate for the same Apple-native surface. The point is not abstract token trivia. The point is less generated surface to review, less churn to diff, and more confidence when a team has to decide whether a feature is safe to ship.

Live authoring surface comparison

defineIntent()

App Intent that runs in Siri

TypeScript16 lines
116tokens
import { defineIntent, param } from "@axint/compiler"; export default defineIntent({ name: "CreateCalendarEvent", title: "Create Calendar Event", description: "Create a calendar event",...
Swift36 lines
225tokens
import AppIntents struct CreateCalendarEventIntent: AppIntent { static var title: LocalizedStringResource = "Create Calendar Event" @Parameter(title: "Event Title") var title: String...
Token reduction ratio
1.9x

defineView()

SwiftUI view component

TypeScript20 lines
164tokens
import { defineView, prop, state, view } from "@axint/compiler"; export default defineView({ name: "ProfileCard", props: { displayName: prop.string("User's display name"),...
Swift61 lines
318tokens
import SwiftUI struct ProfileData { let name: String let bio: String let avatar: String...
Token reduction ratio
1.9x

defineWidget()

iOS/macOS widget

TypeScript20 lines
137tokens
import { defineWidget, entry, view } from "@axint/compiler"; export default defineWidget({ name: "StepCounter", displayName: "Step Counter", description: "Shows your daily step count and progress toward your goal.",...
Swift144 lines
817tokens
import WidgetKit import SwiftUI struct StepData: Codable { let steps: Int let goal: Int...
Token reduction ratio
6.0x

Workflow size at a glance

225
116
Intent
318
164
View
817
137
Widget
TypeScript
Swift

The numbers that matter

69%

Less authoring surface to carry through the workflow

Across the public intent, view, and widget fixtures

~314

Less generated Swift to inspect per feature

Average gap between Axint source and emitted Swift

~31,400

Generated tokens kept out of 100 repair and review loops

How the smaller authoring surface compounds across repeated iterations

What this changes for a team

Smaller review surface

When AI output regenerates, reviewers do not have to reread the full Swift surface from scratch. The compact Axint definition stays smaller, so the review loop stays lighter.

Cleaner handoff to Apple reviewers

Teams still get ordinary Swift at the end, but they carry less generated surface through the authoring and repair loop before it reaches a shipping decision.

Better fit for Cloud validation

Smaller definitions are easier to regenerate and compare, which makes validation, regression review, and release-confidence workflows much more legible inside Cloud.

Methodology you can inspect

What this page measures

Smaller Apple-native authoring surface. Each comparison estimates tokens for the Axint source and the emitted Swift using a fixed 4-characters-per-token approximation.

What it does not measure

This page does not claim compile throughput, universal savings on every Apple feature, or exact provider billing. It is a narrow proof page, not a catch-all performance claim.

How to rerun it

Use the repo benchmarks for compiler throughput, inspect the examples we use as reference fixtures, and read the methodology note that explains where the public numbers come from.

Why this matters beyond compression

This page is not here to brag about shaving five dollars off a bill. It is here to show that Apple-native iteration gets heavy fast, and that smaller authoring surfaces leave less output to inspect, resend, diff, and debug.

Axint changes the workflow shape: one defineIntent() call generates production Swift. The agent or developer works against a compact definition, then carries the generated Swift only when it is time to validate, review, or ship.

Result: 69% less authoring surface and 3.3x average compression across the public samples on this page, which keeps Apple-native iteration lighter and easier to review. That does not replace proof about bugs caught or release confidence. It supports it.

Ready to move from proof to workflow?

Start with the compiler walkthrough, then use Cloud when you want validation, report URLs, and rollout context around a real Apple-native feature.