在ios的OC和Swift混合开发无非是2种，一种是在OC的项目中使用Swift语言开发，这里就需要创建Swift文件（或者引用Swift写的的第三方库），另一种是在Swift项目中使用OC语言开发，这里就需要创建OC文件，（或者引用OC写的的第三方库）
10年的马山网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。网络营销推广的优势是能够根据用户设备显示端的尺寸不同，自动调整马山建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。成都创新互联公司从事“马山网站设计”,“马山网站推广”以来，每个客户项目都认真落实执行。
首先我们在一个已有的OC的项目中，创建一个Swift文件
这里Xcode就会自动提示我们如：图1
Would you like to configure an Objective-C bridging header?
Adding this file to ocProjectUseSwift will create a mixed Swift and Objective-C target. Would you like Xcode to automatically configure a bridging header to enable classes to be accessed by both languages?
提示我们创建一个桥接的头文件，当我点击 “ Create Bridging Header”，Xcode就给我们自动创建，自动创建的规则是：项目名+ "-Bridging-Header.h" 如图2
同时在项目中创建一个Swift文件
然后在在 targets - Build Settings - Packaging 中设置Defines Module 为YES
设置完后开始使用，怎么在oc中使用Swift的类呢？
重点： 在文件中引用 #import "ocProjectUseSwift-Swift.h" 记住不是我创建的SecondVC.swift，是“项目名-Swift.h"文件名 ,引入这个文件就引入了所有的Swift文件内的类、方法、属性
说明：这个文件是系统自动创建，自动添加所有我们创建的Swift的类的方法和属性
前提是要在方法和属性前面要加@objc 如图3：
用@objc声明好之后，在我们引用的是“项目名-Swift.h"文件名的 #import "ocProjectUseSwift-Swift.h" 内就看到有标记了如图4
这里分了3块，红色和绿色标记框内是我们自己标记的oc可用的属性和方法，蓝色框内是系统自己生成的oc可以初始化方法
具体使用就在oc文件中，如图5：
此事，在这个OC创建的项目中，我们创建的Swift文件怎么使用OC创建的类呢？
这里就用到我们创建的桥接头文件了，在图2中的桥接头文件，引入OC的头文件，如图6
就这样很简单，所以Swift文件的类都可以使用这个OC文件内的类了，使用起，和OC调用OC的类一样，如如图7和图8
Swift的项目中，第一次创建OC的文件，此时系统会自动帮我们创建桥接头文件，如图9
然后就有了和图2一样的桥接头文件，剩下的就和图6一样，在桥接头文件内引入头文件，即可使用OC的类,第三方库如果也是OC写的，在引入的时候也自动会加这个桥接头文件，当然一个项目只能加一次，加过的就不需要加了
1.原生开发（Native App开发）：像盖房子一样，先打地基然后浇地梁、房屋结构、一砖一瓦、钢筋水泥、电路走向等，原生APP同理：通过代码从每个页面、每个功能、每个效果、每个逻辑、每个步骤全部用代码写出来，一层层，一段段全用代码写出来
此种APP的数据都保存在本地，APP能及时调取，所以相应速度及流畅性有保障
2.混合开发（HTML5开发）：这个就相当于一种框架开发，说白了就是网页；该模式通常由“HTML5云网站+APP应用客户端”两部份构成，APP应用客户端只需安装应用的框架部份，而应用的数据则是每次打开APP的时候，去云端取数据呈现给手机用户。
混合APP还有一种是套壳APP，套壳APP就是用H5的网页打包成APP，虽然是APP能安装到手机上，但是每个界面，全部是网页。此种APP数据都保存在云端，用户每次访问都需要从云端调取全部内容，这样就容易导致反应慢，每打开一个网页或点一个按钮都需要等半天。
混合开发的优缺点：
优点是：
1、开发效率高，节约时间同一套代码Android和IOS基本都可用
2、更新和部署比较方便，不需要每次升级都要上传到App Store进行审核了，只需要在服务器端升级就可以
3、代码维护方便、版本更新快，降低产品成本
缺点是：
1、由于不能直接操控硬件有些方面性能不是很好
2、另外有技术比较新版本的兼容性比较差，还有就是即懂原生开发又懂H5开发的高端人才难找。
混合App开发是未来的趋势，目前混合开发中使用的技术也很多，主要的混合开发技术有jQuery Mobile、React Native、Cordova、APICloud、AppCan等。虽然混合开发能够提高效率节省成本，但也有很多的限制，除了硬件、缓存等的限制，各大平台之间的兼容性也不足。有的也比较消耗资源。
您好，国内外Hybrid App的开发框架众多。如何选择又成为一个难题。下面对开发者比较关心的集中知名跨平台开发移动应用中间件进行列表和对比，以便选择最适合您的移动应用中间件。
PhoneGap是相对比较早进入公众视线的一种选择。但是，开发者简单的基于PhoneGap来开发移动应用肯定会发现结果和Web App比较差的用户体验类似。这也是为什么基于PhoneGap有实用性的移动应用主要集中在iOS上。可是PhoneGap这种现状弱化了HTML5的跨平台价值。
Titanium是一种基于翻译机制的跨平台中间件，能够开发出具有Native体验的移动应用，但是因为翻译机制的限制导致移动应用开发不能像真正的HTML5开发一样灵活。哪怕一个按钮也不能像普通HTML一样来编写，而必须按照Titanium约定的特定格式。
Salama是全新研发的一套Hybrid APP和云端服务整合的开发套件。在终端，一共有三种开发模式：高度混合模式、JS模式和低度混合模式。在低度混合模式下，需要追求终端速度和显示效果的开发者，可以在不改变原有的构架思路的前提下进行开发。在JS模式下，所有的画面显示及业务逻辑均由JS程序实现，对于原来的基于WEB的开发者，只要熟悉JS、CSS、HTML的前端工程师就可以轻松构建自己的应用。在高度混合模式下，原生和HTML5可以随意组合，可以为开发者在进行大型商业软件开发的过程中提供最高的性价比。不仅如此，在云端Salama还提供了一整套云服务，涵盖了业务处理、数据库操作、文件等资源的存储分发等服务。Salama已经为多家公司提供了方案，知名客户有TOSHIBA-AIRCON、GEDORE等品牌商，同时也在Salama平台上构造了Ishow企业电子目录产品服务。
AppCan在技术架构上和PhoneGap类似是Web主体型中间件，但是通过结合了一些原生交互效果能够达到iOS、Android平台都比较一致的用户体验。但是相比PhoneGap的开源，AppCan相对封闭的路线显得过于谨慎。
Hybrid App这个领域虽然还处于比较初期的阶段，但是已经有很多优秀的公司和技术团队在致力于跨平台开发移动应用中间件技术的研究，给了开发者众多选择。开发者可以根据实际的项目需求来选择中间件。Web App虽被浏览器厂商和搜索引擎公司所推崇，但存在用户体验差、盈利模式不明确等现阶段无法解决的问题，或最终夭折。Hybrid App正在被越来越多的公司和开发者所认同，势必会成为新世界的王。
1、维护两套（IOS，Android，甚至是wp）应用太麻烦了，时间成本，人力成本相对混合框架来说太高
2、对于小公司，并没有ios或者android程序员，但是web程序员肯定是有的。所以因为成本或者别的原因，没有招ios和android程序员，那么最好的解决办法就是Hybrid
