Basic ToDo App in Objective-C

This is my first app I have made after learning programming on iOS.
Most of the app is complete just the UI and some features are left to be added.

Any optimizations and coding practices would be very helpful.

The code can be found on my github repo

Download link for zip if there are some problems with github version:

Here are the main files

ACViewController.h

#import 
#import "ACAddTaskViewController.h"
#import "ACCategory.h"

@interface ACViewController : UIViewController 

@property (strong, nonatomic) IBOutlet UITableView *tableView;
@property (strong, nonatomic) NSMutableArray *tasks;
@property (strong, nonatomic) NSMutableArray *visibleTasks;
@property (strong, nonatomic) NSMutableArray *categories;
@property (strong, nonatomic) ACCategory *category;
@property (strong, nonatomic) IBOutlet UIButton *selectCategoryButton;
@property (strong, nonatomic) IBOutlet UIButton *addNewButton;
@property (strong, nonatomic) IBOutlet UITextField *addTaskTextField;
@property (strong, nonatomic) IBOutlet UIScrollView *menuBarScrollView;

@end

ACViewController.m

```
#import "ACViewController.h"
#import "ACTask.h"
#import "ACTableViewCell.h"
#import "MGSwipeButton.h"
#import "UIApplication+CoreData.h"

@interface ACViewController ()

@property (nonatomic) BOOL didSelectTaskForEditing;
@property (nonatomic) int selectedIndex;
@property (strong, nonatomic) NSMutableArray *arrayOfSortedDates;
@property (strong, nonatomic) NSMutableArray *dates;
@property (strong, nonatomic) NSDateFormatter *dateFormatter;

@end

@implementation ACViewController

-(void)viewDidLoad
{
[super viewDidLoad];

self.tableView.dataSource = self;
self.tableView.delegate = self;
self.tableView.estimatedRowHeight = 54.0;
self.tableView.rowHeight = UITableViewAutomaticDimension;
[self performFirstRunSetup];
self.categories = [[ACCategory fetchCategories] mutableCopy];
self.dates = [[ACDueDate fetchDueDates] mutableCopy];
self.tasks = [[ACTask fetchTasks] mu

There are a lot of things wrong here that I'm probably not mentioning at all. There is so much code that I instead want to focus on the big picture problems and the repeated problems (that you need to correct now and keep correct in the future as you write more code).

weak vs strong

IBOutlet properties should not be declared as strong unless you have good reason to do so. In fact, the same is true for all properties, but outside of IBOutlet properties and delegates, you usually have a decent reason to declare something as strong. But for IBOutlet properties, it is rare that you have a good reason to declare them as strong. The only time you ever need to even consider doing this is if the UI element you're referencing ever spends any amount of time without a superview.

Private vs Public

IBOutlet properties as well as IBAction method declarations never have any business belonging in the .h file of a view controller. Your view controller is in charge of controlling its views. No other class should ever be directly manipulating a view controller's view. And much like we should declare things weak unless we have a compelling reason to mark them as strong, we should default to omitting things from the public part of our class (the .h header file) unless we have a compelling reason to include them there. And when it comes to IBOutlets which should only be referenced by and modified directly by the view controller itself and IBAction methods which should only ever be called by the UIControl object that is hooked up to that action, these things should always be considered private to the view controller.

Single Responsibility Principle

Your classes are doing way too much. You have no real data model for your project, and that's resulting in part of this 'doing too much'. Your utility classes are missing and/or incomplete. You're importing a UIColor extension, but also manually creating other colors in this file--why don't you just put all of the colors you're going to use in extensions and call those extension methods (just as one example of how these classes could do less). But simply implementing actual data models properly will reduce a lot of this code.

StackExchange Code Review Q#120014, answer score: 5