Swift

The monorepo from Version, Archive and Tag Each App in a Swift Monorepo ships two list apps that share packages, a Makefile, and one release process. A third app shows whether that structure holds up for something quite different. SpriteKit, Apple’s framework for 2D games, draws a scene of shapes and images many times a second, moves them with a physics engine, and reports when two of them touch. It comes with iOS and Xcode; there is nothing to install. ...

The monorepo from A Swift Monorepo with an Xcode Workspace and Local Packages builds two iOS apps from shared packages, but it cannot release them one at a time. Both apps report version 1.0, build 1. Their version numbers are typed into each project’s target settings, where a release would have to edit them in Xcode. Shopping has no display name of its own, neither app has an icon, and make archive keeps no record of what it shipped or when. ...

The to-do app from the earlier articles in this series lives in one Xcode project with one package beside it. A second app that needs the same code has two poor options: copy the files, or point a second project at a folder inside the first. A monorepo, one repository holding several apps and the code they share, avoids both, and an Xcode workspace ties it together: it lists projects and packages, opens them in one window, and builds them as one. ...

Pressing Run in Xcode hides a chain of decisions: which scheme to use, which targets to build and in what order, which build configuration, which device, where the output goes, and which of several hundred build settings apply. When a build behaves differently in Xcode than on the command line, or a setting you changed seems to do nothing, the cause is almost always one of those hidden choices. This article makes each one visible with xcodebuild, the command-line tool behind Xcode’s Run button, using the todo-list folder from Build a Swift Package with Swift Package Manager on macOS. You will read the project’s schemes, targets, configurations and destinations from the terminal; find where each build lands; see which build settings apply and where each value came from; and put your own settings in .xcconfig files, plain-text files of build settings that Xcode layers under the project’s own. Those files give Debug builds the name To-Do Dev on the simulator’s home screen and Release builds the name To-Do, so you can tell at a glance which configuration you are running. The Makefile grows a CONFIG switch, a settings make target that prints the settings that matter, and an archive make target that produces the Release build you would later sign and upload. Every later article in this series uses this Makefile. ...

The to-do app from Build Your First SwiftUI App on macOS keeps its model inside the app target. That works for one app, but nothing else can use the code, and its unit tests can only run by building the whole app and booting an iPhone simulator. This article moves that model into a Swift package: a folder of Swift code described by a Package.swift file, which Swift Package Manager (SwiftPM, the build tool that ships with Swift) can build and test on its own. You will create a library package named TodoKit, move the TodoItem model and its five unit tests into it, and run those tests on your Mac with swift test in about a second, with no simulator. Then you will add the package to the Xcode project as a local dependency, so the app imports TodoKit instead of owning the model. The finished project runs the package tests and the UI test from one make test, and the app still shows the to-do you saved in the first article, read from the same database by code that now lives in the package. ...

Many first SwiftUI tutorials stop once the app appears in Xcode’s preview canvas. That leaves out the parts you need before an app is real: data that survives a relaunch, tests that prove it, and a way to build and run the whole thing without clicking through the IDE. This article builds a to-do list app for iPhone with SwiftUI, Apple’s declarative UI framework, and SwiftData, Apple’s framework for saving Swift objects to an on-device database. The result is an Xcode project that you build, test, and launch in the iOS Simulator with three make commands. Its test suite includes a UI test that adds a to-do, quits the app, relaunches it, and checks the to-do is still there. You will run that test, then open the app and see the saved item yourself. ...