Apple Removes BitChat From India’s App Store Under Section 69A: How the Government Went After a Bluetooth Mesh Messenger on Three Fronts

Apple has removed BitChat, the open-source Bluetooth mesh messenger built by Jack Dorsey’s team, from the India App Store at the direction of the Ministry of Electronics and Information Technology (MeitY), which invoked Section 69A of the Information Technology Act, 2000. Dorsey published Apple’s App Review notice on X on October 3, 2026, confirming the removal. It is the third front on which Indian authorities have moved against a messaging system that works without internet, phone numbers, or accounts. The first was mobile network shutdowns, the second a code-hosting takedown order against GitHub.

Apple’s notice says BitChat “includes content that is illegal in India” and identifies none. The government’s earlier filings against the project take the same line: they object to the app’s design and cite no message. For security researchers, privacy advocates, and platform-policy watchers, this is a state trying to ban a communications capability instead of moderating communications content.

Key takeaways

• Apple removed BitChat from the India App Store and disabled all public TestFlight links for the country, acting on a MeitY demand issued under Section 69A of the IT Act, 2000.
• The App Review notice cites Guideline 5 (“Legal”) and says the app “includes content that is illegal in India,” but names no specific content. That mirrors the capability-based rationale in the earlier GitHub takedown order.
• BitChat is a peer-to-peer, end-to-end encrypted messenger that routes messages over Bluetooth Low Energy (BLE) mesh networks. It keeps working when mobile internet and cellular service are shut down, as happened around New Delhi’s Jantar Mantar protest site in July 2026.
• In July, the Cyber Crime Coordination Centre (C4) ordered GitHub to delist the project’s source code under Section 79(3)(b). Mirrors of the repository appeared within hours.
• iOS effectively prohibits sideloading outside the EU’s DMA-mandated alternative marketplaces, so App Store removal works as a de facto national ban for iPhone users in India. Existing installs and Android/APK distribution paths continue to work.
• According to Apple’s notice, the app remains available in every other App Store territory the developer selected in App Store Connect.

The Apple notice: what it says and what it leaves out

The notice from Apple’s App Review team, shared publicly by Dorsey, is short, mostly boilerplate, and legally revealing. It tells the developer that the application, “per demand from the Ministry of Electronics and Information Technology (MeitY), will be removed from the India App Store because it includes content that is illegal in India, which is not in compliance with the App Review Guidelines.” It then quotes the relevant guideline in full:

5. Legal

Apps must comply with all legal requirements in any location where you make them available (if you’re not sure, check with a lawyer). We know this stuff is complicated, but it is your responsibility to understand and make sure the app conforms with all local laws, not just the guidelines below. And of course, apps that solicit, promote, or encourage criminal or clearly reckless behavior will be rejected.

The notice goes on to say that MeitY “issued the takedown demand under Section 69(A) of the (Indian) Information Technology Act, 2000,” and encourages the developer to “reach out directly to the Ministry of Electronics and Information Technology (MeitY)” for more information. It also confirms two operational details that matter in practice. The app stays live in all other territories configured in App Store Connect, and “the TestFlight version of this app will also be unavailable for external and internal testing in India and all public TestFlight links will no longer be functional.”

The notice contains a contradiction. BitChat has no servers, no moderation surface, and no user-generated content accessible to Apple. Messages are end-to-end encrypted and travel only between devices in radio proximity. Apple had no content to review, and the notice specifies none. According to the government’s July order against GitHub, the real objection is that the app “significantly impedes lawful interception, attribution, and investigation.” Apple did not rule on that claim. It mapped the demand onto Guideline 5, complied, and sent the developer to the ministry as the only avenue of recourse. That is Apple’s usual stance in territorial takedown disputes, and it is why transparency-report watchers treat App Store geography as a reliable map of local censorship pressure.

What BitChat is and how it works

BitChat departs from the client-server model that WhatsApp, Telegram, and Signal all depend on, which helps explain why the takedown took three separate legal instruments.

The Bluetooth Low Energy mesh, step by step

