I have encountered this problem over and over either in interviews or during my development. When would you want to use weak or unowned in swift.  To dig deeper into this issue lets first understand what ARC stands for and what its purposes are. If you are a savy apple developer and have started working with ARC you know the painful days of calling release and managing our own memory. Well ARC, Automatic Reference Counting does exactly what it stands for. It counts each reference as your objects are created and decrements the count as they are destroyed and no longer in use. Drumroll.. here is where Strong and weak come into account. As you create an object you increase the reference count by 1 and therefore are creating a strong reference. In Objective-C you create strong references overtime you instantiate a new object, calling self in a closure, or when you copy or add an object to an array. 

The following example all illustrates the way to create strong references in objc and swift
        var strongObject:AnyObject? = nil  
        var closure:((Void)->Void)? = nil

When the closure is called self is called inside the closure a strong reference is created to the closure

        closure{ self.begin()} 
Same applies in objective c when using blocks and calling self within the block.  
  strongObject* strObj =  [strongObject alloc]init] 
             strongObject* strObj =  [strongObject copy]
             strongObject* strObj =  [strongObject new]
             NSMutableArray* arr = [NSMutableArray alloc]initWithObject:strObj]

The responsibility of ARC is to watch when the reference count goes to 0 and at that time deallocate your object.  In Objective-C
      we have weak , retain, copy.  The real purpose of using weak is as follows: In cases of calling self in a closure the closure holds a strong reference to self and self hold a strong reference to he closure. ARC doesn’t know if you done using the object because there is now a retain cycle happening where one object points to the other object and the other object points to the first object. To break this cycle you add create the following:


 __weak self weakSelf = self; 



      In swift you do the following:


 closure{[weak self] in } 
   There is also another case where a retain cycle is created: When you create a class and have a child class that also has a strong 
   reference the child has a strong reference to the parent and vice versa. To break the cycle you do the following:


    @interface ParentClass
    __weak ChildClass* child; 


    class ParentClass{
    weak var childclass:ChildClass?
      There is one more case where strong references can cause a havoc. Whenever you create a delegate you want to make your 
      delegates weak:


   @protocol someProtocol
   @required -(void)successData;
   @interface ParentClass



    protocol someProtocol:class{
       func successData()
    class ParentClass{
       weak var delegate:someProtocol?
 Now you ask when do I use Unowned in swift?  remember that swift has optional values which are values that can be nil. If you  use [weak self]. The self inside the block is an optional , if you were to use [unowned self] then the self is a non optional. For other uses  just replace weak with unowned where every weak is used.In summary you learned about ARC and when to use weak and unowned. Please let me know if you have any suggestions or comments


     Have you heard that MVC is not the best mobile design pattern ? The biggest reason is because it causes massive ViewController. It also doesn’t allow for separation of concerns. All the business logic, network api requests , and UI presentation logic is inside the ViewController. This is why people refer it as a massive ViewController. You ask yourself how to redeem this situation. You can opt to use either a different design pattern or create many classes to separate  the responsibility of each class. For example you can create a NetworkManager class that does all the network connection. You can create a Presenter class for UI Presentation logic and a controller that does all the logic and interacts with Model, NetworkManager.  Lets take a closer look at what MVC is before I get deeper describing how to create an MVVM architecture, let me explain what MVC is:


     MVC is divided into Model, View, and Controller. The Model is responsible to be container for the data and the data can be updated via the Controller. The View is just the screen that includes buttons, Views, and anything UI related. The Controller is the binding between the View and The Model. The Controller calls the network and gets the data and calls the model to update the data .  Once the data is received it reloads the view. The key point to remember is that the Model and The View never talk to each other. The communication between the Model and the View is through the controller.  I


     In the MVVM model the controller is subdivided into ViewModel and the View. In iOS we have a UIViewController. In the MVVM model we create a new class called ViewModel that contains all the calls to network and logic. All the presentation logic stays in the ViewController. Now you ask yourself how do I update the data in the ViewController.  This is achieved by binding the viewModel to the ViewController.

Binding between ViewModel and ViewController

     Create a reference in the ViewController for the viewModel. Then call the viewModel from the viewController. For binding you can either use closures and receive the data in a success closure or you can create a protocol inside the viewModel that has a method declaration : didSucceedWithData(data:Model). At this point make the  ViewController conform to that protocol. When the data is received the protocol method didSucceedWithData will be called and data will be passed. At this moment you can reload the tableview or the View.