In recent days, some users in Russia have been experiencing problems accessingApple’ss website and the App Store. Measurements by OONI indirectly point to blocking.

You can check if there is blocking with our Web Checker: if you see something unusual, let us know via e-mail: [email protected].

In Russia, Apple’s website and the company’s app store, the App Store, have become inaccessible for some users. The internet censorship monitoring service OONI drew attention to this, and the outlet Verstka reported on its measurements.

Share of failed connections

	Before 18.07.2026	18.07.2026	19.07.2026
App Store	14-16%	37,7%	39%
Apple Website	10,2%	65,7%	68%

Earlier, Apple removed VK Holding’s apps from the App Store: Max, Odnoklassniki, VK, and Mail.ru. The company justified this by citing sanctions against Russian companies and individuals imposed in response to the invasion of Ukraine.

Roskomnadzor said that it is not restricting access to the App Store, but RKN always denies involvement in such cases.

At the same time, Apple has repeatedly complied with censorship demands from the Russian authorities. For example, in March 2026 the company removed several VPN applications from the App Store at the request of Roskomnadzor. As the outlet The Bell notes in its newsletter, by 2020 international big tech companies had almost stopped resisting government demands: not only Apple, but also Google complies with Roskomnadzor’s requirements.

One telling detail about the context: the very tool the world uses to measure Russian censorship is itself restricted in Russia — OONI Explorer has been blocked in the Russian Federation since September 2024.

The OONI figures look convincing: precise percentages, a sharp rise. But in a censorship story, these are exactly the kind of “pretty” numbers to be careful with, because they can reflect either a real block or the quirks of measurement. So we went to the OONI data directly and broke it down by day, by domain, and by operator. It all turned out to be far more interesting than the media reports.

What the direct OONI data shows

The figures the media report are correct. If we take the OONI measurements for the App Store domain (apps.apple.com), the share of anomalous connections really does come to 37.7% on July 18 and 39% on July 19. For the website domain (www.apple.com), it comes to about 64-67% on those same days. So the table is accurate as of its date; there is nothing to nitpick.

The problem is that the data presented by the media ends on July 19. The most important part happened after that.

Look at the chart.

• The peak of the Apple website’s access issues on July 17-19 (59.5% → 64.1% → 66.7% anomalies) was calculated on a very small sample: from 54 to 84 measurements per day.
• On July 20, the number of measurements jumps to 703, and the anomaly rate collapses to 3.1%.

In other words, as soon as the sample became truly large, the Apple website’s “unavailability” practically vanished.

On a small sample, a few “noisy” measurements produce impressive percentages, which dissolve once there is a lot of data. The baseline in early July was close to zero (0-3% anomalies), and the rise from July 16-17 is real. Something (we do not know what) really was happening.

However, turning the peak percentages of a small sample into the claim that “availability dropped to 30%” means passing off possible noise as an established fact. The App Store (apps.apple.com) showed at about 38% anomalies on July 20 too, but again on a modest sample of about fifty measurements.

The method matters. OONI marks a measurement as an “anomaly” when a connection failed in a way it would not from abroad. But the project warns: if the server does not show an explicit block page, some anomalies may be false positives. Then we have to evaluate the trend and do this at large numbers. An anomaly is a signal of a possible block, not proof of one.

What user complaints show

OONI is not the only indicator, and it helps to cross-check against where people themselves complain. The Russian aggregator Sboy.rf recorded mass complaints about the App Store starting on July 16. By midday on July 20, there were around 250-290 reports, most of them from Moscow (~20%) and St. Petersburg (13%). The international Downdetector on the same day showed around 130 complaints about Apple services and around 70 about the App Store.

What matters is not the absolute figure (a few hundred complaints is not many) but the shape of the spike. The baseline level of complaints about the App Store is close to zero (the store usually just works), so any sharp jump stands out well and is itself a signal. The official Apple support forum has also accumulated discussions with a characteristic pattern: for some users, logging into the App Store fails specifically without a VPN, while sometimes, on the contrary, it fails with a VPN turned on that has a Russian exit point. The problem is tied to the traffic route, not to the device or the account itself.

