A small cheat sheet on the UIViewController lifecycle - which methods are called, and in what order, during different transitions between UIViewControllers.

Controller A Pushes to Controller B

Call order during the transition:

1. initWithCoder:
   1. When a storyboard is used, this method is called instead of init or initWithNibName:bundle:
2. awakeFromNib
3. willMoveToParentViewController:
4. prefersStatusBarHidden
5. preferredStatusBarUpdateAnimation
6. loadView
   1. loadView assigns all outlets (IBOutlets) to the corresponding @property.
7. prepareForSegue:sender:
8. viewDidLoad
   1. All outlets are already connected, but the views have not been rendered yet
9. extendedLayoutIncludesOpaqueBars
10. edgesForExtendedLayout
11. viewWillAppear:
12. extendedLayoutIncludesOpaqueBars
13. edgesForExtendedLayout
14. updateViewConstraints
15. viewWillLayoutSubviews
16. viewDidLayoutSubviews
17. Animation
18. viewDidAppear:
19. didMoveToParentViewController:
20. updateViewConstraints
21. viewWillLayoutSubviews
22. viewDidLayoutSubviews

Some of the methods are called more than once. Layout is called twice - before and after the animation.

Controller B Pushes to Controller C

During the transition:

1. prepareForSegue:sender:
2. viewWillDisappear:
3. updateViewConstraints
4. Animation
5. viewDidDisappear:

Controller C Pops to Controller B

When returning from C to B, this happens:

1. prefersStatusBarHidden
2. preferredStatusBarUpdateAnimation
3. extendedLayoutIncludesOpaqueBars
4. edgesForExtendedLayout
5. viewWillAppear:
6. extendedLayoutIncludesOpaqueBars
7. edgesForExtendedLayout
8. updateViewConstraints
9. viewWillLayoutSubviews
10. viewDidLayoutSubviews
11. Animation
12. viewDidAppear:
13. updateViewConstraints
14. viewWillLayoutSubviews
15. viewDidLayoutSubviews

Controller B Pops to Controller A

Leaving B for good:

1. willMoveToParentViewController:
   1. The argument for this call is nil, which means that scene B will be removed from the hierarchy.
2. viewWillDisappear:
3. updateViewConstraints
4. viewDidDisappear:
5. Animation
6. didMoveToParentViewController:
   1. The argument is also nil
7. dealloc

Source.

I've been trying to come up with something that would make it convenient to do pixel-perfect screen layout while developing iOS apps. Something that would make it easy and visual to compare the mockup and the result. Today I hacked together this tool for OS X - an almost transparent window where you can open a mockup, place it over Xcode or the simulator, and see what you got. You can adjust the transparency with a slider to check how closely it matches.

Maybe it will be useful to someone. Or maybe someone else feels the same pain and will join the development.

The source code is on github.

Download the binary.

P.S. my first app for OS X.

I found a nice little thing on Stack Overflow. In Xcode's Interface Builder you can set some UI values through User Defined Runtime Attributes. I needed to set a border. You can set the layer.borderWidth thickness and it will be picked up, but the color will not. layer.borderColor stores a value of type CGColorRef, while the color you can choose in Interface Builder is a UIColor. A simple category lets you use UIColor through the layer.borderUIColor property.

CALayer+UIColor.h :

//
// CALayer+UIColor.h
//
// Created by Sergey Armodin on 29/05/15.
// Copyright (c) 2015 Sergey Armodin. All rights reserved.
//

#import <QuartzCore/QuartzCore.h>
#import <UIKit/UIKit.h>

@interface CALayer (UIColor)
/**
* CGColor to borderColor
*/
@property(nonatomic, assign) UIColor* borderUIColor;
@end

CALayer+UIColor.m :

//
// CALayer+UIColor.m
//
// Created by Sergey Armodin on 29/05/15.
// Copyright (c) 2015 Sergey Armodin. All rights reserved.
//

#import "CALayer+UIColor.h"

@implementation CALayer (UIColor)
/**
* Setter
*
* @param color UIColor
*/
- (void)setBorderUIColor:(UIColor *)color {
    self.borderColor = color.CGColor;
}

/**
* Getter
*
* @return UIColor
*/
- (UIColor *)borderUIColor {
    return [UIColor colorWithCGColor:self.borderColor];
}
@end

And voilà:

Released a new app - CompareShots.

While working, I had the thought that it would be nice to have some kind of tool for comparing the mockup and the actual result. I wrote this little tool in one evening. Then I spent a few more evenings making screenshots. Yeah, the screenshots took more time :)

The app lets you choose 2 images from the device library. For example, a designer's app or website mockup and a screenshot of what the developer built, and check whether it really matches pixel for pixel. While you keep your finger on the screen, the first image is shown. Take it away, and the second one appears. There is a transparency slider, so you can clearly see where things do not match. The mismatch result as an image can be shared, emailed, or sent to any other app that accepts images.

App for iPhone and iPad.

Cheat sheet. Tired of having to go hunt for it every time.

+ (instancetype)sharedInstance {
    static MyClass *sharedInstance = nil;
    static dispatch_once_t oncePredicate;
    dispatch_once(&oncePredicate, ^{
        sharedInstance = [[self alloc] init];
    });
    return sharedInstance;
} 

Cheat sheet for getting the weekday number from NSDate:

/* get the Gregorian calendar */
NSCalendar *gregorian = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar];
/* NSDateComponents lets you get the weekday number, day of month, etc. from NSDate. */
NSDateComponents *comps = [gregorian components:NSWeekdayCalendarUnit fromDate:[NSDate date]];
// get the weekday number. It will be from 1 to 7
NSInteger weekday = [comps weekday];

In iOS, depending on which region is selected in the device settings, the week starts either on Monday, as in Russia, or on Sunday, as in the US. If you only need to output the short name of the weekday, for example: Mon, Tue, Wed, Thu, you can do it like this:

NSDateFormatter *weekdayDateFormatter = [[NSDateFormatter alloc] init];
[weekdayDateFormatter setDateFormat: @"EE"];
NSLog(@"%@", [weekdayDateFormatter stringFromDate:dateFromString]);

I'll leave another cheat sheet in the form of a link. Network Link Conditioner is a tool from Apple from the Hardware IO Tools for Xcode set. It lets you limit connection speed in macOS. You can test, for example, how an app behaves under EDGE connections or worse. The same thing exists in the Developer section of iOS settings, but that is on the device, while this is in OS X.

By the way, the same set also contains a simulator for HomeKit.