Zac Hall:
The third most popular free iPhone app in the U.S. App Store today is a mysterious productivity app that’s only available in Russian. That’s a pretty obvious red flag that something isn’t quite what it seems.
[…]
The app icon looks similar to a star mapping app. The app itself isn’t available in English. It seems unlikely that this productivity app organically found its way to the third-place ranking for its advertised purpose.
[…]
The reality seems to be that the app is a Russian banking app disguised as a Pomodoro timer. Activity on Telegram this week points to the app actually being a client for Russian financial institution VTB Bank.
Nick Heer:
In Russian media, the developer says there are other apps lined up to take the place of this one after it is inevitably removed.
Previously:
App Store App Store Scams iOS iOS 26 iOS App Russia
Jaanus Kase (Mastodon):
We deployed direct silent CloudKit notifications in Tact in late 2024. They proved to be too unreliable to use in a messaging app like Tact: notifications arrived late or not at all. To be fair, this is within the bounds of the Apple SDK contract, which does say that the delivery of silent notifications is on a best-effort basis, and you can expect a lower service level than with visible notifications.
Since Tact is a messaging app where users do expect to be notified of new messages reasonably fast, Tact in May 2026 switched to visible notifications delivered from CloudKit. Those do work reliably and fast, but the user experience is not as fast as it could be. CloudKit has several bugs in this area, and the bugs compound.
So this is simply an inventory of open bugs filed to Apple around the area of CloudKit, notifications, and the related developer experience, as of May 2026.
Previously:
Bug CloudKit iCloud iOS iOS 26 Mac macOS Tahoe 26 Programming
Guilherme Rambo:
When using the public database for content hosting or feature flags, you don’t want any random iCloud user to have the rights to publish or edit content on your behalf or to change the feature flags that control your app’s behavior for all of your users, that would be really bad.
That’s where CloudKit’s security roles come in. You can think of them as Unix access control groups for record types. They allow you to restrict the types of operations that users belonging to a given group (security role) can perform on any given record type, and you can then assign security roles to specific users.
[…]
The creator role means “the user who has created this record”. So it’s possible to allow any authenticated user to create a record of a given type in the public database, but not read or write to any record other than the ones that they have created themselves.
[…]
But the most interesting thing about security roles for content hosting and similar applications is that we can define our own security roles and assign them to specific users.
Simon B. Støvring:
So can we actually use CloudKit’s public database to store user-specific and/or sensitive data without it being widely available? So it’s more like a traditional database an app can build functionality on?
Can anyone confirm this?
If that’s the case, I’ve totally misunderstood the public database for years. I have always considered it suitable only for sample data and other data meant to be broadly accessible without auth.
Moritz Sternemann:
yep correct! That’s the conclusion I also came to when working more with CloudKit a while ago. You can definitely have data in the public database that’s only readable by the user who created it.
Jaanus Kase:
The main distinction for me is, who owns the data
Private db: user owns data, I as developer literally have no way to access it. Also it’s counted towards the user’s iCloud storage quota
Public db: I as developer own the data, and my app has storage quota not tied to any user
CloudKit iCloud iOS iOS 26 Mac macOS Tahoe 26
