Some software is better encountered than installed.
On July 10, 2008, Apple announced that its new App Store would open with more than 500 native applications. Within three days, people had downloaded more than ten million of them. Software had acquired a new front door: organized, searchable, trusted, and built directly into the device.
Sixteen years later, a developer named Nolen Royalty spent two days making a website called One Million Checkboxes. It was exactly what the name promised. There were one million checkboxes, and checking one changed it for everyone else who happened to be there. Over the two weeks Royalty kept the site online, 500,000 people checked and unchecked more than 650 million boxes. They competed over the grid, drew images, and even encoded messages for one another inside its changing state.
Nobody installed it. Nobody had to decide whether it deserved a permanent place on their home screen. They followed a link and entered something that was already happening.
The App Store gave software a front door. Over time, we began to mistake the front door for the house.
The Store That Changed the Shape of Software
Before the App Store, consumer software often arrived through boxes, discs, download pages, and websites of uncertain trustworthiness. Developers had to find their own customers, collect payments, distribute files, and persuade people that those files were safe to run. Users had to locate the right version, complete an installation, and remember to look for updates. Mobile software made all of these problems more difficult because the device was personal, constrained, and full of information people could not afford to expose casually.
The App Store brought these scattered responsibilities into one system. It gave developers a way to reach people around the world, while giving users a trusted place to search, pay, download, and update. It created a practical framework for permissions, device compatibility, reviews, and accountability. Its early success was not a marketing illusion. It solved a real problem in the distribution of software.
It also gave the App a recognizable silhouette. An App had a name and an icon. It belonged to a category, presented screenshots, accumulated ratings, passed through review, and occupied a square on the home screen after installation. These conventions helped people understand what they were choosing before they opened it.
The silhouette became so familiar that it began to feel like the object itself. We stopped thinking of the App Store as one route by which software could arrive and started treating the route as part of the definition. An idea could be interactive, useful, responsive, and complete, yet still feel somehow unofficial if it had not been packaged as a product waiting on a digital shelf.
The App Store did not merely distribute Apps. It taught us what an App was supposed to look like before we had even opened it.
Some Apps Are Events, Not Possessions
One Million Checkboxes would have made a poor store product. Its interface was almost comically plain, its behavior depended on thousands of strangers arriving together, and its life was intentionally short. The work was not valuable because it offered a durable set of features. It was valuable because, for two weeks in the summer of 2024, it gave half a million people a shared surface on which to interfere, collaborate, draw, compete, and invent purposes its creator had not planned.
Putting it through a traditional release process would not necessarily have improved it. A product page, a review cycle, an installation, and a promise of continuing updates would have imposed a different relationship between the work and its audience. It was not asking people to keep it. It was asking them to come and see what was happening.
Many small Apps belong to a similar time scale. An App might be made for a wedding weekend, a classroom exercise, a neighborhood event, or one journey through an unfamiliar city. It might be an interactive birthday gift, a game built around a private joke, or a way for a group of friends to leave something behind after a night together. Its usefulness can be real without being permanent, and its audience can matter without becoming a market.
Some software is valuable because people return to it every day. Other software is valuable because it arrives at exactly the right moment. Asking both kinds to present themselves as permanent possessions limits what we are willing to recognize as software in the first place.
Temporary does not mean trivial, and browser-based does not mean slight. Figma and Google Docs have shown that a URL can be the entrance to serious, collaborative work people depend on for years. The point is not that Apps should become disposable websites. It is that duration, complexity, and value do not determine a single correct method of arrival.
Installation Is a Kind of Promise
Installing an App looks like a small action, but it asks a person to make several judgments about the future. This will be useful again. It deserves space on my device. I trust it with the permissions it requests. I am willing to create an account, receive its updates, and perhaps let it call for my attention later.
Those judgments are reasonable when an App will become part of someone's routines. The difficulty is their order. A store listing asks a person to predict the future value of an App before they have experienced its present value. Screenshots, reviews, and descriptions try to close that distance, but the commitment still arrives before the use.
A link reverses the order. A person can open something, try it, understand what it is, and only then decide whether it deserves a place in their life. The difference is not merely fewer taps in a conversion funnel. It changes which ideas can reach people without first pretending to be permanent.
Even the major mobile platforms have recognized that some moments are too brief to begin with a full installation. Apple introduced App Clips so a person could use a small part of an App when a particular need appeared, such as renting a bike or paying for parking, without first downloading the full product. The feature remains inside the native ecosystem, with its safeguards and constraints, but its premise is revealing: sometimes the experience should come before the commitment.
For a small App, that reversal can be the difference between being used and being abandoned before it begins. A guest at a wedding may open a link to add a photograph, but they are unlikely to install a dedicated App for a single evening. A parent may try an interactive story sent by a friend without wanting another permanent subscription. A teacher may share a tool with one class for one lesson. The lighter entrance respects the scale of the occasion.
A Link Is a Different Kind of Distribution
A URL is one of the web's most unassuming inventions. It does not tell us whether the thing at the other end is a page, a document, a film, a game, a design file, or a functioning application. It simply gives that thing an address, making it possible to arrive directly and to pass the same entrance to someone else.
That lightness changes how software moves. A link can travel inside a message at the moment a need appears. It can be attached to an invitation, placed in an article, shared with a classroom, or sent from one friend to another with no explanation beyond "try this." It preserves context: the reason for opening the App can travel alongside the App itself.
Store distribution is organized around the identity of the product. A person encounters the listing, evaluates the App, and decides whether to acquire it. Link distribution can be organized around the situation. The person who sends the link already knows why this particular App belongs in this particular conversation.
This does not make the open web automatically trustworthy. A link can lead to malicious software, deceptive interfaces, or experiences that mishandle personal data. Apps opened instantly still require clear permissions, secure execution, moderation, and a reliable account of who created them. Removing installation friction does not remove responsibility. It shifts more of that responsibility to the platform and the environment in which the work runs.
The useful distinction is not native versus web, or store versus no rules. It is between requiring every App to arrive as an independent packaged product and allowing some Apps to arrive as experiences inside a trusted context.
Discovery Does Not Always Begin With a Need
The App Store is at its best when a person can name what they are looking for. They need a budgeting App, a photo editor, a transit guide, or a game for a long journey. A category, a search result, and a set of reviews help them compare possible answers to a problem they already understand.
Content is often discovered in the opposite order. A person encounters a story, image, or video before they have named the desire it satisfies. Curiosity comes first; recognition follows. We do not always know what we wanted to read, watch, or hear until it is already in front of us.
Some Apps make more sense in this second mode. Few people would think to search a store for an App that turns a child's photograph of an animal into a story that recognizes them. They might not know the category for a tiny game made around an unfamiliar visual idea, a strangely specific household tool, or a World built from someone else's toy. But if the work appears in a Feed or arrives through a friend, its purpose can become clear through use.
Search begins with intent. Discovery begins with curiosity. Neither is superior, and many practical tools will always be found more efficiently through direct search. The important change is that software no longer has to depend on intent as its only path to an audience.
This is why a Community matters around interactive work. An App can be published where other people might encounter it without knowing its name in advance. They can open it rather than judging it entirely from screenshots, share a direct link when it fits someone else's situation, and, when the creator permits it, Remix it into another version.
Discovery does not guarantee attention. A published App can remain unseen, and a Feed cannot decide that an idea deserves an audience. What it provides is a different form of access: software can be met as a work before it is selected as a product.
Creation Has Accelerated. Distribution Has Not.
For most of the App Store era, the effort required to make software and the effort required to release it belonged to the same general scale. A product that took months to design and build could reasonably spend more time on packaging, review, launch materials, and distribution. The process assumed that software was expensive enough to make that each release would be a significant event.
AI is disturbing that balance. Natural-language creation and the broader practice called vibe coding are making it possible to reach a working first version much sooner. This does not eliminate testing, maintenance, security, or craft, but it does change the size of the ideas people are willing to try. When creation becomes lighter, software can be made for narrower needs, shorter moments, and smaller groups.
Distribution has to become lighter with it. An App made for this weekend cannot spend next month preparing to reach the people who needed it. A classroom experiment should not require every student to become a customer. A playful idea made in an afternoon should be allowed to discover whether it deserves a longer life before its creator builds a company around it.
This is the unresolved distance in many AI App builders. They help a person generate software, then leave the finished work at the edge of the older distribution system. The creator still has to decide where it lives, how someone reaches it, why they should install it, and what happens after the first use. Faster production makes this gap more visible rather than less important.
When the cost of creation falls, the appropriate unit of software becomes smaller. Distribution must learn to carry those smaller units without forcing each one to impersonate a mass-market product.
The App Store Can Distribute Eazo. Eazo Can Distribute Apps.
Eazo itself belongs in an App Store. It is a platform people may return to: a place to create, explore a Community, manage work, and encounter what other creators have made. The trust, convenience, updates, and device access provided by mobile distribution all remain useful at that level.
But an App created inside Eazo does not have to repeat the entire journey on its own. It does not necessarily need a separate store identity, a new installation, and an individual claim on the user's home screen. It can exist as a work within the platform, much as a video can exist inside YouTube without becoming a separate application.
There is an important difference: the work in Eazo is executable. A person does not only watch it. They can open it, use it, interact with it, and share its direct link. When Remix is enabled, they can begin with the existing work and create a version shaped around another need. The App behaves like software inside the experience and like content in the way it travels.
This is why Create, Community, and Remix belong in one product. In Create, a person can describe an idea and work toward a functioning App. Publishing gives that App an address and a place where it can be encountered. Use reveals whether it fits the situation that inspired it. Share carries it into a specific relationship, while Remix allows another person to continue from what is already there.
The path is Idea → Create → Publish → Discover → Use → Share → Remix. It does not guarantee an audience, and it does not make every generated first version ready for public use. It gives an App more than one way to arrive. The App Store can distribute Eazo; Eazo can give the Apps inside it a different path into the world.
More Than One Door
Some Apps should live in an App Store. Software that depends deeply on device hardware, runs in the background, requires reliable offline access, handles payments or sensitive information, or becomes part of a person's daily infrastructure benefits from the store's systems of review, permission, update, and accountability. A long-term product should be willing to make a long-term promise.
Other Apps ask for a different relationship. They are made for a journey, a lesson, a gathering, a person, or a question that matters this week. They may be closer to games, gifts, experiments, stories, or invitations. Their value may depend less on occupying a permanent square on the home screen than on reaching someone at the right moment and opening without delay.
The distinction is not between real Apps and lesser ones. It is between different kinds of arrival. An App can be a product someone chooses to keep, but it can also be a work someone encounters, enters, uses, and passes along. We need forms of distribution spacious enough for both.
The App Store remains one of the great distribution systems in the history of software. It does not need to disappear for software to acquire other doors. Not every App is asking to stay, and not every App needs a store before it is allowed to arrive.