34

What are good ways of building groups/folders?

I've tried by feature (UI for a feature plus model etc) with a common group. I've also tried by UI, model, etc.

The former keeps like things together which fits the iPhone paradigm nicely. The latter means I jump around a bit more.

What do you think?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Scott McKenzie
  • 16,052
  • 8
  • 45
  • 70
  • I'm increasingly using VIPER now with a large portion of the structure using services (abstractions over API, system, etc) to contain logic. – Scott McKenzie Nov 01 '16 at 21:42

3 Answers3

24

The standard Xcode MVC folder structure is as follows.

  1. CoreData : Contains DataModel and Entity Classes.

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

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

  4. 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.

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

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

  7. Controller: Contain Logic or Code related to UIElements (eg. UIButton’s reference+ clicked action)

David Moles
  • 48,006
  • 27
  • 136
  • 235
Alvin George
  • 14,148
  • 92
  • 64
  • In MVC can i have storyboard? – Saranjith May 23 '17 at 06:17
  • Yes you can. We can group multiple storyboards in View based on different modules as well. – Alvin George Aug 17 '17 at 07:42
  • isn't `Services` ambiguous? – Mehdi Khademloo Feb 28 '18 at 03:56
  • Personally I suggest using the Uncle Bob approach from clean architecture. So, the structure and names should express business domains and not technical details and frameworks or pattern you are using. – Ali Abbas Jul 29 '19 at 16:00
  • Good idea, let's say in an application written in SwiftUI, is there a risk for the *View* to become cluttered for all the files responsible for different shapes, animations, etc. ? What would suggest that scenario? – Konrad Aug 08 '21 at 22:24
3

It's going to be very project dependent. In my last project I had mostly views, and so I organized the views by view-type.

John Smith
  • 12,491
  • 18
  • 65
  • 111
2

Organizing code by type

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

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.

It looks something like on A.G's & Julian B.'s answers.

Organizing code by feature (intent)

Organizing code by feature (intent) is the best practice for big projects and big teams.

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 greatest companies around the world.

Emm
  • 1,963
  • 2
  • 20
  • 51
  • 3
    Since I posted the original question back in 2010 - wow! I’ve been doing this for a long time - this is very close to what I do. The key difference would be that I engage the core or App fabric and make heavy use of xcframeworks. – Scott McKenzie Aug 14 '21 at 19:18
  • Glad to hear! @ScottMcKenzie if this answer helped you, or you find it useful, please mark it as answered with the green tick under the voting ✅ – Emm Aug 18 '21 at 09:45