Research: Apple-native KSail app (iOS/iPadOS/macOS) for managing clusters from Apple devices

> 🤖 Generated by the Daily AI Assistant
> Filed on the maintainer's direct direction (2026-07-05).

## Problem

KSail is currently reachable from a terminal (CLI), a browser (`ksail open web` + ksail-operator), and soon a richer web UI (Headlamp-parity epic #5827). Users on Apple devices — iPhone, iPad, and Mac — have no first-class native way to manage and operate their KSail clusters on the go. **Research whether an Apple-native KSail application (iOS/iPadOS/macOS) is feasible and worth building**, so Apple users can manage and operate their Kubernetes clusters from their devices with ease.

## Research questions

1. **Architecture options & prior art.** Fully native SwiftUI client against the Kubernetes/ksail-operator APIs; a thin native shell around the existing KSail web UI (WKWebView / SwiftUI wrapper, share the #5827 investment); or a shared core via `gomobile`/xcframework bindings from KSail's Go packages (which of `pkg/client`/`pkg/svc` are binding-friendly, and what is off-limits — e.g. anything shelling out or requiring Docker). Survey prior art (Kubenav and other mobile k8s clients, Headlamp's desktop app model) for what worked and what died.
2. **Capability envelope per platform.** iOS/iPadOS cannot run Docker — the app is a *remote* control surface (cloud/Hetzner/EKS/GKE/AKS clusters, or a home cluster over VPN/WireGuard); macOS could additionally drive local clusters. Which KSail operations make sense on which device (status/lifecycle/GitOps reconcile/logs vs. full cluster creation)?
3. **Connectivity & auth.** Kubeconfig import, OIDC device-flow sign-in (reuse the #4602 federation work), the platform's WireGuard VPN client lane for reaching private clusters, and how a mobile session stays secure (Keychain, short-lived tokens).
4. **Distribution & maintenance cost.** App Store review constraints, signing/notarization, TestFlight vs. sideload, release automation from CI (macOS runners), and the ongoing maintenance weight of a fourth UI surface for a solo-maintainer portfolio — including whether the web UI as a PWA already covers most of the mobile need.

## Acceptance criteria (outcome contract)

The research must land in exactly one of two outcomes:

- [ ] **Proceed:** a follow-up `roadmap` issue that covers the bases on how to proceed — chosen architecture, capability scope per platform (iOS/iPadOS/macOS), auth/connectivity design, distribution plan, and a first decomposed child — with this issue closed pointing at it; **or**
- [ ] **Decline:** this issue closed with a written declination laying out the reasoning (feasibility, cost/benefit, or a better alternative such as a PWA-hardened web UI).

Related: #5827 (web-UI parity epic — a native shell would build on it; a declination would likely lean on it), #4602 (OIDC federation, closed — the auth building blocks).

Rough size: M (research + decision write-up only; any build work belongs to the outcome roadmap issue).

Start by reviewing the existing pkg/client and pkg/svc packages, the #5827 web-UI direction, and the #4602 federation work. Compare native SwiftUI, a web wrapper, and gomobile options across the listed platforms, then document either a follow-up roadmap issue with scope, auth, connectivity, distribution, and a first child, or a written declination.

Written by the indexing model from the issue text.