How We Review
A useful profile should help you decide what to investigate next. YonoList uses four separate evidence stages; a product can meet one without meeting the others.
1. A described name
A named listing supports a public mention and that page’s statements. It does not authenticate software. We retain exact spelling, described games and alternative editions, because similar Yono, Rummy or 777 names can lead to different products.
2. A responsible publisher
We look for an identifiable publishing entity, consistent product and support information, and a privacy explanation. A directory badge or copied logo is insufficient. Useful details omit empty publisher and package rows; the editorial review record still explains any unresolved identity match. Omitting an empty row does not mean that the app has passed verification.
3. The exact installer
A distribution route should connect that publisher to the correct package, version and signing identity. A directory’s download button is an outbound route rather than proof. We do not label a route trusted until the identity connection is documented. None of the current profiles has a publisher-to-installer match approved by this directory.
Where Google Play fits
A dated public store record can identify its displayed developer, package and described edition. When a matching name leads to a different menu or a virtual-coin product, we show it as a separate identity observation. It does not replace another listing’s rating, Rs. fields or version. We publish no store-install links in the profiles and do not treat store presence as Google certification of another APK, payment guarantee or legal clearance. Read the store-identity guide for the distinction between a listing, Google’s policy-review process and a package match.
4. A documented test
A feature test needs a build, device, date, steps and results. A malware report applies to its exact hash and scan date. A payment report applies to that recorded transaction; it cannot guarantee future withdrawals. Current profiles have no documented installation, scan or payout test. Proposed checks explain what would need testing without claiming it has happened.
What an app profile helps you compare
Across the current 94 profiles, original explanations cover the described game formats, useful rule checks, edition differences and a focused practical question. Product-specific amount notes distinguish scoring units, virtual items and the scope of a recorded financial claim. A Games & formats section appears when the record names games or formats; we do not invent a complete installed menu. App-specific Play Safe points address the particular description. General game rules explain a format and are not proof that an untested app implements every rule.
One listing version on the main card
The nine fields cover rating, downloads, APK size, listed version, app-update statement, sign-up figure, withdrawal floor, payment methods and age. Where a listing snapshot is available, its fields stay together; historical descriptions are labelled separately. Stars are recorded figures, not our quality scores, and downloads do not count active Indian users. A sign-up figure can describe promotional credit; a withdrawal floor does not establish that credit can be redeemed. Rs.100 means 100 Indian rupees.
Other amount observations stay separate with their inspection dates. Payment filters mean that a method is named in the selected record, rather than that we successfully used it. An unreported field says so. Original source addresses and capture notes are retained privately; each profile’s expandable editorial review record gives its public scope and inspection date.
Dates and corrections
An inspection date says when a listing was read; an app-update date is the listing’s release claim. An editorial date records a text change, not a new app test. Private references support follow-up. Authorship explains who publishes the text and the use of AI assistance. Report a correction when a fact can be supported more precisely.