Unofficial iPad/iPhone port: standalone client on libaethercore (FLEX-tested, TestFlight)

[OH6OKSA]

Hi Jeremy and all,

I've been building an unofficial iPad and iPhone version of AetherSDR in my fork, and I'd like the project to know about it before it travels further. If there is interest I'd also like to discuss upstreaming it.

What it is

A standalone iPadOS/iOS app (universal: iPad and iPhone). libaethercore is linked in-process and the app talks to the radio directly: no PC, aetherd or SmartSDR in between. The UI is new and written in Qt Quick/QML for touch. It has a tablet layout and a phone layout, and switches between them live on rotation, Split View or fold/unfold. The engine is unchanged, apart from small platform guards.

• Fork and branch: https://github.com/OH6OKSA/AetherSDR/tree/mobile/aether-mobile-core
• Overview: mobile/README.md on that branch

How it fits the existing architecture

• A new CMake option, AETHER_MOBILE, builds the engine only: no QtWidgets, desktop app, tests, QGeoView or desktop peripherals. It is forced ON for iOS and documented in BUILD-OPTIONS.md. Desktop builds are unchanged.
• iOS fixes in core: macOS-only IOKit/CoreAudio code moved behind Q_OS_MACOS, and QProcess users guarded with QT_CONFIG(process). Each feature that cannot run on iOS says so with a reason.
• RX audio follows the desktop rule of one source per backend (IRadioBackend::ownsRxAudio()). Spectrum and waterfall come from the backend-neutral panFeed* signals, so the demo/SimBackend works too.
• TX follows the desktop contract. PTT is captured as a TxController::Input from localTxController(). Every TX packet passes Context::beginDispatch() before sendToRadio(). Release, disconnect, the mic input leaving PC, and loss of app foreground all unkey. PTT is offered only when canTransmit and mic_selection=PC; otherwise the reason is shown.
• Band buttons use the radio's band stack (XvtrPolicy::resolveBandStackKey + requestPanBand), not BandDefs.h frequencies.
• CI (.github/workflows/mobile-ios.yml, mobile branches only) builds the engine and app for iOS arm64 on GitHub's macOS 26 runners, then signs and uploads to TestFlight once the fork's secrets are present.

Status

• Tested against a FLEX on SmartSDR API 1.4.0.0: connect by IP, slice/pan adoption, live spectrum and waterfall, S-meter, mode/filter/NR/NB/ANF/AGC, band stack, RF power and mic level.
• Running on iPads (and now iPhones) through TestFlight for a few testers. We are working through device feedback (zoom gestures, PTT hold on iOS).
• TX has not been verified on air yet.
• Limitation: on iOS, LAN discovery needs Apple's multicast entitlement, so for now users enter the radio's IP address.

Questions for the maintainers

1. Would you like this upstream? If so, I'd start with an RFC per GOVERNANCE.md. The natural split is (a) AETHER_MOBILE and the iOS core guards, then (b) the mobile/ client.
2. Naming: the TestFlight build is called "AetherSDR Mobile" and its description says it is an unofficial community build. Are you OK with the name, or would you prefer something else?
3. Distribution: GPLv3 and Apple's terms are a known tension. For now I share the build only with a small TestFlight group and point to the public source. Do you have a position on this?

It's developed in the project's AI-assisted way (Claude Code). Commits are signed and follow AGENTS.md conventions (Principle N. subjects, BUILD-OPTIONS rows, comments that describe current behaviour).

73, Niko OH6OKSA