Proposal: Native iOS App

[3ch0p01nt]

Proposal: Native iOS App for RackPeek

Hi @Timmoth! I'd like to contribute a native iOS app for RackPeek. I love the project and think a mobile companion would be valuable for anyone managing their home lab infrastructure on the go.

Overview

A standalone iOS app (no server dependency) that provides full feature parity with the web UI, plus iOS-native extras. It would live in an ios/ directory alongside the existing .NET solution — no changes to existing code.

Architecture

Mirrors RackPeek's clean layered architecture using Swift Packages:

• RackPeekDomain — Pure Swift package with SwiftData models mapping to YAML schema v3, use cases, and YAML import/export (via Yams library)
• RackPeekUI — Shared SwiftUI components (cards, resource views, export views)
• App target — Navigation, platform integrations, extension targets

Key compatibility guarantee: The iOS app reads and writes the exact same YAML schema v3 format. Round-trip tests ensure a config exported from iOS can be loaded in the web UI and vice versa.

Tech Stack

• Swift / SwiftUI, iOS 17+ minimum
• SwiftData for local persistence
• Yams for YAML serialization
• AGPL-3.0 license (matching the project)

Feature Scope

Core (matching web UI)

• Full CRUD for all resource types (hardware, systems, services)
• Sub-resource management (CPUs, drives, GPUs, RAM, ports)
• Tags, labels, markdown notes
• Port-to-port connection mapping
• Subnet browser
• Ansible inventory export (INI + YAML)
• SSH config and hosts file export
• Raw YAML editor with import/export

iOS-Native Extras

• Camera for asset photos
• Barcode/QR scanning for asset tags
• Home screen & lock screen widgets (WidgetKit)
• Siri Shortcuts / App Intents
• iCloud sync across Apple devices
• Spotlight search integration
• Share sheet for all exports

Proposed PR Strategy

Phased approach for reviewability:

1. Phase 1 — Core Foundation: SwiftData models, YAML import/export, full CRUD, basic tab UI, unit tests
2. Phase 2 — Network & Exports: Connections, subnet browser, Ansible/SSH/hosts exports, share sheet
3. Phase 3 — iOS-Native Features: Camera, barcode scanner, Spotlight, Siri, iCloud sync
4. Phase 4 — Widgets & Polish: WidgetKit, accessibility, performance, documentation

Each phase is a self-contained PR that can be reviewed independently.

Questions for You

• Are you open to iOS contributions living in the repo?
• Any preferences on directory structure or naming conventions?
• Any features you'd prioritize or deprioritize?
• Would you prefer a different PR strategy?

Happy to adjust the approach based on your feedback. Full design document available in my fork.

🤖 Generated with Claude Code