In the first article, I explained how I built an iPhone app in one weekend, from idea to App Store, with Claude Code and a lot of specs. That was the spectacular part of vibe coding: start from a personal problem, produce a real native app, and get it approved by Apple on the first try.
But a published app does not stay frozen. Once Pugify is available on the App Store, you have to maintain it. Fix the small details that get annoying. Improve onboarding. Strengthen privacy. Prepare release notes. Test on iPhone and iPad. Build an archive. Submit a build. Come back to the code three weeks later without having to reload the whole project into your head.
That is where my workflow really changed. The first article was about creation. This one is about continuity. Until recently, I mostly worked with Claude Code in Visual Studio Code on my machine. Since then, I have moved my environment to Codex. And that change moved another barrier: not "can I build an app?", but "can I keep this app moving properly, version after version, without becoming a full-time iOS developer?"
Real life starts after Apple approval
The first version of Pugify was already a real app. Weight tracking, meals, care routines, vaccines, PDF export, a StoreKit 2 Tip Jar, no server, no analytics, no data collection. I wrote about that in My first vibe-code: from idea to App Store in a weekend. At that point, what impressed me most was speed.
What impressed me next was maintenance.
Version 1.0.2 focused on stability: more reliable weight tracking when creating a profile, cleaner text field handling, more accurate care and reminder calculations, safer PDF export, a stronger Tip Jar flow, and fewer unnecessary UI refreshes. It was not a huge marketing moment. It was the kind of invisible work that keeps a promising app from becoming painful to use.
Version 1.0.3 added a more sensitive layer: an internal lock to protect identification, health information and health record export with Face ID, Touch ID, or the device passcode. It also refreshed the visual direction, aligned Home, onboarding, care and health screens, updated icons, and reduced unnecessary calculations.
In other words, this was no longer "wow, an app exists" vibe coding. This was maintenance vibe coding. The kind where you need a clean branch, a sense of possible regressions, a release process, tests, documentation, publication, and enough context to resume later.
In my old workflow, that still felt scattered.
Before: a good agent, but a scattered workflow
Claude Code helped me enormously when I created Pugify. I do not want to rewrite history. Without it, I would not have produced a native iOS app that fast, with SwiftUI, SwiftData, StoreKit 2, local notifications, and unit tests.
But my working environment was still split across tools.
There was code in Visual Studio Code. There was Xcode for compiling, testing, and archiving. There was the terminal for Git. There was GitHub for branches, pull requests, and merges. There was App Store Connect for release notes, builds, metadata, and submission. There were side notes to avoid losing decisions. And there was me in the middle, connecting all those pieces.
The problem was not that each tool was bad. The problem was the friction between them.
When you are a professional developer, that friction almost disappears. You naturally know where to check a branch, how to read a diff, when to create a pull request, how to interpret a failed build, and how to avoid mixing a design refresh with a data-handling fix. When you are not a trained developer, each transition adds a small amount of mental load.
I could ask for code. I could ask for a fix. But I often had to become the dispatcher: "now test it", "now commit it", "now archive it", "now document it", "watch the release branch", "do not touch these files", "resume from this context".
Vibe coding works very well when the request is clear. It works less well when all the work around the code remains inside the user's head.
The shift: Codex as a work cockpit
Codex changed that feeling because it is not limited to answering in a chat window. In its documentation, OpenAI describes Codex web as an agent that can read, edit, and run code in a cloud environment, work in the background, and create pull requests from GitHub. The Codex app adds worktrees, terminals, files, the in-app browser, automations, and project instructions through AGENTS.md.
Put more simply: I am no longer only asking "write this component". I am handing over a work loop.
On Pugify, that loop looks like this:
| Step | Before | With Codex |
|---|---|---|
| Understand the repo | I reread files and notes myself | Codex reads the code, README, release notes, and Git context |
| Isolate the work | I created and tracked the branch manually | Codex works on a dedicated branch or worktree |
| Modify | I asked for code file by file | Codex proposes coherent changes across multiple files |
| Verify | I had to remember commands and simulators | Codex can run tests and report what passes or fails |
| Prepare the release | I wrote notes, PRs, summaries, checklists | Codex gathers changes and drafts release material |
| Continue later | I rebuilt context manually | Conversation context and project rules remain available |
The difference is subtle, but it is huge in daily work. Codex becomes less of a code generator and more of an assisted production environment.
I can ask it to create a branch, work on it, check what it changed, prepare a pull request, tell me what should be tested, review a release note, then resume another day. Code is no longer an isolated output. It is part of a complete workflow.
For someone like me, that was the missing link.
What changes for someone who is not a developer
The important point is not that Codex "codes better" in some absolute sense. That kind of comparison quickly becomes sterile. What changes is that Codex reduces the distance between a product intention and a shippable change.
I can phrase a request in terms of usage: "identification data is sensitive, I want to protect it inside the app". Behind that, someone has to think about LocalAuthentication, session state, masking when the app goes into the background, localized text, tests, and the user experience when Face ID is not available. It is not just a SwiftUI view.
I can also phrase a request in terms of feel: "onboarding is still too dense, and actions are poorly placed when the keyboard appears". Behind that, someone has to understand the screen hierarchy, navigation, safe areas, forms, validation states, and visual consistency.
Before, I often had to split those requests into technical tasks. With Codex, I can stay closer to the product level, then review and arbitrate. I do not disappear from the process. On the contrary, my role becomes clearer: explain the intention, reject what is wrong, validate what is acceptable, and preserve coherence.
That is why I find Codex particularly interesting for vibe coding. It does not remove the need to understand what you are building. It removes part of the technical handling that prevents many people from finishing.
A non-developer does not magically become an iOS engineer. They become able to steer a development system, provided they are precise, patient, and willing to verify.
The concrete workflow behind a Pugify update
Pugify 1.0.3 is a good example. It was not a tiny isolated fix. The release/1.0.3 branch grouped privacy, design, onboarding, navigation, health screens, assets, performance, documentation, and App Store metadata.
What changed for users:
- Identification, Health, and health record export sections can be protected with Face ID, Touch ID, or the device passcode;
- a privacy shield hides sensitive information when the app moves to the background;
- Home, onboarding, care, and health screens were visually aligned;
- the keyboard no longer overlaps onboarding actions;
- app icons and pug avatars were updated;
- vaccination, parasite treatment, and health advice lists are more stable;
- some screens recalculate less data during rendering.
What changed in the workflow:
- a release branch carried the changes all the way to GitHub PR #2;
- French and English App Store release notes were prepared and archived;
- App Store Connect metadata was documented without storing personal review contact details in clear text;
- iPhone 17 and iPad A16 simulator tests passed;
- a Release build and generic iOS archive were produced;
- the App Store Connect upload was retried outside the local sandbox after a local blocker;
- App Store publication was confirmed on May 6, 2026.
Taken separately, none of these points is magic. Together, they form a real delivery chain. This is where I see the difference between "having code generated" and "moving a product forward".
The most interesting part is that Codex can hold both levels at once. It can talk about SensitiveAccessManager, scenePhase, tests, and pull requests. Then it can rewrite release notes for a normal user who simply wants to know what changed in Pugify.
That bridge is extremely valuable. In a small indie app like Pugify, it is comfortable. In a small business, it matters even more: technical tools only have value when they remain connected to business usage, responsibilities, validation, and risk.
What Codex still does not do for me
There is a risk with this kind of article: making it sound like everything is now automatic. It is not.
Codex does not decide that a pug's identification data deserves a lock. That is a product decision. It does not decide that the app should remain account-free, server-free, and data-collection-free. That is a trust decision. It does not decide that the interface should feel softer, clearer, and less technical. That is a taste decision.
Codex also does not replace verification. When it changes an iOS app, I have to review. I have to test. I have to check that the result matches the intention. I have to accept or reject compromises. I have to keep an eye on what is sent to Apple.
The good news is that this responsibility becomes easier to carry. I do not spend my energy remembering Git syntax or reconnecting a broken technical thread. I spend it on more useful questions:
- does this change really improve the experience?
- should this data be visible without authentication?
- is this release note understandable?
- is this release worth publishing now?
- do I understand the diff well enough to stand behind it?
For me, that is the real shift. Codex does not remove my responsibility. It helps me carry it.
What vibe coding becomes
The first version of vibe coding felt like accelerated development. You wrote a spec, AI produced a lot of code, then you corrected until something usable emerged.
Vibe coding with Codex feels more like production collaboration.
It is no longer only about prompts. It is about branches, worktrees, project rules, tests, pull requests, documentation, sources, automations, and resumed context. The prompt still matters, but it is no longer alone. It sits inside an environment that knows where the files are, which conventions to respect, which commands to run, and which risks to watch.
This is close to what I build for companies with AI agents or workflow automation. The real question is not "does AI answer well?". The real question is: does it enter the actual work process, with the right guardrails, tools, and validations?
Pugify is a small iOS app. But the lesson goes far beyond Pugify. Many small business owners already have a form of vibe coding in their daily work: spreadsheets, patched-together automations, no-code tools, ChatGPT prompts, and scripts left behind by a contractor. The problem is not the desire to make things. The problem is turning that energy into a reliable system.
Codex gives me a concrete glimpse of that future: AI no longer just produces a piece of code. It supports the delivery loop.
Sources consulted
Sources consulted on May 14, 2026:
- Codex web, OpenAI Developers documentation
- Worktrees in the Codex app, OpenAI Developers documentation
- GitHub code review with Codex, OpenAI Developers documentation
- Project instructions with AGENTS.md, OpenAI Developers documentation
- Automations in the Codex app, OpenAI Developers documentation
- Codex for almost everything, OpenAI, April 16, 2026
Conclusion
The first article ended with a simple idea: vibe coding does not turn anyone into a developer. It turns someone who knows what they want to build into someone who can build it.
After the Pugify updates, I would add one nuance: Codex also turns someone who has built something into someone who can maintain it.
That is not a small thing. Creating an app in one weekend is exciting. Evolving it properly, publishing versions, documenting changes, keeping quality high, protecting data, checking builds, that is what separates a prototype from a product.
I still do not want to become a full-time iOS developer. But I now have an environment that lets me steer an iOS app with much less friction. And that deeply changes what I consider possible.
If you are thinking about integrating agents into your company, this is exactly the boundary to examine. Not only "can AI answer?". More like: can it enter your real workflows, work with your tools, respect your rules, prepare validations, and leave you in charge of the decisions?
That is what I build in my AI agent and workflow automation projects: not isolated demos, but systems that help real work move forward.
Also available: Read in French