根据渠道（企业和苹果市场）和模式（Debug和Release）两个维度组合，可以有4种不同的版本组合。
1. AppStore渠道Debug模式
这是最常用的模式，一般就是所谓的开发版
用开发证书
测试手机的
UUID需要上传苹果网站可以用
XCode连接测试机调试，设置断点等可以用
iTools等工具在测试机上安装没有注册
UUID的手机不能用
2. AppStore渠道Release模式
这是通常所说的产线版本
用发布证书
不能用
XCode调试，不能设置断点不过可以通过
XCode安装。运行时会闪出来不能用
iTools等工具在手机上安装只能从
AppStore下载安装
3. 企业渠道Debug模式
299美元/年的账号用开发证书
测试手机的
UUID需要上传苹果网站可以用
XCode连接测试机调试，设置断点等可以用
iTools等工具在测试机上安装没有注册
UUID的手机不能用是企业版的“开发版”
与普通的开发版
bundle id不一样，相当于不同的应用。这个模式也是给开发人员用的
4. 企业渠道Release模式
这是通常所说的“企业版”、“内测版”、“抢鲜版”
用发布证书
不能用
XCode调试，不能设置断点不过可以通过
XCode安装。运行时会闪出来能用
iTools等工具在手机上安装，手机不需要注册UUID也可以放在企业内网，下载安装
不能上传
AppStore
关于友盟统计
一开始，友盟统计的
AppKey是跟bundle id相关的；这样的话，引入企业版就要申请新的AppKey估计企业版用于内测比较多，除了
bundle id不一样，其他功能跟正式版都一样，那么把bundle id作为区分条件就不合适当前的友盟统计的
AppKey跟bundle id无关；这样的话可以自己决定是否需要新建AppKey。
简单处理就不要新增了，跟正式版用同一个；
如果要区分渠道：正式的还是内测的，那么就新建一个。
关于分享
新浪微博分享，一个
AppKey下面可以挂最多4个bundle id，所以可以不新增。微信分享，一个
AppKey可以挂2个bundle id，另外一个的名字叫测试bundle id。看来是专门用来拿企业版当内测版的QQ分享，有AppKey和AppID两个参数，不知道为什么这么设计。从网站介绍来看，AppID好像跟bundle id有关。经过实际试验，其实他的处理方式和友盟统计一样：AppID和bundle id无关小结：微博，
QQ，微信这三个分享，都可以做到企业版和正式版用相同的AppKey，可以简单地把企业版当做“内测版”。
当然，如果要精细化管理，区分数据来源，那么用不同的AppKey来做也是可以的。只是模式太多，版本太多，管理上面要多花点心思。
关于极光推送
这个没有办法，需要上传推送证书。所以AppKey跟bundle id是强相关的。这种相关是苹果的证书生成方式决定的，在可预期的未来也很难改变。
企业版和正式版，是完全不同的应用，虽然功能是完全一样的。
需要几个版本？
开发版：（
AppStore Debug模式）开发和测试使用，测试负责维护服务器数据。开发可以用工具造数据，比如Charles；也可以在本地自己写测试数据，只是不要忘了到时候删除测试代码。建议的方式还是测试和开发合作，由测试提供核心案例数据，开发和测试标准统一。内测版：（
企业账号 Release模式）一般有两种用法：（1）测试维护，用来测试和内部验收。（2）运营维护，真正的内测版，服务器环境和正式版本一致，但是独立的服务器，和正式环境隔离。审核版：（
AppStore Release模式）这个版本专门给苹果审核用。服务器环境和正式版本一致，但是独立的服务器，并且只是1个或者2个测试账号，（用户数最好不要超过10个），注册，短信验证码之类的流程都不要产生。并且，面对审核，有些特殊的要求，比如IPv6服务器等等。同时，苹果审核通过之后，不能自动上架，要手动上架。服务器的开关切换放在后台，手动上架前要把服务器地址切换到正式的。正式版：（
AppStore Release模式）。这是“产线版”，基本上都是有的。
大前端趋势
JavaScript有一统江湖的迹象，iOS、Android开发都准备转JavaScript前端开发，至少思想上需要有这样的趋势。facebook的React Native； 阿里的weex，Google的PWA，这些大公司都在跟苹果争夺开发者。iOS开发者地位下降，需求降低，薪资走低，苹果的影响力控制力降低，这些都是正在发生的事情。
库克比乔布斯差的不是一点点，从iOS开发者的生存状态就可以看出来。PC 前端：主要是浏览器的网站
H5 前端：微信小程序，支付宝生活号，微信公众号，
App中的活动，也可以尝试一下Google的PWAApp开发：
iOS、Android组件开发，这些还是原生的。facebook的React Native， 阿里的weex选择一个。以前用H5写的活动页面，也可以用weex（或者React Native）来实现。网关开发：大前端里面的后台，后端系统的前端接口层。采用
Node.js来做，也是JavaScript。这一层的价值是“大前端”和“大后端”之间的接口层。与后端，是纯的“数据接口”；这一层主要是负责对各端数据格式做适配（比如浏览器的换行是<br />，原生的换行是\n）。
建议的流程
改进点：一般都是后台系统准备好了，在提供数据给前端联调，导致前松后紧，为上线加班。现在将整个流程分为内部发布，内部试用，苹果审核，正式上线4个阶段，减少无意义的加班。
内部发布:在开发分支上开发新特性，
develop，数据由“网关开发”提供。能接实际后台的就接上，比如用户系统。后台提供不了的，那么就由测试根据核心测试案例构造一些，直接以url为key，value就是前端需要的json，直接放在“缓存数据库”中。保证各端都是可用的产品，没有本地写死的Demo数据。开发测试完成之后，就可以内部发布，将版本转移到发布分支。格式为alpha-年年月月日日。产品部门可以验收，试用，看看是否符合设计，完成后就可以进入下一个开发周期。一个周期建议4周（1周理解需求和方案设计，2周开发测试，1周和产品部分交流合作，并未下个研发周期做准备）。当然，采用2周的开发周期也是可以的，只是要求部门间配合要做好。内部试用：这个要看后台的进度。那些由“网关开发”提供的临时
json数据都接上真正的后台数据，再经过测试验证，就可以发布“内测版”。这个内测版最好使用企业版账号的Release模式。这个阶段主要是后台开发的实现以及“网关开发”接口的调整。前端方面，只要将某个合适的alpha-年年月月日日转以为beta-年年月月日日就可以了。当然，由于接上真正的后台，可能会导致前端的调整。并且这段时间也会发现新的bug，只需要直接在beta-年年月月日日这个分支上修改。至于修改是否同步到develop分支，要根据具体情况而定。
“内部试用版”由于采用了企业版账号，就比较灵活，可以直接放在自己的网站上（需要支持https），让相关人员下载试用。这个版本的服务器独立，各方面和真实服务器一致，主要由运营负责。一些活动，一些推广的方案，可以内部先试用一下，看看效果，及时调整。试用的时间长短，是否正式推向市场，这里还有讨论和调整的机会。苹果审核：经过内部试用，终于决定上线了。苹果审核与正式使用的场景还是有很大差异的。前端的代码是一样的，从某个
beta-年年月月日日转到release-年年月月日日就可以了。服务器要单独提供一个，配置和正式的一样，不过要为审核做一些特殊处理。比如支持IPv6，提供测试账号，不能出现Android字样等等。为了满足苹果审核要求，可能会需要做一些修改，直接在release-年年月月日日分支上操作就可以了。至于是否将修改同步到develop分支，要根据具体情况而定。正式上线：经过等待和必要的修改，苹果审核通过了。（1）运营或者运维登录自己的后台，将服务器从苹果审核服务器切换到正式服务器。如果用户量大，或者考虑稳定性，这里可以引入“灰度发布”，逐步放开用户量。（2）登录苹果开发者网站，手动上架产品。
将上架产品对应release-年年月月日日，合并到master分支。如果由"灰度发布"机制，需要等用户全量放开才能合并。这段时间如果发现bug需要修改，直接在这个release-年年月月日日分支上操作。这里的修改是否合并到develop分支，需要根据具体情况而定。
合并到master分支，意味着一个完整周期走完了。master分支和稳定的正式版本保持一致。
master分支和develop分支是必须的，不可删除，权限要特殊控制。alpha/beta/release-年年月月日日都属于中间辅助分支，保留一段时间后，比如半年，可以删除。当然，都留着也是好的，每个过程都有里程碑标志，方便追溯。
一开始，要错开步骤，需要一点启动时间，看起来要慢一点。完整运行起来之后，各个过程是完全独立的，并且各自负责的部门主体也不一样，是完全可以并行的，一点也不慢。
这里的本质是前端能够提供一个最小可用版本，按照自己的节奏发展，不需要干等后台数据。（依赖后台数据的后果：前面没法做，后面累成狗，加班上线后还要解线上bug，还有临时的需求变更.... ）。
核心优势1：技术和产品合作，倒逼运营养成提前规划的习惯。反问：2周前提出，2周后就上线，这样匆忙能作出一个好的活动吗？风险能控制吗？阿里的双十一会这么做吗？
核心优势2：方便领导审批。一份word文档就让领导放成千上百的资金，压力大吗？如果领导能够看到可用的产品（alpha版本），是不是审批时可以简单点？
核心优势3：风险提前发现。推出给最终用户之前，先在公司内部试用一段时间（beta版），就算一周或者两三天也比没有强，是不是更能控制风险，对用户更加负责？这个是不是比光靠测试把控产品质量更靠谱一点？
核心优势4：更多试错的机会。运营策划一个活动之后，可以和产品和技术商量，大家觉得可行，就可以先开发出一个版本看看效果（alpha版），不需要等领导审批之后再动。有实际可用的产品，领导审批也更方便，也更容易过。（alpha版）不涉及后台开发，就算废掉，成本也不高。试错机会多了，出好产品的概率会高一点。
核心优势5：更快的迭代速度。不用等后台实现，迭代版本速度就可以加快。前端和产品可以更紧密合作，加快产品演进速度。到用户手里的版本，在公司内部可能已经更新了三四个版本了。至少不会出现“最近后台任务比较重，前端任务比较少，只能干等着的情况。”
组织架构
技术架构和流程，需要相应的组织架构来支持。组织架构，还是采用传统的分层模式，这个稳定，有归属感。而具体做事的时候，采用4~10人的小团队模式，这个灵活，以团队目标为主，防止个人英雄主义。
产品一开始人少，可能就1~2个，可以先挂在技术下面。并且和客户端团队走得近，对以后的小团队模式有帮助。发展壮大之后，一般会独立成一个部门。形成产品，技术，运营的三角关系。
“Node.js网关”和“客户端数据服务”这两个是客户端和后端的接口，也是将两者分离的交接点，是两位负责人最需要关心的地方。一方面，统一出口，前后端隔离；另一方面，等用户量大起来之后，要注意单点风险。所以这两个模块，要定义需要做什么，更要定义不做什么。公共部分要做，具体实现尽量甩出去
CTO应该是纯管理，怎么和CEO配合好事首要问题。当然，技术方向也要把控。
客户端负责人和后端负责人，一般是前后端的架构师兼任。属于重要的中层。以流程管理和架构技术为主，跟紧发展潮流，同时也应该花30%左右的时间做技术实践，保持熟练度。
测试和运维属于公共服务，可以单独出来
iOS和Android，面对的是两种手机客户端。可以先各找一个，当然也可以先发展一个，等稳定了再上另外一个。界面和交互，两个端也不需要强调一致。两种手机发展理念是不一样的。H5，可以是App中的WebView页面，也可以是微信小程序，支付宝生活号等等。根据需要来吧。Node.js是后台技术，但是放在客户端，主要为多端数据展示做数据适配等工作。也可以做一下公共逻辑，比如日志，加解密，统计，以及其他公共业务逻辑。和具体客户端无关的逻辑放在这里，只要实现一遍，各种端都能受益。另外，这个主动权掌控在自己手中，不受客户端是否升级影响，也不会受限制于苹果审核机制。更重要的是，客户端一般处理单页面单用户逻辑，而这里，则不受这两点限制，发挥空间很大。另外，这里虽然用后台的技术，但是要有客户端的思维，为客户端开发闭环做好服务。现在JavaScript发展势头很猛，在这里可以很好地发挥一下。Node.js网关（数据消费者）和Java数据服务（数据生产者）之间，是纯粹的数据信息通信，不要考虑各种端的差异。比如时间戳，只要一个long数据就可以，不需要考虑是年月日还是时分秒等具体表现形式。这里基本不需要“文艺青年”的参与，纯粹是技术内部“鸟语”。至于是否要引入
React Native，weex等，看需要吧。个人认为是不需要。现在苹果的审核已经很快了。把随心所欲升级当做需求是耍流氓。另外，多端一致，全栈工程师，少招几个开发之类的领导爱听的话，纯粹是损人利己的行为。
当然，产品、运营一天到晚要搞活动，热更新，那确实需要H5，如果还要求体验，React Native，weex也是有一定价值的。面对流氓，也只能耍流氓了。
真正的动态性，正在的提升效率，将公共逻辑移到Node.js网关才是正解。“云 + 轻客户端”才是让企业掌握主动的方式。
