High-level dual-mode app behavior
When the app launches for the first time
When a dual-mode app launches for the first time, it does not know whether it is managed by Ivanti. It does the following high-level steps:
| 1. | Sets its initial dual-mode state to Undecided. |
| 2. | Starts the AppConnect library. |
| 3. | Waits for an event from the AppConnect Cordova Plugin indicating whether Ivanti is managing the app. For example, one typical reason that Ivanti is not managing the app is that the client app is not installed on the device. |
| 4. | Changes its state to AppConnect Mode or Non-AppConnect Mode according to the event. |
| - | When changing to Non-AppConnect Mode, the app notifies the AppConnect library that it is retiring. Normally, the Ivanti server decides when to retire an app. In this case, the app is retiring itself. Then the app stops the AppConnect library. It behaves as a regular app. |
| - | When changing to AppConnect Mode, the app behaves as an AppConnect app. |
| 5. | Stores the dual-mode state persistently for the next time it launches. |
For more details, including specific API calls for these steps, see API call sequence when the app launches for the first time.
When an app subsequently launches
On subsequent launches, the app does the following high-level steps:
| 1. | Gets the dual-mode state that it stored. |
| 2. | Checks the dual-mode state. |
| 3. | If the state is AppConnect Mode, starts the AppConnect library. |
The app continues as an AppConnect app.
| 4. | If the state is Non-AppConnect Mode, continues as a regular app. |
The app does not start the AppConnect library.
For more details, including specific API calls for these steps, see API call sequence when the app subsequently launches.
User requests to switch to Non-AppConnect Mode
A dual-mode app provides a user interface that allows the device user to explicitly request that Ivanti no longer manage the app. That is, the user requests a change to Non-AppConnect Mode. This user interface can be useful if a device user leaves an enterprise, but still wants to use the app as a regular app.
Users are typically not aware of the term “AppConnect”. Therefore, the user interface should use other terminology. For example, an app can use “Managed by Ivanti” in its user interface. Another possibility is “Secure enterprise mode”.
When switching from AppConnect Mode to Non-AppConnect Mode, the app does the following high-level steps:
| 1. | Removes all its secure data, since regular apps do not have secure data. |
| 2. | Notifies the AppConnect library that it is retiring. |
Normally, the Ivanti server decides when to retire an app. In this case, the app is retiring itself.
| 3. | Stops the AppConnect library. |
| 4. | Stores its dual-mode state, Non-AppConnect Mode, persistently for the next time it launches. |
| 5. | Continues running as a regular app. |
For example, the app no longer enforces AppConnect policies.
For more details, including specific API calls for these steps, see API call sequence when user requests Non-AppConnect Mode.
User requests to switch to AppConnect Mode
A dual-mode app provides a user interface that allows the device user to explicitly request that Ivanti manage the app. That is, the user requests a change to AppConnect Mode. For example, device users in an enterprise sometimes have installed and used an app before the enterprise requires it as an AppConnect app.
Users are typically not aware of the term “AppConnect." Therefore, the user interface should use other terminology. For example, an app can use “Managed by Ivanti” in its user interface. Another possibility is “Secure enterprise mode.”
When switching from Non-AppConnect Mode to AppConnect Mode, the app does the following high-level steps:
| 1. | Starts the AppConnect library. |
| 2. | Changes to the Pending AppConnect Mode state. |
| 3. | Waits for an event from the AppConnect library indicating that Ivanti is managing the app. |
| 4. | If the app receives the event that Ivanti is managing the app, the app changes state to AppConnect Mode, and persistently stores the new state. It begins behaving as an AppConnect app. For example, it enforces DLP policies. |
For more details, including specific API calls for these steps, see API call sequence when user requests AppConnect Mode.
Data loss prevention policy handling
When a dual-mode app changes from Non-AppConnect Mode to AppConnect Mode, it starts enforcing the AppConnect data loss prevention policies that it supports. For example, if the app supports the Open In policy, it allows document sharing only as directed by the policy it receives from the AppConnect library. When changing to Non-AppConnect Mode, the app stops enforcing the AppConnect DLP policies.