 |
 |
| |
The team can create a variety of shells, each carrying different policies and branding, forcing inner apps running within each shell to automatically comply with its parameters. Such parameters could include restriction of access to data, use of certain APIs, different branding and more. |
 |
| |
With corporate policies enforced by the shell, the inner apps can be easily built by departmental development teams using nothing but web languages. Such teams are only required to focus on the user interface, the business logic and, potentially, data integration. Distribution of the application or applications can be achieved by three different channels: |
 |
| |
An inner app can be fused into a shell by the centralized build server and |
| |
uploaded to a private or public application store, while new app versions |
| |
are sent and updated directly on the end-user device. |
| |
A shell can be packaged with a directory of corporate-sanctioned applications, |
| |
allowing the user to choose a different inner app according to his or her needs. |
| |
A shell can be distributed empty to the user who will then access a repository of |
| |
applications stored on the Server. |