iOS project directory structure

directory structure and development process for iOS projects

There are few resources on the Internet, and the open source and good quality iOS projects are few and far between, and recently I have worked with colleagues on an iOS project to say some of their ideas.

Directory structure

AppDelegateModelsMacroGeneralHelpersVendorsSectionsResources

A reasonable directory structure should first be clear, giving people a glimpse of the responsibilities of the catalog and the ability to respond to new changes.

Appdelegate

This directory is a AppDelegate.h (. m) file, which is the entry file for the entire application, so take it out separately.

Models

This directory has a number of data-related model files, presumably:

Models    |- BaseModel.h |- BaseModel.m |- CollectionModel.h |- CollectionModel.m ...

Macro

This directory gives the macro definition used by the entire application, presumably:

Macro    |- AppMacro.h |- NotificationMacro.h |- VendorMacro.h |- UtilsMacro.h ...

AppMacro.h app-related macro definitions, such as:

// 表情相关#define EMOTION_CACHE_PATH @"cachedemotions"#define EMOTION_RECENT_USED @"recentusedemotions"#define EMOTION_CATEGORIES @"categoryemotions"#define EMOTION_TOPICS @"emotiontopics"// 收藏相关#define COLLECT_CACHE_PATH @"collected"// 配图相关#define WATERFALL_ITEM_HEIGHT_MAX 300#define WATERFALL_ITEM_WIDTH 146

The NotificationMacro.h is a notification-related macro definition. In UtilsMacro.h, there are some handy macro definitions, such as:

#define UIColorFromRGB(r,g,b) [UIColor colorWithRed:r/255.0 green:g/255.0 blue:b/255.0 alpha:1]#define NSStringFromInt(intValue) [NSString stringWithFormat:@"%d",intValue]

VendorMacro.h Some third-party constants, such as:

#define UMENG_KEY @"xxxxx"#define UMENG_CHANNEL_ID @"xxx"

If you have a new type of macro definition, you can create a new related Macro.h.

General

This directory will be reused by views/classes and categories. It's probably like this:

General    |- Views        |- TPKScollView |- TPKPullToRefresh ... |- Classes |- TPKBaseViewController |- TPKHorizontalView ... | - Categories |- UIViewController+Sizzle |- UIImageView+Downloader ...

Here is the acronym for the TPK Project.

Helpers

This directory puts in some helper classes, with filenames linked to functionality. It's probably like this:

Helpers    |- TPKShareHelper    |- TPDBHelper |- TPKEmotionHelper ...

The main role of helper classes is to help controllers to slim down, but also to provide some degree of reuse.

Vendors

This directory puts third-party class libraries/sdk, such as Umeng, WEIBOSDK, WEIXINSDK, and so on.

Sections

The following files in this directory correspond to the specific elements of the app, such as navigation, waterfall flow, and so on. It's probably like this:

Sections    |- Menu    |- Setting |- Collection ...

Resources

This directory is a list of resources that the app will use, mostly pictures.

Cocoapods

A business-agnostic class library can be conveniently managed through Cocoapods, such as SDWebImage , and Reachability so on. There are also a number of applications will use the basic module, such as Hbapi, Hbsns, Hbfoundation (HB for the company first letter) and so on, you can build a private git repo, and then add to Podfile, so if the Hbapi is updated, only need to pod update Just a moment.

By the way HBFoundation , this git repository can put in some of the small modules that all of the apps you write will basically use. If a lot of apps are going to jump out of a alertview for a while, you can write a HBRating class, so the app that needs to use that feature just adds one sentence: [HBRating checkIfShouldPopupWithAppID:(NSInteger)appID] it's OK. Another example is that the app has the need to accept push notification, can write a HBAPNS class, and so on.

Development process

After getting the design diagram, you can draw out the reusable classes/views/helpers for the design diagram, consider the specific implementation of an effect, use the appropriate design pattern to avoid a large number of if/else nesting, and so on. Do not drill into the sections in a flash to achieve the page effect and function, it may seem faster at first, but as long as the complexity of the project, this approach will only eat the pain later, the code will become more and more difficult to maintain. So we must do a good job in the preparatory work.

Experience is limited, if you have a better idea, welcome to exchange:)

--eof--

iOS project directory structure