Blueprint

Every native app starts as a blueprint: the interface shaped in Swift, the screens arranged, the flow traced before the compiler is asked to agree. The blueprint is where the app’s character is decided.

Shape the interface in code that reads like intent. Names carry the design — a view named for what it presents, a state named for what it means. Swift’s type system is part of the blueprint; the compiler becomes a second reader of the design as you write it.

Design the flow on paper before wiring it. Which screens exist, how the user moves between them, where the app can be interrupted and resumed — these decisions belong to the blueprint, and they are cheaper to change there than in the running app.

Keep the blueprint lean. A screen that does not exist does not need a view, a state, or a test. The first pass should cover the app’s spine; the details earn their way in as the flow proves itself.