Categories are an Objective-C syntax for adding features to a class without subclassing it and without even having access to its code (its .m file).

This comes in handy when you want to keep using a specific class (for example NSString) but would like to add an extra feature.

We have seen categories before, when using the AFNetworking framework. UIImageView+AFNetworking is a category on UIImage that allows setting an image using a URL. It does this by adding methods to UIImage such as setImageWithURL: and setImageWithURL:placeholderImage:.

Categories have their own .h and .m files. These are usually named +. These can be easily created through the New File menu in Xcode.

Header Source

Categories can have their own methods and properties, but no instance variables. This means that properties must be implemented and cannot be synthesized.

Header Source

To use a category, we just need to import the header into the class where we need the additional functionality. This will make the extra methods available to use.


User Testing

After building and testing your app yourself, it’s always a good idea to have a select group of users test your app. These users should be representative of your target audience, and they will usually give you good insight on what works well and what doesn’t in your app. This is also a good way to find bugs as these testers will try to use your app in ways you didn’t anticipate.

To add a device for testing, it needs to be registered for Ad Hoc distribution. The tester needs to send their device ID to the developer, who will add it to the developer account. Most Apple Developer Programs allow for a total of 100 test devices, except for the University Program which allows for 200 test devices.

This device ID is then included in an Ad Hoc Provisioning Profile. This profile is a simple file that contains access rights for an app. The provisioning profile can then be added to Xcode and used to build the app, and must be installed on the device at the same time as the app to allow it to run.

The traditional way of doing this is relatively long and demands a lot from the testers:

  1. Find your device identifier (UDID) by connecting it to a computer and launching iTunes.
  2. Email this identifier to the developer.
  3. Wait for the developer to add your device ID to the portal, to compile it in a provisioning profile, and to rebuild the app using this updated provisioning profile.
  4. Receive the app (with extension .ipa) and the profile (with extension .mobileprovision) from the developer.
  5. Drag both files to iTunes.
  6. Sync the apps on your phone.
  7. If everything went well the app should run, otherwise you will need to troubleshoot.

Fortunately for us, a company called TestFlight has developed a process for distributing apps to testers that is easy and painless. A user simply needs to visit the website on their device and follow the simple steps to create an account and register their device. Once that’s done, a developer can add them to a team and prepare an app for testing without requiring more info from the tester. Once the app is ready, the developer simply uploads it to the TestFlight site where it becomes available to all testers for download. There is no need to manage files or to connect the device to a computer.

Another great feature of TestFlight is that it automatically logs errors and crashes for the app, so that if something goes wrong, the developer can investigate without having to ask the tester for details they probably will not be able to provide.


Once your app is ready for the general public, it is time to package a release build for it. The most common distribution platform is the App Store, but depending on the Developer Program you are registered in, you might also be able to build apps for In House distribution.

In House distribution essentially means bypassing the App Store and is typically used for distributing apps on a group of devices within an organization. The process is very similar to Ad Hoc distribution. You create a specific In House Provisioning Profile which you use to build the app. The main difference is that you don’t need to populate a list of device IDs as the app can run on any device. You can then install the app on the actual devices using iTunes or TestFlight.

App Store distribution is a little more complicated. Once again, you need to create a specific App Store Provisioning Profile and build the app against it. This app is then submitted to Apple using the iTunes Connect tool. You will need to fill out information about the app (description, category, icons) which will be used in the App Store. Your submission will then have to be approved by someone at Apple, and that can take anywhere from a couple of days to a few weeks depending on how busy they are.

Once your app is approved, it will go up in the store and stay available as long as you keep paying your $99 yearly developer fees.

If your app gets rejected, you will usually get a specific reason as to why it was rejected, and you will be able to resubmit once you fix whatever it is that Apple did not like. Unfortunately, your app will go back at the end of the submission queue, and it could take a few days until it is reviewed again.