BitChat turns every running device into both a client and a relay node in an ad-hoc mesh network built on Bluetooth Low Energy. In simplified form, a message travels like this:

1. Discovery. Each device periodically broadcasts small advertising packets on BLE’s advertising channels, announcing a service identifier so nearby peers can find each other without a pairing ceremony or central directory.
2. Session establishment. When two peers discover each other, they open a GATT-based connection and perform an authenticated key agreement using ephemeral, device-generated keypairs (X25519-class elliptic-curve cryptography, per the project’s source). The result is an encrypted session with no server-issued certificates and no phone-number attestation.
3. Encrypted flooding. An end-to-end encrypted message, sealed so that only the intended recipient or channel members can read it, goes to connected peers along with a message identifier and a time-to-live (TTL) hop counter.
4. Deduplication and relaying. Each node checks the message identifier against a cache of recently seen messages. It accepts, stores, and re-broadcasts unseen messages to other neighbors with a decremented TTL, and drops duplicates. This flood-and-deduplicate scheme belongs to the same family of routing used by classical mobile ad-hoc networks and by other mesh messengers such as Briar and the late FireChat.
5. Store-and-forward delivery. If the destination device is out of radio range, intermediate nodes keep the ciphertext and deliver it when the recipient eventually comes into range. This delay-tolerant networking pattern lets messages travel through a crowd over minutes or hours, hop by hop, with no infrastructure at any point.

Individual BLE links are short-range, realistically tens of metres indoors and more in open air. In dense places such as a protest ground, a university campus, or a railway station, hundreds of devices form a connected graph, and multi-hop relaying extends coverage well beyond any single radio. None of this traffic touches an IP network, a cell tower, or a cloud service. A government that cuts mobile internet, or suspends cellular service entirely under Section 144 of the CrPC-era shutdown rules, has switched off nothing that BitChat depends on.

No phone number, no account, no KYC anchor

BitChat’s second conflict with Indian regulation is identity. Indian telecom law mandates KYC-verified SIM acquisition, so every WhatsApp and Telegram account in the country is ultimately anchored to a government-verified identity document. The Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 extend that logic online. Rule 4(2) obliges significant social media intermediaries providing messaging services to enable identification of the “first originator” of information under judicial or government order. WhatsApp has contested that provision in the Delhi High Court for years, arguing that traceability requires breaking end-to-end encryption for everyone.

BitChat sidesteps the whole framework by construction. It has no registration, phone number, email address, or server-side identity, and no persistent central log of who spoke to whom. Devices present ephemeral pseudonymous identifiers over the air. Attributing a ciphertext to a legal person requires physical proximity to the mesh and traffic-analysis capabilities that ordinary interception law never contemplated. That is a feature for users under surveillance or shutdowns, and it is the property the C4 described as impeding “lawful interception, attribution, and investigation.” In policy terms, BitChat is the first mainstream-visible app to make Rule 4(2)-style traceability architecturally impossible, and the Indian state has responded by treating the architecture itself as the violation.

How BitChat compares to other offline and encrypted messengers

Messenger	Transport	Internet required?	Identity anchor	Open source?
BitChat	BLE mesh, store-and-forward	No	None (ephemeral keys)	Yes
Briar	BLE / Wi-Fi Direct, Tor sync	Optional (sync only)	Local identity, no phone number	Yes
Meshtastic	LoRa radio hardware mesh	No	Node keys	Yes
FireChat	BLE / Wi-Fi mesh with internet fallback	Optional	None	No (service defunct)
Session	Onion-routed service nodes	Yes	Session ID, no phone number	Yes
Signal	IP over internet	Yes	Phone number	Yes
Telegram	IP over internet	Yes	Phone number	Clients only

That is why regulators keep running into mesh messaging during crises. It is the one category that survives a full connectivity blackout while staying usable by ordinary smartphone owners with no extra hardware.

Jantar Mantar and the shutdown playbook

