Discussion on building iOS engineering framework elegantly and quickly

A concise and elegant iOS project directory can help the team improve development efficiency and make you code in a pleasant mood. On the contrary, a messy directory will make people irritable and reduce the team's development efficiency.

Do you feel the same way? You are welcome to share your feelings in the comment section.

First of all, I want to say:

• The engineering architecture described in this article is applicable to teams that develop pure code, as well as teams that develop using Storyboards;
• This article is applicable to apps built with traditional Tabbar+NavigationBar, as well as other non-traditional apps;
• This article is particularly suitable for new team members to understand the overall structure of the project and carry out rapid development

This article takes the company's FCS app as an example, the interface is as follows:

Main Interface

The company's projects are mixed Objective-C and Swift projects. For pure Swift projects and pure OC projects, the folders and class files may need to be modified by yourself. The Xcode project directory is as follows:

As shown in the figure above, I divide the project into 9 parts, GitHub address:

Models: Model data class, all custom data models should be placed here;

Views: view class. Another folder needs to be created for the function module. All custom view classes of function modules should be placed here under their own folders, except for third-party UI controls dragged in manually. Third-party UI should be placed in the Vendor folder;

Controllers: controller class. All controller classes are placed in this folder. If there is BaseViewController or BaseNavigationController, they can be placed in the Base folder (you can create a new Base folder in this directory). At the same time, the Storyboard of the corresponding functional module is also placed in this directory. It is more convenient to place the Storyboard here than in the View (our project initially created a new Storyboards folder in the Views directory to store all Storyboards. The disadvantage of this approach is that the corresponding Storyboard and the VC of the functional module are too far away, which is inconvenient to operate);

Resouces: Resource folder, where audio, video, pictures (webP format pictures or png background pictures with large memory space that only need one copy), fonts, animations and other resource files needed for the project are stored;

Util, some tool folders, such as Category folder of Objective-C, Extension folder of Swift extension class, Manager folder of singleton class management, etc.

Vendor, manually managed third-party libraries. The BookRoom module in the above picture is encapsulated as a framework and introduced in the form of a framework, so it is suitable to be added here. There are also some relatively light third-party libraries that can be manually dragged in and added. For example, our project has a third-party library DeviceUtil for obtaining the adapter model. For such relatively light libraries, try to use manual drag-in code management. After all, more frameworks in the project will affect the startup time of the app. The principle is explained in the speech of WWDC 2016 Session 406 - Optimizing App Startup Time;

Pods: An excellent third-party library management tool. For example, AFNetworking for network requests, SDWebImage for image loading, and other heavy third-party libraries can be automatically managed using Pods. Of course, you can also use Carthage to manage them. Which one to use is a matter of opinion. There are also many discussions about this on the Internet. Our company uses Pods, so we mainly use Pods.

Appdelegate and home page: Appdelegate and home page are the entrances to each functional module, so they are placed in the most conspicuous position at the top (for traditional Tabbar+NavigationBar App, the home page class file may be under the corresponding module);

Assets.xcassets, info.plist: This part is in the same directory as Appdelegate, but is placed at the bottom. This part is not operated very frequently. The pictures in Assets.xcassets can be added using the function module placement (New Folder, named after the module).

Seeing this, some people may think: Isn’t it good to divide a project directly according to functional modules, and then divide each functional module according to the MVC model? Take the following app as an example

The division is as shown below:

There is no difference between the two modes of building a project framework. It is meaningful to discuss them in specific situations. However, it is obvious that the second mode of dividing by functional modules is suitable for small team development (less than 2-3 people on the iOS side), so that each person is responsible for developing a module, which is very efficient. If the team is large, it is more suitable to adopt the first mode, which is more efficient. For example, someone is responsible for writing the network layer code, someone is responsible for writing the UI interface, and someone is responsible for the encapsulation and writing of the log class.

Some other tips:

The folder module should be named in English instead of Chinese, and the correct English name should be used instead of pinyin;

1. Capitalize the first letter of the name;
2. Don’t have too many folders, three at most;
3. To quickly locate a class file, place the cursor inside the class file and press command+shift+J to locate its specific location module.

Demo GitHub address