1

This is driving me crazy. I've been working on a UIImage category, and I just updated to using Xcode 5.1. The problem is, the category isn't compiled after I make changes to the file and, heres the catch, that's only on 64 bit devices/simulators. I've tried deleting the app from the device, cleaning, cleaning the build folder, deleting the derived products folder, and all the previous at once. Nothing is working! Any suggestions would be greatly appreciated!

UPDATE 6/19:

So my workaround for this problem was to change the signature of the method. The method had been:

- (UIImage *)imageResizedTo:(CGSize)size scale:(CGFloat)scale

And I changed it to:

- (UIImage *)imageWithSize:(CGSize)size scale:(CGFloat)scale

I added NSLog statements to the method and they would print on 32bit devices and on the 64bit simulator, but not on 64bit devices. I added another category with the same signature and that worked just fine, but for whatever reason I could not get Xcode to recognize changes in the category in question, and only on this one method! Breakpoints didn't work inside the function, but they did in other methods in the same category.

I also looked at the build log and it says its compiling the category for armv7 and armv7s.

To sum up:

Things that didn't fix the problem:

  • Removing the reference and re-adding it to the project.
  • Changing the body of the method and re-building.
  • Changing the valid architectures in project settings.
  • Cleaning product/build folder/derived data.
  • Deleting the app and rerunning on the device.

Things that did fix the problem:

  • Changing the method signature.
  • Copying the body of the method and putting it into the caller's body instead.
  • Adding another category to the project with the same method signature and body.

I still really want to know what is going on with this. Mostly I just want to know why this would be happening, its very strange!

Improve this question
8
  • What's the discrepancy between the old build (that it's supposedly currently using) and the new build that you'd like it to use? Commented Jun 4, 2014 at 21:47
  • Code wise? At first it was just commenting out a few lines, but I've tried adding/removing whole methods. What is interesting is I'll remove methods, and other files that reference those methods never show an error, and in the non-64bit devices the error is only revealed at runtime. Commented Jun 4, 2014 at 22:00
  • If you only remove the method from the .m but not the .h, it won't complain in any way in compile time in the other files (although it should complain in the .h). Have you tried removing the reference to the file in the project then re-adding the files to the project? Commented Jun 4, 2014 at 22:02
  • Do make sure that the .m files involved are marked as being part of the project. Commented Jun 4, 2014 at 22:08
  • Any error? Warning? and etc? Commented Jun 5, 2014 at 2:51

3 Answers 3

Reset to default
2

Go to your target setting > Build Phases > Compile Sources and make sure that implementation file of your category exists in that list. If not, then add it manually by tapping on "+" button.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

1
+50

Are your source files in a "referenced" folder in XCode? You'll know because the folder will appear in blue instead of yellow. If so, referenced folders in XCode currently (and for a long time) have had a bug where changed content within them don't seem to get noticed unless the HIGHEST level parent blue folder has it's mod-date changed. Here's an example

GrandParent Dir (Yellow/Non-referenced) | Parent Dir (Blue) | File1.txt Child Dir (Blue) | File2.txt

So in that contrived example, if you touch File1.txt, it won't be noticed unless "Parent Dir" gets touched as well. If you touch File2.txt, it's not enough to touch "Child Dir"...you have to touch "Parent Dir" instead!

You can test this by doing:

touch -cm parent_dir

If that works, then you know this is the problem. A lot of users write a script to do the "touching" that needs to be done and then add that script to Xcode to be run at the right build phase.

Improve this answer

2 Comments

I didn't know that about the folder colors, super helpful info though. It wasn't in a referenced folder, but I think this may have done the trick, I'll go back and check when I get a chance.
Just wanted to mention that this appears to be fixed in Xcode 6. I'm running Xcode 6 Beta 5 and it seems to be behaving itself properly. Touch an item in a referenced folder and it's getting update.
1

I had a similar bug long time ago with previous Xcode versions where changes to code wouldn't get compiled and linked unless I cleaned the target every time.

One work around was to touch main.m on a script build step to force Xcode into think that there's a change that requires code to be rebuilt and linked.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.