UITableviewDelegate and UITableViewDataSource Methods

Ans : 

UITableview's Delegate Methods :

The UIViewController in which UITableView you use must adopt the UITableViewDelegate protocol. Optional methods of the protocol allow the delegate to manage selections, configure section headings and footers, help to delete and reorder cells, and perform other actions.

Configuring Rows for the Table View

- tableView:heightForRowAtIndexPath:

- tableView:indentationLevelForRowAtIndexPath:

- tableView:willDisplayCell:forRowAtIndexPath:

Managing Accessory Views

- tableView:accessoryButtonTappedForRowWithIndexPath:

- tableView:accessoryTypeForRowWithIndexPath: Deprecated in iOS 3.0

Managing Selections

- tableView:willSelectRowAtIndexPath:

- tableView:didSelectRowAtIndexPath:

- tableView:willDeselectRowAtIndexPath:

- tableView:didDeselectRowAtIndexPath:

Modifying the Header and Footer of Sections

- tableView:viewForHeaderInSection:

- tableView:viewForFooterInSection:

- tableView:heightForHeaderInSection:

- tableView:heightForFooterInSection:

Editing Table Rows

- tableView:willBeginEditingRowAtIndexPath:

- tableView:didEndEditingRowAtIndexPath:

- tableView:editingStyleForRowAtIndexPath:

- tableView:titleForDeleteConfirmationButtonForRowAtIndexPath:

- tableView:shouldIndentWhileEditingRowAtIndexPath:

Reordering Table Rows

- tableView:targetIndexPathForMoveFromRowAtIndexPath:toProposedIndexPath:

Copying and Pasting Row Content

- tableView:shouldShowMenuForRowAtIndexPath:

- tableView:canPerformAction:forRowAtIndexPath:withSender:

- tableView:performAction:forRowAtIndexPath:withSender: 

UITableview's Data Source Methods : The NSTableViewDataSource protocol declares the methods that an instance of NSTableView that provides the data to a table view and allows editing of the contents of its data source object.

All the methods are described in the following.

Getting Values

- numberOfRowsInTableView: (Required)

- numberOfSectionInTableView:

- cellForRowAtIndexPath : (Required)

- tableView:objectValueForTableColumn:row:

Setting Values

- tableView:setObjectValue:forTableColumn:row:

Implementing Pasteboard Support

- tableView:pasteboardWriterForRow:

Drag and Drop

- tableView:acceptDrop:row:dropOperation:

- tableView:namesOfPromisedFilesDroppedAtDestination:forDraggedRowsWithIndexes:

- tableView:validateDrop:proposedRow:proposedDropOperation:

- tableView:writeRowsWithIndexes:toPasteboard:

- tableView:draggingSession:willBeginAtPoint:forRowIndexes:

- tableView:updateDraggingItemsForDrag:

- tableView:draggingSession:endedAtPoint:operation:

Sorting

- tableView:sortDescriptorsDidChange:

Tips : UITableViewDelegate has no any required methods.

What is p12 and pem file

Ans : 

p12 : .p12 is an alternate extension for what is generally referred to as a "PFX file", it's the combined format that holds the private key and certificate and is the format most modern signing utilities use. Same with alternate extensions are .PFX, .PKCS12 

pem : this is a container format that may include just the public certificate (such as with Apache installs, and CA certificate files /etc/ssl/certs), or may include an entire certificate chain including public key, private key, and root certificates. 

Convert from .p12 file to .pem file 

cdcd Desktop openssl pkcs12 -in pushcert.p12 -out pushcert.pem -nodes -clcerts

Difference between the atomic and nonatomic attributes?

Ans : 

Atomic property give guarantee that valid value will be return. But valid does not mean that correct value.

This also not mean that atomic property are thread safe. Different threads can attempt to read and write value at same time. So one of two value will be return - value before change or changed value.

So atomic property is suffering from performance hit due to locking and unlocking before and after get or set value.

Non atomic property has no guarantee regarding correct value, a partially correct value or may be garbage value.
This is not thread safe this enhanced speed of access property.

Atomic property lock while setting value,

While non atomic property does not lock while setting value. 

Class, Structs and Enum

Ans : 

Structs are value type, Class is reference type.
Structs are stored in stack, Class are stored in heap.

So, Structs are faster than class because of its memory management. (Read why stack allocation is more faster than heap)

Similarity between Class and Struct: 

Define properties to store values
Define methods to provide functionality
Be extended
Conform to protocols
Define intialisers
Define Subscripts to provide access to their variables

Only class can do:

Inheritance
Type casting
Define deinitialisers
Allow reference counting for multiple references.

When to use class and when to use struct?

--> When we want to maintain reference, then we should use class due to class is reference type. When not, we should use struct.

i.e 

Here's an example with a class. Note how when the name is changed, the instance referenced by both variables is updated. Bob is now Sue, everywhere that Bob was ever referenced.

class SomeClass {
    var name: String
    init(name: String) {
        self.name = name
    }
}

var aClass = SomeClass(name: "Bob")
var bClass = aClass // aClass and bClass now reference the same instance!
bClass.name = "Sue"

println(aClass.name) // "Sue"
println(bClass.name) // "Sue"

And now with a struct we see that the values are copied and each variable keeps it's own set of values. When we set the name to Sue, the Bob struct in aStruct does not get changed.

struct SomeStruct {
    var name: String
    init(name: String) {
        self.name = name
    }
}

var aStruct = SomeStruct(name: "Bob")
var bStruct = aStruct // aStruct and bStruct are two structs with the same value!
bStruct.name = "Sue"

println(aStruct.name) // "Bob"
println(bStruct.name) // "Sue"

So for representing a stateful complex entity, a class is awesome. But for values that are simply a measurement or bits of related data, a struct makes more sense so that you can easily copy them around and calculate with them or modify the values without fear of side effects.

Another theory for what to choose : 

Structs are preferable if they are relatively small and copiable because copying is way safer than having multiple references to the same instance as happens with classes. This is especially important when passing around a variable to many classes and/or in a multithreaded environment. If you can always send a copy of your variable to other places, you never have to worry about that other place changing the value of your variable underneath you.

With Structs, there is much less need to worry about memory leaks or multiple threads racing to access/modify a single instance of a variable. (For the more technically minded, the exception to that is when capturing a struct inside a closure because then it is actually capturing a reference to the instance unless you explicitly mark it to be copied).

Classes can also become bloated because a class can only inherit from a single superclass. That encourages us to create huge superclasses that encompass many different abilities that are only loosely related. Using protocols, especially with protocol extensions where you can provide implementations to protocols, allows you to eliminate the need for classes to achieve this sort of behavior.

The talk lays out these scenarios where classes are preferred:

• Copying or comparing instances doesn't make sense (e.g., Window)
• Instance lifetime is tied to external effects (e.g., TemporaryFile)
• Instances are just "sinks"--write-only conduits to external state (e.g.CGContext)

Latest version of iOS, Swift, XCode

Ans : 
As per today (18-Oct-2018),

Latest version of

XCode : 10.0
Swift : 4.2
iOS : 12.0
Mac OS : mojave 10.14
Objective C : 2.0

I am using XCode 9.3, Swift 3.0, iOS 11 and mac os as High sierra.

Swift Version History :

Date	Version
2014-09-09	Swift 1.0
2014-10-22	Swift 1.1
2015-04-08	Swift 1.2
2015-09-21	Swift 2.0
2016-09-13	Swift 3.0
2017-09-19	Swift 4.0
2018-03-29	Swift 4.1
2018-09-17	Swift 4.2