When you first open an Objective-C project in Xcode, the .h and .m files may look confusing. It’s important to understand the simple connections and the hidden code behind the scenes.

Welcome back to another episode of Continuous Improvement, where we explore different programming concepts and strategies to help you become a better developer. I’m your host, Victor, and today we’ll be diving into the world of Objective-C programming. Specifically, we’ll be discussing the structure of Objective-C projects in Xcode.

When you first open an Objective-C project in Xcode, you might find the .h and .m files a bit confusing. But fear not, understanding the simple connections and hidden code behind the scenes can help make it clearer.

Objective-C uses these .h and .m files to separate the public and private parts of a class. Think of the .h file as a header file, functioning like an API, where you declare public elements of your class. On the other hand, the .m file contains the private implementation.

To use functions from other files, all you need to do is import the .h file for referencing. It’s as simple as adding:

    #import <Foundation/Foundation.h>

Easy, right? Now let’s move on to the .h file. Here, you can declare public @property attributes of the class, which can be accessed from outside.

For example:

    @property (strong, nonatomic) NSString *something;

This line of code creates a pointer, @property, to an object of class NSString. The strong keyword means that the object will be kept in memory until the property is set to nil. Additionally, nonatomic indicates that access to this property is not thread-safe. If it were, the compiler would generate locking code.

Now, let’s explore the .m file. When you synthesize your @property, the “getter” and “setter” methods for that property are automatically generated for you behind the scenes.

It’s as simple as this:

    @synthesize something = _something;
    {
      return _something;
    }
    {
      _something = something;
    }

By default, the backing variable’s name is the same as the property’s name, but with an underscore prefix. You don’t need to write this code unless you want to override the method and customize its behavior.

Are you still following? Great! Let’s continue.

When you create a new method, you need to declare it in the .h file. The actual details of the method are then written in the .m file.

For example:

    - (int)calculateSomething {
      int num = 0;
      // Something happens in this method...
      return num;
    }

And there’s one more thing. If you have private declarations, you can include them in the .m file using:

    @interface Something()
    // Private declarations...
    @end

And that’s it! By understanding these fundamental concepts, you can start making sense of the code structure in Objective-C projects. Remember, when reading unfamiliar code, looking at the .h files gives you an overview, but if you need to delve into the details, check out the .m files.

Well, that brings us to the end of today’s episode. I hope you found this dive into Objective-C project structure helpful. As always, keep improving, stay curious, and happy coding!