100,000 Lines of Code in 7 Days: A Solo Developer's Hands-On Guide to AI-Assisted iOS Development

From Demo to Real Product: Where's the Gap?

Many people use AI to build apps, only to end up stuck at the "good enough to run" local demo stage—data lives only on the phone, with no login, no cloud, and no real user system. Bilibili creator Hedan shared a strikingly different case: he iterated an iOS app to 100,000 lines of code in just 7 days, actually shipped it, and gained real users.

100,000 lines of code is a significant milestone for a solo developer. Under traditional development models, maintaining a codebase of this scale typically takes an independent developer months or even years. The arrival of AI-assisted coding tools (such as GitHub Copilot and OpenAI Codex) has multiplied code generation efficiency several times over, but it also introduces the risk of "code bloat"—the volume of generated code far exceeds what the developer actually understands, making maintenance difficult. This is precisely the real-world backdrop for why this article repeatedly emphasizes "controlling the structure."

This isn't a toy project. The app he developed, "Pocket Chef" (口袋厨神), boasts a complete tech stack: a cloud database, a login system, subscription payments, and a full AI processing pipeline. Users can import cooking videos, and AI recognizes them and generates detailed recipes with rich text and images, where each step corresponds to a screenshot of the operation.

It's worth noting that Pocket Chef's monetization path relies on the App Store's subscription payment system. Since Apple introduced the auto-renewable subscription model in 2016, independent developers have been able to implement subscription payments through the StoreKit framework, with Apple taking a 30% cut in the first year, dropping to 15% from the second year onward. This mechanism provides a stable and predictable revenue stream for utility apps, and it's also the standard path for solo developers to achieve a business loop within Apple's ecosystem.

Even more advanced is the real-time voice cooking feature—when your hands are covered in grease while cooking, you can simply wake up "Little Chef" and use voice to switch steps, look up ingredients, and control the timer. Behind this feature lie multiple technical layers, including wake word detection, voice activity detection (VAD), automatic speech recognition (ASR), and text-to-speech (TTS). Apple's platform natively provides the SFSpeechRecognizer framework for speech recognition support, but achieving low-latency, hands-free, end-to-end voice interaction usually requires combining it with a persistent WebSocket connection to maintain real-time communication with the backend. Cooking scenarios are extremely sensitive to latency—when the user's hands are occupied, waiting more than 1-2 seconds for a response significantly degrades the experience, which places high demands on the engineering design of the entire voice pipeline. There are also features for inventory management, menu planning, and family sharing. This is already a fully-featured, commercial-grade product, not a practice exercise.

Core Methodology: Delegate the Frontend to AI, Control the Backend Yourself

Hedan's development philosophy is clear and practical, and it's also the most valuable core insight of this article: produce the frontend rapidly with heavy AI assistance, but design the backend logic entirely by hand.

The underlying logic of this methodology is closely tied to the frontend-backend separation architecture. Frontend-backend separation is the mainstream architectural paradigm in modern web and mobile app development—the frontend handles the user interface and interaction, the backend handles data processing and business logic, and the two communicate via APIs. Precisely because the boundaries are clear, developers can safely delegate "visual implementation" work like the frontend to AI while firmly retaining control over the backend's business logic design.

My development approach is very simple

He emphasizes that "grunt work" like frontend UI, interactions, and page iterations is very well-suited for AI. He often uses Codex and mentions that the new version is quite smooth to work with. But he also points out a counterintuitive principle: he doesn't just let AI churn out the frontend right off the bat.

The reason is simple: letting AI pile up the frontend first is like building a house without a foundation. His sequence is to think through the backend first—what data to store, which features go through which flows, where AI needs to be called, and what the final result should be. Only when the structure is sorted out does the AI-generated frontend have a clear integration target.

The essence of this approach is: AI accelerates only when humans control the structure. Think the logic through clearly, and AI merely helps you implement it faster—it doesn't make decisions for you.

The Three-Step Backend: Data Tables, Action Flows, AI Agents

For building the backend, Hedan used a visual low-code backend platform. He specifically clarifies this isn't an advertisement, but rather because it allows building databases, action flows, and AI agents in an intuitive way. He compared it to the industry-renowned Supabase, considering the latter "more suited to developers with a technical background," while the learning curve of a visual platform is far lower.

Background note: Supabase is built on PostgreSQL and provides open-source, self-hostable backend services covering databases, authentication, real-time subscriptions, and cloud functions, making it widely popular among technically-inclined independent developers. Pure visual low-code platforms (such as Xano, Backendless, etc.), on the other hand, have a core technical architecture that encapsulates relational database operations, REST API generation, and business logic orchestration into visual nodes, still running on standard cloud infrastructure underneath. These platforms trade away direct database access and some performance-tuning latitude in exchange for the extremely low barrier of not needing to write backend code—for solo developers who prioritize product delivery, this is a reasonable engineering trade-off.

Step One: Break Down the Data Structure

He first thinks through what data the project needs to store. Take Pocket Chef as an example: what the account table stores, what the recipe base info table stores, how each recipe links to multiple ingredients and steps, and how they relate to one another—break all this down clearly first, then add fields one by one. Good data modeling is the foundation of the entire system; the foreign key relationship design between tables in a relational database directly determines the complexity of subsequent business logic and query performance.

