[Feature] Big changes in the UI and how the setup is done (proposal to land in steps)

[maatheusgois-dd]

Over the last few days I accumulated a meaningful set of changes in my fork (Compare) that I'd like to propose landing back into johnno1962/InjectionNext main.
Everything below was developed and tested against Xcode 26.3 on macOS, using the fork's InjectionLite + DLKit submodules.

Rather than opening one mega-PR, I'd like to split this into ~7 incremental PRs so each one stays reviewable. Happy to adjust the order / granularity, just tell me what you prefer.

New Icons

New nav bar

Configs

Console log (instead of the last error)

Proposed merge plan (in order) - After your PR closed to the Xcode26.3 change

Each step is an independent PR, stacked on top of the previous one. I'll rebase on your main before each.

1. PR 1 — Compiler/runtime fixes (non-UI).
   WMO flag filter, ControlServer start order + logging, watch menu title, @MainActor fixes, safer signal handlers, warning silencing. No behavior change for existing users.
2. PR 2 — Assets + Makefile (help to development).
   AppIcon asset catalog, red status asset, Makefile. Pure additions / cosmetics.
3. PR 3 — SwiftUI migration (status bar + settings + project picker).
   The big UI change. Old XIB/AppKit removed in the same PR to avoid dead code. (can impact the minimal os to build because now is swiftUI)
4. PR 4 — Project picker enhancements.
   Browse option, "Select Project" status bar action, reuse running Xcode.
   Depends on PR 3.
5. PR 5 — Build-system settings UI.
   Auto-detect + override + hybrid SDK-filter fallback + Bazel-path skipping.
6. PR 6 — In-app console + LogManager.
   stdout/stderr capture, dedup, CAS/SIGPIPE hinting.
7. PR 7 — MCP server + event tracker. (only new methods)
   Optional feature, disabled by default; can be its own SPM target so it doesn't bloat the default app.

[maatheusgois-dd]

@johnno1962 curious to hear what you think about this

[johnno1962]

Well, well, well. There I was thinking you'd lost interest and you've gone on and brought the app into the 21st century (not before time!) Yes all these changes are very much of interest thanks. I've think it's important we don't fork the effort at this point particularly for the submodules. Your change to DLKit I can merge immediately though one idea might be to create a new public static var dlOpenMode = RTLD_LAZY | RTLD_GLOBAL used in the dlopen so people can override it. I also particularly appreciate your not making the code Swift 6 concurrency dependant.

I've cleared the decks for you, closed out the Xcode26.3 branch and created a new 2.0_overhaul branch you can PR against bumping the version to give you a pretty free hand. Anything you need to merge in a hurry or if you want a release candidate let me know. I have tried your version of the app and something is up with running Xcode from inside the app (non log-parsing) giving a red Xcode icon on my machine. Is that intentional? That icon is usually for people developing Xcode inside Apple.

[maatheusgois-dd]

Thanks for the warm welcome back and for clearing the decks! the 2.0_overhaul branch is exactly what I needed.

Quick answers:

• Red Xcode icon: not intentional, that's a bug on my side. I'll fix it so running Xcode from inside the app uses the normal release icon instead of the "Xcode dev" one.

• DLKit dlOpenMode: love the idea. I'll open that as a small, standalone PR against DLKit so it can land immediately:
  public static var dlOpenMode: Int32 = RTLD_LAZY | RTLD_GLOBAL and have dlopen read from it.

• Swift 6 concurrency: fully agree, I'll keep the codebase free of any Swift 6 concurrency requirements. No @mainactor sprinkling, no Sendable conformance where it forces callers to adopt strict concurrency, and no language-mode bumps in Package.swift / build settings. Anything concurrency-related will stay opt-in and compatible with Swift 5.

[johnno1962]

BTW, though I was very attached to the old App.icns file I love the new Icons and also the Settings Panel changes.