The Downside of Native Packaging

The 2007 introduction of the iPhone ushered in a new era of mobility. We now expect our applications and data to be accessible on the most convenient network-connected device. Our appetite for mobile technology has resulted in a massive influx of mobile devices supporting a myriad of different mobile operating systems.

Many application developers soon realized the inefficiency of developing native applications in this multi-device, multi-platform world. They chose instead to embrace web technology and the emerging open standards around HTML5. The shift, now called hybrid app development, created the need for a tool to package these HTML5-based applications, run them on the device, and provide access to common device hardware features like the camera, GPS, and accelerometer.

Starting in 2009, native packaging solutions were created to address this need. Developers have lauded native packagers for allowing HTML5-based apps to fit into the still-dominant public app store distribution model. More importantly native packagers meet a number of important needs for consumer applications and have enabled many HTML5 developers to access app store distribution who otherwise would not have had such an opportunity. Yet in subsequent years, the many deficiencies of native packagers have become painfully obvious to many application developers in the enterprise.

These deficiencies include:

  • Security – Sensitive data is stored unencrypted in the packagers’ caches and data stores
  • Complex app lifecycle – You have to build for multiple platforms and manage the deployment and maintenance of those binaries over the life of the application
  • Subject to frequent mobile OS changes – Any changes or backward-incompatibility from a mobile device vendor can break your packaged app
  • App Store Distribution – Distributing enterprise applications through consumer app stores is highly inefficient.

It’s now 2014; organizations have been dealing with this pain for long enough. They want a long-term solution for application and data mobility. The answer is to deploy HTML5 apps directly into a secure, managed runtime environment. This type of solution has many benefits:

  • End-users get a superior application user experience, relief from app fatigue, and protection for personal privacy. Their applications are always up to date.
  • Developers reap the benefits of both the web and today’s mobile devices. They no longer have to package the app for multiple platforms. They can also eliminate the hassle of dealing with consumer app stores to distribute their apps.
  • Organizations can instantly secure and manage the lifecycle of their apps, data, and users, fighting app sprawl in the process. Administrators can grant and revoke user access to apps and data as business needs dictate, wiping business data from users’ devices without touching personal data. Furthermore, their data is encrypted on the device, protecting them from data breach.

Native packagers have served you well at a time when you really needed it. But if these points concern your organization at all, there is a better way to solve these problems now. If you’re making apps for the enterprise, it’s time to let native packagers go.

Click here to learn more about how Sencha can ease your transition to a post-native packager world.


  1. Rob Colburn says

    Last I checked, Senchs Cmd still uses PhoneGap/Cordova under the covers. I imagine Sencha Space does as well, while also rolling in a package manager and native plugins in the binary. While it’s true you can solve the issues listed with a sophisticated package manager that doesn’t negate the roll of PhoneGap, especially if Sencha is still dependant on PhoneGap/Cordova in the backend. I do realize this article comes at a time when Adobe PhoneGap iis now turning on the marketing for their competing PhoneGap Build product, and it’s important to differentiate yourself. Words matter though. Sencha doesn’t solve the problem by doing something totally different, they do so by adding value on top of the hybrid app model.

  2. Nick Harlow says

    Hi Rob,

    Thanks for your comment. I’m happy to clarify and provide some more context around Sencha’s approach to hybrid development and application mobility. Sencha Space was created as a response to persistent challenges our clients and developer community identified with the existing hybrid development model. We specifically set out to address these issues more effectively and comprehensively than the existing technologies.

    To that end, Sencha Space has no dependencies on any native packager anywhere in the solution. Not only that, but Sencha Space is independent from other Sencha technology such as Sencha Cmd and the frameworks (Touch and ExtJS.) We did this because we wanted to be able to help any HTML5 developer deploy and manage their applications, not just the developers who use Sencha frameworks. Please let me know if I can provide any other information.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>