Every acquired user brings in some number of new users. Call that number k. It is the average invites a user sends multiplied by the share of those invites that convert.
If k is below 1, the loop dies out and the total users you get from one acquired user — them plus everyone downstream — settles at a finite multiplier:
M = 1 / (1 - k)
At k = 0.5, M = 2: every user you buy brings one more free. At k = 0.9, M = 10. That is the whole model, and it is the reason "make it go viral" is a coherent goal rather than a wish: k applies a multiplier to every other channel you have.
It is also why a single-number estimate of k is close to useless.
The instability is the point
M = 1/(1-k) is a pole, not a gentle curve. As k approaches 1 the denominator approaches zero, and the function's sensitivity to error explodes. Compare a ±10% uncertainty on k at two different values:
| k | M | k − 10% | k + 10% | M range |
|---|---|---|---|---|
| 0.3 | 1.43 | 0.27 | 0.33 | 1.37 – 1.49 |
| 0.7 | 3.33 | 0.63 | 0.77 | 2.70 – 4.35 |
| 0.9 | 10.0 | 0.81 | 0.99 | 5.26 – 100 |
The same relative error on your input produces a band of 0.12 at k = 0.3 and a band running from 5 to 100 at k = 0.9.
At the bottom of that table the estimate is not an estimate any more. "Somewhere between five and a hundred" is not a forecast you can plan a budget against, and a calculator that returned "M = 10" for that row would be actively misleading. Appstro's viral loop calculator therefore re-runs the multiplier at either side of your k and shows the band, and treats k = 0.7 as the point where the band grows wider than the estimate itself.
If you take one thing from this: the number you should report is the band, not the midpoint.
Above k = 1, and why the answer is null
At k ≥ 1 the closed form breaks: the series does not converge and 1/(1-k) is either infinite or negative. Neither is a growth forecast.
The right output is not infinity and not a very large number. It is nothing — with the note that a measured k above 1 is almost always an artifact. A finite addressable audience and a conversion rate that decays as the loop reaches less enthusiastic people both drag a real k back under 1. A sustained k above 1 would mean the entire population installs your app, which has not happened.
The same applies to "how many cycles to reach N users". If the target is beyond what the loop converges to, the answer is never, not a number. Printing "38 cycles" when the truth is that the loop tops out below the target is the single most misleading thing this kind of calculator can do.
Decay, and why the closed form is not enough
The tidy version assumes k is constant across generations. It is not: your most enthusiastic users invite first, and each successive cohort is less well-connected and less excited.
Modelling that as k_g = k × decay^g makes the series non-geometric, so the total has to be summed by iteration rather than read off the closed form. When decay is set to 1 the iteration reproduces the closed form exactly — that identity is worth asserting in any implementation, because it is the cheapest possible check that the loop is being summed correctly.
The arithmetic here was validated against a Monte Carlo branching process — each simulated user sends i invites, each converting with probability c — at k = 0.2, 0.5, 0.6, 0.9 and 1.2. The closed-form and simulated totals agreed to within 0.5% at every value.
There is no benchmark table, and that is not an omission
You will find "average k-factor by category" figures published. None of them come with a methodology, a sample, or a date.
That is not surprising, because the two inputs are invisible from outside. Invites sent lives inside your app. Invites converted lives inside your attribution. Nothing public exposes either for anyone else's app, which means nobody can compute an industry average for k and nobody has.
So the question gets inverted instead. Rather than "is my k normal", ask: what k would I need? Pick the multiplier you want — say 1.5x on every channel — and the arithmetic runs backwards to the k that produces it, and from there to the invites-per-user and conversion rate that produce that k. That answer needs no benchmark at all, and it is usually sobering: a 2x multiplier needs k = 0.5, which means every second user brings a new one.
A caution about measuring this from the outside
It is tempting to look for viral loops by scanning App Store listings for invite, referral and sharing language. That approach was built here and rejected, because it fails against apps that plainly have loops: Snapchat, Threads, Venmo and Strava all score zero strong signals on their listing copy, and Duolingo scores only "leaderboard".
The scan measures listing text, not the product. Anything built on it would confidently report "none of your competitors has a viral loop" for a cohort where several obviously do. If you are inferring product mechanics from marketing copy, check your method against apps whose answer you already know.
What Apple allows
Invite mechanics touch the App Review Guidelines, and one rule is misfiled almost everywhere. It is 5.1.2(v), under Data Use and Sharing — not 5.1.1. Verbatim:
"Do not contact people using information collected via a user's Contacts or Photos, except at the explicit initiative of that user on an individualized basis; do not include a Select All option or default the selection of all contacts. You must provide the user with a clear description of how the message will appear to the recipient before sending it (e.g. What will the message say? Who will appear to be the sender?)."
Read that as a design brief and it rules out the highest-k invite flow anyone has ever built: no Select All, no pre-selected contacts, one deliberate choice per person, and the message shown before it is sent. It also requires the user to know how the message will appear to the recipient — so no messages that read as though the app sent them on the user's behalf without saying so.
Separately, guideline 3.2.2(x) forbids apps that "force users to rate the app, review the app, download other apps, or other store-related actions in order to access functionality". A referral gate is a design worth checking against that line.
Beyond those, Apple's guidelines say nothing specific about referral or invite mechanics — verified by reading the guidelines page for this post, not by recollection.
What this cannot tell you
- Not your k. Nothing public can measure it. Every input is your own instrumentation, and if you have not instrumented invite sends and invite conversions, you do not have a k — you have a guess with a Greek letter on it.
- Not a category benchmark. No sourceable figure exists.
- Not whether a share feature helps you rank. Apple publishes no such factor. What the arithmetic asserts is narrower and more useful: how many users each acquired user brings.
- Not whether the loop is worth building. A k of 0.15 is a 1.18x multiplier. Whether that justifies the engineering is a product decision, not a maths one.
The work
Put your own numbers into the viral loop calculator — invites sent per user, conversion rate, and your best guess at decay — and look at the band rather than the headline multiplier. Then run it backwards from the multiplier you actually want, and see what it would take.