What is IWC?

IWC is a declarative full-stack development framework. You describe an application in JSON files — its screens, layouts, components, data schemas, APIs, business actions, workflows, security rules and tests — and the iwc command-line tool compiles them and runs them as a complete application: server-rendered web pages, a JSON API, a database with migrations, authentication, background jobs and, from the same files, native Android and iOS apps.

For ordinary application work you do not write JavaScript, TypeScript or SQL. When you genuinely need your own browser code (a map, a payment form, a chart library), a widget adds it behind a declared security policy.

Why IWC?

Most of a business application is the same work, repeated: a table, a form that writes to it, validation on both ends, a page that lists the rows, access rules, a sign-in flow, an API for the mobile app, migrations, tests, a deploy. Frameworks give you libraries for each part; you still wire them together, and every wire is somewhere a bug or a vulnerability can live.

IWC takes the opposite approach. You declare what the application is; the runtime implements how, the same way every time:

• Less code to get wrong. A complete notes feature — table, create/update/delete endpoints, owner-only access, a form with server-side validation — is four short files. See the CRUD tutorial.
• Safe by default. Output is escaped, requests are validated against their declaration, undeclared fields are rejected, queries are parameterised, reads are public but writes need sign-in and updates are owner-only unless you say otherwise. See Security.
• Mistakes caught before they run. iwc check validates every file against its schema and every cross-file reference — a form posting to a GET API, a binding to a column the page never loads, a link to a route no screen has — with file:line:col errors.
• One project, three platforms. The same .iwc files build a web app, a Jetpack Compose Android app and a SwiftUI iOS app.
• One binary. The CLI, compiler and runtime are a single native binary with SQLite built in and PostgreSQL supported. You install it with npm on macOS, Linux or Windows; your apps don't need Node.js or anything else to run.

Core philosophy

1. Declare intent, not mechanism. A file says "this API creates a note for the signed-in user and returns its id and title". It does not say how to parse JSON, open a transaction or check a session.
2. Closed by default. Anything not declared is refused: undeclared request fields, unknown keys in a file, sensitive fields in a response, literal credentials in source, javascript: URLs.
3. The compiler is the first reviewer. Errors carry a position and a suggestion ("justify" must be one of … got "space-between" (did you mean "between"?)). If something compiles, its references resolve.
4. Files are data. .iwc files are strict JSON: diffable, reviewable, generatable by tools. Other tools can attach their own data under x- keys, which IWC keeps and never interprets.
5. No hidden fallbacks. A native target never falls back to a web view; a simulated payment provider refuses to start in production; a migration that would lose data is refused with an explanation.

Declarative development in practice

Here is a complete screen. It lists products from the database in a responsive grid of cards, each linking to its own page:

{
  "name": "Products",
  "route": "/products",
  "title": "All products",
  "sections": [
    { "type": "text", "variant": "h1", "content": "All products" },
    {
      "type": "grid", "columns": 3, "gap": "24px", "responsiveColumns": { "tablet": 2, "mobile": 1 },
      "data": { "source": "DATABASE.products", "columns": ["name", "price", "image", "slug"], "sort": { "field": "name" } },
      "item": { "type": "card", "fields": { "title": "name", "price": "price", "image": "image", "link": "/products/:slug" }, "currency": "USD" },
      "empty": { "type": "text", "content": "No products yet." }
    }
  ]
}

There is no controller, no query, no template loop and no client bundle to configure. The page is rendered on the server, the query selects only the listed columns, the table's read rule is applied to the visitor, and the HTML is escaped.

The file types

The type of a file comes only from its extension; folders are a convention. Full details: file types and the language reference.

Supported project types

Web, API, Android and iOS

• Web. Server-rendered HTML with a small runtime for interactivity (dialogs, tabs, carousels, forms, client state, in-place navigation). Pages work without JavaScript wherever the element allows.
• API. Every .api.iwc is a JSON endpoint under /api, also usable by mobile apps and other systems, with an OpenAPI 3.1 document generated from the declarations.
• Android and iOS. Genuine native apps: Jetpack Compose and SwiftUI, never a web view. Compiled native apps support a focused set of elements in this first phase; server-driven native apps draw whatever the server renders. See Android & iOS apps and limitations.

Where to go next

• Install IWC and follow the quick start.
• Read how IWC works: compilation and the runtime.
• Work through the tutorials, from your first page to a deployed application.