How to structure an Appium framework that scales beyond one team

Single-module Appium frameworks work great — until a second team needs to use them.

It starts small. A shared utility gets copy-pasted into another repo because it's quicker than figuring out how to share it properly. One team upgrades Appium. The other can't follow without breaking half their tests. What started as one shared framework is now three slightly different versions, each maintained by a different team, with no clear owner and no easy way to keep them in sync.

The answer isn't more coordination. It's an architectural decision made early: stay single-module, or build something teams can share without forking.

Here's what the full guide walks through:

• 🧱 When a single module is genuinely enough (and when it isn't)
• 📦 Setting up a Maven multi-module project with a clean parent POM
• 🌱 Why Spring Boot integration has to happen early, not retroactively
• 🔀 The dependency direction rule that keeps your core reusable
• 🏗️ How a core + team-tests split maps to multi-team scaling later
• ⚠️ BOM imports, packaging types, and module naming — the Maven mistakes that silently break builds

When you bring Spring Boot into a Maven framework, import the BOM in your parent POM's instead of inheriting from spring-boot-starter-parent. Inheriting forces your parent POM to extend Spring's parent, which takes over your inheritance hierarchy. The BOM gives you the same managed versions without that trade-off — Spring Boot dependencies need no explicit version declarations.

The full guide covers the parent POM setup, module layout, dependency graph, and the architectural decisions that make this framework usable by 20+ teams without forking.

👉 Read the full guide here: https://www.mobile-automation.io/scalable-mobile-test-framework/