Workflow & pattern

Mobile development with Nift.

Nift can build the web application that you later ship to the browser, install as a PWA, or package inside an Android/iOS shell. The useful boundary is the same one Nift uses elsewhere: Nift owns build-time composition and project relationships; your browser code and mobile wrapper own runtime behaviour and device integration.

The basic shape

Nift project
    │
    ├─ content/ + templates/
    ├─ JavaScript / TypeScript
    ├─ CSS + assets
    └─ contracts / JSON / tracked pages
          │
       nift build
          │
          ▼
       public/
          │
     ┌────┼───────────────┐
     │    │               │
   web   PWA      mobile web shell
                         │
                  Android / iOS

The generated application is ordinary web output. A mobile packaging layer can consume the same public/ directory without Nift needing Android- or iOS-specific rendering semantics.

Nift + a mobile web wrapper

A Capacitor-style workflow is a natural example. Nift builds the application; the wrapper packages those generated assets and provides bridges to native platform APIs when needed.

content/             Nift-authored pages
  index.html
  account.html
  settings.html

templates/           layouts + partials
public/              generated web application
frontend/            optional JS/TS/Vite source
mobile/              optional Android/iOS wrapper project
.nift/

# optional frontend bundle first
npm run build:client

# build Nift pages/assets
nift build-all

# then let your chosen mobile wrapper sync/package public/
# e.g. its normal Android/iOS build commands

No dedicated Nift mobile target is required for this architecture. A future scaffold could make the workflow nicer, but the fundamental integration is already just generated web assets plus the mobile tool's normal packaging step.

What Nift owns

What the runtime owns

Nift                            Browser / mobile runtime
----                            ------------------------
templates + composition         user interaction
tracked routes/pages            API calls
build-time JSON/contracts       application state
asset/path relationships        offline runtime logic
incremental builds              native-device bridges
                                notifications / camera / sensors
                                app-store packaging

This is the same separation used in a Nift + Go/Node/Python web application: Nift remains the small project-aware build layer rather than absorbing runtime responsibilities merely because the deployment target is a phone.

PWA first can be a useful path

For applications that do not need deep native integration, a Progressive Web App may already be enough. Nift can generate the application pages, manifest-related text assets, offline fallback pages and service-worker source just like any other text output; your JavaScript owns the actual runtime caching and install behaviour.

If the same application later needs app-store distribution or native APIs, a wrapper can package the existing web application rather than requiring a frontend rewrite.

React, Vue, Svelte and TypeScript are still optional

A mobile-targeted webapp does not force Nift into a particular client framework. You can keep the runtime as small or as sophisticated as the application needs:

Nift + vanilla JS              small application / content UI
Nift + TypeScript/Vite         larger browser runtime
Nift + React/Vue/Svelte        state-heavy interactive regions
Nift + PWA                     installable web application
Nift + mobile wrapper          Android/iOS packaging + native bridges

The important point is that those choices remain orthogonal to the Nift project model.

Why this fits Nift's philosophy

It would be easy to turn “mobile support” into a reason to invent Nift-specific widgets, navigation, state, layout and native abstractions. That would put Nift in competition with SwiftUI, Jetpack Compose, Flutter, React Native and the mobile platforms themselves.

Build the web application well; let the mobile platform own the mobile platform.

The more interesting proposition is portability through ordinary web output. The same Nift-built frontend can potentially serve a website, install as a PWA and become the web layer inside Android/iOS packaging without changing Nift into a cross-platform UI framework.

Dogfood before making strong claims

This workflow is architecturally plausible, but it should earn stronger website claims through a real application rather than diagrams alone. A useful future Nift dogfooding project is a substantial application built with Nift, packaged for both Android and iOS, with enough navigation, API use, offline behaviour and native integration to expose where the rough edges really are.