Table structure design on the data page

Step Two: Build the Action Flow

The action flow is the core of the entire architecture. It can be simply understood as: a user triggers an operation in the app, the backend flow launches immediately, passes through a series of nodes—making judgments, reading data, updating the database, calling AI—and finally returns the result to the frontend.

An action flow is essentially a visual mechanism for orchestrating business processes, sharing the same philosophy as workflow automation tools like Zapier, n8n, and Make. It connects user operations (triggers) with a series of backend actions into a directed graph, where each node represents an atomic operation. This model dramatically lowers the barrier to writing complex asynchronous logic (such as error handling, conditional branching, and concurrent requests) while keeping the flow readable and maintainable—which is why Hedan describes it as "like building with Lego, very modular." Compared to writing asynchronous backend code directly, a visual action flow makes every node of the business logic clearly visible, making it easier both to troubleshoot problems yourself and to describe modification needs to AI, such as "insert new logic at a certain step."

Take importing a cooking video as an example: the frontend only needs to pass in the video parameters, and the backend action flow first checks whether the user has sufficient credits. Once that passes, it calls AI to recognize the video and generate the recipe, then saves it to the database.

Building nodes in the action flow

Step Three: Integrate AI Agents

AI agents, used in conjunction with action flows, allow AI to access and manipulate data within defined boundaries. An AI agent refers to an AI system capable of perceiving its environment, autonomously planning, and executing multi-step tasks, distinct from a single-shot Q&A large language model call. Traditional LLM calls are stateless single-turn interactions, whereas an AI agent can autonomously decide which tools to call and in what order within a single task, dynamically adjusting subsequent steps based on intermediate results. In app development scenarios, AI agents are typically granted permission to access specific data tables and call specific APIs, autonomously deciding the execution path within defined boundaries—this "autonomy within authorized boundaries" is the core characteristic that distinguishes them from hard-coded logic.

He also calls external model services—this project's video recognition uses the Doubao model series (from ByteDance), which he believes has "genuinely excellent" video understanding capabilities. Doubao is highly competitive in the field of multimodal video understanding; its video frame sampling and semantic comprehension abilities make it well-suited for scenarios like cooking videos that require precise recognition of operational steps.

How to Elegantly Integrate Frontend and Backend

Once the backend is ready, frontend-backend integration becomes extremely clear. Hedan's approach is to organize the data table structures, field information, action flow IDs, agent IDs, input parameters, and other content, then hand them directly to the AI responsible for the frontend.

Integration approach with clearly defined return results

He directly tells the AI: "When the user clicks the recognize recipe button, call this action flow, pass in these three parameters, and update the page after getting the result." The entire project is completely transparent to the developer—which table the data is in, which flow is triggered on click, which AI is called in between, and what the final result returns—he always has it all in mind. This clear API contract is also one of the biggest advantages of the frontend-backend separation architecture: as long as both sides agree on the input and output data formats, frontend and backend development can be fully decoupled and advanced in parallel.

The Core Pitfall of AI Development: Turning the Project into a Black Box

The most valuable part of this sharing is Hedan's understanding of the essence of "AI-assisted development." He repeatedly emphasizes:

"If you don't understand the project at all and just throw requirements at the AI, once the project gets complex, you'll struggle to tell whether it made the right changes. Gradually, the whole project becomes a black box to you."

The "black box" problem is one of the most widely discussed core risks in AI-assisted development. The concept of Technical Debt was proposed by software engineer Ward Cunningham in 1992 to describe the architectural and code quality problems accumulated in pursuit of short-term development speed that must be repaid in the future. AI-assisted development introduces a more insidious new type of technical debt: Cognitive Debt—the code runs, but the developer's understanding of its internal mechanisms has fallen seriously behind the growth in code scale. In this state, adding any new feature or fixing any bug faces extremely high uncertainty, because you can't predict whether the AI's changes will introduce hidden side effects. When a system evolves into a "black box that no one truly understands," the project has actually entered an extremely fragile state—it might run today, but no one can safely modify it.

Hedan's methodology aligns closely with the software engineering concept of "Architecture Decision First": make architectural decisions before coding, ensuring the core logic stays within human cognition, while AI only serves as an accelerator at the implementation level.

The truly sustainable approach to AI development should be: think through the structure, sort out the logic, then let AI accelerate for you. AI is an accelerator, not a decision-maker. When you understand the project structure inside and out, adding features later won't leave you clueless—instead, you can precisely direct the AI and effectively review the results.

Of course, Hedan candidly admits this workflow doesn't apply to every project. In actual development, he also interspersed quite a few cloud functions, Vercel services, and standalone AI task processing modules.

Final Thoughts

From a locally-stored demo to a real cloud-connected product, what lies in between is not just technology, but a shift in development mindset. Hedan's case demonstrates that with the help of AI and low-code tools, an independent developer can absolutely deliver a commercial-grade application in an extremely short time. But the prerequisite is—you must first become the "master" of the project structure, not a hands-off boss.

In an era where AI can write code, where exactly does human core value lie? The answer perhaps lies hidden in that simple phrase: clarify the logic, control the structure, and let AI serve your thinking.