Right now each file and folder is stored in an object I created (it contains the filepath, filetype, filesize, a pointer to an offset in the file, and if it is a directory), and those objects are placed in a NSMutableArray.
That's the correct solution. C arrays are trickier, since you'd have to handle size management yourself and you don't get bounds-checking.
A big problem with this is at the end of processing all the files, I need to get statistics for all the files in each folder. I am doing this using 2 nested for loops, and the performance is terrible.
Have you profiled using Shark and/or Instruments? That's the first thing you should check, if you haven't already. The bottleneck may not be where you think it is. Stop reading this answer (and any other answers) until you have profiled.
If you're currently blocking the main thread with this task, consider using NSOperationQueue instead. For each item in the top level, if it's a file, add an operation that examines the file, and if it's a directory, add an operation that will do the same iteration upon the directory's contents. If you can require Snow Leopard, you'll find blocks handy here, since you won't have to explicitly tell the directory-inventory operation which queue to add the examine-file operations to.
You should probably put a lid on the number of operations the queue will run at once, lest you end up running too many them. Mike Ash has details (that post is about GCD, but as of Snow Leopard, NSOperationQueue is based on GCD).
Assuming that you're displaying a running total in your UI, you can use the main queue to hold (possibly block-based) operations that add new information to the totals. If you're supporting Leopard, you can make your own “main” queue, but you'll have to make the operations run on the main thread yourself.
By the way, if you're totaling file sizes, you should consider whether want to uniquify on inode. If I hard-link a 200 MiB file into three other places, you'll see four files, but they're all really the same file, so they only take up 200 MiB, not 800.