During this time, I have been using the Codex App and the Codex CLI to develop iOS Apps at the same time, especially in the SwiftUI + Xcode workflow, and it is becoming more and more obvious that many people actually misunderstand the positioning of these two products.
But once you really start high-frequency development, they're more like two completely different runtimes.
📱 If you are doing iOS development, my conclusion is now very clear: the Codex CLI should be the main development environment, and the Codex App is more suitable as a visual collaboration layer and task console.
The reason is simple.
most of the time in iOS development, there is essentially no need for GUI judgment, but a continuous engineering cycle: modify Swift/SwiftUI code, run xcodebuild, repair compile errors, adjust test, refactor module, handle dependency management project structure, which is essentially: "long time, structured, recyclable" execution workflow.
And that happens to be where the Codex CLI is strongest.
What's really powerful about the ⚙️ CLI is that it's closer to an automated runtime (or harness runtime).
It can be iterated continuously in the same goal: fix bugs, → build → → retry, and repair.
Especially when the project starts to get complicated, you will clearly feel that the CLI is more like a real engineering worker.
And the problem with the Codex App here is obvious.
Although its computer use and GUI comprehension are very strong, it always defaults to being a "desktop collaboration agent", not a runtime that can be unattended coding for a long time.
So you're going to encounter this a lot: "Go on?" Do you want to allow the operation?
"" Do you want to confirm the modification?
"In scenarios such as Lightroom, Figma, and design review, this interaction is completely reasonable, because AI needs to constantly make visual judgments.
But in iOS development, 80% of the time, there is no need for visual cognition at all.
Often just: build failed → fix → retry.
If each step is interrupted by confirmation, the flow will be very fragmented.
🚀 So my most recommended workflow right now is actually: CLI responsible: write code build test refactor long-running goals App responsible: check Simulator do UI review check SwiftUI page observe animation and interaction management multiple tasks and context This division of labor will be very comfortable.
Because it conforms to a very important law: 🧠 Apps are better at "visual cognition" ⚙️ CLI is better at "pipeline execution" For example: I will first let the CLI complete the entire feature implementation, including networking, view model, navigation, and state management.
Then look in the app: whether the page hierarchy is comfortable Whether there is a problem with the safe area Whether the animation is naturally dark mode Whether there is a collapse At this time, the value of the app will suddenly become particularly large.
Because the real strength of the GUI agent is to begin to have "desktop context understanding".
I even feel more and more that the really mature Agent OS in the future may be: one runtime is responsible for cognition, and the other runtime is responsible for execution.
The current Codex App and CLI can already vaguely see this direction.