Chapter 25. Threads
A thread is, simply put, a subprocess of your app that can execute even while other subprocesses are also executing. Such simultaneous execution is called concurrency. The iOS frameworks use threads all the time; if they didn’t, your app would be less responsive to the user — perhaps even completely unresponsive. The genius of the frameworks, though, is that, for the most part, they use threads precisely so that you don’t have to.
For example, suppose your app is downloading something from the network (Chapter 24). This download doesn’t happen all by itself; somewhere, someone is running code that interacts with the network and obtains data. Similarly, how does Core Motion work (Chapter 22)? The data from the sensors is being gathered and processed constantly, with extra calculations to separate gravity from user-induced acceleration and to account for bias and scaling in the gyroscope. Yet none of that interferes with your code, or prevents the user from tapping and swiping things in your interface. That’s concurrency in action.
This chapter discusses concurrency that involves your code in deliberate use of threading. It would have been nice to dispense with this topic altogether. Threads can be difficult and are always potentially dangerous, and should be avoided if possible. But sometimes that isn’t possible. So this chapter introduces threads, along with a warning: threads entail complications and subtle pitfalls, and can make your code hard to debug. There ...