chanora/apps/chanora_flutter/ios/Runner/AppDelegate.swift

import UIKit
import Flutter
import AVFoundation

@main
@objc class AppDelegate: FlutterAppDelegate, FlutterImplicitEngineDelegate {
  override func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
  ) -> Bool {
    // Configure the iOS AVAudioSession **category + mode** at
    // app-launch time, but DEFER setActive(true) until the scene
    // is foregrounded. Calling setActive in didFinishLaunching is
    // racy on iOS 17+ devices: if the user launches the app from a
    // cold state, the UIApplication isn't yet `.active` and
    // setActive returns `AVAudioSessionErrorCodeCannotStartPlaying`
    // (561017449) — the iOS audio policy server refuses to grant
    // the audio session because the app is not yet considered the
    // foreground priority owner. Symptom in production builds:
    // 'AVAudioSession setup failed: Error 561017449 "Session
    // activation failed"' in NSLog, after which the audio engine
    // is unusable until the user backgrounds + foregrounds the
    // app.
    //
    // The category itself can be set whenever; only the active
    // state needs to be deferred. We listen for
    // didBecomeActiveNotification and activate then. Most
    // production iOS voice apps (Discord, Zoom, FaceTime) follow
    // this same shape.
    do {
      let session = AVAudioSession.sharedInstance()
      try session.setCategory(
        .playAndRecord,
        mode: .default,
        // Mode rationale:
        //
        // .voiceChat (previously used here) wires the audio session
        // into iOS's telephony processing pipeline: forced mono
        // output, automatic gain control, aggressive noise gating,
        // and \u2014 crucially \u2014 binds the underlying AudioUnit's
        // output element to a SINGLE physical transducer (the
        // receiver/earpiece) at session-configure time. The
        // overrideOutputAudioPort API updates AVAudioSession's
        // route metadata, but the AudioUnit's output binding is
        // stale: it keeps routing audio to the originally-bound
        // hardware. Net symptom: tapping "Speaker" in the picker
        // flips AVAudioSession.currentRoute.outputs (so our log
        // says out=Speaker) but no audio comes out the speaker
        // \u2014 it's still going to the earpiece.
        //
        // .default mode uses iOS's standard audio graph: stereo
        // output, no AGC, no telephony post-processing, and the
        // output AudioUnit re-binds live when the route changes.
        // This is the same mode Music.app and most non-telephony
        // apps use. We lose iOS's hardware AEC \u2014 if the user
        // reports hearing their own voice loop back on speakerphone,
        // we'll add a software AEC pass on the Rust side (DEC-030
        // covers the AEC plan).
        //
        // Category options unchanged \u2014 .allowBluetoothHFP +
        // .allowBluetoothA2DP still permit BT headsets for both
        // input and output regardless of mode.
        options: [.allowBluetoothHFP, .allowBluetoothA2DP]
      )
      NSLog("chanora_flutter: AVAudioSession category set (playAndRecord/default)")
    } catch {
      NSLog("chanora_flutter: AVAudioSession setCategory failed: \(error)")
    }

    // Activate the session once the app is actually foreground. The
    // notification fires immediately after the cold-launch settles,
    // and again on every resume-from-background — both safe
    // moments to call setActive(true). Repeated activation while
    // already-active is a no-op per the docs.
    NotificationCenter.default.addObserver(
      self,
      selector: #selector(activateAudioSession),
      name: UIApplication.didBecomeActiveNotification,
      object: nil
    )

    // Request microphone access on first launch rather than waiting
    // for the user's first voice-channel join. The latter is
    // surprising: the user has only tapped "connect to server" and
    // suddenly iOS pops the permission prompt because joining a
    // text channel happens to trigger audio engine startup. Asking
    // up-front matches user expectations for a voice-chat client.
    //
    // The request is asynchronous and non-blocking. If the user
    // denies, voice_join will surface a clearer error later when
    // the audio engine fails to open the input device. The
    // permission state is cached by iOS so subsequent launches
    // skip the prompt.
    //
    // Deferred ~1 s so iOS finishes initialising the keyboard /
    // text-input subsystem before the permission alert appears.
    // Firing the alert too early steals focus from the not-yet-
    // ready text-input layer, with the symptom that the first tap
    // on a TextField does nothing (the second tap works because
    // by then iOS has caught up). DispatchQueue.main.asyncAfter
    // keeps everything on the main thread; the permission API
    // itself must be called there too.
    DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) {
      AVAudioSession.sharedInstance().requestRecordPermission { granted in
        NSLog("chanora_flutter: microphone permission granted=\(granted)")
      }
    }

    return super.application(application, didFinishLaunchingWithOptions: launchOptions)
  }

  /// Called by `didBecomeActiveNotification` (cold-launch settle +
  /// every resume-from-background). Activates the AVAudioSession.
  /// Repeated activation is a no-op when the session is already
  /// active so this is safe to call on every foreground.
  @objc private func activateAudioSession() {
    do {
      try AVAudioSession.sharedInstance().setActive(true, options: [])
      NSLog("chanora_flutter: AVAudioSession activated on foreground")
    } catch {
      NSLog("chanora_flutter: AVAudioSession setActive failed: \(error)")
    }
  }

  func didInitializeImplicitFlutterEngine(_ engineBridge: FlutterImplicitEngineBridge) {
    GeneratedPluginRegistrant.register(with: engineBridge.pluginRegistry)
  }
}