移动应用客户端集成中的苹果开发规范的问题
前言：
售前对于apple开发和集成可能都比较陌生，我们在给客户推移动应用的时候也只是介绍功能，集成相关最好让客户自己详细调研一下，我们可以提供集成文档
下面是一个前期调研不足，购买产品以后发现我们的集成方式和他们的需求不吻合，apple相关开发的规范也不一样，以后要尽量避免这样的事情
客户问题：
问题1
ARC 回收是高版本的功能，我们一直使用的arc回收。 他们整个项目都是手动回收机制，客户给我讲也尝试过改成arc自动回收，但他们项目太庞大，他们做不到，所以希望我们来改。
和春雨沟通，需要重新做个项目工程，统一使用手动回收。 工作量在10-15天。:
好处是以后可以适应不同客户的需求。缺点是维护两套。
问题2：
客户反馈，如果用到的功能涉及到了StoryBoard，希望我们改一下，他们的理由是代码容易维护，而引入stroyBoard不容易维护。并且实际的跳转工作不太多。
这块如果改的话春雨需要调研一下才有结果。
1不会改了。2似乎也不会改。我们是标准产品，而且这里用的技术是主流技术。客户开发集成前，也应该先把相关技术研究好。
更新： Storyboard春雨已经有了结论：
“ 客户用纯代码来构造界面(看任务中的回复，应该是纯代码，没有用XIB)，咱们用StoryBoard，如何能在客户的项目中展示StoryBoard界面。
这个我试过了，新建了一个没有用StoryBoard (在A.1图中没有勾选第一个红框)的项目，用纯代码写了个简单的界面X，然后强制新建了一个StoryBoard文件，在上面做了界面Y，在X中用代码可以跳转并展示Y界面。所以即使客户没用storyBoard，也应该可以和咱们集成。”
对于ARC，
“可以在Edit -> Refactor -> Convert to Objective-C ARC，根据苹果的步骤，一步步来把代码转换为使用ARC，简单的试了一下，确实可行。
关于ARC，用了应该比不用要好。如果手动回收，很可能某个地方就造成了内存泄露。并且工具也提供了从非ARC项目转换为ARC项目的工具”
另外：“Apple也想到了这一点，因此为开发这提供了一些ARC和非ARC代码混编的机制”http://onevcat.com/2012/06/arc-hand-by-hand/ 最后这条，我们没有具体研究，仅供参考。
结论：
1. Storyboard问题不是障碍，可以混调。
2. ARC是苹果建议的方式，我们不认为有必要修改。实际上是客户的项目应该考虑转为ARC方式以避免CRASH，另外对于集成问题也应该在项目早期进行试验。这个不是我们的责任和问题。
3. 建议客户研究一下非ARC混编。