Stop Writing Bad AI Prompts: 7 Principles Every iOS Developer Should Know

  • Wednesday

Stop Writing Bad AI Prompts: 7 Principles Every iOS Developer Should Know

  • DevTechie
  • AI


Most developers blame the AI when the output is wrong.

The reality is usually the opposite.

If Claude(or any other agent) generates a ViewModel that violates MVVM, places networking code inside a SwiftUI view, or returns a 500-line file that ignores your architecture, the model often isn’t the problem.

The prompt is.

Modern AI models behave much more like junior engineers than search engines. The quality of the instructions determines the quality of the implementation.

After building production SwiftUI applications with AI-assisted workflows, these seven prompting principles consistently produce better code, fewer revisions, and significantly faster development cycles.


1. Be Specific

Vague prompts create vague code. Consider this request:

Build a task management app in SwiftUI.

This forces the model to make dozens of assumptions. Instead, remove the ambiguity:

Build a SwiftUI task management application using MVVM and Repository pattern. Persist tasks using SwiftData. Support categories, due dates, and completion status. Target iOS 26 and use the Observation framework instead of Combine.

The second prompt defines:

  • Architecture

  • Storage technology

  • Platform requirements

  • Feature scope

  • State management approach

The result is dramatically more useful. Specificity is the single biggest upgrade you can make to your prompts.


2. Provide Context

Context gives the model constraints.

Without context:

Create a color picker.

With context:

I am building a task management app for iOS 26 where users can create tasks with a title, description, due date, completion status, and a custom color. Each task can be assigned a color using a color picker, allowing users to visually organize and identify tasks more easily throughout the application. So build a reusable color picker component for the app.

The second version communicates:

  • Application domain

  • User behavior

  • Feature expectations

  • Future feature requirements

That context influences every design decision the model makes. Two sentences of context frequently outperform twenty additional instructions added later.


3. Define the Output Format

Most revision cycles happen because developers forget this step.

Instead of:

Explain SwiftData migrations.

Try:

Explain SwiftData migrations using:

A short overview.

A table comparing lightweight and custom migrations.

A complete code example.

Common migration mistakes.

Production recommendations.

AI models are exceptionally good at following structure when structure is provided.This is equally useful for documentation generation:

Generate:

Repository protocol

SwiftData implementation

Mock implementation for testing

Unit tests

File names for each component

You are no longer reviewing content. You are reviewing a specification.


4. Define the Audience

The same explanation can vary dramatically depending on who will read it.

For example:

Explain @Observable for an experienced UIKit developer moving to SwiftUI.

Produces a completely different response than:

Explain @Observable for a senior SwiftUI engineer familiar with Combine and ObservableObject.

The first explanation focuses on concepts.

The second focuses on implementation differences, performance implications, and migration strategies. Audience determines complexity. Complexity determines usefulness.


5. Give the AI a Role

Role assignment narrows the solution space. Instead of:

Review this SwiftUI code.

Try:

You are a senior iOS architect reviewing a production SwiftUI application that follows MVVM and Repository pattern. Identify architectural violations, performance issues, and testability concerns.

Suddenly the model evaluates code differently. Another example:

You are an App Store reviewer evaluating this implementation for privacy compliance.

Or:

You are a senior SwiftUI instructor creating teaching material for intermediate developers.

The role changes the lens through which the problem is solved.


6. Show Examples

Examples outperform descriptions. Suppose you want generated ViewModels to follow a specific pattern. Instead of describing it:

Use MVVM architecture.

Provide an example:

@Observable
final class GoalViewModel {
    private let repository: GoalRepository
    var goals: [Goal] = []
    init(repository: GoalRepository) {
        self.repository = repository
    }
    func loadGoals() async throws {
        goals = try await repository.fetchGoals()
    }
}

Then instruct:

Generate all future ViewModels using this structure.

This approach is called few-shot prompting. The model learns from examples much faster than it learns from instructions.

The same technique works for:

  • Coding style

  • Documentation format

  • Folder structure

  • Testing patterns

  • Naming conventions

Examples remove interpretation.


7. Iterate Instead of Writing Mega Prompts

Developers often spend fifteen minutes creating a giant prompt hoping for perfect output.

That approach rarely works.

This workflow is significantly more effective:

First Prompt

Create a SwiftUI dashboard for a goal tracking application.

Second Prompt

Extract business logic into a ViewModel and introduce Repository pattern.

Third Prompt

Add unit tests and replace callback APIs with async/await.

Fourth Prompt

Optimize for large datasets and improve accessibility support.

Each iteration improves the result. Each iteration adds precision. Three small refinements almost always outperform one massive prompt. AI-assisted development is an engineering feedback loop, not a one-shot request.


Putting Everything Together

A strong prompt usually contains all seven principles:

You are a senior iOS engineer building a production-ready task management application using SwiftUI for iOS 26.

Users can create tasks with a title, description, due date, completion status, and a custom color. Each task can be assigned a color using a color picker to improve organization and visual identification throughout the application.

The application must follow MVVM and Repository pattern principles and be designed for scalability, maintainability, and testability. Use SwiftData for persistence and the Observation framework for state management.

Return the response as:

Architecture overview

Folder structure

Data models

Repository protocols and implementations

ViewModels

SwiftUI views

Unit tests

Follow the coding style and architectural patterns demonstrated in the attached examples.

This single prompt provides:

  • Specificity

  • Context

  • Format

  • Audience

  • Role

  • Examples

  • An iterative foundation

That combination consistently produces higher quality output.


Conclusion 

Specific prompts create specific code. Context improves architectural decisions. Formatting reduces revisions. Roles improve perspective. Examples improve consistency. Iteration improves quality.

These principles apply whether you are generating SwiftUI views, designing application architecture, building AI-powered goal planning applications, or shipping production-ready iOS apps with Claude Code and Foundation Models.