Android applications offer a diverse range of options for deploying apps within organizations. This section provides a concise overview of the available choices for provisioning Android devices and distributing applications to them within your organization. Android’s flexibility and the accessibility of hardware across various platforms make it the default choice for developing internal applications. This article aims to guide you through the critical concepts and the three primary methods of deploying Android applications within your organization.

Core Concepts: GMS and Management

Before delving into the deployment methods, it’s essential to grasp two core concepts:

Google Mobile Services (GMS): Android has various implementations, with GMS being a significant consideration. GMS-certified devices have undergone Google’s assessment, ensuring compliance, security, and access to Google services like the Play Store. However, some cases may require Android devices without GMS due to data privacy concerns.

Device Management: Understanding the level of control over the devices is crucial. Consider whether devices will be fully managed, partially managed, or unmanaged. This relates to whether applications can be installed on externally controlled devices.

There are generally three approaches to device management:

Fully Owned: The organization has full control over the device, typically through Mobile Device Management (MDM) services.

Corporate Owned Personal Environment (COPE): The device is owned by the organization but may contain personal data, requiring clear segregation.

BYOD (Bring Your Own Device): Employees bring privately owned devices into the organization’s scope, necessitating a separate profile and fenced-off area for organization-deployed apps and data.

Three Main Deployment Options

With these core concepts in mind, let’s explore the three primary options for deploying Android applications within your organization:

1. Sideloading:

  • Simple, quick, and cost-effective.
  • Users click a link to install the app.
  • Requires users to enable installations from unknown sources.
  • No monitoring of app installations or updates.
  • Manual updates can be burdensome for both users and the organization.
  • Suitable for small organizations or limited internal testing.

2. Distribution via Google Play:

  • Leverages Google Play’s private functions for controlled distribution.
  • Users access the app via Google Play but are restricted to specific Google accounts or groups.
  • Offers a full app experience with updates, monitoring, and staging rollouts.
  • Requires Google accounts and approval for each app release.
  • Limited control over the presentation and deployment experience.
  • Suitable for organizations comfortable with Google and deploying on GMS-supported devices.

3. Distribution via MDM (GMS/Play Store Backed):

  • Suitable for larger organizations with corporately owned devices.
  • Apps are still uploaded to Google Play but installed and updated via MDM.
  • Provides more control with forced installations, no need for Google accounts, and silent updates.
  • Automated checks ensure quicker approvals for app releases.
  • Ideal for organizations seeking control, reporting, and scalability.
  • Worth considering for organizations supplying 20+ devices.

Distribution via MDM to non-GMS Platforms:

  • Appropriate for dedicated hardware devices outside the typical Android phone category.
  • Provides flexibility when the OS is not GMS-certified.
  • Offers various deployment options but may lack certain features like staged rollouts.
  • Requires careful consideration of the MDM’s compatibility with your unique use case.

Selecting the right method for distributing Android applications within your organization depends on factors such as user base size, technical proficiency, and the need for control and security. Whether you choose direct APK distribution, Google Workspace’s Private Marketplace, or opt for an Enterprise Mobility Management (EMM) solution, understanding the strengths and limitations of each approach empowers you to make informed decisions aligning with your organization’s goals and requirements.

Rolling Out to Test Users:

While public deployment can offer widespread accessibility and visibility, there are circumstances where privacy and exclusivity are paramount. In the next section, we’ll delve into the world of private apps, shedding light on their unique characteristics and the scenarios in which they become a strategic necessity. Join us as we uncover the compelling reasons behind the discreet realm of private apps and why they hold a pivotal role in certain organizational landscapes.

App Store Rollout:

One important consideration is the order of rollout to different app stores. It’s common to focus on the Google Play Store for the initial rollout, given its tools to support this phase. iOS users tend to spend more, making it prudent to wait until a build’s stability is ascertained in the real world before releasing to iOS.

Post Go-live:

After the release, a few days will pass before the majority of users have upgraded to the new version. Some users may continue to use older versions, which is important to consider when addressing error reports. Implementing a force update function can help move users off outdated versions with critical bugs.

Crashlytics and Diagnostics:

Every modern technical project with a substantial user base should have Crashlytics installed. These tools report live errors from users, providing complete oversight of your product’s robustness. Monitoring this in the days after release is crucial. The reports contain the app version number, making it easy to spot new bugs and assess their severity.

KPI Monitoring:

Integration with an analytics platform allows you to examine your app’s key performance indicators (KPIs) on a version-by-version basis, helping you identify high-level negative impacts of new versions in the days after a release. This data can guide your decision to continue with the rollout or investigate potential issues.

Successful releases require a delicate balance of speed and quality. Larger tech teams with extensive resources can afford the luxury of meticulous quality assurance and testing processes, ensuring that releases are virtually error-free. However, for smaller and growing projects, the pressure to meet tight deadlines often means taking calculated risks. This delicate dance between innovation and reliability is where the real challenge lies.

The pre-release phase is a critical juncture in this journey. It’s a time when you must carefully manage the introduction of new features, balancing the urgency of meeting deadlines with the need to maintain a high level of quality. In this phase, the ability to A/B test features, toggle them on and off, and monitor their performance is invaluable. These strategies allow you to spot errors sooner, minimize risks, and bring features to market in a manner that is both efficient and reliable.

Yet, the release itself is only part of the equation. The post-release phase plays an equally vital role in the app’s success. This phase involves monitoring and ensuring the stability of the app as users begin to update. It’s a time of heightened vigilance, where you must be prepared for the unexpected. By closely tracking crash reports, analyzing user behavior through key performance indicators (KPIs), and maintaining flexibility in responding to user feedback, you can navigate the complexities of the post-release