According to Access Now’s #KeepItOn tracker, India imposes more internet shutdowns than any other country, year after year. They range from the eighteen-month cellular and broadband suspension in Jammu & Kashmir that began in 2019 to repeated district-level blackouts during unrest in Manipur, Punjab, and Rajasthan. Authorities use shutdowns as a law-enforcement tool on the theory that cutting connectivity cuts organisers’ ability to coordinate.

In July 2026, protesters found a way around that theory. Authorities suspended mobile networks around Jantar Mantar in New Delhi, the capital’s canonical protest ground, where students had gathered over a leaked medical entrance examination. The protesters moved their coordination onto BitChat, whose mesh kept working across the crowd because it needs no network. The episode turned BitChat from a curiosity into an operational problem for the state, and the escalation that followed was methodical. First the network layer was attacked, with shutdowns that proved insufficient. Then came the code layer, in the July C4 order to GitHub, and now the distribution layer, in Apple’s App Store and TestFlight. Each instrument targets a different dependency of the software, and together they make a template other governments could copy.

The three-front takedown

Date (2026)	Action	Legal instrument
June	Telegram blocked in India over the leaked exam	Section 69A, IT Act
July	Mobile internet suspended around Jantar Mantar; protesters migrate to BitChat	Shutdown orders
July	C4 orders GitHub to delist BitChat source code; mirrors appear within hours	Section 79(3)(b), IT Act
Oct 3	Apple removes BitChat from India App Store; public TestFlight links disabled	Section 69A, IT Act

The GitHub order set out the capability-based rationale that now reappears in Apple’s notice. It was issued under Section 79(3)(b), the provision that strips an intermediary of safe-harbour protection if it fails to act on actual knowledge of unlawful activity. It did not allege that any file in the repository violated any law. It alleged that the software’s design “significantly impedes lawful interception, attribution, and investigation.” GitHub, as is its practice, published the government takedown notice in a public archive and complied with the territorial request. The repository’s contents were forked and mirrored to alternative hosts, federated code forges, and content-addressed archives within hours, which shows again that code takedowns against a popular open-source project are largely symbolic. Dorsey responded at the time: “the government of India does not like technologies like BitChat and wants it taken down.”

The two legal instruments work differently. Section 79(3)(b) is a liability lever aimed at intermediaries who host third-party material. Section 69A is the state’s affirmative blocking power. It authorises directions to block “any information through any computer resource” for public access, backed by criminal penalty for non-compliance. Using 69A against an app distributor treats an app-store listing as “information through a computer resource” subject to blocking. The government used the same construction against Telegram in June, and before that against URLs, apps, and entire platforms in hundreds of orders. Those orders are usually invisible to the public because Rule 16 of the Blocking Rules mandates confidentiality.

Section 69A, the Blocking Rules, and the safeguards courts have read into them

Section 69A(1) lets the central government direct the blocking of public access to information when it is satisfied that doing so is necessary in the interests of sovereignty, integrity, defence, security, or public order, among other grounds. The Information Technology (Procedure and Safeguards for Blocking for Access of Information by Public) Rules, 2009 put the power into practice. A designated officer examines requests, issues notice to the originator or intermediary, offers a hearing, and records reasons in writing, and a review committee periodically audits orders.

Those procedural features matter constitutionally. In Shreya Singhal v. Union of India (2015), the Supreme Court struck down Section 66A of the same Act but upheld Section 69A, because its safeguards (notice, hearing, reasoned orders, committee review) narrowed the power to a tolerable form. In Anuradha Bhasin v. Union of India (2020), the Court applied proportionality reasoning to connectivity itself and held that shutdown orders must be published, temporary, and subject to judicial review.

Against that benchmark, the BitChat order raises questions the public record cannot yet answer. Did the developers receive notice and a hearing before their distribution was blocked? Do reasoned findings exist beyond the one-line “content that is illegal in India” formulation? How does a blocking order square with proportionality when the app’s alleged defect is its cryptographic design and no adjudicated unlawful speech is involved? Rule 16 confidentiality means the order text may never be published. Apple’s compliance notice, however, discloses the order’s existence, statutory basis, and territorial scope, so the usual secrecy has partly lifted, and challengers in the Delhi High Court would be quick to use that.

