Digital-asset & online-business income
Mobile Apps
Software published to the App Store or Google Play that earns from paid downloads, in-app purchases, subscriptions or advertising, with the store collecting and remitting.
A mobile app generates income through paid downloads, in-app purchases, auto-renewing subscriptions, in-app advertising, or a combination. The app stores act as the payment collector and take a commission before remitting to the developer, and in most jurisdictions also handle sales tax and VAT. Apps can earn for years after launch, but operating-system updates, store policy changes and SDK deprecations force periodic maintenance, making the income semi-passive.
Business profits Semi-passive
The labels above place this income type before you read a word. The first is the mechanism — how the money actually reaches you, whether by lending it out, owning a slice of something, renting an asset, licensing a right, selling an option or owning a business somebody else runs. The second says whether the income keeps arriving on its own once it is running, or whether it needs work from you to keep coming. Both are descriptions of how the thing is built, not verdicts on it.
How it works
Publishing starts with enrolment in the Apple Developer Program and/or the Google Play Developer program, each with its own fee and a review process that can reject or delay a build before it ever reaches a user. From there, four monetisation models exist and are frequently combined in the same app: a paid download, one-off in-app purchases that are either consumable or non-consumable, auto-renewing subscriptions, and advertising.
For digital goods consumed inside the app, the store's own billing is generally mandatory, and the store deducts its commission before paying the developer. Reduced commission tiers exist for small developers and for subscriptions past their first year, and US rules on linking out to external payment systems have been the subject of ongoing litigation and regulatory change, so the exact commission a developer pays can shift over time. Advertising revenue instead runs through an ad SDK and a mediation layer that auctions each ad slot across networks, with publishers tracking eCPM and fill rate by geography. Apple's App Tracking Transparency framework requires user permission before cross-app tracking, and the resulting loss of stable identifiers reduced targeted ad pricing across consumer apps.
Discovery is dominated by store search and featuring, so app store optimisation — title, keywords, screenshots, ratings — sits alongside paid user acquisition bought through the stores' own ad products. Ratings compound: a well-reviewed app keeps converting store visits into installs long after launch, while a cluster of one-star reviews after a bad release is slow to repair. Payouts arrive monthly on the store's own schedule, net of commission, with a reporting lag behind actual usage.
What it pays
The relevant metric depends on the model: subscription apps are measured by ARR and trial-to-paid conversion, one-off purchase apps by downloads times conversion rate times price, and ad-supported apps by daily active users times ad impressions per user times eCPM. Retention drives all three — an app that loses most of its users in the first week cannot accumulate a paying base no matter how many installs it generates.
eCPM varies by geography and category by an order of magnitude; the identical ad unit shown to a user in a high-spend advertising market and a low-spend one produces very different revenue per impression. Store commission is deducted before the developer sees anything, so the developer's real economics are always the gross price net of the store's cut, not the sticker price shown to the user.
Some apps — utilities, reference tools, niche calculators — earn for years on organic store search with almost no ongoing marketing, a back-catalogue effect that rewards durability over novelty. Paid user acquisition changes the model entirely: the app becomes a media-buying business, and profitability depends on lifetime value exceeding customer acquisition cost within a defined payback window, which is a different and less forgiving discipline than building an app people find on their own.
Costs and taxes
Fixed costs include the annual developer program fee for each store plus code-signing and any third-party services — backend hosting, analytics, crash reporting, push notifications, subscription-management SDKs. Variable costs scale with active users, so a free app with a large audience can cost real money in server and bandwidth spend before it earns anything at all.
Development and maintenance is the dominant ongoing cost. Each year's OS release breaks something, deprecated APIs must be replaced, and store policy updates force changes to privacy labels, permission prompts and data-disclosure forms. Support and moderation costs are easy to underestimate for any app with user accounts or user-generated content.
For US tax purposes, app revenue is ordinary business income reported on Schedule C or an entity return, with self-employment tax due on net profit for a sole proprietor. The stores generally act as seller or agent for digital goods and collect and remit consumption taxes in most jurisdictions, but developers still file the relevant US tax forms — a W-9, or a W-8BEN for non-US developers, which sets treaty withholding on US-source income. Advertising revenue is typically paid directly by the ad network rather than the store, and arrives with its own separate 1099 reporting.
Liquidity and time commitment
Apps change hands through brokered marketplaces and private transactions, priced on a multiple of trailing profit, with the transfer itself executed through the stores' own app-transfer processes. Those transfers carry technical preconditions — no shared certificates or bundle-ID dependencies with the seller's other apps, and matching entity requirements — that can block an otherwise workable sale outright.
A buyer is also inheriting a maintenance obligation, so an app built on an obsolete framework or an unsupported SDK trades at a discount or fails to sell at all. Ongoing work for an owner is episodic rather than continuous: quiet for months at a stretch, then compulsory when an OS release or a store policy deadline lands.
Support volume scales with users and can be delegated to a contractor; engineering maintenance requires a developer, and the cost of retaining one is what actually determines whether the income is passive or merely deferred labor. Cash flow itself is monthly from the stores and monthly-to-quarterly from ad networks, and in both cases arrives in arrears.
How it goes wrong
Store removal is the sharpest failure mode: a policy violation, a privacy-label discrepancy, or an unresponsive developer account can pull the app from the store and stop revenue entirely and instantly. An OS update that breaks the app — a crash on the newest iOS or Android release left unfixed — produces a review collapse that outlasts the underlying bug long after it is patched.
Deprecated SDKs and unsupported dependencies leave an app that still runs for existing users but can no longer be rebuilt or resubmitted without a significant rewrite. The broader privacy shift in mobile advertising — consent-gated tracking and the loss of stable device identifiers — permanently reduced ad pricing for many consumer apps and broke the acquisition math that had funded their growth.
Subscription refund and cancellation policy sits with the store, not the developer, which limits control over involuntary churn or refund abuse. Clone apps can copy a successful concept and outspend the original on store advertising, and single-platform concentration — all revenue running through one store — leaves the entire business exposed to that store's next policy change.
What to remember
- Revenue comes from paid downloads, in-app purchases, subscriptions, or advertising, with the app store collecting payment and deducting a commission before remitting to the developer.
- Retention determines everything: an app that cannot hold users cannot build a paying base regardless of install volume.
- The work is episodic but compulsory — quiet stretches interrupted by mandatory fixes whenever an OS, SDK, or store policy changes.
- Store removal, OS-breaking updates, and privacy changes to ad tracking are structural risks that can cut revenue abruptly rather than gradually.
- Sale is illiquid and technically constrained: transfers go through store-managed processes that can be blocked by shared certificates or bundle-ID dependencies.
- Income is ordinary business income subject to self-employment tax, with the store generally handling consumption tax and ad networks reporting separately.
This page explains how the income type works, which does not change from week to week, so it deliberately carries no rate and no price. The links below go to the pages that hold the current figures for it, each one stamped with the date the data was pulled. Read the mechanism here first: the numbers there are far easier to judge once you know what they are measuring.
See the live numbers: Digital Income.
Frequently asked
How much of an in-app purchase does the developer keep?
Is app income passive?
Who handles sales tax and VAT on app purchases?
Can an app be transferred to a buyer?
Why did mobile ad revenue fall for many apps?
Written for information only. Nothing here is investment, tax or legal advice, and no page on this site recommends buying or selling anything. Rules and tax treatment change; verify anything that matters with a professional who knows your situation. This explainer was drafted by a language model (claude-sonnet-5) from an editor-approved outline and fact sheet, under the rules set out in our editorial policy, and carries no market figures. Last updated Jul 29, 2026.