Heya, fellow dev with a C# background here! I also came into the iOS world from C#.NET wondering how all of this should be organized. Unfortunately, app development doesn't implicitly lead to the same level of modularization that may be enforced by various .NET standards, but that doesn't mean it isn't possible.
To elaborate further on what Eneko mentioned, some other notes:
- A Project may contain multiple Targets, and each Target results in a unique Bundle/Module. This means you could theoretically create a new Target for each "separation" of the library you'd like to create. (However, Packages are a better format for library modularization IMO.)
- A Workspace may contain multiple Projects and Packages. So right here, you can either separate with one Project and numerous Targets, or by multiple Projects all with on Target.
- A Swift Package may contain multiple Products, which are basically "output" Modules that can be consumed by your project (or other projects, if you decide to make your package external).
Basically, all I'm trying to elaborate on is that while .NET has more of a standardized way of separating modules into different projects (or even simply different namespaces), and also has a different level of access control (with the
protected keyword coming to mind), there are still ways to achieve what you're looking to do.
Personally, I prefer:
- Always having a Workspace unless I'm doing command-line (ie. Package-only) development.
- Having one Project for each "product". (eg. multiple apps in a monorepo should all have their own Project)
- Shared code within a Workspace should always go into a Package as they are much easier to manage these days than a shared Framework Project. Additionally, managing Target Membership is a nightmare and will lead to unnoticed issues and human error, so I avoid it at all costs.
There are plenty of exceptions to what I've mentioned above, and also probably some things I over-simplified, but if I were helping someone make the move from C#.NET to iOS/Swift development, these are the high-level "project structure" notes I would include.
Given the above info and comparison @karamba, do you have any additional questions or is there anything still unclear?