On Apr 4, 2014, at 19:24 , Rick Mann <email@hidden> wrote:
There is a use case for adding/removing files based on config:
I should probably stay out of this, but I can’t help noticing that the more details you provide, the clearer you make it that you *already* have “complexity” in your testing scenarios, but at the same time you reject obvious solutions on the basis that they *introduce* complexity**. It seems to me they do not. They merely introduce explicit representations of the complexity that is currently implicit in the information you carry around in your head.
Debug builds often have extra files (we have files that provide the data used when simulating our attached hardware, for example). There's also the iTunesArtwork that goes into certain types of build but not the app store build.
For example, this seems to be exactly the kind of thing that multiple targets are designed to support. You have *two* developer-local scenarios to debug (that is, to test even before you build anything to give to others to test) — one with simulated device data and one without. Why not have 2 targets?
Again, it seems to me that Apple has already considered the kinds of build scenarios you wish to support, and targets and configurations (along with schemes and #ifdefs) *are* the features you’re requesting, except that you simply decline to use them.
I handle that now with build scripts, but I wish I could just flip switches in the UI.
It might be worth asking yourself, if hypothetically you were called away from work for a good while, whether your projects contain enough information to allow others to pick up the reins. Even if these so-called “UI switches” were there to be flipped, that doesn’t really help anyone else with what to flip when. OTOH, if your project contained three targets/schemes called “Test Build”, “QA Debug Build” and “Release Build”, even I could figure out which one to use.
** I’m referring to comments you made much earlier in this thread.
|