I love native apps, but for large enterprise projects they’ve been making less and less sense as mobile devices have become more powerful and the modern browser capabilities have exploded in the recent years.
One particularly important aspect of mission- critical mobile app is the risk involved with rolling out each new version. Imagine waiting out the 10 day approval period from Apple only to discover that you had a royal screw up and now the production version is unusable. Now you need a day or two to fix the issue, then another 10 days for approval, all while your app is unusable? A single occurrence can be enough to destroy your business.
Consider the advantages that a hybrid app can offer you in this case, illustrated in the following fictitious scenario, based on real life implementations I’ve been involved with:
- The hybrid app stack is based on PhoneGap and Sencha ExtJS6
- Has not needed an app store redeploy in years because the native code has no need to change
- The app downloads its JavaScript code dynamically
- Depending on the organizational unit that the user belongs to, or whatever organization they are choosing to operate in during their session, a different version of the JavaScript code is downloaded
- A seamless transition between different versions of code occurs as the user navigates between different organizational units
This approach allows you to perform staged rollouts of new production code, or to perform AB testing on potential code candidates, within isolated organizational units, without risking mass disaster, with no regards for the app store or the 10 day waiting period. Try doing that with a native app.
Now some of you might be thinking “but it’s against some policies to remote download code” and I say “welcome to the big league, boys”. When we are talking about multi billion dollar enterprises, it costs peanuts to “persuade” Apple to “overlook” these policies and countless businesses operate based on this model.
Hybrid Apps: Staged Rollouts,