当我们使用Ionic时,React Native或构建Native应用程序。

从移动响应网站到您的手机上运行的本机应用,用户参与移动的方式广泛。 在大多数情况下,本机应用程序是更好的选择,这意味着您可以从应用程序商店中获得一个应用程序(iOS的扩展名为.ipa,Android的扩展名为.apk)。 但是,有多种方法可以生成.ipa或.apk文件。 最常见的方法是使用Apple / Google的语言构建“传统”本机应用程序并构建工具,使用混合框架将网站“包装”为应用程序,或使用介于两者之间的框架(如React Native)。

与要构建新应用程序的人进行的最常见的对话之一是他们应构建的框架。应该使用像Ionic,Expo.io或Xamarin这样的Cordova包装器,还是像React Native这样的框架来构建适用于iOS和Android。 在Playlogix,我们首选的选项是Ionic,React Native或“ Full Native”,因为我们通常尝试在Java和Javascript堆栈上运行,以使我们的客户更容易雇用开发人员。 尽管每种选择都有很多利弊,但这通常是我(非技术性)对话的方式:

TLDR; 这取决于预算,团队经验和业务阶段。

这是一个Cordova包装器,您可以在Angular 2+中编写Typescript(一种Javascript),然后将其“包装”在Cordova Shell中,然后将其部署到从iOS,Android到Blackberry的各种不同平台格式中。

优点:

  • 它只需构建一次,即可部署到任何地方。 因此,您只有1个javascript代码库,几乎所有开发人员都可以轻松进行。
  • 对于标准页面而言,使用Ionic Creator(其拖放界面生成器)非常容易,并且它们的默认样式和模板看起来很棒。
  • 可以非常快速地构建基于表单或静态页面的应用程序。 更改只需进行一次,然后部署到多个平台。

缺点:

  • 很难不让应用缓慢而笨拙。 尽管易于构建,但实际上它是一个在Cordova Shell中运行的浏览器中运行的网站。 因此,即使是简单的东西也有很多事情发生,而且很快就会被窃听。
  • 处理长列表确实很糟糕–添加一些图像,这将成为一场噩梦。 大多数其他“半复杂”项目可能比应做的要困难得多。
  • 作为单一代码库,这些应用程序必须看起来完全相同,因此无需针对iOS和平台之间的Material设计进行优化。
  • 不太向后兼容。 [推荐的最低Android版本是4.4.4,但可以扩展到4.2]

我们通常会在以下情况下推荐它:您只是想以低预算快速推出一款非常简单的应用程序,以测试核心业务假设。 此后,只有一个小型(或没有)开发团队可以使用它,并且不需要任何设备硬件(例如大量的CPU使用率,用于AR的摄像头,加速计等)作为您的主要功能。

我们建造了 :让我们聊科萨

它由Facebook构建和开发,它使用React.js版本,该版本可直接部署到应用程序二进制文件(最低级别的本机应用程序格式)。 因此,当您在React中编写代码时,它就像本机应用程序一样部署和运行(它在构建时生成一个二进制文件),而不是像包装程序那样在浏览器中运行。

优点:

  • 您可以使用相同的语言(React.js)构建所有应用程序,从而可以重用许多组件。 这也意味着单个开发人员可以维护您的所有应用程序,并且通常意味着更改很容易完成,因为代码库将非常相似。 所有这些节省了时间和金钱。
  • 它具有接近本机的性能,通常很容易编写快速响应的应用程序。
  • 您有多个代码库,可用于修改iOS和Material设计模式的设计和样式,从而为用户提供更自然的感觉。

缺点:

  • 您仍然有多个代码库。 因此,如果您的设计差异很大,那么您将减少很多代码重用,并且将失去很多好处。
  • 不能向下兼容较旧的Android设备,这可能是一个问题,具体取决于您的目标市场。 (例如第三世界的学生)[目前最多支援4.1(API 16)]

我们通常会在以下情况下推荐它:您拥有相对复杂的应用程序(除了MVP之外),但仍然在功能和功能上进行了大量迭代,而只有一个小团队来维护它。 如果您设计用于最大程度地重复使用代码,那么当您移植到第二个平台时,您可以获得90%的代码可重用性(并节省大量时间/金钱)。 另一个很大的好处是,如果您将React用于您的Web应用程序,则可以重用组件并节省更多时间。

我们建立了: Flow Living | Some1访客

我们通常在iOS中使用Swift构建,在Android中使用Java / XML构建。

优点:

  • 最佳应用程序性能。
  • 出色的构建工具和支持库使其比在每个平台上的React Native中构建每个应用程序更快或更快。
  • 强大的向后兼容性和设备支持。 (请注意,由于Android过于分散,因此仍然很痛苦-但它仍然更容易使用。)
  • 在应用程序内付款和集成到平台服务更加容易。

缺点:

  • 您拥有2种完全不同的语言的2种完全不同的代码库,并且保持功能奇偶性变得困难。
  • 由于大多数本机库都利用本机模板和样式指南,因此使应用程序具有不同的样式要容易得多,因此,您需要确保您的设计师知道差异,否则需要大量的自定义。

我们通常会在以下情况下建议使用它:…您预算充裕且性能出色,而用户体验最为重要。 另外,如果您有一支庞大的团队来维护应用程序的发展,或者已经对先前的设计进行了大量的迭代,并且对应用程序需要做什么有一个很好的了解。

我们建造了:Shyft | EM指导


没有一个合适的解决方案,最终决定将取决于您的业务阶段以及您希望应用程序真正满足的客户需求。 预算,复杂性和支持可能是做出此决定的最大因素。 这不是对与错的问题,而是最适合您所在位置的其中一项。

请记住,除非人们在移动中需要它,否则通常不需要早期原型(或涵盖两个平台)的应用程序,而节省技术开发成本的最简单方法是减少构建并集中精力。


如果您喜欢这篇文章,则可能会喜欢 这里的 其他内容 或我的 BOOK

如果您需要内置的应用程序,请与我们联系: www.playlogix.com

感谢@ BradElliottSA @Wallfish 帮助校对这篇文章。