Spec-Driven Development for iOS: when programming feels like process engineering

TL;DR: if you come from process engineering, Spec-Driven Development does not feel that strange. At its core, it looks a lot like defining specifications, planning an intervention, executing with method, and reviewing before release.

This post comes from a video I published on YouTube: Spec driven development para iOS siendo ingeniero de procesos.

The underlying question is personal: how do you build quality software if you do not come from software engineering?

I am a chemical engineer and have worked for almost 14 years in process engineering. I have written Python, I understand some architecture, and I have been learning tools along the way, but I was not trained as a traditional software developer. So when I think about building an iOS app, I am not only interested in “making it work”. I want to build with method.

That is where Spec-Driven Development comes in.

The familiar act of specifying before building

In process engineering, a specification is not decoration. It defines what a product, a part, or an operation must satisfy to be acceptable.

There are limits. There are criteria. There is documentation. There is review.

If something deviates, it is not enough to say “it mostly works”. You need to understand what changed, why it changed, and whether it is still within the acceptable range.

When I look at Spec-Driven Development from that perspective, it stops feeling like a software trend and starts feeling familiar.

A feature can also be treated like a process artifact:

• it has an intention;
• it has constraints;
• it has acceptance criteria;
• it has risks;
• it needs implementation;
• it needs review.

The material is different. Instead of nylon, catalysts, or plant variables, we work with code, interfaces, states, and data.

But the mental pattern is not that far away.

Building apps without starting from chaos

One of my biggest concerns while learning iOS is starting from outdated practices.

iOS evolves quickly. Swift changes. SwiftUI matures. Xcode incorporates new tools. What was a good decision a few years ago may now be deprecated or, at least, not the best starting point.

That is why, in the video, I try to build a modern template for iOS projects with Spec-Driven Development.

The goal is not to have a nice-looking folder. The goal is to have a repeatable environment:

• an up-to-date Xcode setup;
• SwiftFormat for formatting;
• SwiftLint for rules;
• XcodeBeautify to make builds easier to read;
• GitHub CLI for publishing and repository work;
• UV for installing Python tools;
• Spec Kit to organize specifications;
• MCP to connect tools into agent workflows;
• a documentation structure that defines how the work happens.

In other words: I do not want to learn iOS by accumulating loose code. I want to build a working system.

Agents with roles, not one “chat that does everything”

The most interesting part for me is separating responsibilities between agents or models.

A reasonable flow could look like this:

1. Planner / Specifier: a stronger model, such as Opus, helps clarify, specify, and plan.
2. Implementer: a faster model, such as Sonnet, executes one task at a time.
3. Reviewer: a stronger model reviews judgment, concurrency, edge cases, and quality.
4. Second opinion: eventually Codex/GPT can act as an external reviewer.

This also feels a lot like engineering.

The person defining the criteria, the person executing, and the person reviewing do not have to occupy the exact same mental role. Separating those functions lowers the risk of mixing intent, implementation, and validation into one confusing mass.

The agent does not replace judgment. But it can help sustain a more disciplined workflow.

Spec Kit as scaffolding

Spec Kit interests me because it does not stop at “write a better prompt”. It proposes scaffolding:

• a project constitution;
• feature specifications;
• implementation plans;
• smaller tasks;
• review criteria;
• repeatable structure.

That matters to me. When you do not come from software engineering, structure helps. Not because you want to become rigid, but because you do not want to depend only on inspiration or intuition.

In process engineering, something similar happens: a good methodology does not replace experience, but it prevents every problem from being attacked from zero.

The goal: apps for process engineers

All of this is not just about learning Swift for the sake of learning Swift.

I am thinking about an application that helps solve process engineering problems. There is a lot to explore there: diagnosis, variable analysis, case documentation, decision support, problem tracking, and tools for day-to-day plant work.

The opportunity I see is combining three worlds:

• real process engineering experience;
• modern iOS development;
• AI agents as support for specifying, building, and reviewing.

I do not know yet what the final shape of that app will be. But I do know that I want to build it on a more serious foundation than “open Xcode and see what happens”.

Closing

Spec-Driven Development interests me because it translates something I already respect from process work: before intervening, understand; before building, specify; before releasing, review.

Maybe that is the bridge I needed.

Not between chemical engineering and software as two separate worlds, but between two ways of doing the same thing: building systems that work better.

More to come.