That said, complaints are the most subjective of the sources: people complain more readily when a topic is in the air, and against the backdrop of Mintsifry’s (Ministry of Digital Development) talk about responding to the removal of VK’s apps, any failure is immediately read as policy. So we read the spike in complaints as a confirming signal alongside OONI and the operator data, not as standalone proof.

Where the signal really is stable

The OONI sample for Apple is small, so where does the confidence come from that this is network interference? The other two pieces of the data that do not depend so heavily on sample size prove this.

First, let’s have a look at the breakdown by network operator. Even at small numbers, you can see that on July 20 access to apple.com diverges: Rostelecom (AS12389, AS42610) and Tele2 (AS12958) show anomalies, while MGTS (AS25513), Tattelecom (AS28840), and the provider Perspectiva (AS41733) have normal access. Over the preceding week, anomalies popped up now at one operator, now at another: at ER-Telecom (Dom.ru) on July 14, at MTS on individual days. A global Apple outage cannot behave this way: it would affect everyone at once. But targeted interference at the level of individual networks looks exactly like this.

The second is a neighboring store, Google Play. Its sample is large (hundreds of measurements per day), and the spike there is clearly visible: against the usual ~54% anomalies, July 20 shows a jump to 77% with a record 564 measurements. This is no longer the noise of a small sample but a stable signal.

Here is what comes out: while the data on Apple alone is scarce, the unevenness of the access problems across operators, plus the spike for Google Play, plus the fact that the problem is localised to Russia only, together give a consistent picture of targeted network interference inside the country.

How this works technically

We do not have access to the operators’ equipment, so we can describe the mechanism by the types of anomalies, the error codes, and open breakdowns. OONI distinguishes several kinds of anomalies, and they let you judge the blocking method:

• A DNS anomaly. The domain is returned an incorrect address.
• A TCP/IP anomaly. A connection to the service’s address is not established from the user’s network, although it works from abroad.
• Interference at the stage of establishing a secure connection. It works by the domain name (SNI), which is visible even in encrypted traffic.

Partial degradation that is uneven across operators is a characteristic signature of interference through TSPU (technical countermeasures against threats), the deep packet inspection equipment installed at Russian operators. It allows connections to specific addresses and domains to be selectively slowed or dropped. The picture of “it works at one provider but not at the neighbouring one” is a typical trace of such interference. Indirect confirmation of the network nature: access is restored through a VPN or a foreign IP, since only the route changes, not the service itself.

It is telling that this is not the first episode. On July 14, the sites of Apple, Google, and GitHub already stopped opening from Russian IP addresses, starting at roughly 10:00 Moscow time; access came back through a VPN then too.

We set up our own monitoring and confirmed the blocking with direct measurements

Public OONI data and complaint aggregators are indirect indicators. To learn more, we organised our own monitoring: several servers in different regions of Russia — from Vladivostok and Novosibirsk to Moscow and St. Petersburg — are continuously checking whether connections to Apple services, GitHub, iCloud, and control targets like Google go through. Unlike user statistics, this is a direct probe: the server itself tries to establish a secure connection and records what happens at each step — whether the domain resolves, whether the port responds, whether a reply comes back.

Starting from the very first saved measurement (our data shows blocking as early as July 19), access to Apple from Russian vantage points has been consistently interrupted. And interrupted characteristically: the port responds, a secure connection begins to be established, and then at that stage it is reset; there is no response from the service, and the attempt hangs until a timeout at around eight seconds. At the same time, the same Apple servers respond normally if you check them from outside Russia. In other words, the break occurs somewhere along the route inside the country.

Three observations from our data are hard to explain as anything other than targeted filtering

First, among all tested targets, only Apple showed persistent failures, in all measurements and across all locations. GitHub, iCloud, and Google worked, with only occasional single glitches. A general network outage would not behave like this: it would affect everything, not selectively a single service.

Second, the blocking is selective not only by service but also by specific networks, down to individual hosts within the same data centre operator. Two servers of the same provider but in different cities: on one, Apple is blocked; on the other, it works normally at the same time. Neither an Apple-side failure nor an operator issue looks like this—this looks like a filter configured for specific routes.

