Difference between .xcodeproj and .xcworkspace, and when to use a workspace
Tests your mental model of Xcode build containers. A project defines one buildable unit; a workspace groups multiple projects so they build together and share derived data. Use it for package managers or modular codebases.
What's really being asked
This question checks whether you understand the structural hierarchy of Xcode's build system and how Apple organizes code, targets, and dependencies. A senior engineer should know that a workspace is not just a convenience feature but a mechanism for cross-project dependency resolution and shared build artifacts.
The full answer
First, define an xcodeproj as a single project document that contains targets, build settings, schemes, and references to source files and resources. Second, define an xcworkspace as a container that aggregates one or more xcodeproj files and optionally other workspaces, establishing a shared build directory so that projects can discover each other's build products. Third, explain the when and why: you need a workspace when using external dependency managers like CocoaPods or Swift Package Manager because they inject additional projects that must build alongside your app, or when you manually split a monolithic codebase into separate framework projects to improve build times and modularity. Fourth, mention that opening a workspace rather than the underlying project is essential because the workspace context provides the derived data path and scheme visibility for all contained projects.
The mistakes people make
Saying that a workspace replaces a project or that you can delete the xcodeproj after creating a workspace. Another red flag is claiming workspaces are only for CocoaPods and have no native purpose in Xcode. Confusing schemes with workspaces or suggesting that a workspace merges the project files into one is also incorrect. Finally, stating that Swift Package Manager requires a workspace is wrong; SPM packages can be added directly to a project in modern Xcode versions, though workspaces are still common in hybrid setups.
What usually comes next
How does Xcode resolve build dependencies between two projects in the same workspace? What happens to derived data and build products when projects share a workspace? How would you migrate from a single project to a multi-project workspace without breaking CI? Can you nest workspaces, and when would that be useful? How do CocoaPods and SPM differ in how they integrate with workspaces?
A concrete example
Imagine you have an iOS app project and you want to extract a Networking layer into a reusable framework. You create a new framework project called Networking.xcodeproj and add it to MyApp.xcworkspace alongside MyApp.xcodeproj. You set the app target to link against the Networking framework. Because both projects are in the same workspace, Xcode builds Networking first, places the product in the shared build directory, and then links it into the app without requiring a prebuilt binary or manual search paths. If you opened MyApp.xcodeproj directly, the build would fail because the project file has no knowledge of the sibling framework project.
Interview question
What is the primary reason to open an xcworkspace instead of the underlying xcodeproj when your app depends on a separate framework project?
- a.The workspace is required because Swift Package Manager cannot work with raw project files
- b.The workspace merges the projects into one file for easier version control
- c.The workspace replaces the project file and overrides its build settings
- d.The workspace provides the shared build directory and dependency resolution contextCorrect
Why? this is the answer
The workspace establishes a shared build directory and dependency context that lets projects discover each other's products, which an individual project file cannot do. Option C is tempting because it sounds like a higher-level container might replace its contents, but a workspace always contains the underlying project files rather than replacing them.
Just read this? Test yourself on what you have been reading.
Read the original → developer.apple.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ios — each one lists the topics its interview covers.
See open roles