Does it matter if there are unused functions that I nested in the large CoolFunctions.h / CoolFunctions.m file that was included in my project?
I want to create a large file for all the cool features that I find somehow reusable and useful, and put them in one file. Well, for a start, I don't have much of them, so I guess you shouldn't think too much about creating multiple files. I would use pragma labels to visually separate them.
But the question is: will these unused methods be somehow? Will my application explode or have less performance? Or is the compiler / linker smart enough to know that functions A and B are unnecessary and therefore don't copy their "code" into my resulting application?
a source to share
No, they will not directly affect your application. Keep in mind that all this unused code will make your file files more difficult to read and maintain. Also, writing functions that you are not actually using at the moment make it easy to introduce errors that won't become obvious until you start using those functions, which can be very confusing because you forgot how they are "written and probably assume they are correct because you haven't touched them for so long.
Also, in an object-oriented language like Objective-C, global functions should really only be used for exceptional, very reusable cases. In most cases, you should write methods in classes. I may have one or two global functions in my applications, usually related to debugging, but usually nothing else.
So, no, it won't hurt anything, but I'll avoid it anyway and focus on writing the code you need now, at this very moment.
a source to share
This sounds like an absolute architectural and supportive nightmare. In practice, you should never create a huge blob file with a random set of methods that you find useful. Add methods to the appropriate classes or categories. See here for information on the blob anti-pattern you are doing here.
To answer your question: no, methods that are never called will not affect the performance of your application.
a source to share
The code will still be compiled and linked to the project, it simply won't be used by your code, meaning your final executable will be larger.
I would probably split the functions into separate files based on the common areas they need to access, so I would have an image function library separate from the string manipulation function library and then include whichever is relevant project in hand.
a source to share
I don't think using unused functions in the .h file will hurt you. If you compile all the relevant .m files containing unused functionality in your build target, you end up making a larger executable than required. The same happens if you include code through static libraries.
If you use a function, but you haven't specified the correct .m file or library, you will receive an error message.
a source to share