How to utilize Xcode project & target to manage products

How much (and what kind of) structure you need depends a lot on what you want to be able to do. Figure out what you can't live without, what you want to have, and what you don't care about.

A good example set of decisions might be:

Things we can't live without:

• be able to reconstruct any past release at any time
• be able to maintain multiple supported major versions of the product at any time

Things we would like to have:

• be able to perform ongoing major-feature development (for the next major release) without worrying about branch merges
• be able to perform maintenance updates to past releases

Things we can live without:

• automated backporting of changes from current work to past releases
• never interrupt major feature development even for a few days or a week at at time

If the above were your goals, you could then adopt a process like this:

1. Do all development work on the trunk of your VCS ("master" in git)
2. When you are close to a major release, halt major feature development, and focus on system stability for a week or so
3. When the trunk seems stable, create a branch for this major release
4. Major feature development can now proceed on the trunk, while only bug fixes and release preparation are allowed on the branch
5. However, all bug fixes to be made to the branch must first be tested on the trunk; this ensures that they will also be present in all future releases
6. Create a (VCS) tag on the branch when you are ready to release; this tag can be used to recreate the release at any time, even after further work on the same branch
7. Further maintenance releases to this major release (minor releases) can now be prepared on the branch; each will be tagged before release
8. In the mean time, major feature development geared toward the next major release can continue on the trunk
9. When you get close to that release, repeat the above steps, creating a new releases branch for that release. This allows you to have multiple major releases, each on their own branch, in supported status at the same time, with the ability to release separate minor releases against each.

This process won't answer all of your questions -- in particular, you will need a process in place to decide what fixes can be made to a release branch, and to ensure that bugs are not fixed on a release branch first (such fixes should always be tested on the trunk where possible). But it will give you a framework in which to make such decisions.

40% of the code is reused and 60% customized feature made to particular company

This might take a little time to actually get to the point that you can do this, but I think it should be a goal to extract that 40% out and make it its own repository. This is your main library/framework from which to work.

Then, that other 60% can be in dedicated repositories on a per-client basis.

It sounds like your code base qualifies as "legacy," so I highly recommend picking up Working Effectively With Legacy Code by Michael Feathers for yourself and your team. It provides techniques for bringing code under test, which can also be used for creating a plan to extract your code out into a library.

How would you go about doing this starting now? Here's what I'd do:

1. Make every client its own repository (or, if you're using something like Github or Gitlab to manage the git repositories, and you have several repositories for a client, you can create an organization per client, but we'll assume 1 repository per client).
2. Take a class that I reuse a lot and extract it out (assuming an object-oriented approach, though a functional one should have similar principles). We'll use this to start the library repository (this makes it useful from day 1). If you don't have full classes yet, then that's where Feathers' book comes in, as it shows you how to make classes out of non-classed code. While we're at it, we can add some basic testing to ensure it still does what we expect it to do.
3. Commit this extraction as its own thing, and you can use it as the template to replicate the change across all repositories.
4. As I come across shared parts, I extract them out and add them to this library repository.
5. As the library grows, and I find things that are used by some clients, but not others, I can work toward a modular approach, where larger features are extracted out into their own repositories and included as "modules" or "plugins" to the main system. Alternatively, if there are themes for particular groups of items (such as a bunch that deal with authentication or payment processing), I can extract those out to their own repositories. How you go, exactly, in this stage depends on the nature of your code and the direction you want to go with it.

The advantage of this system is that all you need to do is add that shared item into the library and wire up any hooks necessary to make it work, and it's available to all of the clients, no copy-pasta needed!

Why this instead of branches? While technologically, branches aren't much different from standalone repositories, convention differentiates between them. A repository is a complete project (with references of some sort, either via submodules or scripts, to dependencies), while a branch is generally a given state of the project. You branch when you want to add a feature, fix a bug, or make another kind of change, but the system itself is considered the same. You make a new repository when the project is considered a different one (in this case, for a different client, with its own customizations and whatnot).

A good example of this is Oracle OpenOffice vs LibreOffice. LibreOffice is a fork of OpenOffice, and is even maintained by the same people. However, LibreOffice, even when it was technologically identical to OpenOffice (when it was first forked), it was considered a different product. The team then stripped the Oracle branding from it and started LibreOffice's own development path, which is now distinct from OpenOffice. While the changes that have been made to LibreOffice could have gone into a branch in OpenOffice, since LibreOffice is considered a different project, it needed its own repository, instead.