之前在另一家公司的时候，就打包上传APP到AppStore上面，第一次上传成功（2015年2月1号之前），不过悲剧的是第一次被拒了（因为有微信登陆，用户没有安装微信的时候还是显示微信登陆按钮，不够友好）
PS：如果用户没有安装微信 但是你们APP有微信登陆的话请把微信登陆按钮隐藏了。然后过了几天又重新提交，已经提交不上去了（已经过了2月1号了），不过后来老板也不说再上传这个APP了，然后就不了了之了。后来，又来到了现在这家公司，经过两个多月，修改bug的任务完成了，准备着今天提交APP进行审核呢，可是提交的时候提示不支持arm64，于是乎，在building setting里面加上了arm64，编译之后报错（由于使用了zbar这个二维码扫描的类库，由于之前的没有兼容arm64所以现在报错了，于是百度了一个支持arm64的静态库把之前的替换了）。可是，扯淡的问题出现了，首页的数据竟然不显示了，然后就冥思苦想，仔细看项目代码，原来- (CGFloat)tableView:(UITableView*)tableView heightForRowAtIndexPath:(NSIndexPath*)indexPath这个方法写的是- (float)tableView:(UITableView*)tableView heightForRowAtIndexPath:(NSIndexPath*)indexPath
返回的是float，返回的是float，返回的是float，重要的事情要说三遍，他坑了。于是又研究了一下arm64编译环境和之前的差异。
说了那么多的废话，正式开始
拒绝基本数据类型和隐式转换
首当其冲的就是基本类型，比如下面4个类型在32-bit和64-bit下分别是多长呢？
size_t s1 =sizeof(int);
size_t s2 =sizeof(long);
size_t s3 =sizeof(float);
size_t s4 =sizeof(double);
32-bit下：4, 4, 4, 8；64-bit下：4, 8, 4, 8
（PS： 这个结果随编译器，换其他平台可不一定）
它们的长度变化可能并非我们对64-bit长度加倍的预期，所以说，程序中出现sizeof的代码多看两眼。而且，除非你明确知道自己在做什么，应该使用下面的类型代替基本类型：
int -> NSInteger
unsigned -> NSUInteger
float -> CGFloat
动画时间 -> NSTimeInterval…
这些都是SDK中定义的类型，而我们大部分时间都在跟SDK的API们打交道，使用它们能将类型转换的影响降低很多。
再比如说下面的代码：
NSArray*items=@[@1,@2,@3];
for(inti = -1; i < items.count; i++) {
NSLog(@"%d", i);
}
结果是，for循环一次都没有进。
数组的count是NSUInteger类型的，-1与其比较时隐式转换成NSUInteger，变成了一个很大的数字：
(lldb) p i
(int)$0= -1
(lldb) p (NSUInteger)i
(NSUInteger)$1=18446744073709551615
这和64-bit到没啥关系，想要说明的是，这种隐式转换也需要小心，一定要注意和这个变量相关的所有操作（赋值、比较、转换）
老式for循环可以考虑写成：
for(NSUIntegerindex=0;index< items.count;index++) {}
当然，数组遍历还是更推荐用for-in或block版本的，它们之间的比较可以回顾下这篇文章。
使用新版枚举
和上面的原因差不多，枚举应该使用新版的写法：
typedefNS_ENUM(NSInteger, UIViewAnimationCurve)
{ UIViewAnimationCurveEaseInOut,
UIViewAnimationCurveEaseIn,
UIViewAnimationCurveEaseOut,
UIViewAnimationCurveLinear
};
不仅能为枚举值指定类型，而且当赋值赋错类型时，编译器还会给出警告，没理由不用这种写法。
