| < How do you return a value from a closure that takes no parameters? | Why does Swift have trailing closure syntax? > |
Why would you want to use closures as parameters?
Updated for Xcode 15
Swift’s closures can be used just like any other type of data, which means you can pass them into functions, take copies of them, and so on. But when you’re just learning, this can feel very much like “just because you can, doesn’t mean you should” – it’s hard to see the benefit.
One of the best examples I can give is the way Siri integrates with apps. Siri is a system service that runs from anywhere on your iOS device, but it’s able to communicate with apps – you can book a ride with Lyft, you can check the weather with Carrot Weather, and so on. Behind the scenes, Siri launches a small part of the app in the background to pass on our voice request, then shows the app’s response as part of the Siri user interface.
Now think about this: what if my app behaves badly, and takes 10 seconds to respond to Siri? Remember, the user doesn’t actually see my app, just Siri, so from their perspective it looks like Siri has completely frozen.
This would be a terrible user experience, so Apple uses closures instead: it launches our app in the background and passes in a closure that we can call when we’re done. Our app then can take as long as it wants to figure out what work needs to be done, and when we’re finished we call the closure to send back data to Siri. Using a closure to send back data rather than returning a value from the function means Siri doesn’t need to wait for the function to complete, so it can keep its user interface interactive – it won’t freeze up.
Another common example is making network requests. Your average iPhone can do several billion things a second, but connecting to a server in Japan takes half a second or more – it’s almost glacial compared to the speed things happen on your device. So, when we request data from the internet we do so with closures: “please fetch this data, and when you’re done run this closure.” Again, it means we don’t force our user interface to freeze while some slow work is happening.
SPONSORED Join a FREE crash course for mid/senior iOS devs who want to achieve an expert level of technical and practical skills – it’s the fast track to being a complete senior developer! Hurry up because it'll be available only until April 28th.
Sponsor Hacking with Swift and reach the world's largest Swift community!