Third, the blocking is not constant. On the evening of July 20, there was a moment when Apple suddenly became accessible again across all our probing points, with zero anomalies; after that window, access dropped again. By July 21, the blocking persists, but the set of affected points changes from hour to hour. This explains why some users report ” everything works” while others nearby do not.

Technically, this matches the signature we described above as characteristic of TSPU. The connection to Apple is not rejected immediately: the port responds, the secure channel begins to establish, and then it is interrupted mid-process, based on the domain name, which remains visible to the equipment even in encrypted traffic. The name resolves correctly, so this is not DNS spoofing but interference specifically at the stage of establishing the secure connection: a fingerprint of deep packet inspection, i.e., DPI.

Our measurements do not contradict OONI data; they complement it. OONI provides statistics across many users, with caveats about false positives, while our monitoring shows the mechanics of the interruption at controlled points. Together they present a consistent picture—selective network interference with access to Apple infrastructure inside Russia. This increases confidence in the targeted restriction hypothesis: we are observing not just a statistical anomaly, but the mechanism of the disruption itself. There is still no official acknowledgement, and Roskomnadzor denies involvement, but the technical evidence points clearly toward blocking.

Check for yourself

You can tell in a minute whether this is your problem or a general one.

• Compare access over Wi-Fi and over the mobile network.
• Check a second device on the same network. If the store fails to open on several devices only on one network, the problem is in the route, not in your phone.

To see whether your computer reaches the App Store’s infrastructure without a VPN and with a VPN, we made a simple web checker. It opens in a browser and requires no installation.

▶ Check service availability

The logic is simple. You turn your VPN off and run the check, then turn it on and check again. The checker tests the availability of the stores and update servers of Apple, Google, Microsoft, Samsung, and Huawei and shows the difference between the two runs.

If access appears only with a VPN, that is a sign of a network block rather than a failure of the service itself. The report does not contain your exact IP, only the provider’s subnet. There is an important caveat right in the tool. From a browser, only web endpoints are visible, so the check is an indicator and makes no diagnosis. It will not distinguish a block from a temporary failure.

What this means for users of different devices

The consequences depend on the ecosystem.

• Apple users have it the hardest: in Russia, the company has not opened alternative stores and sideloading, unlike in the EU, Brazil, and Japan. The store is a single, closed one, and under a network restriction, there is almost no legal way to install a new app other than using a VPN.
• Android is more resilient. Even with problems at Google Play, there remain F-Droid, AppGallery, and installing from APK files directly. Windows users are the least vulnerable, since Microsoft Store is not the main channel for installing programs. Samsung and other Android vendors are in an intermediate position. Their own stores provide a margin of safety, but updates to their proprietary services may suffer.

The general principle: do not keep a single channel of access to an important service. Having a reliable workaround to install apps in advance is cheaper than dealing with it after access is gone. Already-installed apps keep working even after removal from the store. You only lose updates and notifications.

What happens if the block becomes permanent

The main risk is security updates. The App Store is the main channel for delivering patches; under a permanent block, users get stuck on old, vulnerable versions of apps and the OS. The paradox: a measure presented as protecting “digital sovereignty” reduces the real security of citizens’ devices. Beyond that, the stratification of ecosystems deepens, and VPNs finally turn from a privacy tool into a basic necessity, even as the circumvention services themselves come under mounting pressure.

Recommendations for VPN and circumvention developers

The result is a vicious cycle: to get around the block you need a VPN, and to install a VPN you need to get around the store’s block, because Apple regularly removes VPN apps from the Russian App Store at the request of Roskomnadzor, Russia’s communications regulator, while access to the stores themselves is restricted at the network level.

Key takeaways:

• Do not rely on the official stores as the only delivery channel. You need direct distribution of signed builds, mirrors, and resilient third-party stores.
• Prioritise disguising traffic as ordinary HTTPS rather than just having a foreign exit point, because the same class of filters chokes protocols like WireGuard as well.
• Provide backup channels for obtaining new addresses and settings.
• Build in payment methods that are not tied to Apple and Google infrastructure.

The general principle: design a service on the assumption that any store, protocol, server, or payment method can be cut off. Resilience today is measured not by speed but by the number of independent backup paths.