PictureThis App Revenue: What the Estimates Actually Show
The best defensible current answer is $155M/year, reported on the ProvenStartups project record and labeled Verified/Hard Data, but explicitly qualified as...
The best defensible current answer is $155M/year, reported on the ProvenStartups project record and labeled Verified/Hard Data, but explicitly qualified as unaudited public reporting and a video roundup. That is a headline annual figure, not proof of audited recognized revenue; dated trackers instead show $10M-$25M/month for App Store revenue on August 7, 2026, and $3M/month for Android on September 18, 2026—both estimates with narrower coverage.
Contents
What is the best-supported revenue number?
The best-supported number is $155M/year, with a Verified/Hard Data evidence label and a material limitation: the record’s credibility note identifies public reporting and a video roundup, and the figure is unaudited.
The same record reports 1M+ paid subscribers, which helps describe scale but does not establish the accounting basis of the annual figure.
| Date/source | Figure | Metric type | Confidence/limitation |
|---|---|---|---|
| ProvenStartups project record | $155M/year; 1M+ paid subscribers | Reported annual revenue and subscriber count | Verified/Hard Data label; based on public reporting/video roundup; unaudited |
| Appsprint, Aug 7, 2026 | $10M-$25M/month | Third-party App Store revenue estimate | Rounded, unaudited, and excludes non-store revenue |
| Peekly, Sept 18, 2026 | $3M/month | Third-party Android-only estimate | Explicitly an estimate and limited to Android |
| Official Apple App Store listing | No revenue figure | App identity and subscription presence | Supports storefront and subscription evidence, not audited revenue |
For the business model, evidence grade, source context, and replication lessons, readers can inspect the underlying ProvenStartups project record. The responsible citation is therefore “$155M/year, reported and unaudited,” not “PictureThis has precisely recognized $155M in current revenue.”
Why do published numbers disagree?
Dates, ARR/run-rate/recognized revenue, and source type cause the disagreement.
The project record gives $155M/year, but the supplied evidence does not establish whether that figure represents recognized revenue, annualized revenue, or a run-rate label. Appsprint gives a rounded, unaudited App Store estimate of $10M-$25M/month as of August 7, 2026, while Peekly gives an estimated $3M/month for Android only as of September 18, 2026.
These are not like-for-like observations. Store estimates can exclude non-store revenue, vary by platform, and vary by territory coverage; the official Apple listing supports app identity and subscription presence, not an audited revenue total.
A broad annual business figure can therefore coexist with narrower store estimates without making either source a clean substitute for the other. Averaging or annualizing them would create false precision because the periods, platforms, territories, and metric definitions are not aligned.
What does the revenue model look like?
The supported monetization mechanism is subscription presence in the official App Store listing, with store trackers estimating store revenue; the materials do not disclose the full price mix, renewal behavior, geographic mix, or non-store revenue.
The reported 1M+ paid subscribers and the storefront’s subscription signal support a paid app business model at a high level. They do not show how revenue is divided between platforms, how much of a store estimate reaches the company, or which revenue is recognized in a stated period.
That is the useful boundary around the phrase “PictureThis business model.” The mechanism is visible enough to identify paid app monetization, but the supplied sources do not support a complete unit-economics model. The Appsprint estimate and Peekly estimate are directional evidence about store activity, not a full company revenue statement.
What can founders actually learn?
A concrete operating lesson is to maintain separate lines for paid subscribers, annual revenue claims, and platform estimates before putting any figure in a board deck.
PictureThis is a useful record because those lines coexist: the project entry reports scale and a yearly figure, while third-party trackers describe specific store slices. That structure does not prove why the figures differ or that one caused another; it shows why an evidence ledger should preserve metric definitions and coverage instead of laundering every observation into one number.
Founders can copy the reporting discipline, not the headline. A strong internal dashboard should make it obvious whether a number is first-party, estimated, platform-specific, territory-specific, audited, or unaudited.
What the number does not prove
Revenue does not prove profit, retention, customer outcomes, or replicability.
Neither $155M/year nor 1M+ paid subscribers tells us the margin, cash generation, cohort durability, or user benefit. The store estimates add directional evidence about observed transactions, but they do not prove company-wide revenue, recognized revenue, valuation, or the economics of acquiring and serving those subscribers.
A founder can study the measurement pattern, but cannot infer that the same result is repeatable from this record alone. Revenue is an important outcome metric; it is not a complete explanation of the business.
How to verify the next update
Use a dated source ledger and prefer first-party disclosure or a filing over estimates.
Use this reusable checklist:
- 1.Date every observation. Preserve the publication date and the period the figure claims to describe.
- 2.Name the metric precisely. Label it recognized revenue, annualized revenue, run-rate, ARR, store revenue estimate, or subscriber count.
- 3.Record the coverage. Note platform, territory, store versus non-store scope, and whether the source is audited or unaudited.
- 4.Rank the evidence. Prefer first-party disclosure or a filing, then use official storefront evidence and third-party estimates as supporting context. The evidence methodology provides a useful framework for assigning that weight.
- 5.Write the reconciliation. Explain what can and cannot be compared, then preserve the old observation instead of silently replacing it. The revenue evidence dataset is a useful model for keeping those distinctions visible.
The next update should not merely replace $155M/year with a newer-looking number. It should state whether the new evidence changes the metric, the date, the coverage, the confidence grade, or only the interpretation.
Verdict
Verdict: PictureThis has a strong public headline of $155M/year at the project’s Verified/Hard Data label, but the defensible conclusion is a qualified reported-revenue claim—not a precise audited current revenue figure.
The App Store and Android estimates are useful triangulation, yet they are rounded, unaudited, platform-specific, and incomplete. For a decision-ready view, inspect the underlying ProvenStartups project record and preserve every figure with its source, date, metric type, and limitation.
Related revenue evidence
Frequently Asked Questions
What is the best available PictureThis app revenue figure?
The best-supported published figure is $155M/year from the ProvenStartups project record. It is labeled Verified/Hard Data but qualified as unaudited public reporting and a video roundup.
Is the $155M figure audited revenue?
No. The record does not present it as audited financial revenue, so it should be treated as a reported annual figure whose accounting basis is not fully established. It should not automatically be described as recognized revenue, ARR, profit, or valuation.
Why is the App Store estimate different from the Android estimate?
The Appsprint estimate covers App Store revenue and is dated August 7, 2026, while the Peekly estimate covers Android only and is dated September 18, 2026. Platform, territory, non-store coverage, dates, and estimation methods can all produce different figures.
What should a founder copy from this example?
Copy the evidence ledger: label the date, metric, platform or territory, source type, confidence, and unknowns. Use the official storefront to confirm app identity and subscription presence, then treat store estimates as directional until stronger first-party disclosure or filing evidence appears.