0

Coming to the end of a project and it has been a long few months of a mixture of stress and relief. I'm testing the app using instruments now and noticed when I run profile I get a bunch of yellow warnings that never showed up when I built and run a project are showing up.

They all seem to be integer based and XCode will automatically correct them for me if I choose to do so.

Here are some of the errors:

enter image description here

I'm wondering whether these warnings would cause performance issues if ignored?

I'm a little hesitant to correct them because I have a feeling they will cause issues in parts of my app (which shouldn't be an issue because the main aim is to get an error free app in the app store). But you know when you've spent countless weeks on a large project and become sick of working on it... yea.

I can go ahead and correct them but is XCode ever wrong when it comes to correcting these integer type warnings?

A lot of the warnings seem to be on lines similar to these:

enter image description here

I'd be interested in reading your views.

Thanks for your time.

LondonGuy
  • 10,778
  • 11
  • 79
  • 151

1 Answers1

1

Are you compiling 32 bit for the simulator vs. 64 bit when running instruments (you may be compiling to run on an actual iPad air or something)? I'd urge you to clean up these warnings in order to be 64 bit compliant.. NSInteger is int64 (long int) on 64 bit platforms and int 32 on 32 bit platforms. Its complaining because the type in the string doesn't match the type given when its compiled as a 64bit binary.

There are several ways to fix this. One method is to convert the number into an NSNumber using the @() syntax and then use %@ in your format strings (thanks Sulthan). You could also either explicitly upcast to a long int and then use %li in the format string, or explicitly downcast to an int (these options are more performant because you don't have to instantiate an NSNumber every time).

Ron
  • 1,249
  • 9
  • 20
  • Yep in the simulator I'm compiling for iPhone 3.5inch, iPhone 4 inch (not 64bit) and the actual iPhone I'm testing on is an iPhone 4s. I'm guessing an iPhone 4s is 64bit? – LondonGuy Jul 30 '14 at 15:59
  • 1
    Usually, the simplest way to fix it is using `%@` and wrapping the value in `@(...)`, making it a `NSNumber`. – Sulthan Jul 30 '14 at 16:00
  • So if you are compiling to a hardware platform on a recent version of Xcode it will automatically compile the 32 bit and 64 bit versions so it can bundle them together (check your build settings, it'll say something about using arm and arm64 as targets). I believe the iPhone 4s is 32 bit. – Ron Jul 30 '14 at 16:08
  • @LondonGuy iPhone4S is 32bit, the iPhone 5S is the first iPhone that is 64Bit! – Bas Jul 30 '14 at 16:08
  • Usually, the simplest way to fix this is to follow the advice in the warning. – gnasher729 Jul 30 '14 at 16:15
  • The advice in the warning is more performant (recasting the type has much less overhead than instantiating an NSNumber every time.). "Simplest" is in the eye of the beholder... – Ron Jul 30 '14 at 16:19