What the App Store Taught Us That Skill Marketplaces Keep Relearning

Every new marketplace category goes through the same disorienting phase: the people building it are convinced their problems are novel, and the people who've watched marketplaces before know almost all of them aren't. Skill marketplaces in 2026 are deep in that phase right now, rediscovering — one hard lesson at a time — decisions the App Store made, argued about, and eventually settled, some well and some badly, starting nearly two decades ago. The useful move isn't to treat that history as a template to copy. It's to figure out precisely which parts transfer and which parts don't, because the places where the analogy breaks are exactly where a skill marketplace operator will get burned trusting it too far.

What Transfers Cleanly: Review Processes Are Non-Negotiable Once Trust Matters

The App Store launched in 2008 with essentially no review process, and the fallout — scams, broken apps, apps that did something different from their listing — forced Apple into building real human and automated review within a couple of years, because an unreviewed marketplace at scale is indistinguishable from no marketplace at all in terms of buyer trust. That exact lesson is playing out in skill marketplaces right now, and it's the direct subject of the previous two pieces in this series: the 2026 audit finding a majority of MCP servers vulnerable to path traversal and code injection is, structurally, the same problem the App Store hit in its first eighteen months, just in a different technical costume. A marketplace without real review isn't a lighter-weight version of a marketplace with one — it's a fundamentally different, weaker product that happens to look similar from the outside.

The lesson transfers because the underlying dynamic is identical regardless of what's being distributed: an open submission model without verification degrades trust faster than growth can outpace it, and once buyer trust is damaged publicly, it's expensive to rebuild — more expensive, usually, than building the review process would have cost from the start. Skill marketplaces that skip this step aren't finding a shortcut. They're scheduling the same crisis Apple had in 2009 and 2010, just later.

What Transfers Cleanly: Discovery Determines Who Actually Gets Paid

The App Store's ranking algorithm became, within a couple of years of launch, more consequential to a developer's revenue than the quality of their app — a top-25 ranking in a category could make a business, and obscurity could kill a genuinely good product regardless of its quality. That's the same discovery-is-harder-than-creation dynamic covered earlier in this series, and it transfers almost exactly: a skill's actual usefulness and a skill's visibility are only loosely correlated, and the gap between them is where a marketplace's ranking and search design ends up mattering more than almost anything else it controls.

The App Store's specific mistakes here are worth studying directly rather than rediscovering independently. Early ranking that weighted raw download velocity heavily created gaming incentives — developers buying downloads to spike ranking — that took years to fully counteract. A skill marketplace weighting install count too heavily, without correcting for the retention problem covered in the piece on what makes a skill get reused, is walking directly into the same trap with a two-decade head start on knowing it's a trap.

Where the Analogy Genuinely Breaks: Portability

This is the sharpest, most consequential difference, and it's worth stating plainly because it undoes a lot of App Store intuition that otherwise transfers well. An iOS app and an Android app were, for the vast majority of the App Store's history, separate codebases requiring separate builds, separate review processes, and separate relationships with two different platform owners. A developer locked into iOS had real switching costs to reach Android users, and Apple's leverage over developers was substantially a function of exactly that lock-in.

A skill built to the SKILL.md convention doesn't have that lock-in, because — as covered earlier in this series — the format's simplicity makes it compatible across more than 20 agents and tools with little to no rework. That single difference changes almost every power dynamic the App Store analogy would otherwise predict. Apple could extract a larger revenue cut, impose stricter policies, and reject apps for competitive reasons, in real part because developers had nowhere else to go once they'd built specifically for iOS. A skill marketplace trying the same moves against creators whose product runs natively across a dozen other platforms is going to find that leverage simply isn't there — which is a large part of why 70/30 splits, discussed earlier in this series, have held in creators' favor rather than eroding toward the platform the way app store economics sometimes did over time.

Where the Analogy Genuinely Breaks: What's Actually Being Reviewed

App Store review, for most of its history, was fundamentally reviewing a finished, self-contained binary — a static thing that either worked as described or didn't, tested against a relatively fixed set of behaviors. A skill is a different kind of object: markdown instructions interpreted live by a model whose behavior can vary somewhat across runs, potentially combined with scripts that behave differently depending on runtime context. Reviewing a skill isn't just checking whether a fixed artifact does what it claims — it's closer to reviewing a recipe that a different chef might execute slightly differently each time, which is a fundamentally harder and less deterministic review problem than the App Store ever had to solve.

This is a genuine, unsolved gap, not a solved problem skill marketplaces just haven't gotten around to importing yet. The static-scan-plus-sandbox-execution checklist covered in the previous piece is a reasonable current best practice, but it's still catching a narrower slice of possible bad outcomes than App Store binary review could, precisely because a skill's behavior is less fixed than an app's compiled code. Marketplace operators borrowing App Store review intuition wholesale risk under-appreciating just how much harder this specific piece of the puzzle is in a category where the thing being reviewed reasons rather than simply executes.

The Meta-Lesson

The App Store's history is most useful not as a playbook to copy but as a fast-forward preview of which problems are structural to any two-sided marketplace and which problems are specific to what's actually being sold. Trust, review, and discovery are structural — every marketplace at scale hits them, regardless of product category, and the App Store's scars are worth studying closely because the underlying dynamics really do repeat. Lock-in, revenue leverage, and what "reviewing a product" even means are specific to the product, and the skill economy's answers to those questions are going to look meaningfully different from the App Store's — not because skill marketplace operators are smarter, but because portable markdown files interpreted by a reasoning model are a genuinely different kind of thing to sell than a compiled binary tied to one platform.

The operators who do best in this category over the next few years are unlikely to be the ones who ignore the App Store's history, or the ones who copy it uncritically. They're the ones precise enough to know, problem by problem, which half they're looking at.

Part of the "The Skill Economy" series on aiskill.market.