An overview of how we are complying with Japan’s Mobile Software Competition Act (MSCA).
What the Act Aims to Change
Japan’s Mobile Software Competition Act (MSCA) targets the power that a small set of mobile platforms hold over how software reaches users. It focuses on practices that can lock developers into a single store, a single payment path, or a single set of system APIs. The goal is not to punish platforms for existing. It is to keep distribution, billing, and default choices open enough that smaller products can compete on merit rather than on access to a gatekeeper’s stack.
For anyone shipping apps or mobile backends, that means compliance is less about a one-time legal checklist and more about how product, engineering, and support decisions are structured. If your app depends on exclusive store rules, mandatory in-app billing, or hard-coded defaults, you need a plan for alternatives before those choices become legal or commercial liabilities.
Map Where Your Product Touches the Rules
Start by inventorying every place your product interacts with a mobile platform’s competitive choke points. That usually includes app distribution, in-app purchase and subscription billing, system-level defaults (browser, search, assistant, keyboard), and any use of platform APIs that rival services cannot call on equal terms. Write down what is required by the platform, what is required by your own product design, and what is merely historical habit.
This map should be concrete enough that legal, product, and engineering can share one view. For each touchpoint, note: who controls the user choice, whether users can switch without friction, and whether a competitor could offer the same capability. Gaps in that map are where compliance risk hides—especially when a “convenience” default quietly becomes a de facto exclusive arrangement.
Practical Compliance Patterns
Once the map is clear, design for choice rather than for capture. Prefer flows that let users install from more than one source when the law and platform rules allow it. Support payment and subscription paths that do not force every transaction through a single processor when alternatives are required or available. Avoid dark patterns that make leaving your default hard to reverse. Treat equal access to platform APIs and capabilities as a product requirement, not a nice-to-have for partners.
- Document user choice points: install source, payment method, and default apps or services.
- Separate “platform-required” constraints from “product-preferred” ones so you can change the latter quickly.
- Log and test switching paths so support can walk users through alternatives without friction.
- Review contracts and SDK terms that limit multi-store or multi-billing options.
Engineering should treat these as first-class requirements: feature flags for billing providers, clear deep links for alternative install or payment flows, and telemetry that shows whether users can complete a switch without dead ends. Product and legal should agree on what “fair default” means in your UI before marketing ships a campaign that hard-codes a single path.
How We Operate Day to Day
Compliance under the MSCA works best as an ongoing operating model. We review new features against the same choke-point map used for existing products. Store listing changes, billing experiments, and default-setting prompts go through a short gate that asks whether the change reduces user choice or rivals’ access. When a platform policy and the Act pull in different directions, we escalate early rather than shipping and reverse-engineering later.
We also keep internal runbooks for support and incident response: how to explain alternative payment or install options, how to fix a broken switch path, and who owns a policy conflict. The measure of success is simple: a user or a partner developer can leave a preferred path without unfair friction, and our team can demonstrate that path with evidence—not slogans. That is how we stay aligned with the MSCA’s purpose while still shipping useful mobile software.