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 MobileIron. It does the following high-level steps:

Sets its initial dual-mode state to Undecided.

Sets its initial encryption state to Unencrypted.

Checks whether AppConnect is available.

If AppConnect is not available, the app changes its dual-mode state to AppConnect Not Available, and continues as a regular app.

If AppConnect is available, the app starts the AppConnect library.

Waits for a notification from the AppConnect library indicating whether MobileIron is managing the app.

Changes its dual-mode state to AppConnect Mode or Non-AppConnect Mode according to the notification.

When changing to Non-AppConnect Mode, the app notifies the AppConnect library that it is retiring. Normally, the MobileIron 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. However, the app changes its data encryption state to Encrypted only if secure apps are available and the secure file I/O policy requires secure file I/O. The app uses the data encryption state to determine whether it can use secure file I/O APIs.

Stores both the dual-mode state and data encryption state persistently for the next time it launches.

NOTE:

For more details, including specific API calls for these steps, see API call sequence when the app launches.

When an app subsequently launches

On subsequent launches, the app does the following high-level steps:

Gets the dual-mode state and data encryption state that it stored.

Checks the dual-mode state, and takes the following actions depending on the state.

AppConnect Mode: Starts the AppConnect library.

The app continues as an AppConnect app. It uses the data encryption state to determine whether it can use secure file I/O APIs.

Non-AppConnect Mode: Continues as a regular app.

The app does not start the AppConnect library.

AppConnect Not Available: Checks whether AppConnect is available.

If AppConnect is not available, the app stays in AppConnect Not Available, and continues as a regular app.

If AppConnect is available, the app starts the AppConnect library, and waits for a notification indicating whether MobileIron is managing the app.

After receiving the notification, changes its dual-mode state to AppConnect Mode or Non-AppConnect Mode according to the notification.

Stores both the dual-mode state and data encryption state persistently for the next time it launches.

NOTE:

For more details, including specific API calls for these steps, see API call sequence when the app launches.

User requests to switch to Non-AppConnect Mode

A dual-mode app can provide a user interface that allows the device user to explicitly request that MobileIron 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. The dual-mode sample app uses “Managed by MobileIron” 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:

Removes all its secure data, since regular apps do not have secure data.

Sets the data encryption state to Unencrypted, and stores it persistently for the next time it launches.

Notifies the AppConnect library that it is retiring.

Normally, the MobileIron server decides when to retire an app. In this case, the app is retiring itself.

Stops the AppConnect library.

Stores its dual-mode state, Non-AppConnect Mode, persistently for the next time it launches.

Continues running as a regular app.

For example, the app no longer enforces AppConnect policies or uses AppConnect features such as secure file I/O.

NOTE:

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 can provide a user interface that allows the device user to explicitly request that MobileIron 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.

When switching from Non-AppConnect Mode to AppConnect Mode, the app does the following high-level steps:

Starts the AppConnect library.

Changes to the Pending AppConnect Mode state.

Waits for a notification from the AppConnect library indicating that MobileIron is managing the app.

If the app receives the notification that MobileIron 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.

If secure services are available and the secure file I/O policy requires secure file I/O, the app changes the encryption state to Encrypted. The app decides what to do with existing data as described in Actions when changing to the Encrypted state.

NOTE:

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 handles the AppConnect data loss prevention policies that it supports. For example, if the app supports the Open In policy, based on the policy it receives from the AppConnect library, it enables or disables any Open In user interfaces. When changing to Non-AppConnect Mode, the app stops handling the AppConnect DLP policies.