Open App Markets Act
- Sponsor
- Sen. Blackburn, Marsha [R-TN]
- Committees
- Judiciary Committee (primary)
- Last action
- Jun 24, 2025
Bottom line
The Open App Markets Act seeks to curb the market power of dominant app store operators by mandating greater openness and competition in app distribution and payment processing.
What it actually does
This bill aims to increase competition in the app economy by imposing new requirements on large app store operators, termed 'covered companies.' It prohibits these companies from mandating the use of their in-app payment systems, restricting developer communications with users, or using nonpublic business information to compete with third-party apps. The bill also requires covered companies to allow users to install third-party apps and app stores through alternative means and to provide developers with equivalent access to operating system features.
Proponents argue
Proponents argue that the bill will foster a more competitive and innovative app ecosystem by empowering developers and giving consumers more choice. They contend that by preventing 'gatekeeper' platforms from self-preferencing and imposing restrictive terms, the bill will lead to lower costs for consumers, fairer treatment for developers, and a wider array of high-quality apps and services.
Opponents contend
Opponents contend that the bill could compromise user security and privacy by allowing unvetted apps and payment systems onto devices, potentially increasing exposure to malware and fraud. They also argue it would undermine the business models that fund platform development and maintenance, leading to a fragmented user experience and reduced investment in the underlying technology.
The bill is relatively short and its core provisions are clearly articulated, making it accessible for an informed reader to evaluate within a reasonable timeframe.
Sec. 2(3)
Definition of 'Covered Company'
This provision defines which companies are subject to the Act's regulations. A 'covered company' is any person that owns or controls an app store with over 50 million monthly users in the United States and also controls the operating system on which that app store operates. This effectively targets a small number of dominant technology companies.
Supporters argue
Proponents argue that this definition is crucial for targeting the specific market power issues associated with a few dominant platforms, ensuring the regulations are applied where they are most needed to restore competition.
Critics contend
Opponents might argue that the definition is overly narrow or unfairly targets specific companies, potentially creating an uneven playing field for other large digital service providers that may not meet both criteria.
Tradeoffs
The tension lies in precisely defining 'gatekeeper' power without inadvertently capturing smaller players or creating loopholes for those intended to be regulated. The specific user threshold and operating system control criteria aim to strike this balance.
Sec. 3(a)(1)
Prohibition on Mandatory In-App Payment Systems
This provision forbids covered companies from requiring app developers to use their own in-app payment systems as a condition for distributing an app on their app store or making it accessible on their operating system. This means developers can offer alternative payment methods.
Sec. 3(a)(2)-(3)
Prohibition on Anti-Steering and Price Parity Clauses
This section prevents covered companies from requiring developers to offer equal or more favorable pricing on their app store compared to other app stores. It also prohibits punitive actions against developers for using different pricing or offering access to third-party apps/games through remote services rather than direct app store downloads.
Sec. 3(c)
Restriction on Using Nonpublic Business Information
This provision prohibits covered companies from using nonpublic business information derived from a third-party app for the purpose of competing with that app. This aims to prevent platforms from leveraging data collected from developers to create competing products.
Sec. 3(d)
Interoperability and Sideloading Requirements
This provision requires covered companies to allow users to choose third-party apps or app stores as defaults, install third-party apps or app stores through means other than the covered company's app store (often called 'sideloading'), and hide or delete preinstalled apps or app stores.
Sec. 3(f)
Open App Development (Access to OS Interfaces and Features)
This provision mandates that covered companies provide developers with access to operating system interfaces and hardware/software features that are generally available to the public. This access must be timely and on terms equivalent to those offered to the covered company's own apps or business partners, along with sufficient documentation.
Sec. 4(a)-(b)
Security and Privacy Safeguards and Requirements
This section provides exceptions to the Act's prohibitions, allowing covered companies to take actions necessary for user privacy or security, to prevent spam/fraud, intellectual property infringement, or to comply with law. However, such actions must be applied consistently, narrowly tailored, and certified under penalty of perjury by a principal executive officer, ensuring they are not a pretext for anti-competitive behavior.
Sec. 5(b)
Private Right of Action for Injured Developers
This provision allows any developer injured by a violation of the Act to sue in federal court for treble damages (three times the actual damages sustained) and injunctive relief. It explicitly excludes developers owned or controlled by a foreign state from bringing such actions.
Requires the principal executive officer(s) of a covered company to submit a certification under penalty of perjury that any action taken for user privacy or security is not a pretext to exclude or impose discriminatory terms on third-party apps or payment systems.
Sec. 4(b)(2)
Why it matters:This is standard legislative practice to place specific requirements within the relevant operational section. However, its significance for executive accountability might be overlooked by a casual reader.
Case for: Proponents argue this certification adds a strong layer of personal accountability for corporate executives, making it harder for companies to use security claims as a pretext for anti-competitive behavior, thereby strengthening the bill's core intent.
Case against: Opponents might argue that such a requirement places an undue burden on executives and could lead to excessive caution or legal challenges over the interpretation of 'pretext,' potentially hindering legitimate security responses.
Estimated impact: Increases executive liability and forces careful consideration of security-related actions, potentially reducing the likelihood of pretextual exclusions.
Clarifies that the Act does not require a covered company to interoperate or share data with any person or business user identified on Federal Government sanctions lists, as a national security/intelligence/law enforcement risk (including the Government of the People's Republic of China or foreign adversaries), or engaged in illegal/fraudulent activity.
Sec. 7(6)
Why it matters:This is a common legislative technique to ensure the bill's primary intent (promoting competition) does not inadvertently conflict with other critical national security or law enforcement objectives. It's not necessarily evasive, but easily missed.
Case for: Proponents argue this provision is essential to prevent the bill from being exploited by malicious actors or foreign adversaries, ensuring that increased interoperability does not compromise national security or facilitate illegal activities.
Case against: No specific opposition is typically raised against this provision, as it addresses widely accepted national security and law enforcement concerns. However, some might argue about the breadth of 'national security risk' definitions.
Estimated impact: Provides a clear legal basis for covered companies to refuse interoperability or data sharing with entities deemed national security risks or engaged in illicit activities, maintaining a level of control for critical security functions.