Whether it’s a new or an existing Xcode project, I always apply these changes immediately when I open it for the first time. I’ve been developing apps since 2009, and some of these changes prevent tech debt from day one.
Even though we should trust Xcode’s defaults, the reality is that a new project today still uses Swift 5 as a language version. This is just an example; there are quite a few other changes that I always make to ensure I’m not refactoring fundamentals in a few months. Let’s dive in!
New vs. Existing Xcode Projects
Before we dive into each individual change, I want to highlight that many of these changes might even be applicable to existing projects. In fact, some changes are properly applied to new projects now, but weren’t back in the days!
This is also why it’s important to stay up to date on the latest best practices. I can help you with this with videos on my YouTube channel (subscribe here), or you can wait for each WWDC to see what’s new.
Change 1: Enable Approachable Concurrency
Approachable concurrency is one of those settings you don’t want to leave to chance. Depending on your Xcode version, new projects may have it enabled by default, while older or existing projects often don’t. This creates inconsistencies in how concurrency rules are applied, leading to subtle bugs over time. In general, it’s essential for you as a developer to know this setting’s value for the projects you work on.
By enabling approachable concurrency and setting the default actor isolation to MainActor, you immediately establish a safer and more predictable foundation for Swift concurrency. It also makes your project more resilient to future Swift updates and encourages a consistent mental model from day one. You can learn more about this concept in my article Approachable Concurrency in Swift 6.2: A Clear Guide.
FREE 5-Day Email Course: The Swift Concurrency Playbook
A FREE 5-day email course revealing the 5 biggest mistakes iOS developers make with with async/await that lead to App Store rejections And migration projects taking months instead of days (even if you've been writing Swift for years)
Change 2: Review Upcoming Features
The “Upcoming Features” section exposes a list of experimental or soon-to-be-stable Swift features that you can enable early. Some of these features meaningfully improve your workflow, while others may still be too unstable for production use. The key is to choose intentionally rather than blindly enabling everything. Critical here is the Approachable Concurrency build setting, actually, since it automatically enables several upcoming features. If you don’t properly migrate, this can cause trouble in existing projects. (I’m showing this in action in my Approachable Concurrency video).
Before starting a new project, it’s worth checking the Swift Evolution proposals linked to each feature. Understanding what each item does helps you decide whether it’s a good fit for your codebase, especially in areas such as Swift concurrency, performance improvements, or type system enhancements. They are disabled for a reason, but they also exist for a reason!
Change 3: Switch to Swift 6
Even in a brand-new project, Xcode still defaults to Swift 5 for compatibility reasons. But if Swift 6 is available, switching to it early allows you to benefit from stricter concurrency checks, updated language rules, and modern APIs. This avoids painful migration work later, especially if your app grows in complexity.
For existing projects, migrating to Swift 6 requires more time and effort. Strict concurrency might surface issues that have been silently present for years. Still, making the switch as early as possible reduces technical debt and ensures your codebase stays modern and maintainable.
Change 4: Remove Unused Targets
Every new Xcode project includes extra targets like UI tests, even if you never plan to use them. These unused targets clutter the project and, at the very least, annoy me. Removing them early keeps your project focused and avoids confusion down the line. But most of all, using CMD + U to run tests will also run the UI tests that you don’t even use.
When deleting a target, you also need to remove the associated folder from the file system. This keeps the repository clean and prevents artifacts from lingering in your source control history. Small housekeeping steps like this compound into a healthier project structure over time.
Change 5: Fix General Build Settings
Several build settings deserve a quick review whenever you start a new project. Compilation mode should be incremental when debugging, while release builds typically benefit from whole-module optimization. Debug optimization levels should be set to none so the debugger remains reliable. I discuss these in detail in Build performance analysis for speeding up Xcode builds.
Change 6: Add an App Group Early
Adding an App Group later in a project is notoriously painful, especially once you add widgets, extensions, or other extensions. This pain mostly comes from having to migrate anything that’s inside your main target, which now needs to become available in those extensions. I’ve migrated Core Data databases into an app group and trust me: you don’t want to do that for an app that reaches millions of users.
Change 7: Establish a Folder Structure
A clean folder structure helps you navigate your project as soon as it grows beyond a few files. Even if you’re only starting with a simple prototype, placing views, models, and features into clearly defined folders saves time and reduces cognitive load later on.
Creating Swift packages early is another habit that pays off. They help you decouple features, improve modularity, and speed up build times in larger apps. A solid structure gives your project a sense of direction and makes future changes far easier to manage.
Obviously, this is something you do after you vibe coded your initial proof of concept. However, the earlier, the better, and it might even help your AI agents better understand your project’s structure!
Conclusion
Starting a new project is easy, but doing it the right way requires a bit more attention. These 7 changes I’ve collected over the years and are kind of my natural habit: I always apply them right away. Hopefully, they will now help you make fundamentally better projects that help you be successful in building apps.
Thanks!