Chap 7:Motion Effects -- Memory leak?


Hello, 8Aug14

Chapter 7, Motion Effects:
The code works but I have a question. Why doesn’t it leak memory?

  1. motionEffect = alloc and init…
  2. Should I set motionEffect to nil before the next alloc and init?
  3. motionEffect = alloc and init…

It seems to me the pointer address and therefore the memory would be lost on the second alloc/init. Have not been able to find this in the docs. Where should I be looking?

Book code:Chap 7:Motion Effects

     UIInterpolatingMotionEffect *motionEffect;
     motionEffect = [[UIInterpolatingMotionEffect alloc] initWithKeyPath:@"center.x"
     motionEffect.minimumRelativeValue = @-25;
     motionEffect.maximumRelativeValue = @25;
     [messageLabel addMotionEffect:motionEffect];

     // Memory Leak???
     // Should I set to Nil before the alloc? (motionEffect = nil;)
     motionEffect = [[UIInterpolatingMotionEffect alloc] initWithKeyPath:@"center.y"
    motionEffect.minimumRelativeValue = @-25;
    motionEffect.maximumRelativeValue = @25;
    [messageLabel addMotionEffect:motionEffect];

Also, this code does not work on my dev iPhone4. It must be the old hardware but it is running iOS 7.1.2.
How should I test for this?

Thank you,


It doesn’t matter if the pointer address is ‘lost’ between the first and second alloc/inits as you have added it to the messageLabel object. messageLabel now owns the first object you created and it will be destroyed when messageLabel releases it.

As messageLabel now has a reference to the address of the first object, you can change the value of motionEffect and messageLabel doesn’t care.


Correct; motion effects are not supported on that device.


You’ll have to decide whether it’s worth the effort or not since there is no direct means of testing for this. That is, while the DEVICE and the iOS VERSION can be checked directly, determining whether a supported device+iOS_version actually has it enabled (mine doesn’t) is a different matter.


Hello, 11Aug14

I am correct that motionEffect does lose the pointer. However, messageLabel gets it via addMotionEffect and become responsible for it.

It seems to me that as I develop apps, I should check the hardware to see if it is supported. Then check, if able, to determine if a user has it disabled by a setting.

My plan is to “collect” various test over time and have my apps adjust occordinaly. Do you consider this a good idea?

Thank you both for you feedback.



Sometimes, this is important; other times, to me, it’s more trouble than it’s worth.

For example, looking ahead to chapter 11 (Camera), you’ll be adding the ability for Homepwner to capture a photo. It’s important to see if the device actually has the ability to take a photo with a camera (page 217), because if the app tries but there’s no camera, then the app will crash:

In the case of motion effects, though, the app doesn’t crash if motion effects are not available; the code just has no visible effect.

Obviously you can spend your time as you wish. But since the net effect of checking whether motion effects are available is just saving a little CPU at the cost of having more code to maintain and not spending that time adding real value to your app, you may find it’s not worth the effort.

I don’t feel I’m in a good position to say.

It may be interesting as far as being able to say, “My users have motion effects available and enabled 80% of the time, so it’s worthwhile for me to spend the time adding this feature”. But personally I don’t think I’d take it that far. If I liked the idea, then I’d try to implement it; if I liked the results, then I’d keep it.