Before you whip out your snarky comments, I know -- this is a nooby question. This is my first time using a C based language.

I'm an undergrad student learning Objective C for a computer science course on mobile development. I know that, in an academic setting, a lot of real-world considerations aren't necessary since you're building smaller projects, work in smaller teams, etc.

But our professor demands -- and XCode supports -- .h header files for every .m implementation file. To me, it kind of seems like busy work. I have to make sure I copy every method signature and instance variable over to the other file. If I change one file, I have to make sure it's consistent with the other file. It seems like just a bunch of small annoyances like that.

But I know there has to be some real-world use for header files. A great answer would address both:

  1. What is a header file useful for that an implementation file isn't suited for? What is its purpose?
  2. Why do we as programmers have to manually write our header files? It seems like they could easily be generated automatically.

Thanks in advance!

  • Does XCode support automatic refactoring so that if you change a signature in the header it is automatically propagated to the implementation (and vice-versa)? Or maybe there is a plugin that supports that? I know it's a pain to do manually. Oct 20, 2011 at 15:32
  • My first reaction when I learned about header files was "there's gotta be a way to do that automatically". I was pretty puzzled when I tried searching for a tool that would assist with that and didn't find any great, obvious choices. Oct 20, 2011 at 15:45
  • I'm surprised such functionality doesn't exists. I know Eclipse can do such refactoring for Java, I don't know if the C/C++ plugins can do header/impl refactoring. I guess if no such tool exists for XCode, it might be something worth developing. ;) Oct 20, 2011 at 15:49

4 Answers 4

  1. In short;

    • The header file defines the API for a module. It's a contract listing which methods a third party can call. The module can be considered a black box to third parties.

    • The implementation implements the module. It is the inside of the black box. As a developer of a module you have to write this, but as a user of a third party module you shouldn't need to know anything about the implementation. The header should contain all the information you need.

  2. Some parts of a header file could be auto generated - the method declarations. This would require you to annotate the implementation as there are likely to be private methods in the implementation which don't form part of the API and don't belong in the header.

Header files sometimes have other information in them; type definitions, constant definitions etc. These belong in the header file, and not in the implementation.

  • But when would someone be in a situation where they needed to use my code, but only had access to the .h file? Wouldn't they still need the .m to run it? Oct 20, 2011 at 15:37
  • 1
    I understand the need for abstraction on a theoretical level, in case you change implementation details, but I'm just not sure when a situation like this would arise. Oct 20, 2011 at 15:38
  • 10
    Sometimes, usually for commercial reasons, you might want to allow someone to use your code, but not have access to your implementation. In this case you would provide a header file and either library or object code which has already been compiled. Oct 20, 2011 at 15:39
  • Ahh, I see. Hadn't considered the code would already be compiled, thus usable but not readable. Thanks! Oct 20, 2011 at 15:41
  • 3
    Also, why would I want to read the implementation to know how to use your code? It should be enough to read the header file. Oct 22, 2011 at 15:13

The main reason for a header is to be able to #include it in some other file, so you can use the functions in one file from that other file. The header includes (only) enough to be able to use the functions, not the functions themselves, so (we hope) compiling it is considerably faster.

Maintaining the two separately most results from nobody ever having written an editor that automates the process very well. There's not really a lot of reason they couldn't do so, and a few have even tried to -- but the editors that have done so have never done very well in the market, and the more mainstream editors haven't adopted it.


Including a header allows your code to call functions or methods which are written elsewhere and which may or may not be a part of your software project/build, but which can be found by the 'linker' when you are building the software.

For instance, when you call a function in the standard C library then you don't want to have to put all the innards of that function inside your project - you simply expect your program to be able to call it.

But your compiler needs to be told that the function exists somewhere even if it cannot see the code and the header does that. When the compiler is finished, the linker is called and it looks to 'link' those bits of your code that are left dangling, such as library calls.


Header files are mainly used to declare and include the signatures (i.e. function name, return value and arguments) of your functions in other files. The compiler needs to know these signatures when compiling and linking your files together.

Read this article for more information.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.