Method for finding all classes
First and foremost, I must absolutely recommend against doing anything of this sort.  

If you want to know what classes are available in the scope, you need only look up at the imports you're making.  All of the imports will either be your own files, for which you should only really have one visible class per import, or they will be library/framework imports.  The library/framework imports are likely bringing multiple classes with them, but they should be well documented.

Anything that a program like yours does manage to find is going to fall into one of two categories:


Stuff we already know about anyway.
Stuff that's undocumented and we almost certainly shouldn't be using.


And perhaps more importantly, this is incredibly inefficient.  The difference between just looking at your source code and making this run-time check is, well, your check is happening at run-time.  But, what useful thing can you actually do with that knowledge?  None, really.

More importantly, when do you know to stop looking?  There's not a character limit to class names (as far as I know).  All we can do is check literally every character combination.  The math to figure out how many combinations we need to check is:

Number of characters = N
Maximum length = M
Minimum length = m


  (N^M) - (N^(m-1))


(roughly... I might be slightly off)

If we don't impose a minimum length, and we just want to check every combination with 8 characters, we have to check 248,155,780,267,521 combinations.  That's 248 trillion, and that's just for every combination of characters up to 8 length, so forget about discovering anything that starts with NSMutable which alone is already 9 characters long before we count the last part (Array, Dictionary, Set, Data, String, etc).

If I do 63^255 on the OS X calculator, it says simply "Infinity".  While that's not technically correct, it might as well be.  And I don't even know that 255 characters is actually any sort of limit on class name length.



But, with all of this said, a little multithreading can go quite a long ways.

With two threads working on this problem, you're checking twice as many strings per cycle.  With four, four times as many, etc.  All that is required is a strategy for effectively breaking your total workload into equal chunks of work for all of the threads to work on.

And it doesn't matter if you create more threads than your CPU can actively work on.  The overhead for creating threads is relatively low.  

What might make sense is to create 53 separate threads--one for each of the valid starting characters (class names can not start with numbers).  It's unlikely we'll be running this on a CPU that can simultaneously process 53 threads at a time any time soon, so this should be more than plenty to make sure we're getting maximum value out of our CPU.