The Things about iOS App Development series takes a broader view, not just of the implementation of a specific feature or interface, but of the combination
Netease cloud letterFrom the perspective of how to optimize the existing code, I deeply analyzed how to create appropriate norms and frameworks for iOS App development.

Recommended reading

IOS App Development things 2: How to Build the Right framework

Grade code specifications properly

It is well understood that software development requires proper specifications: code specifications, program specifications, process specifications, etc., in order to reduce the number of surprises: the least surprising principle. However, in practice, there will be various situations, among which the biggest problem is: how to identify which specifications need to be enforced and which specifications are recommended.

Enforcing the specification makes the code more readable and less ambiguous, but the downside is obvious: it’s too rigid for most thoughtful programmers, and it tends to be resistant and destabilizing. This is often the case with standard outsourcing companies.

However, if most of the specifications are set as recommended implementation, the specifications can easily be ignored without good guidance. There are plenty of ObjC code specifications on the web, from Apple’s own specification to the Google Objective-C Style Guide. These specifications generally have only two grades: recommended and not recommended. I prefer to classify code specifications into five levels: mandatory, strongly recommended (but not mandatory), good, acceptable, and unacceptable.

The following are only some examples.

Naming in accordance with Apple specifications

  • Class names are capitalized and method and variable names are humped. Strongly, there is nothing to be said for this, as is the Case with the Apple System libraries and most third-party open source libraries. However, IN some Apple samples, I have seen the method of using m as prefix to express class member variables. These are problems of heritage code, which are still acceptable, but it is unacceptable to use Hungarian naming method in your own code.
  • Class names are prefixed with at least three characters, and inner methods are prefixed with two underscores. Highly recommended. The above approach minimizes duplication of names with the system libraries because Apple claims to reserve all two-character prefixes, and its internal method names are prefixed with an underscore.
  • Both K&R Style and Allman Style are acceptable ranges, but keeping one form within a file is highly recommended.
  • Keep code short and consistent while maintaining readability: small classes, small methods, and uniform function returns. Small classes, small methods make it easier for others to focus on class logic rather than details, and uniform function returns reduce accidental errors and ease error detection. If (count > 1) {return YES; if (count > 1) {return YES; } { return NO; }, really can not look at.

Good code/engineering structure

  • Create worksapce for the entire project.
  • Resource files are grouped by authority: each type of resource is stored in a separate directory: images, sounds, configuration files, and so on. Images can be stored in different subdirectories by type: global type, background image, logo, login, etc.
  • Reasonable code structure. The following project directory structure is recommended.


Core: some common mechanisms in engineering implementation classes: unified task management, module management, service management.

General: ViewController within public classes and methods, including engineering, UITableViewCell Base class (Base), public Category (Category), common UI components (CustomUI), public auxiliary method (Helper) and the macro definition (Marco).

Model: Common data Model

Sections: Different program units. Such as login, Settings and so on. It can be divided into subdirectories based on functionality: custom UI components used by the current unit, management classes, data models, ViewControllers, and so on.

Vendors: Third-party libraries.


The second article in iOS App Development will introduce you to what is the right framework and how to build the right framework. Please share your opinion and discuss with us.