The Post Apple Tax World | Agentic & Distributed Systems, DeFi, and Compute Economics

A friend asked how to avoid Apple's cut on his golf app. My answer started with the web, then became a question about how much work logging a round should take.

A buddy of mine shipped his golf app and asked me how to dodge the 30 percent cut.

I told him: don't ship a native app at all.

Ship a web app. Then ship a skill. Let the agent handle the input and the browser handle the visuals.

That was my answer for his product, not a rule for everything on a phone. The interesting part wasn't finding a cheaper checkout. It was realizing that the thing he wanted people to do might not need another app they open and tap through.

He wanted them to log a round of golf.

The round

My buddy wanted users to log birdies and eagles per hole per course. Multiple courses. Some of them in country clubs where you're not pulling your phone out every hole.

The tap-driven version asks the golfer to stop what they're doing. Unlock the phone, find the app, open the round, find hole 7, tap birdie, save. Then do it again when something else happens.

That is a lot to ask of someone who came to play golf.

The version I was describing starts with a sentence: "I shot a 78 at Innisbrook today, birdies on 7 and 14, eagle on 17."

That sentence isn't a complete scorecard. It doesn't tell us the score on every hole, which tees were played, or which round to update if there are two possible matches. A useful product has to ask for what is missing instead of inventing it.

An agent could use the answer to propose a record, let the golfer correct it, then send it to his API after the user checks it. The dashboard would be there when the golfer wants to see a season, compare courses, or correct an entry later.

That could capture the details the golfer actually remembers without making them navigate a form first. That is the product change I care about.

And it doesn't have to be voice. The golfer can type the same sentence. In a quiet room, around other people, or for someone who doesn't want to speak to a machine, text may be better. The point is less entry work, not a microphone requirement.

The cut

I understand why my friend started with the fee. If someone else controls the route to your customer and takes a share of the sale, that changes the business.

The 30 percent in our conversation is not a universal rate. Apple's Small Business Program introduced a 15 percent commission for qualifying developers on paid apps and in-app purchases. I would check the terms for his product and program before building a financial model around either rate.

In April 2025, the European Commission fined Apple €500 million for breaching the Digital Markets Act's anti-steering obligation. That decision concerned restrictions on directing users to alternatives; it did not abolish App Store fees everywhere.

A product sold and delivered entirely on the web takes a different distribution path from an iOS app steering users to an external checkout. My advice was to consider the first, not count on litigation to make the second free.

The web path still has costs. Hosting, payments, support, customer acquisition, and whatever model or agent service the product needs. Avoiding one commission doesn't mean keeping all the revenue as profit.

What I want to avoid is treating the store as a requirement before I've decided whether the product needs it.

What the store does

Apple offers a place to find and install software, a familiar payment relationship, and a platform developers can build against. Those things can be worth paying for. Getting listed doesn't guarantee customers, but distribution and trust aren't imaginary benefits.

Going direct means taking on more of that work. A website is an address, not an audience. My friend still needs a way for golfers to find him and a reason for them to trust the product.

The web can do more than a static landing page. Apple's WebKit team documented Web Push for Home Screen web apps with iOS and iPadOS 16.4. The user has to add the web app to the Home Screen, and the permission request must follow a direct interaction. A visit alone doesn't grant a notification channel.

That is a useful capability, not proof that a web app is indistinguishable from a native one. Background behavior, device integration, performance, and the installation experience can change the decision. The question is which of those differences the actual product depends on.

For a golf log, I would test entering a round and finding it again before spending the roadmap on store distribution. If the core experience works on the web, there is no reason to make a native launch the gate to learning whether anyone wants it.

The skill

For the golf app, a skill could tell an agent how to identify a course, ask for missing round details, and use the API to create or correct an entry. It is an instruction package for doing that job, with a SKILL.md file as its entry point.

Anthropic introduced Agent Skills on October 16, 2025, describing folders containing instructions, scripts, and resources Claude can load when needed. That gives us a way to package the instructions, not a guarantee that every chatbot accepts the file or can execute its tools.

The backend would still have to authenticate the user, validate the data, and store it. The agent would need a supported way to call that backend.

A markdown file doesn't provide a microphone, speech recognition, account connection, or secure credential storage by itself. Those belong to the surrounding software. Someone has to build and support the path between them.

I would start with one agent runtime, document how the user connects their account, and test the whole path from that golf sentence to a saved round. Name other runtimes as supported only after they work, not because their models can read markdown.

The user doesn't care that I wrote a skill. They care that their round was recorded correctly.

The product behind the sentence

The appealing diagram is a web app, an API, and a skill. The difficult part is making them behave like one product.

If the agent submits a round twice, the user should not get duplicate rounds. If it mishears a course name, the user needs an easy correction. If access is revoked, the integration must stop working. If the agent service is unavailable, the golfer should still be able to enter the score in the web app.

I would make the account permissions narrow. An integration for logging golf scores doesn't need broad access to everything the user owns. Credentials belong in the runtime's secure configuration, not pasted into a shared instruction file.

The review before saving needs to show the course and round the agent chose, along with the scores it proposes to write. The golfer should be able to fix the wrong course there and undo a mistaken save later, without having to learn how the model failed.

There is a privacy decision here too. A voice or text entry may pass through another company's service before reaching the golf app. Removing Apple from the checkout doesn't remove other companies from the data path. The user should know who processes the input.

That is the product I would be asking my friend to build, not just a file to install.

The next gatekeeper

An agent could become a discovery channel. A user asks for a way to track golf, and the agent recommends a compatible service. That is an interesting possibility for a small builder who doesn't want to depend on store search.

It is not guaranteed distribution. Someone still decides which integrations are listed, which tools are available, and how recommendations work. If the customer can only reach my product through one agent platform, I may have traded one gatekeeper for another.

I want the API and the web experience to remain useful without that platform. A portable instruction file helps, but portability also depends on authentication, tool support, account state, and data export. The claim has to survive an actual move, not just copying the file.

I have a business interest here: I build cypher.camp. Of course I like the idea of products people can use through an agent. That is also why I don't want this argument to end with everyone needing my platform.

My friend's golf product should be able to keep working if he stops recommending cYpher.camp. A referral can be a distribution relationship without becoming the foundation of the product.

My default

I still stand by the advice I gave him. Start with the web. Make the golf log useful on its own. Give it a documented API, then test an agent integration around one job people already want to do.

I would charge for the useful service, not assume an AI label deserves another tier. If voice entry saves people effort and they value it, that is something to learn from customers. If they prefer the form, keep the form.

Native earns its place if it makes the central task better or reaches customers the web doesn't. For some products that is obvious from the start. For this golf log, I would want to see the need before committing to it.

What I am rejecting is the automatic sequence: consumer idea, native app, store approval, then finally a chance to find out whether the experience works.

My friend asked about Apple's cut. The more useful question was how to let a golfer log the round without interrupting it.

Build for that. Make the platform earn its place.