idb

Summary is backed by , which fatal-errors if more than one is ever created from it: The helper () reads via , and every call constructs a fresh iterator; a loop makes one too. Any handler that combines two such reads on the same request stream aborts the whole companion on the second read. Affected RPC handlers (directly, or via the shared ): Fix Introduce a shared () that makes one iterator per RPC and exposes / against it. Each multi-frame handler wraps its once and routes every read through the wrapper; handlers that delegate to a helper (, , , ) thread the wrapper into the helper, and now takes the wrapper as well. The trailing loops become on the same iterator. The extension is kept for the many genuine single-read handlers, now with a doc-comment warning about the single-shot hazard. Notes Reproduced with grpc-swift 1.23.1 / current SwiftNIO. The trap is inherent to grpc-swift's single-iterator contract, so this reproduces wherever a recent grpc-swift/NIO is used; please confirm against the internal pin. Verified the companion builds (Xcode 26.2 / Swift 6.2) and that now records a valid MP4 instead of aborting. No behavior change for the single-read handlers (, , -single-frame paths, etc.).

Summary evaluates its initializer arguments in declaration order: looks up with , but the thing that actually loads SimulatorKit into the process — inside — runs after it. Any process that has not already loaded SimulatorKit by other means throws on the entire Indigo path. This includes the default transport selection: on a simulator where is not active, resolves to , so a plain fails. Why idb_companion does not hit this calls before , so inside the companion SimulatorKit is always resident before the client lookup runs. The bug only surfaces for consumers that link directly and follow the documented HID entry point. Reproduction main @ c51004c9, macOS 26, Xcode 27.0 beta 4 ( pointing at it), CoreSimulator 1169.1, booted iOS 27.0 simulator, Device Hub closed (no , so the indigo path is selected): With the log confirms only CoreSimulator was ever loaded: Forcing works fine in the same process (no SimulatorKit needed), which also confirms the rest of the stack is healthy. Suggested fix Load the Xcode frameworks (or at least SimulatorKit) at the top of before constructing , e.g.: or reorder so is constructed first. Consumers can work around it today by pre-loading themselves before creating an .

Hello everyone, the current main branch code is quite different from the latest version released so far (better arm64 and new system version support). Are there any plans to release a new version? Any information would be greatly appreciated, thank you all.