Why an App Store removal is a national ban on iOS

A single-country removal is routine in Apple’s transparency reports, which also record China’s VPN purges and territorial poker-app blocks. On iOS it carries more weight. Outside the European Union, where the Digital Markets Act forces Apple to permit alternative marketplaces and web-based distribution, the App Store is the only lawful installation path for iPhone software. India has no DMA analogue. Sideloading tools such as AltStore exist, but they need a computer, re-signing every seven days on free developer accounts, and a tolerance for friction that ordinary users do not have. Those users (the people who most need a shutdown-resistant messenger in an emergency) are the ones left without it.

BitChat’s iOS presence began as a TestFlight beta, and public TestFlight links were how many Indian users got the app before its formal release. Apple’s notice confirms those links are dead in India. TestFlight builds expire ninety days after upload under Apple’s own policy, so the beta cohort will shrink to zero even if nobody uninstalls anything. Existing App Store installs will keep running and meshing with each other, since removal from a storefront does not reach into devices. They will receive no further updates, which is a real security problem for a cryptographic protocol. Every future vulnerability disclosure, BLE stack change, or iOS compatibility break becomes permanent for the frozen Indian install base.

Android is different. It permits direct APK installation, and open-source projects routinely distribute builds through GitHub releases or F-Droid-style repositories. By going after the App Store, MeitY has imposed a near-total ban on iPhone users and a speed bump for Android users. Platform governance, more than statute, decides how much a takedown order bites. Guideline 5 puts responsibility for “all local laws” on developers, but in practice Apple’s compliance decisions determine whether Indian citizens can install privacy-preserving software at all. The walled garden makes Apple the enforcement endpoint of every local blocking order it accepts.

Does removing the app remove the network?

Not immediately and not completely, which is presumably why the takedown came in three waves instead of one. Every device in India already running BitChat continues to advertise, relay, and deliver messages, because a mesh has no central switch to flip. Forks of the source code remain buildable by anyone with a toolchain, and Android packages circulate outside store control. The repository mirrors created after the July GitHub order are, if anything, more widely distributed now than the original.

App Store removal targets adoption. Mesh messaging depends on network effects: a mesh of three phones is useless, and a mesh of three hundred can be a lifeline. Store removal, TestFlight termination, and the update freeze raise the cost of acquiring exactly the marginal users whose presence makes the network function, while the frozen codebase slowly decays in security and compatibility. The government’s strategy looks like friction warfare. It does not need to delete the technology, only to confine it to a technical minority small enough that shutdowns regain their coercive effect on everyone else. Whether that works is the empirical question to watch in the coming months, along with any follow-on orders to Google Play, APK mirrors, or browser-based distribution.

Precedents: from FireChat to Telegram

Two older stories lead into BitChat’s situation. The first is the history of mesh messaging under protest conditions. FireChat carried messages through Hong Kong’s 2014 demonstrations and later through blackouts in Iraq and Iran before its service shut down. Briar continues to serve journalists and activists with Bluetooth, Wi-Fi Direct, and Tor-sync transports. Meshtastic has made LoRa hardware meshing a mass-market hobbyist movement, and its emergency-communications value showed during hurricanes and wildfires. States have repeatedly found that radio-based messaging cannot be switched off, and have repeatedly responded by going after devices, stores, and developers.

The second is India’s escalating confrontation with encryption-native platforms. The June 2026 Telegram block, issued under the same Section 69A over the same leaked-exam fallout, cut off a platform used by more than 150 million Indians. Founder Pavel Durov protested that the move punished “150M+ ordinary Telegram users” for conduct they had no connection to. Set beside the BitChat orders, a pattern emerges: where interception and originator traceability cannot be compelled by design, distribution will be prohibited by order. It resembles approaches elsewhere, including China’s App Store VPN purges, Russian restrictions on Western messengers, and the EU’s unresolved “Chat Control” debate over client-side scanning. It also runs against the position the UN Special Rapporteur on freedom of expression set out in 2015, that encryption and anonymity enable the rights to speech and privacy online.

