DEV Community: Mohamed Haizoun

ASO Is Product Work, Not Marketing — A Developer's Case

Mohamed Haizoun — Thu, 09 Jul 2026 10:08:57 +0000

In most teams, App Store Optimization lands on whoever owns "marketing." The keywords get handed to a growth contractor, the screenshots go to a designer, and the developers go back to building features. I want to argue that this org chart is backwards. ASO is not a marketing channel you bolt on after the app is built. It is product work, and treating it as anything else leaves compounding growth on the table.

I've shipped and iterated on enough store listings to have changed my mind about this. Here's the case.

The store listing is your first feature

Before a user taps a single button in your app, they interact with a product surface you built: the icon, the title, the screenshots, the first three lines of the description. That surface has a conversion rate. It has a funnel. It responds to iteration. By every definition we apply to in-app screens, the store listing is a screen — it's just the one that runs before install.

When a designer treats the onboarding flow as product work but the store listing as "marketing assets," they're drawing a line that the user doesn't experience. To the user it's one continuous journey: search result → listing → install → onboarding → aha moment. Optimizing four of those five steps and outsourcing the middle one is a strange way to build a product.

Keywords are user research in disguise

Here's what changed my thinking most. Keyword research is usually framed as a marketing tactic — find high-volume, low-competition terms, stuff them in the metadata. But look at what a keyword actually is: the exact language a user typed when they had the problem your app solves. That is the purest user research you will ever get. It's unprompted, it's at the moment of intent, and there's a lot of it.

If your app is a habit tracker and the data shows people searching "stop doom scrolling" far more than "habit tracker," that is not a metadata insight. That's a positioning insight. It tells you what job users are hiring your app for, in their words. A marketing team will use it to rank. A product team will use it to rename features, rewrite onboarding copy, and maybe reprioritize the roadmap. The second team wins.

Retention and ranking are the same signal

The old model of ASO was mechanical: right keywords in the right fields, watch the rank. That model is mostly dead. Modern store algorithms lean heavily on behavioral signals — install-to-open rate, day-1 and day-7 retention, session frequency, uninstall rate. The store is asking, in effect, "when we send someone this app, are they happy a week later?"

Sit with what that means. You cannot optimize your ranking without optimizing your retention. The single highest-leverage ASO move available to most apps is not a keyword change — it's fixing the day-1 drop-off. And fixing day-1 drop-off is, unambiguously, product work: onboarding, activation, the first-run experience, the moment the user first gets value. The store now rewards the same thing your PM already wanted. ASO and product strategy have collapsed into the same activity, and a lot of teams haven't noticed.

What this looks like in practice

If you accept that ASO is product work, a few things change about how you operate:

Developers read reviews. Not because it's their job to reply, but because one-star reviews are bug reports and feature requests with a distribution penalty attached. A review that says "crashes when I add a photo" is telling you about a bug and dragging your rating and suppressing your rank. Three problems, one root cause, and it's engineering's to fix.
Screenshots get versioned like features. You A/B test them, you write them down, you attribute conversion changes to specific edits. "We changed screenshot 2 and install rate moved 4%" is a product experiment, and it should live in the same place as your other experiments.
The listing ships with the release. New feature that changes what the app is for? The store listing changes in the same cycle, because the listing is part of the product's story, not an afterthought handled two sprints later.

The counterargument, fairly stated

The honest objection: ASO involves real marketing craft — competitive keyword strategy, paid UA interplay, seasonal timing, localization economics. A senior developer is not automatically good at any of that, and pretending the marketing discipline doesn't exist would be its own mistake. That's true. The claim isn't that developers should own every part of ASO or that specialist skill doesn't matter. It's narrower: the parts of ASO that move the needle most — retention, positioning, the listing-to-onboarding continuity — are product decisions, and they suffer when they're treated as someone else's post-launch cleanup. Keep the specialists. Just stop drawing the org-chart line in a place the user never feels.

The reframe

Try this the next time you plan a release. Instead of "we'll build the feature, then hand it to growth for ASO," ask: what does this feature change about who searches for us, what they expect, and whether they'll still be here in a week? Answer those in the same room where you decide what to build. That's not marketing borrowing your engineers. That's product finally including the surface that runs before install.

