Delivering the right apps and resources to users at the right time is critical to delivering a positive employee experience, which in turn is paramount to enterprise organizations. A device without the appropriate apps could have little to no value to users and be costly to a business that has invested in the solutions. Similarly, apps that are difficult to use, bug-riddled, or insecure can be a distraction and cause more problems than they solve.
Most organizations in this modern time employ dedicated development teams that create apps specific to their business’s requirements. However, app development doesn’t stop after the launch of version 1.0. Business goals and challenges evolve along with associated platforms, external and peripheral systems. As systems change, bugs and vulnerabilities are continuously discovered and reported. Development teams must continue to innovate and patch their apps for as long as the business wants users to be productive with the app.
Over the history of enterprise app development, the landscape has evolved and grown to be more modern and rapid. It can be daunting for new teams looking to launch applications to their users, which is why Apple themselves have released support articles and best practices regarding how to manage the application lifecycle for enterprises. And with Workspace ONE, deploying and maintaining these apps has never been easier. This article will be your guide to what has changed over the years and how IT teams and engineers should think about this lifecycle.
Why the app lifecycle is important
Most teams are accustomed to iteratively managing devices to maximize their longevity and their productivity over that span. It is fair to ask the question “why a similar process is needed for the applications that live on these devices,” as well.
Arguably, an essential reason to continually tweak and update apps is to deliver increasing value to users. These updates likely translate to cost savings or increased productivity in the form of bug fixes, innovative new features, or user experience improvements. Massaging the code quality and feature set can keep users coming back and recommending these apps to their coworkers. Updates generate a snowball effect of exponential adoption and justifying future investment into the solution.
Another benefit of app lifecycle maintenance is standardization across the organization. Uniformity can be important for both end-users and engineering teams. Engineers who may work on multiple apps can more effectively deliver new features and fixes if the release and delivery processes is familiar. Effectiveness compounds if a more significant percentage of the organization’s device fleet is on the same version, driving down delays and cost of doing business for these apps. Meanwhile, users moving to new teams or leveraging new apps are much more likely to be comfortable with periodic updates and changes if they are consistent with what they’re used to seeing.
Lastly, maintaining a consistent app lifecycle can offer improved security for the organization. With a streamlined process for administering updates, platform vulnerabilities and risks can be patched and often mitigated automatically and before the issue is publicly released.
How to deliver applications
Updating applications is essential but ultimately useless if not reliably delivered to devices. Often, this is half the battle when developing as this method not only needs to work one time but repeatedly as more updates are released. Luckily, with Workspace ONE, there are multiple methods to deliver apps to devices, each with its own advantages. Use this page to select the method that is right for your organization.
Public App Store
The most well-known method for deploy applications for your internal teams is using Apple’s public App Store. Users are familiar with the App Store experience, and Apple offers several advantages to leveraging its App Store. However, to recognize these advantages, Apple requires submission and review of all apps in their store. This may not work for many organizations who do not want their internal applications available for public download, or they may potentially violate Apple’s Terms of Service Agreement. Apple also sets standards and user experience requirements that must be met, such as visually supporting Apple’s latest iPhone models that require additional overhead for development.
| Pros | Cons |
| Automatic updates | Apple review process can delay emergency releases |
| Access to TestFlight for testing | Apple review process may flag apps for breaking terms and conditions |
| Able to publish notes and screenshots to help users | Only one supported version |
| Able to be viewed by all Apple users |
Internally-deployed apps
Currently, the most common method for delivering enterprise applications to enrolled devices involves uploading (or externally linking) .ipa (for iOS) binary files directly to Workspace ONE and instructing the device to install the app via MDM. This method gives full control to developers and admins to deploy these apps and their different versions to alpha, beta, and production groups of users. Each new version for each app must be uploaded and assigned independently which can be cumbersome. This approach also requires admins to manage mobile provisioning profiles and their renewal. Although Workspace ONE APIs can automate this process, some development effort is required. Lastly, it is important to call out that at WWDC 2019, Apple stated that some businesses new to the developer program would be unable to use this method without prior approval by Apple. This likely indicates a plateau or decline of this approach’s availability in the future.
| Pros | Cons |
| Can support multiple production versions simultaneously | Requires Apple enterprise signing certificate |
| No approvals required allowing for quick turnaround time | Requires management of provisioning profile |
| Flexible APIs to automate testing and delivery | Multiple supported versions can be challenging |
| Requires enterprise signing certificate for mass deployment which may be difficult to obtain |
Custom App Store (formerly B2B)
While this method has existed for a while, Apple recently implemented new capabilities that make Custom apps the best all-around solution for many organizations. Apple built the Custom App Store for distributing business-to-business apps without requiring the developer to provide raw Xcode projects via MDM or uploading apps to the public App Store.
The Custom app store was also updated to be a method for organizations to deploy their apps directly to their employees (called In-House apps by Apple). With this change, organizations can leverage all the benefits of the App Store without exposing their organization’s apps to all Apple App Store users. This change also gives access to TestFlight for easy testing and automatic updates with no changes in Workspace ONE UEM. At its core, the Custom app approach is the “best of both worlds” model and should be strongly considered by most organizations.
| Pros | Cons |
| Automatic updates
|
Although unlikely, Apple review process may flag apps if there are issues |
| Access to TestFlight for testing
|
Only one supported version |
| Available to all organizations | |
| Apple review process is streamlined expedited |
Check out our full guide on TechZone for how to implement Custom Apps in Workspace ONE UEM.
How to prepare devices for app updates
Once an application delivery method has been selected and implemented, organizations should review how they prepare their devices for continuous application updates. Developers should regularly deploy updates to keep apps running smoothly and delivering value. Of course, these updates can sometimes cause problems if devices or users are not prepared. There are a few organizational procedures that can minimize the risk while maximizing the number of updates deployed.
Standardize OS update versions
Testing and deploying application updates are complex and critical processes—and the complexity compounds as the number of operating system versions increases. Although the landscape is not as fragmented as Android, iOS still has millions of devices that are greater than two major OS versions behind. This fragmentation means changes should be tested multiple times for backward compatibility, or the team needs to assume the risk of issues appearing on older OS versions. The easiest method to avoid these two scenarios is a disciplined OS update management process.
At the simplest level, standardizing your device fleet on a specific OS version is a trivial matter within Workspace ONE UEM. The first action is to select the approved version or group of versions for your devices. Typically, it is best practice to standardize on a major and minor version (e.g., updating devices to iOS 13.4.X instead of just iOS 13.X), but broadening policy to only a major release may be more predictable and achievable. With Workspace ONE UEM’s OS update framework, admins can quickly review the OS versions available from Apple, target a specific version, and deploy the update to devices. This automation limits the variability of OS versions across a device fleet by quickly and automatically fixing discrepancies.
Review our video on OS Updates management to learn more about these best practices.
Defer new, untested OS versions for up to 90 days
Even with devices on a standardized version, there is risk depending on how well-vetted an organization’s app is on that version. Often, the latest available iOS update has new features and platform issues that are undiscovered until after the update is generally available. Essentially, the longer an update is available, the more the update stabilizes and mitigates risk for your apps. With Workspace ONE UEM, admins can defer any update for up to 90 days. This deferral gives developers and testers plenty of time to approve new releases on the latest version and to make it easier to standardize your fleet.
Establish beta, early adopters and production rollout groups
Often in organizations, testing in developer environments does not entirely reflect the large-scale production use of applications. Luckily, you can usually find a group of users that has the technical understanding to be comfortable using pre-production applications and communicating feedback. Organizations can leverage these users to offer additional live testing before releasing it to production. Discover which users in your organization are comfortable with this process and organize them into groups. Once new app updates reach milestones like beta readiness, distribute these apps to those groups for added testing and feedback. With TestFlight, it is easy to roll out beta versions, and with Workspace ONE UEM, it is easy to deploy updates to early adopters before general production groups.
Conclusion
Despite each organization’s uniqueness, developing applications for their critical business needs is paramount to keeping users effective in their roles. With Workspace ONE UEM, organizations can not only get their workers productive but keep them that way over time and across perpetual OS releases.
Find out more at https://www.vmware.com/products/workspace-one/ios-management.html
