How to Choose a Name for Your Swift Project

By Jesse Feiler

You need to choose a name for your project and its targets. Actually, your project can have multiple targets, each with its own name. Name your project with a simple one‐word short name (eight letters or fewer) that doesn’t contain non‐letter or non‐number characters such as spaces, dollar signs, or tildes.

For later reference, here are a few of the options that you can consider as you are more comfortable with Xcode and app development.

The project is the overall collection of files that you are creating. It is contained within a folder that uses the project name. This name is for your benefit, so you can include abbreviations, department codes, or other shortcuts that you would not reveal to the public.

Be careful of the characters that are not allowed in Finder names such as / , ~, {, (, and spaces. (This list is not exhaustive.) It’s safest to stick to upper‐ and lowercase letters and numbers; limit special characters to dashes.

If you’re not certain about a character, create a file in the Finder and rename it with the name you’re thinking of: If the Finder changes the name automatically, you’ll know that you should use either the changed name or a more middle‐of‐the‐road name without special characters.

The project can contain multiple targets, each of which can be built with Xcode. One target may be a version of your app for iOS, and another may be a version for Macs. Still another may be designed for testing (the Xcode templates often create a testing target as a companion for your app’s target).

You can create several targets from the same basic files. (That’s a reason for using multiple targets: It’s easy to share the common files in the project.)

Another variation on this theme occurs if you’ll have several versions of your app — perhaps Your App Lite, Your App, and Your App Pro. A common strategy is to create Your App Lite as a free app, Your App as a priced app, and Your App Pro as a higher priced app. Multiply those three apps by two (for iOS and OS X), and you now are talking about building six apps. If you can write your basic functionality code once for all six apps, you’ll be far ahead.

Within a family of devices (iOS or OS X), the differences typically do not require separate apps. For example, you can build an iOS app that runs on both iPhone and iPad; you can build an OS X app that runs on MacBook Pro and iMac.

When you create a new project, you provide the name of the project as well as the name of each target. Review the App Store and Mac App Store ­guidance for naming conventions so that your names don’t confuse anyone. (Browse the App Store Resource Center on developer.apple.com for the most current information.)

Also, be aware that there are also restrictions on the ways you can promote Lite and Pro versions. In short, remember that every version of your app should give users a satisfactory experience rather than a sense of frustration when they are suddenly informed that they have to get out their credit card to type even one more keystroke.

In short, naming the user‐facing parts of your project — that is, the parts that normally become products — is a more critical and complex matter than naming projects or targets, whose names are visible only to you and other developers. (You have almost total control over the product name if you modify it in the Build Settings section of an Xcode target. Use the Build Settings section under Packaging, where you’ll find Product Name — which you can specify separately for debug and release versions.)

Stick with a simple short, one‐word product name for your first tests. Get into the complexity of naming products later on. The name of the project and the targets can be changed later. However, although changing the names is easier than it was in the past, it is often best not to do it if you can avoid it. Renaming can cause problems with bundles.