https://qdan.me/list/VaXl7N8emfv1ayWg
从零开始做App的Bootstrap
做一个App，需要很多东西。
不定期更新。
团队
工欲善其事，必先利其器。
需求管理
支持版本、迭代、需求的创建与管理。
产品经理在上面录入需求，开发参照开发，测试参照写测试用例，并进行状态流转。
国内大厂如腾讯都有内部自己开发的管理平台如tapd。
小团队可以使用轻量级的平台如：
国外：Trello、Basecamp、Jira、Asana
国内：Tower、Teambition、FengChe
也可以使用较传统的重型工具如 禅道（真的很丑，但是流程和大公司内的比较像）
缺陷管理
测试在上面录入从各个渠道收集到的bug，分配给开发，并进行状态的流转。
在诸如tapd、禅道这样的传统平台上，都包含缺陷管理模块。反而在上文中的轻量级的项目管理平台里，缺陷管理并不是非常容易做，简单的还好，复杂的归类、人员间的流转就不容易了。
传统的解决方案如Bugzilla等太老旧不利于使用，目前没看到特别好的方案。
代码托管
一流小团队用Git，买GitHub或者自建GitLab或者用第三方的代码托管甚至云开发平台，如Coding之类。
不入流的大多用SVN。
云服务＋CDN
选定云服务商和CDN服务商，不再自己买机器租机房。
国外主流用Amazon家，国内主流用阿里云，腾讯百度也有云但是稳定性不说了。新浪的云是打酱油的。也有青云之类做的不错。
CDN选择就更多了，云CDN是主流，国外如Akamai 、CloudFlare，国内阿里云的CDN最广泛。
持续集成与分发
大多数团队在初期都会忽视持续集成，然后它很重要。
每次有代码提交到主干或每日特定时间，都应自动以最新代码编译一次出一个app版本，并上传到分发渠道上，如 TestFlight。这样产品、测试和其他外围人员随时可以安装并检查最新版本。
传统的持续集成有Jenkins/Hudson，自己部署自己设定，iOS的话还有Xcode Server的bot。但云持续集成也在逐渐流行起来，Travis CI就是其中的典型。
内部分发渠道上，TestFlight在Apple买了之后就不是那么好用。国外还有HockeyApp，国内Fir.im、蒲公英则是使用的比较多的分发渠道。
而将持续集成和分发渠道联系在一起，除了自己写脚本外，也有第三方工具如http://nomad-cli.com 和 https://fastlane.tools
设计资源交付与共享
设计师与开发之间需要一个平台来共享设计稿、切图、标注等资源。
有些团队是给设计师代码权限，让设计师直接把切图提交到代码里，也有些团队是用Dropbox等云盘来和开发分享切图。
另一方面，还有Sketch＋Zeplin这样的工具来分享设计稿、自动批量切图并支持自动查看标注，把设计师从标注中解放出来。结合上面提到的云盘，可以实现自动切图＋标注＋同步到开发一气呵成。
内部沟通工具
内部沟通工具和传统IM不同，讲究的是：
1. 自带组织构架、人员查找
2. 方便发起群组讨论
3. 多人文件共享场景更多
4. 和邮件、持续集成等其他系统的互通互动更重要
5. 手机和桌面版本同样重要
不入流团队爱用的QQ微信就不说了。
以前腾讯的RTX用的比较多，但明显缺点是RTX的Mac版问题很多，Windows版也很老旧（不是腾讯内用的新版），手机版也很差。
后起之秀如Slack、瀑布IM、BearyChat等值得尝试，特点是支持大量第三方服务。
阿里也有做钉钉，但针对的是传统企业，功能臃肿不实用。
邮件系统
在保守乃至正常的工作流程中，邮件都是有效的事务推动和留痕工具。需要具备：
1. 和组织构架打通
2. 清晰的邮件组划分
3. 和日历、会议邀请挂钩
4. 与沟通工具的互通。
目前只看到微软的Exchange可以满足此类需求。
开发、测试、线上环境及快速上线流程
设定三个不同的环境，确保数据同步。并且支持每个小的代码变动可以自助式的在三个环境逐个部署并验证，最终可以在短时间内快速上线。避免传统式的开发一大坨、部署一礼拜的情况。
OA系统
外围事务，如请假、调休、事务投票、个人信息补全等。与核心业务无关，但是能避免杂事影响效率。
App
一个App需要有的基本模块
账号体系+第三方登录
email/手机号短信验证是主流的注册账号体系，有需求可再加微博、微信、QQ的第三方登录。涉及到在三者的开放平台注册并通过审核拿到api key。
第三方登录有第三方的SDK可以支持，但其中还不乏一些不靠谱的平台。
登录时
版本更新提示与强制更新
在早期版本就需要预埋好的功能。尽管 Apple 不允许 App 内出现检查更新字样，但仍然可以在有更新的时候弹出更新提示。并且为以防版本出现重大bug，需要支持对老版本可以封停的能力，也就是强制更新，不更新不给用。
Push服务
一个强健的Push服务后台，支持高效率的大量Push发送，以及对每条Push打开率的统计。大多数团队自己开发的后台都做不到，包括发送效率和打开率统计。额外从运营层面还会需要支持预设定时发送Push等功能。
因此大多数情况下，建议使用第三方的方案。国内做的主要有百度云推送、极光、云巴、个推、腾讯信鸽、友盟，据传百度云推送团队已经没了，极光的后台感觉粗糙，个推貌似新浪微博也没再用了送达率低，云巴不知道，此外知乎用的是LeanCloud的推送。
短信下行服务
手机号注册等功能涉及验证码短信下行，需要有一个低延迟、高送达率、不受运营商白名单影响的短信服务商接入。
国内的短信服务商多如牛毛，收费也从1毛到5分不等，但基本上处于便宜没好货的状态。除了送达率的问题，还有对于17*的新号段常有支持不好，以及运营商有白名单，名单中的用户容易送达不到。
最简单的方式是直接和移动等运营商谈，价格不贵且专线保证送达率。其他服务商的免费体验账号都存在上述问题，客服一般反馈都说付费了就好了。
邮件发送服务
重邮件的业务，一定需要一个强大的邮件代发业务，因为：
1. edm邮件需要统计到达率和打开率等，需要支持针对特定用户发送，传统的邮件服务器并没有这些功能。
2. 大多数邮件代发服务提供足够多的样式，可以快速编辑产出
3. 国内许多邮件商对发送IP等都有过滤限制，邮件代发服务则提供白名单的途径可以避免被过滤。
常用的邮件代发服务有：Mailchimp、Mailgun、Sendgrid、SendCloud。其中SendCloud是国内做的比较不错的。
数据上报与统计
支持App内的各类规模类、点击类数据上报，并且有支持各种复杂分析的后台，最好能与用户账号挂钩。
这方面国内算友盟做的最有名，其他还有TalkingData、百度统计等，但做的都一般，国外的Flurry、Localytics更为成熟，Google Analytics for Mobile也很强大。
一般建议一个App接入至少两个数据上报平台，在也就是在App内封装一层。
内测问题反馈
用于在内测（甚至正式版本）用户发现问题时，可以简单快速的将当前问题反馈到开发团队。需要支持截图和注释。
目前已知有Instabug支持此项功能，但是Instabug的管理功能很差，幸好他家支持自动与其他缺陷管理平台集成。
建议配置成尽在内测版时启用该项功能。
用户互动
在App中放置入口，允许用户向开发团队反馈问题或提意见，并且可以收到开发团队的回复。一般以聊天或私信的形式。
国外主要有UserVoice、ZenDesk等，国内LeanCloud中包含该服务，还有逸创云客服算是对ZenDesk复制的比较好的，比其他的更多的是有帮助中心页面可用；此外还有Udesk和美洽。
其他App如知乎等则选择将该功能和自己的私信功能和在一起。
Crash上报&质量监控
收集每个版本上线的同类Crash的log和堆栈。后台应支持快速转入缺陷管理。
此类服务国外Crashlytics较有名，国内则有腾讯的Bugly做的不错。同时也可以选择自己架设相关上报Server，也有足够多的开源方案。
官方网站+博客
如有网页版，那么网站会有额外的工作。
1. 搜索引擎优化，这里涉及到的除了传统内容，还有和iOS 9相结合的地方
2. 登录时的机器识别，避免被批量注册号码。这里的服务有比如geetest等。
App分享
允许用户从App内简单分享当前App到微信、微博等。由于微信的存在，需要开发一个承接页用来判断是否在微信中打开，是则跳转至应用宝的产品页。
内容分享
允许分享应用内内容到微信、微博、QQ等。大多数团队选择用第三方的SDK来实现一次性支持多家分享。但目前大多数第三方SDK的使用交互和样式都非常非常烂。
考虑到分享出去的网页存在不断被转发的情况，所以需要支持Open Graph protocol让微信等app可以正确的读出预览图片、描述而不是显示一个默认的链接。
http://ogp.me
