Architecture

Architecture

中文

Current implementation

Screen-Remote-macOS is one native macOS App target named Screen-Remote. The target deploys to macOS 11.0, uses SwiftUI with AppKit bridges where needed, and currently keeps most Swift sources directly under Screen-Remote/ in one Xcode group. This is the current layout, not the desired long-term module boundary.

The app owns product state, windows, menu bar, persistence, SwiftUI presentation, native scrcpy orchestration, decoded-frame display, and future input mapping. ScreenRemoteApp.swift, RootView.swift, and SidebarView.swift form the application entry and navigation shell. Models.swift, AppPersistence.swift, DesignSystem.swift, and MacOSCompatibility.swift are current shared foundations.

Runtime responsibilities

Area	Current owner	Boundary
Device discovery and lifecycle	ScreenSessionManager.swift and device views	Product session state and UI-facing coordination
ADB/helper work	DADBHelperRuntime.swift, app managers, external/dadb	Reusable remote collection belongs in dadb/helper
Screen presentation	NativeScrcpySession.swift, ScreensView.swift	App manages the server, sockets, decoder, and display
Product UI	SwiftUI views and DesignSystem.swift	Views must not become a second ADB/process layer
Persistence and language	AppPersistence.swift, app state, Localizable.xcstrings	Persisted settings drive locale and presentation

Target directory architecture

The target is still a single App target, organized on disk and in Xcode into:

Screen-Remote/
  App/          application entry, environment, root navigation
  Core/         models, design system, localization, logging, utilities
  Platform/     macOS compatibility, windows, menu bar, file panels
  Services/     persistence, ADB/helper, scrcpy, Android tooling
  Features/     device- and product-facing feature modules
  Resources/    assets, String Catalog, bundled server resources

Services/Scrcpy/ further separates Protocol, Session, Video, Audio, and Control. Features/ is feature-first (Devices, Screens, Apps, Management, VirtualDevices, Settings, Diagnostics, Tooling, Notifications, Messages, Photos). This is a migration target; it does not assert those folders already exist.

Change rules

• Keep UI, view-model/state, service, model, parser, and process responsibilities separate.
• Prefer one principal type per Swift file. Investigate files over 500 lines; files over 700 lines are not a normal extension point.
• Preserve the app/dadb boundary and do not move media or window lifecycle into dadb.
• Verify ADB and session semantics against the Android reference when those semantics change; native macOS lifecycle and UI remain native.