Capstone: A Complete Workflow From New Project to a Debugged, Profiled Build

This chapter puts the whole course to use in one continuous workflow: start a project, organize it, design a view, commit, find a bug, clean up the code, and then run and profile the result. Every step points back to the chapter that supplies its tool. It adds no new tools.

The Workflow, Step by Step

Step 1: Check Your Tools (Chapter 1)

Confirm your Xcode version before anything else, since menus and features move between releases. Chapter 1 named Xcode 27 as the latest version when this course was written.

Step 2: Create the Project and Its Repository (Chapters 2 and 8)

Create a new iOS app project. During setup, Chapter 8 noted a checkbox for creating a Git repository. Afterwards, identify the pieces from Chapter 2: the project, its app target, and the scheme with its Debug and Release configurations. Decide with anyone you work with which files go into version control, since Chapter 8 could not give a verified list.

Step 3: Add a Dependency and a Linter (Chapters 2 and 7)

Add SwiftLint as a package through File → Add Package Dependencies, or through its build tool plugin, which its repository describes as recommended for modern projects. Keep the default "Up to Next Major" rule unless you have a reason not to. Check the Package Dependencies in your project rather than assuming where Package.resolved ended up, because Chapter 2 could not verify that.

Step 4: Build a View and Preview It (Chapter 3)

Write the view below and open the canvas with Option + Command + Return. It contains a deliberate bug, a function that should total a list of scores but skips the first one. It is written to be valid Swift, but I did not compile it.

The preview should show a total of 50, not the expected 60, because the loop starts at index 1. Notice that nothing crashes. That is the kind of bug the debugger is for.

Step 5: Commit the Starting Point (Chapter 8)

Stage and commit the project. In Xcode 15 and later you must explicitly stage changes before committing. Write a commit message that says the view has a known bug, so the history records it.

Step 6: Find the Bug (Chapter 4)

Run the app in the Simulator (Chapter 6) and put a breakpoint on the line sum += scores[index]. Make it conditional, so it stops only on the last iteration, then use the console.

You should see that sum is 50 on the final iteration and that the loop never used scores[0]. The fix is to loop over all indexes.

Step 7: Fix and Clean Up (Chapter 7)

Correct the loop, then use Refactor → Rename to give the function a clearer name, and Refactor → Extract to Method if you split it further. Run Product → Analyze, keeping in mind Chapter 7's caution that its coverage of pure Swift is unverified, and run SwiftLint. Commit again, and check the diff first.

Step 8: Run on the Right Target, Then Profile (Chapters 5 and 6)

Run on the Simulator for quick checks and on a real device for anything the Simulator cannot show. Then profile from a Release build with Product → Profile. For a screen this small, Time Profiler would show little, and that is a result too: it tells you there is nothing to fix. For a real app, use Allocations to watch Persistent Bytes while repeating an action, and Leaks with its Cycles & Roots view, remembering Chapter 5's note that Leaks may miss a cycle that a live object still references.

Which Chapter Supplied What

What This Course Did Not Cover

• Xcode Cloud in depth (see iOS Development — Production & Publishing 9).
• Testing tools such as Swift Testing and XCTest as Xcode features (see iOS Development — Architecture & Data 6 and 7).
• The coding agents and Device Hub that Apple's page lists for Xcode 27.
• Storyboards, and any Interface Builder workflow beyond its history.
• Newer instruments such as the SwiftUI instrument, which iOS Development — Production & Publishing 3 covers.

Hands-On Exercises