The apps that compound aren't the ones with the cleverest keyword stuffing. They're the ones that treated the entire journey — search to aha — as one product, owned by the people who build the product.

Wiring RevenueCat Subscriptions into a Flutter App: A Production Setup

Mohamed Haizoun — Thu, 09 Jul 2026 10:06:27 +0000

Subscriptions are where a lot of Flutter apps quietly lose money. Not because the paywall is ugly, but because the plumbing is wrong: entitlements checked in the wrong place, restore-purchases missing, receipts validated on the client, no single source of truth for "is this user premium?" RevenueCat exists to handle that plumbing, but you still have to wire it correctly.

This is a production-minded walkthrough — not "call purchasePackage and you're done," but the setup I'd actually ship: a clean entitlement gate, correct restore behavior, and a reactive premium state your whole app can trust.

Why not just use the raw billing APIs?

Apple and Google's billing APIs give you a receipt. They do not give you: cross-platform entitlement state, server-side receipt validation, subscription status webhooks, or an answer to "did this user's trial convert?" You can build all of that yourself. On a solo or small team, you shouldn't. RevenueCat gives you a single CustomerInfo object that tells you what the user is entitled to, validated server-side, identical on iOS and Android.

Modeling products the right way

Before touching code, get the mental model straight, because this is where people go wrong:

Products are the SKUs you configure in App Store Connect and Google Play (e.g. pro_monthly, pro_annual).
Entitlements are what a product unlocks (e.g. premium). Your app checks entitlements, never product IDs.
Offerings are the set of products you show on a paywall. You can swap offerings remotely without shipping an update.

The golden rule: your code asks "does the user have the premium entitlement?" — it never asks "did they buy pro_monthly?" That indirection is what lets you rename SKUs, run price experiments, and add plans without touching app logic.

Initialization

Initialize once at startup, before any purchase UI can appear:

Future<void> initPurchases() async {
  await Purchases.setLogLevel(LogLevel.info);
  final config = PurchasesConfiguration(
    Platform.isIOS ? 'appl_YOUR_IOS_KEY' : 'goog_YOUR_ANDROID_KEY',
  );
  await Purchases.configure(config);
}

One production note: do not set an app user ID here unless you have a real, stable account ID for the user. If you use anonymous IDs now and add login later, RevenueCat's logIn() will alias the two. Getting this wrong scatters a single customer across multiple identities and breaks your revenue reporting.

A reactive premium gate

The whole app needs to know, reactively, whether the user is premium. RevenueCat pushes updates through a listener; wrap it so the rest of your app consumes a simple boolean stream.

void start() {
  Purchases.addCustomerInfoUpdateListener(_onUpdate);
  _refresh();
}

void _onUpdate(CustomerInfo info) {
  final active = info.entitlements.active.containsKey('premium');
  _controller.add(active);
}

Because RevenueCat validates receipts server-side and pushes changes through this listener, your gate updates correctly even when a subscription renews, lapses, or gets refunded in the background — no polling, no client-side receipt parsing.

Presenting the paywall

Fetch the current offering and render its packages. Never hard-code prices — read the localized priceString so users see the right currency and amount for their store region.

Future<bool> buy(Package package) async {
  try {
    final result = await Purchases.purchasePackage(package);
    return result.customerInfo.entitlements.active.containsKey('premium');
  } on PlatformException catch (e) {
    final code = PurchasesErrorHelper.getErrorCode(e);
    if (code == PurchasesErrorCode.purchaseCancelledError) {
      return false; // user backed out — not an error, don't alert
    }
    rethrow;
  }
}

That purchaseCancelledError branch matters. A huge share of "purchase failed" support tickets are really just users tapping cancel. Treat cancellation as a normal outcome, not a crash.

The two things people forget

1. Restore purchases. Apple will reject your app without it, and users switching devices need it. Call Purchases.restorePurchases() — the entitlement listener fires automatically, so there's no manual state update to do.

