Xcode 4.6. fails processing .iconset files after touch by Xcode 3

  • Somewhere I remember reading a statement by Apple not to worry if you need to build for old Macs in Xcode 3, because Xcode 4 did not change the project file format, you can open and save projects alternately in Xcode 3 and Xcode 4 without any damage. I think I found some damage…

    • You have a project with multiple targets.  In particular, you have a "Regular App" target, which builds for Mac OS X 10.6+, and a "Legacy App" target, which builds for Mac OS X 10.5.  (I suspect this is probably not necessary to reproduce the bug, but it's what I did.)
    • Open project in Xcode 4.6.2.
    • Build the "Regular App" target.
    • Verify that .iconset folders have been processed into .icns files in the product.
    • Close project.
    • Open project in Xcode 3.2.5.  Presumably you do this as I did, by navigating to it from and older Mac over your local area network.
    • Build the "Legacy App" target in Xcode 3.2.5.
    • Close project.
    • Open project in Xcode 4.6.2.
    • Again, build the "Regular App" target.

    Expected Result:

    "Regular App" product should be good.

    Actual Result:

    Instead of producing .icns files, Xcode copies each .iconset folder into the product's Contents/Resources.  Viewing the product in Finder, you see the generic "A" icon.

    Workaround:

    After building in Xcode 3, back in Xcode 4, remove all .iconset files from the project ("Remove References") and add them again.  The .iconset files will now be processed properly.

    Is this a bug or am I doing something wrong?

    Jerry
  • On 22 Apr 2013, at 5:31 PM, Jerry Krinock <jerry...> wrote:

    >
    > Somewhere I remember reading a statement by Apple not to worry if you need to build for old Macs in Xcode 3, because Xcode 4 did not change the project file format, you can open and save projects alternately in Xcode 3 and Xcode 4 without any damage. I think I found some damage…
    >
    > • You have a project with multiple targets.  In particular, you have a "Regular App" target, which builds for Mac OS X 10.6+, and a "Legacy App" target, which builds for Mac OS X 10.5.  (I suspect this is probably not necessary to reproduce the bug, but it's what I did.)
    > • Open project in Xcode 4.6.2.
    > • Build the "Regular App" target.
    > • Verify that .iconset folders have been processed into .icns files in the product.
    > • Close project.
    > • Open project in Xcode 3.2.5.  Presumably you do this as I did, by navigating to it from and older Mac over your local area network.
    > • Build the "Legacy App" target in Xcode 3.2.5.
    > • Close project.
    > • Open project in Xcode 4.6.2.
    > • Again, build the "Regular App" target.
    >
    > Expected Result:
    >
    > "Regular App" product should be good.
    >
    > Actual Result:
    >
    > Instead of producing .icns files, Xcode copies each .iconset folder into the product's Contents/Resources.  Viewing the product in Finder, you see the generic "A" icon.
    >
    > Workaround:
    >
    > After building in Xcode 3, back in Xcode 4, remove all .iconset files from the project ("Remove References") and add them again.  The .iconset files will now be processed properly.
    >
    > Is this a bug or am I doing something wrong?
    >
    > Jerry

    I sympathize, but I'm not sure what else Xcode 3 can do.

    The .iconset -> .icns conversion was introduced in Xcode 4.4. The build rule (Target editor, Build Rules) for the folder.iconset UTI is that it uses the Iconutil tool to make the conversion. Xcode 4.4.x recognizes the .iconset extension, and automatically tags it as folder.iconset.

    Xcode 3.x doesn't have the Iconutil utility, and doesn't know about .iconset or the folder.iconset UTI. When it sees a directory with that UTI in the copy-files build phase, it treats (and apparently retags) it as a folder, the nearest UTI it knows about. That's arguably a repair. I don't know what else it's supposed to do — preserve the unknown UTI? How does this affect the build process? Even if Xcode 3.x handled it gracefully, it would have to copy the .iconset literally into .app/.../Resources, because that's its rule for folders.

    You could argue that backing the UTI off to folder for build purposes, hoping it does the right thing; but preserving the unknown UTI for the use of a future Xcode, is desirable. Alas, it's too late to file a bug on 3.x. Maybe it could be a feature request for Xcode 4.6.+.

    — F

    --
    Fritz Anderson
    Xcode 4 Unleashed: 4.5 supplement for free!
    http://www.informit.com/store/xcode-4-unleashed-9780672333279
  • On 2013 Apr 23, at 08:00, Fritz Anderson <fritza...> wrote:

    > Alas, it's too late to file a bug on 3.x. Maybe it could be a feature request for Xcode 4.6.+.

    Thank you, Fritz.  Of course this is not a problem with Xcode 3.  But it is a Serious Bug in Xcode 4.  And it now has a Bug ID number, 13770305.

    Apparently, Xcode 4 only processes Build Rules only when a file is added to a project, or when a Build Rule cannot be interpreted.  Maybe it places "tags", as you call them, Fritz.

    For known pathological cases like .iconset in particular, Xcode should apply its Build Rules more often, at least whenever a project is opened.  Whenever I open my project in Xcode 4 after closing in Xcode 3, I wait through a minute or two of "indexing" 700 source files.  So it already seems to know and have a routine it executes when a project has been touched by others.  Certainly this little test would not add more than a few seconds to that routine.

    Another way to look at it: If Xcode 3 can change them, Xcode 4 can change them back.
previous month april 2013 next month
MTWTFSS
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          
Go to today