title: What's the difference between Build Configurations and Targets?
body: <p>We have five practically identical apps, with a few different icons/names/settings. They are different "brands" of the same app, only differentiated in a few different icons, separate AppGroups, and a few default settings in code. These are created as their own <strong>targets</strong> in Xcode. It's <strong>one</strong> codebase, but 5 targets pointing to it.</p>
  
  <p>It started out looking really nice, with five different targets. However, we have now added two extensions to the app. One custom "NotificationContentExtension", and one "TodayExtension"(Widget). Since we have 5 different targets with 5 different entitlements/groups, we found no other way to achieve this than to add these extensions to EACH target. Since an extension is another target, that means we now have 15 different targets.</p>
  
  <p>We're now experiencing extremely slow compile-times, because every time we as much as open the storyboard, Xcode compiles the entire thing once for EVERY (main)target. I don't need to build my storyboard 5 times. Or any of my other files. I have ONE app, but a few different files, and a few runtime-settings.</p>
  
  <p>This made me wonder - each and every one of these 15 targets have two build configurations by default: RELEASE and DEBUG. I noticed it's possible to customise these, and add more. Why not add configurations instead of targets?</p>
  
  <p>E.g instead of "RELEASE" and "DEBUG", make them "MYAPP1", "MYAPP2", "MYAPP3" etc. Each configuration can have their own product name, icons, and whatever, right?</p>
  
  <p>Are there any good reasons <strong>not</strong> to do this? Is it possible, when dealing with different AppGroups/Entitlements etc.? We have CoreData-databases stored in AppGroups. It is important that these apps can all be installed on the same device without being corrupted by each other.
  As far as I can think, this shouldn't be a problem as long as there are a few different FLAG's for each configuration, and customising the code as such.
  What about signing?</p>
  
  <p>I read <a href="http://onebigfunction.com/ios/2017/03/14/flavor-ios/" rel="noreferrer">this</a> article/tutorial on the subject, which explained the basics and got me started, but it will be a huge amount of work to actually test it with databases and entitlements and all.</p>