2. Trial and intro-offer eligibility. If you advertise "7-day free trial" to a user who already used it, the store will charge them immediately and you'll get a chargeback and a one-star review. Check eligibility with checkTrialOrIntroductoryPriceEligibility before showing trial copy.

Testing before you ship

Use sandbox accounts on iOS and a license-tester account on Android. Verify, at minimum: a fresh purchase flips the gate, killing and relaunching the app keeps premium (state is restored from RevenueCat, not local storage), restore works on a second device, and cancelling mid-flow leaves the user unchanged. If all four pass, your plumbing is sound.

The payoff

Once this is in place, adding a new plan is a config change in the RevenueCat dashboard, not a release. Running a price experiment is an offering swap. Answering "how many trials converted last month?" is a dashboard glance instead of a data-engineering project. That's the real win — you spent an afternoon on plumbing so you never have to think about it again.

Offline-First Sync in Flutter with Drift and Riverpod

Mohamed Haizoun — Thu, 09 Jul 2026 10:03:33 +0000

Most mobile apps are written as if the network is always there. It isn't. Users open your app in elevators, on planes, on rural roads, and in the ninety seconds before a train enters a tunnel. An offline-first app treats the local database as the source of truth and the network as a background detail — reads and writes never block on connectivity, and the server catches up when it can.

This tutorial builds a small task app that works fully offline and syncs to a remote backend when a connection is available. We'll use Drift for a reactive local SQLite layer and Riverpod to expose that data to the UI. By the end you'll have a pattern you can drop into a real app.

What "offline-first" actually means

Three rules define the architecture:

The UI only ever reads from the local database. It never waits on an HTTP call to show data.
Writes go to the local database first, then get queued for the server.
A sync engine reconciles the two on a schedule, on reconnect, and on demand.

Everything below is in service of those three rules.

Setting up Drift

Add the dependencies:

dependencies:
  drift: ^2.16.0
  sqlite3_flutter_libs: ^0.5.20
  path_provider: ^2.1.2
  path: ^1.9.0
  flutter_riverpod: ^2.5.1
  connectivity_plus: ^6.0.1

Define a tasks table. The two columns that make sync possible are updatedAt (for last-write-wins conflict resolution) and syncStatus (so we know which rows still need to be pushed). The important detail is that Drift's watch() returns a Stream that re-emits every time the underlying rows change — that stream is what makes the UI feel instant, because a local write updates the screen before any network call is even attempted.

Exposing data through Riverpod

Riverpod turns the Drift stream into something the widget tree can watch. There is nothing about HTTP in this layer — the UI has no idea the network exists.

final tasksProvider = StreamProvider<List<Task>>((ref) {
  return ref.watch(databaseProvider).watchTasks();
});

Creating a task is a local write plus a status flag set to pending. The moment the write completes, watchTasks() fires and the list rebuilds. The user sees their task immediately, connection or not.

The sync engine

Now the interesting part: pushing pending rows to the server and pulling remote changes. The engine runs when connectivity returns and when the app asks it to.

Future<void> sync() async {
  if (_running) return; // never overlap two sync passes
  _running = true;
  try {
    await _push(); // send pending rows, mark them synced
    await _pull(); // fetch remote changes since last pull
  } catch (_) {
    // Swallow and retry next cycle — offline-first means failure is normal.
  } finally {
    _running = false;
  }
}

Two design choices do the heavy lifting:

The _running guard prevents two sync passes from racing when connectivity flaps — a surprisingly common source of duplicate writes.
Last-write-wins on updatedAt is the simplest conflict strategy that actually works for single-user data. If two devices edit the same row, the newer timestamp wins. For collaborative data you'd reach for CRDTs, but don't pay that complexity tax until you need it.

Where to go next

This pattern scales further than you'd expect. Add a deletedAt tombstone column so deletes propagate. Batch your push into a single request when the server supports it. Add exponential backoff to the catch block. But the core stays the same: local database is truth, network is a background job, and the UI never waits.

The full benefit shows up the first time a user files a bug that says "the app was slow on the subway" — and you realize your app doesn't have that bug, because it never touched the network to draw a screen.