Escape from Tutorial Hell
by Sarah Reichelt
1st Edition, June 2025
Copyright © 2025 Sarah Reichelt.
Notice of Rights
All rights reserved. No part of this book or corresponding materials (such as text, images, or source code) may be reproduced or distributed by any means without prior written permission of the copyright owner.
Notice of Liability
This book and all corresponding materials (such as source code) are provided on an “as is” basis, without warranty of any kind, express of implied, including but not limited to the warranties of merchantability, fitness for a particular purpose, and noninfringement. In no event shall the author or copyright holder be liable for any claim, damages or other liability, whether in action of contract, tort or otherwise, arising from, out of or in connection with the software or the use of other dealing in the software.
Trademarks
All trademarks and registered trademarks appearing in this book are the property of their own respective owners.
License
By purchasing Escape from Tutorial Hell, you have the following license:
-
You are allowed to use and/or modify the source code in Escape from Tutorial Hell in as many apps as you want, with no attribution required.
-
You are allowed to use and/or modify all art, images, and designs that are included in Escape from Tutorial Hell in as many apps as you want, but must include this attribution line somewhere inside your app: "Artwork/images/designs: from Escape from Tutorial Hell".
-
The source code included in Escape from Tutorial Hell is for your personal use only. You are NOT allowed to distribute or sell the source code in Escape from Tutorial Hell without prior authorization.
-
This book is for your personal use only. You are NOT allowed to sell this book without prior authorization, or distribute it to friends, coworkers or students; they would need to purchase their own copies.
All materials provided with this book are provided on an “as is” basis, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and non-infringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software.
All trademarks and registered trademarks appearing in this guide are the properties of their respective owners.
Preface
Welcome to the first edition of Escape from Tutorial Hell.
When learning to code, everyone hits a block at a certain point. You’ve read books and articles, watched videos, done tutorials and courses. You feel like you know what’s being taught — the code is familiar and you can write small functions when told what the functions should do, but now what? How do you take that knowledge and use it to write a complete app? You’re stuck in tutorial hell so how do you escape?
This book aims to fill in that gap and take you from a person who knows the basics of Swift and SwiftUI to a developer with an app that’s ready to ship.
You do need to have that basic knowledge first. I’ll explain some code, but I’ll ask you to write some of it on your own, and I won’t always explain every line. This book is more about building an app than it is about learning to code.
I’m primarily a Mac developer, so the app we’ll build together in this book is a Mac app but the concepts and techniques I use are applicable to any Apple platform.
Every project in this book has been tested with macOS Sequoia and Xcode 16 using Swift 5.10. The Swift team released Swift 6 in 2024. The main focus of this update is strict concurrency checking, which can lead to some interesting errors and warnings. Since the default for new Xcode projects is still Swift 5, I have decided not to switch to Swift 6 yet. I think that the team needs more time to improve this and make it usable.
I hope you enjoy this first edition of Escape from Tutorial Hell.
About the Author
I got hooked onto trying to make computers do what I told them a very long time ago and have never stopped loving it. I’m a keen evangelist for developing native Mac apps. When not at my computer, I love coffee, puzzles, reading and cooking — the day hasn’t started until the first cup of coffee is drunk and the crossword is done! — Sarah
About the Language Engineer (Editor)
I’m a fan of words and the things you can do with them, and I’ve spent a decade floating between different forms of writing — academic, fiction, technical. I hope that in this book I’ve succeeded at easing the passage of ideas between Sarah’s brain and your own, and I ask only that you blame me for any typos, stray capitals, Australianisms, and unoxfordenised commas that have made it into the final manuscript. — Peter
Dedication
To Jack who persists in trying to teach his mother some computer science and to Jerry who was here at the start of this book but couldn’t make it to the end.
Introduction
Most books, articles, and tutorials issue a lot of orders: create this project, add that file, insert some properties, write some code. Usually, only the write some code section is explained in any detail, and even then, the explanations tend to be focussed on the details of the programming language. I know, because I’ve written those sorts of books and articles myself.
But knowing the nuts and bolts of programming doesn’t make you an app developer and this is why many learners get stuck in tutorial hell. They can understand the code snippets that have been taught and they can write functions to perform specific tasks, but there is a crucial gap.
It isn’t easy to sit down at your computer and create an app from scratch. There are a lot of decisions to make before you can start coding:
-
What app should I build?
-
What platform am I building for?
-
What frameworks and libraries should I use?
Once you start writing the code, there are even more decisions:
-
What do I write first — data or user interface?
-
How should I structure my data?
-
How should I lay out my code files?
-
What goes where in my project?
In this book, I am not going to concentrate on the code itself — there are lots of other resources for that, including my other books. Instead, I’m going to show you how to take an app from the original idea, through development and on to distribution.
First, you’ll configure Xcode so as to maximize your productivity and improve your workflow.
Then you’ll see how to design an app, before using various resources to learn how to code it.
Next you’ll look at ways to use Xcode more efficiently, we’ll discuss coding with AI, and finally, you’ll learn how to distribute your apps.
It is a very opinionated book - I’m going to teach you how I do things. Once you learn how I operate when creating or modifying an app, you’ll have the tools and knowledge to adapt those lessons to create your own style. But you’ll have escaped from tutorial hell and you’ll have the confidence to start writing your own apps.
What you need
To follow along with this book, you’ll need the following:
-
A Mac computer with an Intel or M series processor, running macOS 15 or later. Any Mac that you’ve bought in the last few years will do, even a Mac mini or MacBook Air.
-
Xcode 16 or later. Xcode is the main development environment for building macOS Apps. It includes the Swift compiler, the debugger and other development tools you’ll need. You can download the latest version of Xcode for free from the Mac App Store. Note: Xcode 16.3 has a bug that crashes any playground using JSON. You must use another version of Xcode 16 when running the playgrounds in this book.
-
A basic understanding of Swift and SwiftUI. If you’re new to Swift, you might want to read my macOS Apprentice book first: https://www.kodeco.com/books/macos-apprentice
Where to download the materials for this book
The source code for this book can be downloaded from the GitHub repository:
Click the link to open it in your browser. You’ll see a big green Code button. Click on that and on Download ZIP. This puts all the code files in your Downloads folder. Please download instead of cloning as this gives you a clean set of files, without my source control.
Depending on your browser settings, you may need to double-click the ZIP file to expand it. That gives you a folder containing one sub-folder for each chapter. The text of each chapter tells you when you need to use any of these files or folders, but every chapter that involves coding has a final folder showing the end result of working through that chapter.
How to read this book
Each section is designed to cover a particular aspect of development but they can each be read independently.
When you get to the code blocks, if the code is unfamiliar to you, then I strongly recommend that you type it in for yourself, rather than copy and paste it. Xcode’s auto-suggestions will help you, and having to get every detail correct will embed the new knowledge in your brain in a way that reading it can’t.
As you read, you’ll find boxes like this one where I ask you to perform a programming task. Please give it your best shot before looking up my solution. Writing code yourself is the only real way to learn. After trying, your code may be very different to mine - that’s fine! Test it. If it works, use your version. Coding is like any form of writing - everyone has their own style and while you can learn from others, you’ll never write exactly the way they do, but that doesn’t make either version wrong.
The downloaded material contains a folder for every chapter. For chapters that deal with coding or that have a task for you, the final folder will contain my solutions.
If you are using copy and paste for any of the code blocks, then go to Xcode’s Settings and in Text Editing → Indentation, turn on Re-Indent on paste. This will solve a lot of issues with the format of the text in the book differing from Xcode’s format.
This book is available as HTML, PDF or ePub. I recommend reading this book from the HTML version. It has good light and dark variations and the most accurate formatting. Also, the code blocks have a COPY button for when you want it, and there are no issues with pagination. My next favorite is PDF — use the light or dark version to suit your preference. If you’re reading either PDF, I suggest you use Preview or Firefox. Do not use Adobe Reader or Acrobat as they are unable to fully read the embedded fonts so will miss out some characters. My least favorite reading option is the ePub, as its display depends greatly on your ePub reader.
If you find any errors or typos, please report them to me at [email protected]. For problems with the code, please open an issue at https://github.com/trozware/escape_book_code/issues.
Section I: Configuring Your Tools
Before you can start any development work, you need to configure the tools and make sure that you are familiar with the important parts of these tools. When developing apps for any Apple platform, your main tool will be Xcode.
If you’ve learned any Swift you’ll have Xcode installed already, but in Chapter 1 I’ll take you through how I like to set it up.
The other important tool you’ll need is source control. Chapter 2 shows you how to use GitHub from within Xcode.
Chapter 1: Setting up Your Coding Environment
I assume you’ve done some coding tutorials or courses and have a basic understanding of Swift, SwiftUI and Xcode. It doesn’t matter if your knowledge is iOS-based - I’ll take you through the process of making an app more Mac-like in a later chapter.
In this chapter, you’ll configure your main Xcode window and some of Xcode’s many options. You’ll set it up to make your workflow more efficient and productive, and you’ll learn some important keyboard shortcuts. As an added bonus, you’ll find out how you can personalize the header at the top of every Swift file.
Xcode is the primary tool used for Apple development. It has a lot of view options, configuration options, and keyboard shortcuts, but don’t stress — you don’t have to learn them all.
Creating a Sample Project
I assume you have Xcode installed already, but if not, download it from the Mac App Store. When it runs for the first time, you only need the macOS components which are installed by default. Get the Predictive Code Completion Model too, if it’s offered to you.
Launch Xcode and create a new project using the macOS App template. Set the options for your project like this:
- Product Name
-
When choosing a name, always keep it simple with no spaces or non-standard characters - underscores or dashes are fine. You can change the display name of your app later, but keeping the project name plain makes some things easier in Xcode. In this case, use Xcode_Config as this project is for configuring Xcode and seeing the effects.
- Team
-
If you haven’t added an Apple ID to Xcode yet, Team shows an Add Account… button. I reset Xcode to start as if it was a fresh install, so that’s what I see now. If you’ve already added an Apple ID, leave Team set to None.
- Organization Identifier
-
You must enter an Organization Identifier. Every app has a bundle identifier, and when publishing in the App Store this must be unique. The conventional format is to use your domain name reversed as the organization identifier. Xcode uses this to create the bundle identifier by appending the product name.
For example, my domain name is troz.net, so I reverse that and enter net.troz into the Organization Identifier. Xcode then appends the product name to give a bundle identifier of net.troz.Xcode-Config. I’m not sure why it replaces my underscore with a hyphen, but that makes Xcode and the App Store happy :-)
If you own a domain name, use it here. If you don’t, you can make one up e.g. my.org. The domain does not have to exist.
For the rest of this dialog, set the following:
-
Interface: SwiftUI
-
Language: Swift
-
Testing System: None
-
Storage: None
Click Next and you get to decide where to save your project.
I like to use a folder called Developer in my user folder. Finder gives it a neat hammer icon and it’s a logical place to store your development work.
If you don’t have a Developer folder, navigate to your user folder and click New Folder to create it. Unselect Create Git repository on my Mac and click Create to create and save your project files.
Xcode opens with the default view for a new project:
As Xcode prepares the preview, you may see a message like this:
This is because you haven’t assigned a team yet, so click Open Anyway whenever you see this. You’ll fix it in a minute.
Tip
|
In Finder, locate your Developer folder and drag it into your Finder window sidebar for easy access in the future. |
Setting Up the Main Window
The first thing to do now is to make this window as large as possible. Full screen mode makes the menus harder to see and access, so I prefer to maximize the window instead. Mouse over the green blob at the top left of the window, and when the window resizing popup appears, choose the first Fill option to expand the window as much as possible. If you have a very wide screen, you may prefer to shrink the width, but keep the height as large as you can.
Note
|
I’ll be showing smaller windows in my screenshots for ease of reading, but I always work in a large window. |
Now that the main project window is large, you can make some more changes to increase your working space even more.
First, turn off the minimap. This is the view beside the code pane that shows a miniaturized version of your code for navigation purposes. It’s a neat implementation that shows more detail as you mouse over it, but in my opinion, if a file is long enough to make this valuable, then it’s too long and should be split into multiple files.
Go to Editor → Minimap and toggle this off.
The next thing to hide is the sidebar on the right. If you’re editing an AppKit or UIKit storyboard, then it’s important, but you don’t need it for anything else - its space is more valuable.
Click the Hide or Show the Inspectors toggle at the top right corner of the window, or press Option-Command-Zero to hide it.
Now you’ve got a large window with three vertical panes:
-
The navigators
-
The code editor
-
The SwiftUI preview
One final tweak before leaving this section. In the top toolbar, you may see a cloud icon with a blue dot. This is an Apple advertisement for Xcode Cloud. To get rid of it, click the cloud icon and then click Dismiss:
It keeps popping back, but this is how you can get rid of it, temporarily at least.
Now your project window looks like this:
Next to configure some settings…
Xcode Settings
Go to Xcode → Settings… or press Command-, to open the Settings window. There are a lot of settings here, grouped into tabs. I’ll take you through each tab, telling you the ones I consider important.
General
Most of the defaults are good on this tab, but there are two settings I like to change:
Turn off Show live issues
If you’ve used Xcode much, then I’m sure you’ve had the experience of starting to write a function and having Xcode complain because you haven’t finished it already:
Of course the function doesn’t return anything yet — I’ve only just written the declaration!
If you turn off Show live issues, then Xcode will wait and only report such errors when you build the project. This is a real quality-of-life improvement as your view is not continuously interrupted by warnings that you’re just about to fix anyway.
Note
|
You may have to quit and restart Xcode for this to take effect. |
Set File extensions to Show All
This may be the default, or it may copy it from Finder → Settings… → Advanced → Show all filename extensions which is another setting that I recommend you turn on:
Showing file extensions everywhere makes it easier to identify files in Finder and in your projects.
After making these changes, the General tab looks like this:
Accounts
Here’s where you can link the accounts needed for identifying you as a developer and for accessing source control.
The first one to add is your Apple ID. If you have an Apple developer account, that’s the one to use. If you don’t have a developer account, link your standard Apple ID. This is enough to get rid of the unidentified developer warnings but doesn’t allow you to publish apps on the App Store.
Click the + button in the bottom left and select Apple ID. Enter your credentials and any authorization code that Xcode asks for.
I’ve added two accounts: my personal Apple ID and my Apple developer account, and I’ve edited the description for each to make the distinction clear:
As you can see, the non-developer account (selected in the screenshot above) shows the team name as Sarah Reichelt (Personal Team). Normally, I’d only add my developer ID, but I want to show that you can use a standard Apple ID for the development stage.
To assign your newly added Apple ID to this project, click the project in the navigator - that’s the top entry in the list with the blue and white app icon.
This opens a tab called Xcode_Config.xcodeproj which is the project file. It’s actually a bundle where Xcode stores all the settings for your project. In the secondary sidebar, select Xcode_Config under TARGETS and then click Signing & Capabilities in the tab bar.
In the Team popup menu, select your Apple ID. I’m using my personal team ID for this project.
Wait a few seconds and Signing Certificate changes to Development:
Switch back to ContentView.swift and before you can make any changes, you may see codesign asking for permission to access your selected Apple ID. Enter your Mac’s login password and click Always Allow. If you click anything else, you’ll see a lot of this dialog!
You’ll probably get one more look at the dreaded unidentified developer warning, but then it will disappear from your life. Hurray!
Back in Settings → Accounts, you’ll add a source control account later, but for now, let’s move on.
Behaviors
This is an interesting tab where you can attach various actions and display changes to any of the Xcode events listed on the side.
I like to add a behavior for Running → Starts so it will switch to the debug navigator and make sure that the variables and console view pops up at the bottom of the window.
Select Starts in the Running section of the sidebar. Select the checkbox next to Show navigator and make sure that the popup is set to Sessions. Despite the name, this actually opens the Debug navigator.
On the next row, select Show debugger and set the popup to Variables & Console View:
To undo these changes when your app stops, select Running → Completes from the sidebar and set it to show the Project navigator. For the debugger, set it to Hide, and not If no output, hide. There’s always some output… :-)
Press Command-R to run the sample app and your window switches to the Debug navigator and shows the console:
The Debug navigator lets you see if your app is doing anything extreme with memory or CPU usage. If so, you can analyze further in the Instruments app, but this gives you a quick and useful overview.
Click the Stop button in the toolbar to quit the app and your Xcode window reverts to edit mode.
Navigation
The defaults here are all as I like them, but you should read the fine print to learn some useful keyboard shortcuts.
Themes
Here’s where you can really get creative in setting up your preferred editor theme. For the purposes of this book, I’ll be using Default (Light) with a slightly larger font, as that gives very readable screenshots.
If you swap between light mode and dark mode on your Mac, you can select a theme for each mode.
The Presentation themes are great if you’re giving a talk or screen sharing during a meeting, although you can also change the font size temporarily using Editor → Font Size or Command-Plus and Command-Minus.
If you want a completely new theme, search online for xcode themes. I found one at https://github.com/idleberg/Kimbie-Xcode, which also includes installation instructions.
To get to your Library folder, in Finder, open the Go menu and then hold down Option to make Library appear in the list. This is another folder that I like to drag into my Finder window sidebar for quick access.
If you like an existing theme but want to make a few tweaks, then I recommend making a copy first. Select your base theme and click the + button at the bottom left. Select the Duplicate option at the top of the popup menu and you get a copy that you can name and edit.
I frequently change my coding font - there are so many good monospaced fonts available and I enjoy the variety. Do a search for programming fonts and you’ll find lists of them, most of which are free to download and install. There’s also a selection of fixed width fonts pre-installed on your Mac.
It looks like it would be a big task to change the font for all the different components of the theme, but you can select multiples and set them all at once.
In this screenshot, I duplicated Default (Light) and named the copy Sarah (Light). Then I clicked one of the lines in the Source Editor section and pressed Command-A to select them all. After that, I clicked the button with the T icon to open the font picker and selected a font from the Fixed Width collection:
With that done, you can adjust individual components as well as the entries in the Console tab until you get the exact look you were after.
Text Editing
This is a settings tab with a lot of possibilities - so many that it has three sub-tabs! However most of the defaults are fine.
Display
There’s only one setting to change in the Display tab and that is to turn on the Code folding ribbon. This is useful for hiding blocks of your code to make the rest easier to read. It also helps you work out where certain blocks start and end, and allows you to cut and copy entire blocks as if they were a single line.
Editing
Most of the Code Completion options are already on, which is great. If you have Predictive code completion turned on, uncheck Suggest predictive completion while typing. For trimming the whitespace while editing, I like to turn on Including whitespace-only lines as well.
Indentation
Here’s where things get a bit controversial. Some people have very strong views on whether to use spaces or tabs and how many spaces to use.
The Xcode default is to indent using Spaces, so that’s what you’re going to do. This doesn’t mean you have to type multiple spaces to indent a line - when you press the Tab key, Xcode translates this into a set of spaces.
The Tab Width and Indent Width are both set to 4 by default. When I started writing for raywenderlich.com (now Kodeco), their style guide suggested using 2 to allow more text per line in books and articles. I found this awkward at first, but now it’s my preferred option, especially with SwiftUI, as it groups my code blocks more closely and makes it easier to see what is in which block.
I’ll be using 2 in this book and I recommend you give it a try, especially as the new swift-format tool uses 2 spaces by default.
The other change to make in this tab is to enable Re-indent on paste so that any code that you copy and paste into your project files is indented to match.
Key Bindings
For teaching purposes I never change these, and while working through this book I suggest you also stick to the default set.
As with themes, you can duplicate the default set and modify it while leaving the default unchanged. If you find yourself always doing something unexpected, like printing instead of refreshing the SwiftUI preview, then this would be a good reason to make some changes.
Source Control
This is a big topic that I’ll cover in detail in the next chapter, so ignore it for now.
Components
When you install Xcode, it includes the macOS platform by default and suggests adding iOS. You can choose the other platforms to add here by clicking Get next to any missing ones.
To delete any (except for macOS), right-click on the line and select Remove….
If your Mac is capable of it, here’s where you can install the Predictive Code Completion Model if you didn’t install it earlier.
Locations
Leave all these set to their defaults. They set where Xcode stores intermediary builds and archived projects, as well as setting the installed version of the Xcode command line tools.
Applying the Settings
Most of the new settings are applied immediately and automatically. Some, like Show live issues, seem to require you to quit and relaunch Xcode.
The one that you need to keep applying is the indentation. I am a fanatic about indentation — it’s such a useful tool in helping you work out the structure of your code.
Unlike some integrated Development Environments or IDEs, Xcode doesn’t have the ability to do this for you automatically on save, so you’ll have to do it manually from time to time. Now that Xcode includes a formatter, I use Control-Shift-I to re-indent and format all my code. This is also available from the menus, using Editor → Structure → Format File with 'swift-format'.
If you’ve accepted my suggestion to switch to a 2 space indent, then you’ll need to do this for every new file, as Xcode’s file templates are preset to use 4 spaces.
But with the settings you’ve applied, any code you paste in will be indented to your own preferences.
Keyboard Shortcuts
As you saw in the settings, Xcode offers a lot of keyboard shortcuts. I don’t expect anyone to remember them all, but learning to use a selection of them will really speed up your workflow and increase your productivity.
Here are the ones I use all the time:
-
Command-B: Build.
-
Command-R: Build & run.
-
Command-N: Open the template chooser for a new file.
-
Command-S: Save the active file.
-
Control-Shift-I: Re-indent and format using swift-format.
-
Command-/: Comment or uncomment the selected lines or the line containing the cursor.
-
Control-M: Format a long line onto multiple lines.
-
Option-Command-] & Option-Command-[: Move the selected lines up or down/
-
Command-E: Put the select text into the find boxes
-
Command-F: Find in the current file
-
Shift-Command-F: Find in the project
These are enough to get you thinking about shortcuts but here’s my technique for learning more:
-
If you find yourself using a menu item more than three times a day, take a note of its shortcut.
-
Next time you go to it, remind yourself of the shortcut, close the menu and press the keys instead.
-
After doing this for a few days, the keyboard shortcut will get embedded in your brain and you’ll do it automatically.
File Headers
This section is not essential, but it adds a nice level of personalization to your projects.
Look at the top of any of the .swift files in the project. When you create a file, Xcode adds a header that shows the file name, project name, your name and the creation date.
I don’t know about you, but to me, that’s a lot of wasted space for data that I can see at a glance in other places. The window title and the Project navigator both show the project name. The tab title shows the file name. I know who I am. So the only useful piece of data there is the creation date. I do find it interesting when opening an old project to see when I created various files.
Here’s how to change that header for every new file:
-
Close all projects and windows in Xcode and then press Command-N to make a new file.
-
Search for property and select the Property List file template.
-
Set the name of the new file to IDETemplateMacros.plist and save it to your desktop or any convenient location.
-
With the file open in Xcode, press Command-1 to show the Project navigator.
-
Right-click on the file in the navigator and select Open As → Source Code from the popup menu.
-
Replace the contents with this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>FILEHEADER</key>
<string> Created on ___DATE___.</string>
</dict>
</plist>
This is XML containing some standard header elements and then a dictionary. The only entry in the dictionary has the key FILEHEADER. Its value is set to a string which includes the ___DATE___ macro. Notice that it has a leading space — Xcode will add this to a comment line. Without the space, the text would start right after the comment marker:
-
Save and close this file.
-
In Finder, open your Library folder - use the Go menu with the Option key if you haven’t added this to the sidebar.
-
In Library, navigate to Developer → Xcode → UserData.
-
Drag your IDETemplateMacros.plist file into the UserData folder.
-
Back in Xcode, open the Xcode_Config project and use Command-N to make a new SwiftUI file called SubView.swift.
-
Check out the new, condensed file header:
If you’re interested in adding any more data to your file header, check out Apple’s Text macros reference page.
Project File Headers
This process sets the file header for every file you create using Xcode, but what if you have a project that needs a different header, maybe one with a copyright notice?
The file creation process is exactly the same - make a new property list file called IDETemplateMacros.plist and edit it to include your required data.
My new file contains:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>FILEHEADER</key>
<string> Created on ___DATE___.
// Copyright (c) ___YEAR___ Sarah Reichelt, TrozWare.</string>
</dict>
</plist>
Notice that you have to add the comment marker manually before any lines after the first one, and subsequent lines don’t need any leading spaces.
This time, instead of installing in it to your Library, you’ll add it to the project bundle:
-
Open the project folder and right-click on the .xcodeproj file.
-
Select Show Package Contents from the contextual menu.
-
If you don’t see a folder called xcshareddata, create one here.
-
Drag your IDETemplateMacros.plist file into the xcshareddata folder.
-
Now any new files made for that project will use your new header.
-
Files made in other projects will still use the header you added to the Library.
Summary
There are a lot of ways to configure Xcode. Some of them may seem largely cosmetic like themes or indentation levels, but anything that enhances the readability of your code will improve your productivity.
Other options provide more utility or quality-of-life improvements, and learning keyboard shortcuts is useful for any app that you use regularly.
As you work through this book, you’ll see that I stick to the settings I listed in this chapter, so you’ll find it more familiar looking if you use these too. After that, I encourage you to experiment with your own settings and find out what works best for you. There’s no wrong answer, so enjoy yourself trying out new themes, fonts and layout options.
Other Resources
-
macOS Apprentice - a book I wrote for Kodeco that will take you from a total beginner to someone who can write in Swift, SwiftUI and AppKit. This includes a chapter on installing Xcode and learning the basics.
-
xcode-themes - an old collection but it has some good ideas.
-
programmingfonts - a great page for trying out new fonts, with filters to make it easier to find what you’re looking for.
-
Xcode cheat sheet - keyboard shortcuts and other Xcode hints.
Where To Buy?
This is the end of the sample chapter. To purchase the complete book, go to Gumroad.