What is UIResponder Chain?

Ans : 

Apps receive and handle events using responder objects. A responder object is any instance of the UIResponder class, and common subclasses include UIView, UIViewController, and UIApplication. UIKit manages most responder-related behavior automatically, including how events are delivered from one responder to the next.

Example : 

For every event, UIKit designates a first responder and sends the event to that object first. The first responder varies based on the type of event. 

UIKit uses view-based hit testing to determine where touch events occur. Specifically, UIKit compares the touch location to the bounds of view objects in the view hierarchy. The hitTest:withEvent: method of UIViewwalks the view hierarchy, looking for the deepest subview that contains the specified touch. That view becomes the first responder for the touch event. 

If a touch location is outside of a view’s bounds, the hitTest:withEvent: method ignores that view and all of its subviews. As a result, when a view’s clipsToBounds property is NO, subviews outside of that view’s bounds are not returned even if they happen to contain the touch.

UIResponder Chain

• If the view is the root view of a view controller, the next responder is the view controller. 
• If the view is not the root view of a view controller, the next responder is the view’s superview. 
• If the view controller’s view is the root view of a window, the next responder is the window object. 
• If the view controller was presented by another view controller, the next responder is the presenting view controller. 
• UIWindow. The window’s next responder is the application object. 
• UIApplication. The app object’s next responder is the app delegate, but only if the app delegate is an instance of UIResponder and is not a view, view controller, or the app object itself.

What is AutoReleasePool?

Ans : 

In simple word, it is pool contained objects that will be released in some time.

Object's retain and release is constant action on object. For that Retain() and Release() methods called in objective c to control memory flow. As iOS objects work on retain count concept, it tells retain counts and it will be released if it reaches to 0.

Sometimes, we can not continuously use Release() method to release object.

Code for example :

 -(NSString *)getCoolLabel {

    NSString *label = [[NSString alloc] initWithString:@"SwiftRocks"];

    [label release];

    return label;

 }

    

Here label has 2 retain count and after return it has 1 retain count. It will be in memory as we can not execute release after return label; statement.

So solution :
return [label autorelease];
It will not release label instantly, but it inserts label in pool, and in some time, when autorelease pool thread execute, it

Note : Instead of instantly reducing the retain count of an object, autorelease() adds the object to a pool of objects that need to be released sometime in the future, but not now. By default, the pool will release these objects at the end of the run loop of the thread being executed, which is more than enough time to cover all usages of getCoolLabel() without causing memory leaks.

Whatever code that takes much memory we can add in autoreleasepool block.
I.e

@autoreleasepool {

           NSString *contents = [self getFileContents:files[i]];

           NSString *emojified = [contents emojified];

           [self writeContents:contents toFile:files[i]];

       }

Above all code written in objective - c, but in swift AutoReleasePool is required?

Yes, it depends on code.  It’s a different story if your code is dealing with legacy Obj-C code, specially old Foundation classes in iOS.

To put it short, autoreleasepool is still useful in iOS/Swift development as there are still legacy Obj-C classes in UIKit and Foundation that call autorelease, but we not have to worry where there is pure swift code.

How many times Viewdidload and viewDidLayoutSubviews called?

Ans : 

ViewDidLoad called once only when all views are loaded.

viewDidLayoutSubviews :  Apple gave a very good explanation on this by saying that it is called to notify the view controller that its view has just laid out its subviews.

In another word, viewDidLayoutSubviews is called every time the view is updated, rotated or changed or it’s bounds change.

But know that with viewDidLayoutSubviews, it only take places after all the auto layout or auto resizing calculations on the views have been applied. Meaning the method viewDidLayoutSubviews is called every time the view size changes and the view layout has been recalculated.

Read More : AppCoda

Which method will first called if I came from back button?

Ans : 

The navigation controller sends viewWillAppear: to a view controller before putting its view on the screen, and viewDidAppear: after.

Inside viewWillAppear: and viewDidAppear:, the view controller can check self.isMovingToParentViewController.

If isMovingToParentViewController is YES, the view controller is being added to the navigation controller in the first place (presumably because it's the navigation controller's root view controller, or because it is being pushed).

If isMovingToParentViewController is NO, the view controller is already in the navigation controller's stack, and another view controller is being popped to reveal it.

Which method called when I click on next, done button of keyboard?

Ans : textFieldShouldReturn

func textFieldShouldReturn(_ textField: UITextField) -> Bool {

     return false

}

What are UITextField delegate methods?

Ans : 

Copy from Apple Developer Site : Link

Managing Editing

func textFieldShouldBeginEditing(UITextField) -> Bool

Asks the delegate if editing should begin in the specified text field.

func textFieldDidBeginEditing(UITextField)

Tells the delegate that editing began in the specified text field.

func textFieldShouldEndEditing(UITextField) -> Bool

Asks the delegate if editing should stop in the specified text field. 

func textFieldDidEndEditing(UITextField, reason: UITextField.DidEndEditingReason)

Tells the delegate that editing stopped for the specified text field.

func textFieldDidEndEditing(UITextField)

Tells the delegate that editing stopped for the specified text field.

enum UITextField.DidEndEditingReason

Constants indicating the reason why editing ended in a text field.

Editing the Text Field’s Text

func textField(UITextField, shouldChangeCharactersIn: NSRange, replacementString: String) -> Bool

Asks the delegate if the specified text should be changed. 

func textFieldShouldClear(UITextField) -> Bool

Asks the delegate if the text field’s current contents should be removed.

func textFieldShouldReturn(UITextField) -> Bool

Asks the delegate if the text field should process the pressing of the return button.

Instance Methods

func textFieldDidChangeSelection(UITextField)