Why I Built Hiaso: App Store Growth Without the Guesswork

Shipping an iOS app is the easy part. Getting found is the hard part. I built Hiaso, a native macOS ASO tool, to replace ranking superstition with keywords, competitors, and prices you can actually see.

The worst week of shipping an app is not the week you write the code. It is the week after launch, when the app is live, the screenshots look good, and nothing happens.

I have been in that week more than once. With Skineat I had a working AI food scanner, a clean onboarding flow, and downloads that arrived in a thin trickle from people I already knew. The product was fine. The store listing was invisible.

So I did what most indie developers do. I opened a spreadsheet, guessed thirty keywords, pasted them into App Store Connect, changed the subtitle twice, and waited. Two weeks later I could not tell you whether anything I did had worked, because I had changed four things at once and had no idea what the app ranked for before I started.

That is why I built Hiaso.

Hiaso is an App Store Optimization tool for people who ship apps: keyword research with real demand and difficulty, AI-assisted metadata, competitor rank comparisons, download and revenue estimates, price localization, rank monitoring, and audits. It runs as a native macOS app, costs $39 once, and does not ask you to become an ASO consultant to use it.


ASO Is Where Engineers Stop Being Engineers

Developers are usually rigorous about the parts of the product they can see. We measure latency, watch crash rates, write tests, review diffs, and refuse to ship changes we cannot explain.

Then we get to the store listing and turn into astrologers.

Someone on a forum says the subtitle matters more than the keyword field. Someone else says the keyword field is dead. A blog post from 2021 says to repeat your brand name. A YouTube video says never repeat anything. Nobody shows their data, and none of it is falsifiable, so you pick the advice that sounds confident and move on.

The frustrating part is that the underlying problem is not mysterious. It is a search ranking problem with a finite input space: a title, a subtitle, a keyword field, a category, a price, and a set of competitors who are all fighting for the same terms. You could reason about it the way you reason about a query planner, if only you could see the numbers.

That was the first thing I wanted Hiaso to fix: make the inputs visible so ASO becomes a decision instead of a ritual.


A Keyword Without Demand and Difficulty Is Just a Word

Every developer has a keyword list. Almost none of them are ranked by anything.

The list usually comes from describing your own app to yourself. "AI food scanner." "Nutrition tracker." "Skin health." These are words you already believe in, which is exactly the problem. They tell you nothing about whether anyone searches for them, or whether the top three results are billion-download incumbents you will never displace.

A keyword is only useful when you know two things about it:

  • Demand. How many people actually search this term?
  • Difficulty. Who currently owns it, and how entrenched are they?

The interesting keywords live in the gap between those numbers. High demand and high difficulty is a wall. Low demand and low difficulty is a win nobody sees. The terms worth restructuring your metadata around are the ones with real volume that the incumbents have not bothered to defend, and you cannot find those by intuition, because intuition is what put you in the wall in the first place.

Hiaso puts demand and difficulty next to every keyword, then attaches download and revenue estimates so you can answer the only question that matters before you spend a release cycle on it: if I ranked here, would it be worth anything?

Sometimes the honest answer is no. That is a useful result too. It has saved me from at least two rewrites of a subtitle that would have changed nothing.


AI Should Draft the Metadata, Not Decide It

Hiaso generates titles, subtitles, keyword fields, and full store listings with AI. I want to be precise about what that means, because it is easy to build the irresponsible version of this feature.

The irresponsible version is a button that says "optimize" and replaces your metadata with something a model invented. It feels magical for about a day, until you realize you have no idea why the new subtitle is the way it is, whether it fits the 30-character limit gracefully, or whether it quietly dropped the one term you actually ranked for.

Metadata generation is a good fit for a model because it is a constrained writing problem: fixed character budgets, no repetition across fields, natural phrasing, and a target keyword set. It is a bad fit for a model to choose the keyword strategy, because that decision depends on demand, difficulty, and your competitive position — data the model does not have and will happily hallucinate around.

So in Hiaso the flow runs in that order. You look at the keyword data. You decide which terms you are going after. The AI drafts metadata that packs those terms into the character limits without reading like a robot wrote it. You keep, edit, or throw away the draft.

The model does the tedious part. You keep the judgment. This is the same principle I ended up applying in every AI product I have built: ask the model for the work, not for the decision.


The Feature Nobody Asks For: Price Localization

Most developers set one price. It is almost always priced for the United States, Western Europe, and a handful of similar markets, and then it is applied to the entire world by whatever conversion the store does automatically.

That default quietly does two bad things at once. In lower-income markets the price is far above what the market will bear, so the conversion rate collapses. In a few high-income markets it is under-priced, and you leave money on the table on every sale.

Nobody notices, because the failure mode is invisible. There is no error log for "this user in this country saw a price that made no sense to them and closed the page."

Price localization is one of the highest-leverage changes an indie developer can make, and it takes an afternoon. It requires no new code, no App Review cycle, and no design work. It is a table of numbers you have never looked at.

Hiaso shows that table and suggests localized pricing per market, which is how a $39 tool can pay for itself off a single tier adjustment. It is also, I suspect, the feature people will find most surprising, because it has nothing to do with keywords and everything to do with why the downloads you already have are not turning into revenue.


Why a Native macOS App, and Why $39 Once

Two decisions that people ask about.

Native macOS. Hiaso is a desktop app for Apple Silicon Macs, not a web dashboard. ASO work is a dense-table, many-windows, sort-and-compare activity, and native tables handle thousands of rows better than any web grid I would have built. More honestly: everyone shipping to the App Store is already on a Mac, sitting next to Xcode and App Store Connect. Putting the tool in that same environment removes a context switch, and I get to build it in the stack I already know well.

One-time $39. Almost every ASO tool is a subscription that costs more per month than most indie apps earn. That pricing exists because those tools are sold to companies with an ASO team and a budget line. I am not building for that customer. I am building for the developer who ships an app, wants to understand why it is not being found, and needs the answer to cost less than the problem.

A recurring bill also creates the wrong pressure on the product. Subscriptions need you to open the app constantly. ASO does not work like that. You do the work around a release, monitor for a few weeks, then go back to building. A tool that respects that rhythm should not punish you for closing it.


What I Actually Wanted

I did not build Hiaso because I love app store marketing. I built it because I was tired of the specific feeling of shipping something good and watching it disappear, then having no way to tell whether my response to that was working.

The same instinct produced Currai: when a system's behavior is invisible, you stop improving it and start guessing about it. Traces made AI failures visible. Keyword and price data make store failures visible. Different domain, same disease.

If you have an app that deserves more downloads than it gets, start with one thing. Pull your current keyword rankings and look at what you actually rank for versus what you assumed. That gap is usually the whole story.

You can find the rest in Hiaso.