According to Apple Documentation:
-[NSProgressIndicator usesThreadedAnimation]
When the value of this property is YES, animation of the progress indicator occurs in a separate thread. If the app becomes multithreaded as a result of an invocation of this method, the app’s performance could become noticeably slower.
Why? If the progress indicator implements animation in a separate thread, it won't block the main thread.
Is creating a new thread is more expensive than running animation in the main thread?
I suspect that this doc is referencing some old performance characteristic (e.g., perhaps result of introducing multithreading on single core CPUs; perhaps some pre-GCD issue, etc.). I wouldn’t sweat this old method documentation. Just benchmark it yourself, if you’re concerned.
But this method is 20+ years old and is an anachronism. It predates GCD, offering multithreading back when this stuff was very complicated. Nowadays we would just keep all UI (including progress indicator) on main thread, and put time-consuming work on a background queue, rendering this method moot.
You asked:
Is creating a new thread is more expensive than running animation in the main thread?
Creating a thread is, admittedly, a relatively expensive process. That’s one of the advantages of GCD, that threads are generally pulled from an existing pool of worker threads (eliminating some of that overhead).
That having been said, I am not sure if that one-time overhead of spinning up a new thread is the concern here, and as I suggested above, they may well have been focusing on some other legacy performance issue.
But, go ahead and follow modern practices: Keep the progress indicator on the main thread and move your time consuming process to some background queue, and you will be fine.