let it be

This post explains one of my favorite


categories – one that is extremely universal and handy for shorter and, in my opinion, more memory-manageable code.  (Code below.)

Edit: Commenter David found a bug in this implementation. Check out the fixed version here; the new source files are listed at the bottom of that post. (The fix doesn’t require any change in usage or in the header file, just in the .m file).

The idea is very simple – we can replace code that looks like this:

UIView *view = [[[UIView alloc] initWithFrame:myFrame] autorelease];
MyObject *obj = [[[MyObject alloc] init] autorelease];

with this:

UIView *view = [[UIView be] initWithFrame:myFrame];
MyObject *obj = [MyObject beInit];

As you can guess, we’re basically replacing the


pair with a single method,



Besides giving us much shorter code (more readable, less clutter, friendlier to inlining new objects), this method also encourages use of autoreleased objects.  To really go into why I think this is a good thing, we need another blog post; but I can say briefly that autorelease is the Objective coder’s smart pointer.  It helps the code, not the coder, remember what needs cleaning up.

Without further ado, here’s the extremely simple yet incredibly useful category:


  1. kainjow
    Posted May 9, 2010 at 12:59 pm | Permalink

    This doesn’t follow standard Objective-C naming conventions though. If you’re replacing -[UIView initWithFrame]: you should use +[UIView viewWithFrame:]. If you’re replacing a standard allot/init, you should either provide your own autoreleased convenience method if the class is yours, or name it according to the class name. For example +[MyObject myObject].

  2. Posted May 10, 2010 at 8:43 am | Permalink

    Traditionally, your approach has been considered the correct way to go. For example, the naming conventions suggested here:


    seem to strongly suggest that any non-framework method that returns an object should have that object’s name in the method name ( e.g. arrayWithObjects: ). And, yes, this approach does violate that suggestion.

    But there is already a precedent for returning pointers you don’t own from a method without the object in its name – specifically, all init methods. Yes, this is a unique type of method; so is the be method introduced in this post. It’s not meant to be a standard method, but rather a replacement for all alloc/autorelease pairs.

    And it does adhere to the golden rule of naming conventions for memory management, i.e., that you own a returned object iff it has alloc, new, or copy in the name. It doesn’t have those words in its name, and you don’t own the returned object.

  3. David
    Posted August 5, 2010 at 8:15 am | Permalink

    Does this still work if the init method returns an object other than the receiver?

  4. Posted August 6, 2010 at 5:36 pm | Permalink

    David – thanks for pointing this out. I just posted a fix:


3 Trackbacks

  1. By Bynomial Code » Simplified popovers on May 2, 2010 at 6:12 pm

    […] beInit method is explained in an earlier post, as is the handy UIView+position […]

  2. By Bynomial Code » Memory management guidelines on May 23, 2010 at 9:43 pm

    […] These rules, explained in more detail below, can easily be followed with the help of the be method. […]

  3. By Bynomial Code » Don’t worry, Be happy on August 6, 2010 at 5:32 pm

    […] post describes a correction to the Be category when dealing with class […]

Post a Comment

Your email is never published nor shared. Required fields are marked *