Building a high-availability App framework for iOS from 0 to 1

I have been building an iOS framework for a new project recently, and I have been thinking about how to build a highly available App framework and whether I can avoid reconstruction due to code quality issues in the later stage. I have taken over many "bad codes" in the past, with loose architecture, chaotic underlying structure, and lack of specifications, which led to different code styles when the team was developing. A clear project structure and good code specifications are the key to ensuring product quality. Let me share my architectural ideas below.

Architecture diagram:

Architectural principles: readability, maintainability, and scalability.

1. Thinking

To do something well, you should spend more time thinking than executing.

First, based on the product requirements and design drawings, build a product architecture in your mind:

1. What is the product positioning?

Social? Media? Games? Sports? Audio and video? E-commerce... You need to figure out what type of App you want to make. Different types of products require different technology choices. Here I am building a basic App architecture, on which you can expand social, e-commerce, audio and video, etc.!

2. Technology selection

Based on the current product demand and possible future demand (how do I know what the future demand will be? You can refer to competing products and use your imagination. If the product says, "We want to do IM text chat, only text! No audio or video, and we won't do it in the future!" If you believe in promises like this... the story that follows will be exciting... Hahahaha... So at this time you have to consider that there will be voice + video chat in the future. Don't be lazy when designing, and reserve some space. When the product goes back on its word one day, you can smile and deal with it calmly.

Let's get back to the topic and talk about technology selection. Usually, I will choose some popular and easy-to-use third-party frameworks, such as YYKit. YYKit is a large and feature-rich iOS component that includes basic services such as Model parsing, image loading, and caching. They are all designed based on Category, easy to use, and have higher performance than some old frameworks. Those who have used it all say it is good.

You can choose other frameworks based on project requirements. Search on GitHub and take a look at each one with many stars. It will give you some ideas.

Programmers can look conservative, but they must not be too conservative in their thinking.

2. Build the directory structure

As shown above, this is how I built the App directory structure, from bottom to top, using Pods to manage third-party frameworks, re-encapsulating the third-party frameworks for top-level use, minimizing the coupling between modules for clarity.

3. Encapsulation Basic Class

1. AppDelegate is the proxy of the application. It is entrusted with handling application-level events, including startup, exit, push, and other events, as well as callbacks from third parties such as IM and payment. This makes the code in AppDelegate huge and complicated, which is not conducive to reading and maintenance. Therefore, I added an AppDelegate+AppService category to handle business outside the life cycle. AppDelegate is used as the event entry, and the specific implementation directly calls the methods in the category for clarity.

2. Modules includes the functional modules in the application, which are divided and associated with entity folders according to the Tab bar at the bottom (the default is virtual, and you need to manually create entity folders and drag them in). The MVC mode is used in each module. Some people may ask why there are more Resource and Service folders. MVC is a design concept, not a dead routine of three folders. It can be appropriately increased according to actual needs. Here I choose to encapsulate data requests in Service and call VC to get data. As for why Resource is here, I think that when there are many levels of functional modules, each large functional module corresponds to many resources, which is convenient to use in the module. Of course, it can also be placed in the outermost Resource folder to create a corresponding module name. Here I choose to put the public ones in the outermost Resource, and the function-related ones in the Resource folder in the module, just for clarity.

3. The definition of Manager is a global basic service, which is usually implemented using class methods or singletons. It mainly includes the management and services of applications and users, such as network status monitoring, advertising page application introduction page, etc.; user quick login and logout operations and login status acquisition, etc. Just for clarity.

4. The Utils folder mainly contains global general tools, which come from the secondary encapsulation of third-party frameworks or self-written tool classes. In this project, I encapsulated AES encrypted network request tools, global Toast prompts, advertising pages, etc. Just for clarity.

5. The Base folder is used to store the base class of the project. The base class contains some customized content, such as page style, empty data page, etc. Using the base class to implement it can unify control, facilitate maintenance, reduce redundancy, and make it clearer.

6. The third-party folder contains some third-party class libraries and third-party encapsulation, such as third-party login, payment, IM, etc. I have not added any third-party framework to the project yet.

7. Global macros, as the name implies, define some global general macros. I define four here:

UtilsMacros defines some tool macros, such as obtaining screen width and height, system version, data type verification, etc.;

URLMacros defines the server interface address and environment switches;

FontAndColorMacros defines the global color value and font size. It is recommended to maintain a design specification with the designer. For example, define a main color macro MainColor with a color value of 0x333333. We use the MainColor macro as the background color globally. When the App is updated one day and the color value changes, we only need to change 0x333333. Other codes do not need to be changed. At the same time, it can also constrain the designer to a certain extent. Do not add a color casually. Very close colors should use one. If the designer is unwilling to maintain this specification, you can try to fight. If you can't win, you can only maintain it yourself, just for clarity.

ThirdMacros contains definitions related to third-party frameworks, such as keySecret, etc. Just for clarity.

8. Resource files. As mentioned above, I store some global resource files here. For functional modules, I put them in the Resource folder within the module. This is a personal preference and just for clarity.

9. CocoaPods is a dependency management tool for iOS projects. When developing iOS projects, it is inevitable to use third-party open source libraries. The emergence of CocoaPods allows us to save time on settings and third-party open source libraries.

The above is my basic architectural idea.