| I don't believe there is a workaround for your case 1 (files not removed from previously-built applications created by the Run command). The idea of the Run command is to get your application running and in the debugger as quickly as possible, so the assumption is that anything already there that the new build doesn't affirmatively replace can (or must) stay.
The workaround is as you suggest, cleaning the whole build so there is no previous copy. If you think Xcode should keep delta sets that would catch resource deletions (not a bad idea), you should file an enhancement request.
For case 2 (Xcode doesn't detect modification of files on Windows shares when only the enclosing folder reference is in the project), I'd argue that there's not much Xcode can reasonably do. It would have to identify the file system (remote? Windows?) for every folder it references, know what the limitations of each version of each file system are (is there a BSD call for that?), and walk every file in what might be a huge tree to check modification dates. Again, the Xcode team's priority has always been making the development cycle as near immediate as possible, and what you propose could take minutes.
You don't say, but I'd think the workaround would be to clean the project before a Run build. (Archive builds are always clean.)
That doesn't say you shouldn't file a (separate) enhancement request. Apple has been known to do "delightful" things. But I wouldn't expect much to come of it.
— F On 10 Jan 2012, at 10:37 AM, Guillaume Billard wrote: In situations 1 and 2, I'd expect a complete synchronization between what is listed in the Copy Bundle Resources build phase and the contents of the application bundle on the device.
|