From 9eed68196c4e893974983d4ac9acf398a80acd63 Mon Sep 17 00:00:00 2001 From: Nourrisse Florian Date: Wed, 22 Apr 2026 18:13:40 +0200 Subject: [PATCH] fix(ios): trigger BLE scan when entering ScanningEquipment view The upstream .task{} block was empty, which meant BlufiUtil.startScan() was never called after the user reached the QR scan page. Consequence: after scanning the QR, readCodeString() calls openBlufi() to set the discovery callback, but there's no live scan feeding it - the iPhone never sees the ESP32 in advertising mode and the app stays stuck on the main view. Call getPermission() in .task (which in turn calls getBlueAndWifiInfo() and startScan() once the user grants location permission, as iOS requires for BLE scans). This is a real bug in the open-source app that should also land upstream as PR #9. For now it lives on self-host to unblock our provisioning immediately. --- app/StackChan/View/BindingDevice.swift | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/app/StackChan/View/BindingDevice.swift b/app/StackChan/View/BindingDevice.swift index fff7c02..f550f3d 100644 --- a/app/StackChan/View/BindingDevice.swift +++ b/app/StackChan/View/BindingDevice.swift @@ -227,9 +227,13 @@ struct ScanningEquipment : View { } } .task { + // Upstream ships this block empty. Without triggering the BLE scan + // here, the post-QR openBlufi() callback never fires because + // BlufiUtil.shared.startScan() is gated behind getPermission(). + getPermission() } } - + func updataName() { }