Mobile Overview

Wails v3 runs on iOS and Android using the same main.go and frontend you already write for desktop. There is no separate mobile project, no code-sharing bridge, and no rewrite: the Go binary is compiled for the mobile target and a native WebView renders your existing frontend.

See it running: Kitchen Sink example

The best way to understand what’s possible is to look at the Kitchen Sink — a single Wails app that runs identically on iOS, Android and desktop from one codebase:

Mobile Kitchen Sink — GitHubBindings · Events · Dialogs · Haptics · Geolocation · Biometrics · Notifications · Secure storage · and more — all from one main.go

It demonstrates every major mobile API surface across 7 tabs — and it runs on desktop too. The Mobile and Hardware tabs are hidden on desktop via a platform check in the frontend; the Go side registers no handlers for common:* mobile events when built for desktop. This is the recommended pattern for shipping one codebase everywhere.

To run it yourself:

git clone https://github.com/wailsapp/wails.git
cd wails/v3/examples/mobile

wails3 task ios:run        # iOS Simulator (macOS + Xcode required)
wails3 task android:run    # Android Emulator
wails3 task run            # Desktop

How it works

The same application model applies on every platform:

1. Go backend — your services, event handlers and application logic compile unchanged for GOOS=ios and GOOS=android.
2. Frontend — the exact same HTML/JS/CSS. The @wailsio/runtime package works identically; service bindings, events, dialogs and the clipboard all route through the same in-process transport.
3. WebView host — on iOS a WKWebView inside a UIViewController; on Android a WebView inside an Activity. Wails wires up the message bridge automatically.
4. In-process asset serving — assets are served directly from Go memory, not a localhost server. No open ports, no loopback, no extra latency.

Platform-specific behaviour lives in files guarded by //go:build ios or //go:build android, keeping your shared code clean.

Prerequisites at a glance

What’s supported

Both platforms share the same core feature set:

Build tag rules

Two important rules to know when writing platform-conditional code:

• ios implies darwin — a file tagged //go:build darwin will also compile for iOS. To target macOS-only, use //go:build darwin && !ios.
• android implies linux — a file tagged //go:build linux will also compile for Android. To target desktop-Linux-only, use //go:build linux && !android.

At runtime, runtime.GOOS returns "ios" and "android" respectively.

Runtime platform detection

Build tags are for code that can only compile on a given platform. For ordinary branching in shared code, use application.System — it’s available in every build (no build tags needed) so the same file works everywhere:

import "github.com/wailsapp/wails/v3/pkg/application"

if application.System.IsMobile() {
    // iOS or Android
} else if application.System.IsDesktop() {
    // macOS, Windows or Linux
}

// Or test a single target directly:
if application.System.IsPlatform(application.PlatformIOS) {
    // iOS only
}

Available: IsMobile(), IsDesktop(), IsServer() (the server build tag), and IsPlatform(application.PlatformMacOS | PlatformWindows | PlatformLinux | PlatformIOS | PlatformAndroid | PlatformServer).

The frontend has the matching helpers in @wailsio/runtime:

import { System } from "@wailsio/runtime";

if (System.IsMobile()) { /* iOS or Android */ }
if (System.IsIOS()) { /* … */ }      // also IsAndroid, IsMac, IsWindows, IsLinux, IsDesktop

Next steps