Applying Service Tooling to Mobile Projects

When a company grows, the tooling that helped small teams move quickly starts to show its limits. Teams adopt different tools for similar problems, which makes it hard for a central tooling group to build one solution that works for everyone. Knowledge sharing suffers, developers struggle to contribute outside their own projects, and when an incident happens only a few people have enough context to respond.

Shopify aims to keep teams highly aligned but loosely coupled—able to work independently while sharing common goals. To achieve that at scale, engineers have leaned heavily on enforced tooling for web services: automated checks that standardize CI, testing, deployment, and production environments. The same discipline was missing on mobile, where the team had shipped useful tools but couldn't make sure they were actually used.

Defining a Contract for Mobile Apps

Shopify has several apps across the App Store and Google Play, and checking which tools each project used meant digging through configuration files and scripts scattered across repositories. To solve this, the mobile tooling team extended ServicesDB, the internal system that tracks all production services at Shopify. ServicesDB exists to track services company-wide, define what owning a service means, and provide owners with tools to improve their infrastructure. Applying it to mobile apps treats each app as a service with an owner and a set of expectations codified in a configuration file.

That configuration drives automatic checks, each with instructions on how to pass it. The checks fall into these categories:

  • Service ownership—each project has a responsible team or individual accountable for maintenance, development, and handling requests or issues about the app.
  • Contact information—Slack channels are designated for questions and for notifying teams when their projects fail required checks.
  • Testing and deployment configuration—CI and Shipit Mobile, Shopify's mobile release tool, must be correctly set up so a new version of any app can be shipped at any time.
  • Versioning—apps must run the latest versions of internal tools, ensuring dependencies don't include known security vulnerabilities.
  • Monitoring—bug tracking services are configured to detect production errors and crashes.

When a check fails, the system automatically files a GitHub issue that explains the problem and tells the team how to fix it. In practice, these failures typically come from an outdated Ruby version or a missing bug tracker configuration.

Reducing the Surface Area for Developers

The advantage of these checks is that they remove the need to read every project's configuration to understand which tools it uses. A team can see immediately whether a project is eligible for Shopify's mobile tooling and, if not, why a tool or command isn't working. This levels the playing field without requiring new team members to absorb years of context about how mobile projects are set up.

The point is to make tooling and configuration a solved problem so mobile developers don't have to think about it. Instead, they spend their time on commerce problems that improve the buyer and merchant experience.

So far the checks are basic, but the roadmap includes defining service level objectives for mobile apps, streamlining new project creation, and reducing build times—confident that those tools work as long as the contract defined by ServicesDB is met.