过去几年Cocoa社区已经发生了很大变化。曾经，在init/dealloc中使用accessor方法是很令人厌恶的，这种做法彻底地被认为是错误的。他们的说法是：最好直接操作实例变量，而不使用accessor方法。并且建议像这样写代码：

- (id)initWithWhatever:(id)whatever
{
    if((self = [self init]))
    {
        _whatever = [whatever retain];
    }
    return self;
}
- (void)dealloc
{
    [_whatever release];
    [super dealloc];
}

iOS中，给视图加阴影很容易，只需要：

1. 项目中引入QuartzCore框架
2. 实现文件中import QuartzCore的头文件
3. 然后仅需一行代码[myView.layer setShadowOpacity:0.5]

然而，最简单的方法通常都不是性能最好的方法。

Objective-C是一个非常酷的编程语言。TIOBE已经公布了十一月的编程语言排行榜，Objective-C很可能会再次成为年度编程语言。Objective-C的流行不只是因为iOS和Mac OS X平台的原因，还得益于它在移动设备上的高性能。在Objective-C中，手动内存管理代替了垃圾回收机制。当然，现在Objective-C也不需要纯手动管理内存了，苹果引入了自动引用计数(Automatic Reference Counting, 简称ARC)机制，在编译时自动加入内存管理代码。大部分情况下，这非常棒。然而，当ARC和Core Foundation对象混用的时候，总是感觉很混乱。今天，我们聊聊ARC的要点和陷阱，尤其是用toll-free bridging将Objc对象和CF对象相互转换时的一些注意事项。

一个XCode project包含了两种设置：Project Settings 和 Target Settings。

它们之间的主要区别在于：Project settings应用于project里面的所有target；而Target settings只对target本身有效，不影响project中的其他target。

Objective-C引入ARC(Automatic Reference Counting)后，我们经常会面对这样一种困境：自己的项目使用了ARC，却发现要使用的第三方库是non-ARC的；或者自己的项目是non-ARC的，但是想使用一个ARC的第三方库。

真是左右为难啊，是该让non-ARC迁就ARC，还是让ARC迁就non-ARC？

目前网上有2种做法来解决这个问题：

1. 将自己的ARC项目转换成non-ARC项目。
2. 将第三方类库编译成framework的形式。

但是都太麻烦了，其实我们只需要在Xcode中设置源代码的Compiler Flags就能让ARC和non-ARC文件共存。

我们经常会定义一些retain的property，而且大概每次我们都会像这样写：

@property (nonatomic, retain) Type *name;

每次都把 @property (nonatomic, retain) 挨个敲一遍，太累了。

那么能不能像Xcode自带的代码提示功能一样，每次只敲几个字符，代码提示就自动出来了，这样不是方便了许多吗？

是的，Xcode提供了代码片段管理功能。我们可以自定义自己的代码片段并有自动提示功能。下面我就以这段代码为例，展示如何在Xcode中添加自定义的代码片段。