Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I as well struggled with this for a long time. The answer is to use ento's "External Target" solution. He is WHY this problem occurs and how we use it in practice...</p> <p>Xcode4 build steps do not execute until AFTER the plist has been compiled. This is silly, of course, because it means that any pre-build steps that modify the plist won't take effect. But if you think about it, they actually DO take effect...on the NEXT build. That's why some people have talked about "caching" of plist values or "I have to do 2 builds to make it work." What happens is the plist is built, then your script runs. Next time you build, the plist builds using your modified files, hence the second build.</p> <p>ento's solution is the one way I've found to actually do a true pre-build step. Unfortunately I also found that it does not cause the plist to update without a clean build and I fixed that. Here is how we have data-driven user values in the plist:</p> <ol> <li>Add an External Build System project that points to a python script and passes some arguments</li> <li>Add user-defined build settings to the build. These are the arguments that you pass to python (more on why we do this later)</li> <li>The python script reads some input JSON files and builds a plist preprocessor header file AND touches the main app plist</li> <li>The main project has "preprocess plist files" turned on and points to this preprocessor file</li> </ol> <p>Using touch on the main app plist file causes the main target to generate the plist every time. The reason we pass in build settings as parameters is so our command-line build can override settings:</p> <ol> <li>Add a user-defined variable "foo" to the prebuild project.</li> <li>In your prebuild you can use $(foo) to pass the value into the python script.</li> <li>On the command-line you can add foo=test to pass in a new value.</li> </ol> <p>The python script uses base settings files and allows for user-defined settings files to override the defaults. You make a change and immediately it ends up in the plist. We only use this for settings that MUST be in the plist. For anything else it's a waste of effort....generate a json file or something similar instead and load it at run-time :)</p> <p>I hope this helps...it's been a couple rough days figuring this out.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload