A thread is, simply put, a subprocess of your app that can execute even while other such 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 they use threads precisely so that you don’t have to.
For example, suppose your app is downloading something from the network (Chapter 37). This download doesn’t happen all by itself; somewhere, someone is running code that interacts with the network and obtains data. Yet a long download doesn’t prevent your code from running, nor does it prevent the user from tapping and swiping things in your interface. That’s concurrency in action.
It is a testament to the ingenuity of the iOS frameworks that this book has proceeded so far with no explicit discussion of threads. Indeed, it would have been nice to avoid the topic altogether. Threads are difficult and dangerous, and if at all possible you should avoid them. But sometimes that isn’t possible. So this chapter introduces threads, along with a warning: here be dragons. There is much more to threading, and especially to making your threaded code safe, than this chapter can possibly touch on. For detailed information about the topics introduced in this chapter, read Apple’s Concurrency Programming Guide and Threading Programming Guide.
You are ...