Ans: When the app is calling for an API, and we need to perform a certain action after a task reaches completion, completion handlers come in handy. For example, when you are updating the UI for displaying the data from the API call. In Apple’s APIs, you can see the completion handlers, such as dataTaskWithRequest. They can be very convenient in your own code.
With 3 arguments that are NSData?, NSURLResponse?, NSError?, the completion handler takes a piece of code that doesn’t return anything. As they executed when the execution of the enclosing function, they must mark @escaping.
Ans: Following are the ways that are often used for the specification of the layout of elements in UIView.
Ans: It is almost clear from the name that synchronous is in order. In case you are performing the synchronous operation, everything that is supposed to take place after the operation must wait for it to be completed prior to proceeding.
On the other hand, asynchronous doesn’t have an order. When you perform a task asynchronously, you are allowed to run the next code without waiting. Eventually, the asynchronous process is going to happen. You can run on a different thread from the rest of the code. It is not difficult to reschedule it on the same thread later. You get notified when it is done.
Ans: Whenever autorelease is sent to an object, it is included in the inner part of the autorelease pool. After this pool gets drained, to every object in the pool, it sends a release message.
Autorelease pool blocks allow a mechanism due to which a user can let go of the ownership of an object but avoid the chances of its immediate deallocation. Usually, there is no need for you to create your own autorelease pool blocks. However, in some scenarios, you have to do it or it is in your benefit to do it. In Swift, the autorelease pool pattern is used when you want to return autorelease objects.
Ans: There are a few applications that use external libraries. For such applications, ABIs are essential. Suppose a program is designed to use a specific library and that library is updated after using it for some amount of time, you don’t want to re-compile that application. And, a user may not have the source do it.
In that situation, if the updated version of the library uses the previous ABI, then there is no need for the program to change. With Swift 5.0, ABI stability will be introduced. Once the ABI is stable, it will be persistent for the entire lifetime of a platform.