Best practice for an Xcode project groups structure?

Developers organise their groups, code, and files many ways. But I use something like the following:

• CoreData: Contains DataModel and Entity Classes.

• Extension: Contain One class(default apple class extensions+project class extensions.)

• Helper: Contain Third Party classes/Frameworks (eg. SWRevealController) + Bridging classes (eg. Obj C class in Swift based project)

• Model: Make a singleton class (eg.AppModel - NSArray,NSDictionary, String etc.) for saving data. The Web Service Response parsing and storing data is also done here.

• Services: Contain Web Service processes (eg. Login Verification, HTTP Request/Response)

• View: Contain storyboard, LaunchScreen.XIB and View Classes. Make a sub folder Cells - contain UITableViewCell, UICollectionViewCell etc.

• Controller: Contain Logic or Code related to UIElements (eg. UIButton’s reference+ clicked action) It could be replaced by ViewModel if MVVM is employed.

This structure is from another Stack Overflow post.

These may also help you:

1. http://akosma.com/2009/07/28/code-organization-in-xcode-projects/

2. https://github.com/futurice/ios-good-practices/issues/28

3. http://www.slideshare.net/MassimoOliviero/architecting-ios-project

I actually created a project to demonstrate what I consider my go-to Xcode project structure for a small or mid-sized code base. You can find it here.

Here's an outline of it:

• Source - All source code
  • Account - Account-related classes (session-related classes, account logic, etc)
  • Application - Application-related classes. App delegate, configuration classes, etc
  • Core Additions - Extensions and subclasses stemming from apple's classes
    • Utilities - General utility classes. Useful extensions, formatting utilities, convenience classes and such
    • Element-based folders - Folder for UIView, UITableViewCell, etc
  • Local Persistence - Local persistence layer. All interactions with local database (realm, core data)
    • Repositories - All model-related local persistence logic
  • Constants - All constants. URLs, fonts, colors, errors, etc
  • Models - All models (server-side entities' representation). We would also throw here any object mapping logic
  • Modules - Here we can find each of the application's pieces divided by functionality
    • Module-based folders - Each folder contains all module-specific view controllers, views, delegates and related classes
  • Networking - The app's networking layer (e.g. classes responsible for interacting with web services)
    • Services - All model-related web logic
• Storyboards - Contains all storyboard files
• Resources - Any additionaly resources like media, documents, localization files and such

When it comes to organizing files in a project, there are two most known ways. Organizing code files by type and by feature.

Organizing code by type

Organizing code by type is ok for small projects but it's not a good practice for big ones.

In this way, you put all Models in one folder, all Views in another folder, all Controllers in the third folder, etc.

Just imagine you have tons of files and folders organized by type, and when you work on a single feature, you have to open all of the folders. Which can confuse you and you can get lost many times while you scroll through files.

Something like this:

• AppDelegate
• View Controllers
  • Feature 1 VCs
  • Feature 2 VCs
  • Feature 3 VCs
• Models
  • Feature 1 Models
  • Feature 2 Models
  • Feature 3 Models
• Views
  • Feature 1 Views
  • Feature 2 Views
  • Feature 3 Views
• Extensions
  • Feature 1 Extensions
  • Feature 2 Extensions
  • Feature 3 Extensions
• Networking
• Resources

Organizing code by feature (intent)

Organizing code by feature (intent) is the best practice for big projects and big teams. You put everything related to the feature in a folder, and while you work on that feature, you don't have to open all other folders (groups).

Cause usually teams work on a single feature, and they focus only on a single folder or group of files. They don't necessarily have to know about other features and files.

It looks something like this:

• AppDelegate
• Features
  • Feature 1
    • View Controllers
    • Models
    • Views
    • Logic
  • Feature 2
    • View Controllers
    • Models
    • Views
    • Logic
• Networking
  • Models
  • Logic
  • Extensions
• Resources

Also, to mention, this practice and technique (organizing project by feature) are implemented by the biggest companies around the world. So, they divide their teams by the features of the project, each team works on a specific feature. Besides that, when you work with git, it reduce the chance of conflicts when merging and rebasing.