What a mesh still leaks

No radio protocol is metadata-free, and BitChat is no exception. Flood routing means every node within range sees ciphertext volumes, timings, and pseudonymous sender identifiers. Signal-strength measurement across multiple sensors can localise active transmitters in a crowd. Sybil nodes planted by an adversary can infiltrate the mesh to harvest topology and traffic patterns. Channel membership lists, if propagated for room delivery, are themselves metadata. These exposure surfaces are real and documentable. The project’s openness, including the community audits that followed its launch and produced rapid patches, is what lets them be discussed honestly instead of discovered adversarially.

Conventional messengers, by comparison, hand authorities subscriber identity, contact graphs, cell-tower location history, and persistent server logs on request. The government’s own language concedes the gap: an app that merely complicated interception would be regulated, while one that “significantly impedes” it is blocked. For defenders, the guidance stays the same. Treat mesh apps as a complement to audited internet-based E2EE tools, keep builds updated from verifiable sources, and remember that radio proximity is itself an information channel.

What happens next

Three developments deserve close monitoring.

1. Litigation. Any challenge to the MeitY order will test whether the procedural safeguards in Shreya Singhal and the proportionality standard in Anuradha Bhasin extend to blocking software on capability grounds. Apple’s notice has made the order’s basis public, which gives petitioners an unusual evidentiary foothold.
2. Escalation. The logic of the order points toward Android distribution channels, APK hosts, and possibly browser or enterprise-certificate vectors, each raising fresh questions about the outer limits of Section 69A.
3. Contagion. A capability-based ban in the world’s largest open internet market becomes a citable precedent for every government frustrated by encryption, from democracies debating exceptional access to autocracies that skip the debate.

For developers of privacy infrastructure, distribution concentration is a single point of legal failure. Open-source licensing, reproducible builds, multi-store Android presence, direct APK signing keys with transparency logs, and documented offline installation procedures now work as continuity planning. BitChat’s code survived its GitHub takedown within hours because no platform owned it. Its Indian iPhone user base may shrink inside the walled garden, but the protocol is mirrored and buildable worldwide.

Frequently asked questions

Is BitChat still working in India after the App Store removal?

Devices that already have the app installed continue to work and to mesh over Bluetooth, because removal from a storefront does not uninstall software. New iPhone downloads are blocked, public TestFlight links no longer work in India, and frozen installs will stop receiving security updates. Android builds distributed outside store channels are unaffected by Apple’s action.

Why did the Indian government ban BitChat?

The government’s orders target the app’s capabilities, not any specific message. BitChat’s encrypted, account-free Bluetooth mesh operates during internet shutdowns and resists interception and originator attribution. The July order against GitHub stated that the app “significantly impedes lawful interception, attribution, and investigation,” and protesters used it during the July 2026 Jantar Mantar connectivity blackout.

What is Section 69A of the Information Technology Act, 2000?

Section 69A empowers the central government to direct the blocking of public access to any information through a computer resource on specified grounds such as public order and national security. Procedures under the 2009 Blocking Rules include notice, hearing, and reasoned orders. The Supreme Court relied on those safeguards when it upheld the provision in Shreya Singhal v. Union of India (2015).

Can iPhone users in India sideload BitChat?

Not through any practical lawful route. Alternative marketplaces and web distribution exist only in the EU under the Digital Markets Act. Third-party sideloading tools need a computer and weekly re-signing, and enterprise-certificate installs violate Apple’s policies and carry security risks. For most Indian iPhone users, App Store removal is functionally a ban.

Does BitChat require internet, a SIM card, or an account?

No. BitChat communicates over Bluetooth Low Energy mesh networks, relaying messages store-and-forward between nearby devices, with end-to-end encryption keyed by ephemeral device keypairs. It was built for environments where connectivity is absent, unreliable, or deliberately suspended.