DEV Community: Khalit Hartmann

Klaviyo Push Notifications in Flutter: 3 Silent Pitfalls

Khalit Hartmann — Fri, 17 Jul 2026 19:18:41 +0000

For CTOs, tech leads, and senior developers debugging why Klaviyo push notifications stopped working in their Flutter app — or about to find out why they will.

Klaviyo × Flutter series (part 3 of 4): planning & scope · the analytics layer · push notification pitfalls · profiles & newsletter.

TL;DR: The Klaviyo Flutter SDK's push setup looks like a 10-minute job — until you add it to an app that already uses firebase_messaging. Three silent bugs surfaced in production:

Silently dropped pushes: Multiple Android services competing for the MESSAGING_EVENT intent caused Klaviyo pushes to vanish without a trace.
Broken tap handling: On both platforms, Klaviyo's tap handler broke firebase_messaging's onMessageOpenedApp callback — deep links stopped working.
Invisible marketing pushes: Android's write-once channel importance meant marketing notifications displayed silently instead of as heads-up banners.

The 10-minute install and the 3-day debug

The Klaviyo Flutter SDK's push notification setup documentation reads like a checklist: add the klaviyo_flutter_sdk package, pass the FCM token, register for remote notifications on iOS. If you follow it from scratch in a new project, it works. The problems appear when you add Klaviyo to an app that already uses firebase_messaging — which is every Flutter app that already sends push notifications.

The collision is not a Klaviyo bug. It is a consequence of how Android's intent system and iOS's notification delegate chain work when multiple frameworks compete for the same system callbacks. The SDK documentation does not warn you because the SDK works correctly in isolation. The failures are integration-level, not SDK-level, and they produce no error logs, no crashes, no warnings. Pushes just stop arriving, taps stop responding, or banners stop popping up — and you have nothing in the console to search for.

This post covers three pitfalls I hit during a production Klaviyo integration into a Flutter e-commerce app. The overview post maps the full integration scope; this one zooms into the push layer. Each pitfall took longer to diagnose than to fix.

Pitfall 1: Your Klaviyo pushes are being silently dropped

On Android, push notifications arrive through Firebase Cloud Messaging. FCM delivers each incoming message to a service registered with the com.google.firebase.MESSAGING_EVENT intent filter. The critical detail: FCM dispatches to exactly one service. If multiple services declare the same intent filter, Android picks one based on service resolution order — and the others receive nothing.

After adding the Klaviyo SDK, the merged Android manifest contained three competing services:

FlutterFirebaseMessagingService — registered by the firebase_messaging plugin
KlaviyoPushService — registered by the Klaviyo SDK
A custom service — the app's own messaging service

FCM picked one. The others were silently excluded. No exception, no log entry. Messages dispatched to the wrong service simply vanished. If FlutterFirebaseMessagingService won, Klaviyo pushes were dropped. If KlaviyoPushService won, the app's own push handling broke.

The fix: a single unified service

The solution is a single custom service that extends FlutterFirebaseMessagingService and delegates Klaviyo messages based on the _k payload marker:

// AppPushService.kt
package com.example.app

import android.util.Log
import com.google.firebase.messaging.RemoteMessage
import com.klaviyo.pushFcm.KlaviyoNotification
import io.flutter.plugins.firebase.messaging.FlutterFirebaseMessagingService

class AppPushService : FlutterFirebaseMessagingService() {
    override fun onMessageReceived(message: RemoteMessage) {
        if (message.data.containsKey("_k")) {
            try {
                KlaviyoNotification(message).displayNotification(applicationContext)
            } catch (t: Throwable) {
                Log.e(TAG, "KlaviyoNotification.displayNotification failed", t)
            }
        }
        super.onMessageReceived(message)
    }

    companion object {
        private const val TAG = "AppPushService"
    }
}

Extending FlutterFirebaseMessagingService ensures that firebase_messaging's Dart-side callbacks (onMessage, onMessageOpenedApp) keep working for non-Klaviyo pushes via the super.onMessageReceived(message) call. The _k check gates only the Klaviyo rendering. Every message still flows through the Flutter plugin's handler.

The second half of the fix is removing the competing services from the merged manifest:

<service android:name=".AppPushService" android:exported="false">
  <intent-filter>
    <action android:name="com.google.firebase.MESSAGING_EVENT"/>
  </intent-filter>
</service>
<service
    android:name="io.flutter.plugins.firebase.messaging.FlutterFirebaseMessagingService"
    tools:node="remove"/>
<service
    android:name="com.klaviyo.pushFcm.KlaviyoPushService"
    tools:node="remove"/>

The tools:node="remove" directive strips both plugin-registered services from the final merged manifest. Only AppPushService remains, and FCM has exactly one target.

Pitfall 2: Push taps stop working on both platforms

After fixing delivery, a second problem appeared: tapping a notification stopped doing anything useful.

Two things broke independently on the two platforms.

On Android, Klaviyo's SDK builds its own PendingIntent for the notification it displays. That intent does not carry the FCM extras that firebase_messaging needs to populate the RemoteMessage object in onMessageOpenedApp. When the user taps a Klaviyo notification, the app opens, but firebase_messaging's tap callback receives an empty message — or never fires at all. The Dart-side onMessageOpenedApp handler that normally routes deep links gets nothing.

On iOS, the problem was in the UNUserNotificationCenter delegate chain. The initial implementation forwarded every notification tap to Klaviyo's handler without calling super. That meant firebase_messaging's plugin — which also hooks into the same delegate method — never saw non-Klaviyo taps. The app's own push-based navigation stopped working entirely.

The `_k` marker and the iOS trap

The fix is gating on Klaviyo's _k marker on both platforms, and always calling super so firebase_messaging keeps working for non-Klaviyo pushes.

There is a subtle platform difference here that cost debugging time: on Android, _k sits top-level in the FCM data payload. On iOS, it is nested under the body key of the APNs payload. A naive check for userInfo["_k"] on iOS will miss it.

override func userNotificationCenter(
    _ center: UNUserNotificationCenter,
    didReceive response: UNNotificationResponse,
    withCompletionHandler completionHandler: @escaping () -> Void
) {
    let userInfo = response.notification.request.content.userInfo
    let isKlaviyoPush =
        (userInfo["body"] as? [AnyHashable: Any])?["_k"] != nil
        || userInfo["_k"] != nil

    if isKlaviyoPush {
        KlaviyoFlutterSdkPlugin.shared.handleNotificationResponse(response)
    }

    super.userNotificationCenter(
        center,
        didReceive: response,
        withCompletionHandler: completionHandler
    )
}

The double check — body._k first, then top-level _k as a fallback — handles both the current APNs payload structure and guards against future changes.

The critical line is super.userNotificationCenter(...). Without it, firebase_messaging never receives the tap event, and onMessageOpenedApp on the Dart side stays silent for non-Klaviyo pushes. Always call super, regardless of whether the push is from Klaviyo.

Dart-side handling: skip Klaviyo taps

On the Dart side, the onMessageOpenedApp handler should skip messages that carry the _k marker. The Klaviyo native SDK already tracks the open event when the user taps a Klaviyo notification — if the Dart handler also processes it, you get double handling: Klaviyo registers the open, and your app also tries to route a deep link that does not exist in the Klaviyo payload.

The gate is straightforward: check for _k in message.data on Android, skip if present. On iOS the Klaviyo tap is already handled natively and typically does not bubble to onMessageOpenedApp at all if the delegate chain is set up correctly.

Pitfall 3: Android channel importance is write-once

This one is the quietest failure mode. Klaviyo pushes arrive. Taps work. But the notifications show up silently in the notification shade instead of popping up as heads-up banners. Marketing pushes that nobody sees are marketing pushes that do not convert — and in a DTC e-commerce app, push notifications are a direct revenue channel. Silent notifications mean lost sales, not just a UX inconvenience.

The cause is an Android platform behavior: notification channel importance is immutable after creation. Once a channel is registered with Importance.DEFAULT, no code can raise it to Importance.HIGH. The channel ID is the key — same ID, same importance, forever, until the user manually changes it in system settings or the app deletes and recreates the channel with a new ID.

If the app's notification channels were originally created at default importance — which is common, since default importance is the... default — then switching to Klaviyo for marketing pushes does not magically upgrade those channels. The push arrives, lands in the existing channel, and displays silently.

The fix: bump the channel ID

The only reliable fix is to create new channels with new IDs at the desired importance level, and delete the legacy channels on startup.

enum NotificationChannelId {
  marketing('marketing_v2'),
  content('content_v2'),
  loyalty('loyalty_v2');

  const NotificationChannelId(this.id);
  final String id;
}

The _v2 suffix is a convention, not a requirement — any new string works. The point is that it is a different channel ID, so Android creates a fresh channel with the importance level you specify at creation time. On app startup, delete the legacy channel IDs so users do not see duplicate entries in their notification settings.

This generalizes beyond importance: any channel-level property change in Android — sound, vibration pattern, LED color — requires an ID bump. Android's channel system is designed to give users control after the channel is created. The app gets one shot at the defaults.

What this means for your estimate

If someone quotes you a day for "adding Klaviyo push notifications to the Flutter app," they are quoting the SDK installation. The SDK installation is real — it takes an hour or two. But if the app already has firebase_messaging, the three pitfalls above are near-certain, and each one takes longer to diagnose than to fix.

A realistic estimate for push notification integration in a Flutter app that already uses firebase_messaging:

Delivery routing (Pitfall 1): 0.5–1 day. The fix is small; diagnosing silent drops is the time sink.
Tap collision (Pitfall 2): 0.5–1 day. Two platforms, two different _k locations, both need testing.
Channel importance migration (Pitfall 3): 0.25–0.5 day. Straightforward once diagnosed.
iOS Notification Service Extension (if rich push is required): 0.5–1 day. Klaviyo's rich push (images, GIFs, action buttons) requires a separate Xcode target that the Flutter toolchain does not scaffold. The extension code itself is minimal — KlaviyoSwiftExtension handles media downloads — but the Xcode configuration, provisioning profile, and app group setup are all manual steps.

Total: 2–3.5 days for push alone, not counting QA across both platforms with real devices. End-to-end push delivery through Klaviyo's infrastructure requires physical devices — the iOS simulator supports basic push simulation (drag-and-drop APNs payloads since Xcode 11.4), but the full Klaviyo routing chain only works on real hardware. Budget for device builds on both platforms.

If you are evaluating a Klaviyo integration as part of a larger app development project, the push layer is just one of four workstreams — the overview post maps the full scope.

Planning a Klaviyo integration for your Flutter app? I've shipped this in production and documented the hours — book a 20-minute coffee chat and bring your tech stack. I'll tell you where the days will go.

The pattern across all three pitfalls

The failure is silent, the diagnosis takes longer than the fix, and the root cause is a platform behavior — not a Klaviyo bug. Here is what that means in practice:

Silent failures are the worst failures. All three pitfalls produce zero log output. The push arrives at the device, gets dispatched to the wrong handler or the wrong channel, and disappears. Add logging at the native service entry point before you start debugging anything else.
The _k marker is your routing key. Every Klaviyo-specific code path — delivery, taps, Dart-side handling — should gate on this single marker. Memorize where it lives: top-level in Android data payloads, nested under body in iOS APNs payloads.
tools:node="remove" is essential in multi-SDK Android apps. When two plugins register services for the same intent filter, the merged manifest creates a race condition. Stripping the plugin-registered services and replacing them with a single custom service is the pattern.
Channel importance is a one-shot decision. If you are setting up notification channels for the first time, think about importance carefully. If the channels already exist at default importance, the only path to heads-up banners is a new channel ID.
Budget platform debugging, not SDK installation. The SDK works. The platform integration is where the days go.

For debugging all three pitfalls, start with native-layer logging at the service entry point. On Android, add a Log.d call at the top of onMessageReceived in your custom service — if you never see the log line, the service is not receiving messages. On iOS, log in the didReceive delegate method. These entry-point logs are the fastest way to determine which layer is swallowing the message.

With push delivery, taps, and channels sorted, the remaining integration work was identity and newsletter — which introduced its own set of silent data-integrity bugs. Part 4 covers those traps.

Frequently Asked Questions

How do I set up Klaviyo push notifications in Flutter?

Install the klaviyo_flutter_sdk package, pass the FCM token to Klaviyo on app startup, and register for remote notifications on iOS. The SDK documentation covers the basic steps — the setup itself takes an hour or two. The real work starts when you hit the three integration pitfalls described above, which are near-certain if the app already uses firebase_messaging.

Can I test Klaviyo push notifications in the iOS simulator?

Partially. The iOS simulator supports basic push simulation via drag-and-drop APNs payloads (since Xcode 11.4), and Android emulators with Google Play Services can receive FCM messages. However, end-to-end delivery through Klaviyo's infrastructure — where Klaviyo sends the push via FCM/APNs — requires physical devices on both platforms. The three integration pitfalls described above all manifested during real-device testing.

Does the MESSAGING_EVENT conflict apply to other push SDKs besides Klaviyo?

Yes. Any SDK that registers its own FirebaseMessagingService in the Android manifest will create the same intent filter collision. The pattern — a single custom service that extends FlutterFirebaseMessagingService and delegates based on payload markers — applies to any multi-SDK push setup.

Do I need to fix all three pitfalls, or can I skip some?

Pitfall 1 (delivery routing) is mandatory — without it, either Klaviyo pushes or your existing pushes will be silently dropped. Pitfall 2 (tap collision) depends on whether your app uses onMessageOpenedApp for deep linking. Pitfall 3 (channel importance) only matters if you need heads-up banners for marketing pushes, but marketing pushes that display silently have significantly lower engagement.

One trackEvent(), Four SDKs: Analytics Layer for Flutter

Khalit Hartmann — Fri, 17 Jul 2026 12:59:12 +0000

For CTOs, tech leads, and senior developers managing analytics across multiple providers in a production mobile app — or about to add Klaviyo to an existing Firebase setup.

Klaviyo × Flutter series (part 2 of 4): planning & scope · the analytics layer · push notification pitfalls · profiles & newsletter.

TL;DR: Before adding Klaviyo to a Flutter e-commerce app, I built a unified analytics layer — an AnalyticsDispatcher that fans one trackEvent() call to every registered provider through per-provider adapters. The dispatcher handles consent gating and error isolation so one SDK crashing never blocks the others. Google Ads was added after Klaviyo with zero changes to any call site — the pattern paid for itself immediately.

The starting point: 10 call sites, 2 SDKs, no abstraction

The app — a Flutter e-commerce app for a Shopify-based DTC jewelry brand — had grown its analytics organically. About 10 screens and controllers tracked events. Each one imported FirebaseAnalytics directly, built a parameter map, and called logEvent(). A second SDK — an attribution service — was wired in alongside it in some of those same call sites.

No interface. No shared contract. Every call site had to know which SDKs existed and how to talk to each one.

That worked with two providers and low churn. The moment the client asked for a Klaviyo integration, the math changed. Adding Klaviyo to the existing model meant visiting every one of those ~10 call sites, adding a third direct call, and tripling the consent-checking surface. The next provider after that — Meta was already in the estimate — would do it again.

Rough count before the refactoring: ~10 call sites, ~15 integration points (some files called both SDKs, some only Firebase), 0 shared abstractions. After: ~10 call sites, 1 integration point each, and a dispatcher that handles the fan-out.

The analytics layer was the largest single work package of the entire Klaviyo project. It had to ship and stabilize before the Klaviyo adapter could plug in.

The design: Adapter + Mediator

The architecture has two moving parts: an interface that every provider implements, and a dispatcher that iterates over all registered providers.

The adapter interface

Every analytics SDK — Firebase, Klaviyo, Google Ads, and a Meta stub — implements IAnalyticsAdapter:

enum AnalyticsProviderId {
  firebase('firebase_template_id'),
  klaviyo('klaviyo_template_id'),
  googleAds('google_ads_template_id');

  const AnalyticsProviderId(this.templateId);
  final String templateId;
}

typedef ConsentResolver = bool Function(String templateId);

abstract class IAnalyticsAdapter {
  AnalyticsProviderId get providerId;

  Future<void> trackEvent({
    required String eventName,
    Map<String, Object?>? parameters,
  });
  Future<void> trackScreenView({
    required String screenName,
    String? screenClass,
  });
  Future<void> setUserProperty({
    required String name,
    required String value,
  });
  Future<void> setUserId(String? userId);
  Future<void> setEnabled(bool enabled);

  Future<void> applyConsent(ConsentResolver hasConsent) {
    return setEnabled(hasConsent(providerId.templateId));
  }
}

The templateId on each enum value is the key used by the consent management platform (Usercentrics in this project) to identify each data processor. More on that in the consent section below.

The applyConsent method has a default implementation: it resolves the provider's own template ID against the consent resolver and calls setEnabled. Providers that need deeper consent integration — Firebase with Google Consent Mode v2, for example — override this method.

The dispatcher

The AnalyticsDispatcher receives events through a single API and fans them out:

class AnalyticsDispatcher {
  final List<IAnalyticsAdapter> _providers;
  final ConsentResolver _hasConsent;

  Future<void> trackEvent({
    required String eventName,
    Map<String, Object?>? parameters,
  }) async {
    await _checkConsentAndDispatch(
      (provider) => provider.trackEvent(
        eventName: eventName,
        parameters: parameters,
      ),
      debugLabel: 'trackEvent($eventName)',
    );
  }

  Future<void> _checkConsentAndDispatch(
    Future<void> Function(IAnalyticsAdapter provider) action, {
    String? debugLabel,
  }) async {
    for (final provider in _providers) {
      final name = provider.providerId.templateId;
      final hasConsent = _hasConsent(name);
      if (!hasConsent) continue;
      try {
        await action(provider);
      } catch (e) {
        developer.log(
          'Error in $debugLabel on $name: $e',
          name: 'AnalyticsDispatcher',
          error: e,
        );
      }
    }
  }
}

Three things happen in _checkConsentAndDispatch:

Consent gating. Each provider's template ID is checked against the user's consent state. No consent, no call. The provider never even sees the event.
Error isolation. Each provider call is wrapped in its own try/catch. If Klaviyo's SDK throws, Firebase and Google Ads still receive the event. Failures are logged but never propagated.
Debug labeling. The debugLabel parameter produces readable log messages like Error in trackEvent(view_item) on klaviyo_template_id: ... — which makes production debugging viable without a debugger attached.

Every call site in the app now depends on a single type: the dispatcher. Screens and controllers call dispatcher.trackEvent(...) and never import a provider SDK directly. The Firebase Analytics integration, the Klaviyo adapter, attribution — all invisible to the calling code. That single interface also means every call site can be tested with one mock dispatcher that asserts on event names and parameters — no per-provider mocking, no coupling to SDK internals.

Patterns rejected on purpose

The Adapter + Mediator combination was not the first option on the whiteboard.

Observer pattern. The textbook choice for "one event, many listeners." But Observer assumes listeners subscribe and unsubscribe dynamically at runtime. Analytics providers don't do that — they're registered at app startup and stay fixed. The subscription mechanism would be dead weight, and the untyped event payloads would lose the structured contract the adapter interface provides.

Strategy pattern. Strategy selects one behavior from many at runtime. The analytics layer needs the opposite: every registered provider receives every event. Strategy's one-of-N semantics are wrong for a fan-out-to-all scenario.

Plain callback list. A List<Function> that the dispatcher iterates over. Lightweight, but it can't carry consent state, initialization logic, or typed methods like setUserProperty and trackScreenView. The moment you need more than fire-and-forget event dispatch, callbacks force you to rebuild the interface anyway.

The Adapter + Mediator design costs one class per provider instead of a closure. In exchange: typed method contracts, per-provider consent and lifecycle management, and the ability to add provider-specific methods (like Klaviyo's setProfile) without leaking them into the dispatcher interface.

GA4 names as the canonical event language

The dispatcher needs a naming convention for events. Every provider speaks a different dialect — Firebase expects view_item, Klaviyo expects Viewed Product, Google Ads maps to conversion IDs. Someone has to pick the canonical format.

GA4 event names were the right choice for us. They are the de-facto industry standard for e-commerce events, Firebase consumes them natively without any mapping, and every other provider can map from them internally.

How events map across providers

GA4 Event	Firebase	Klaviyo Adapter
`app_open`	`app_open` (custom event)	`EventMetric.openedApp`
`view_item`	`view_item` (GA4 native)	`EventMetric.viewedProduct` (with `value`)
`add_to_cart`	`add_to_cart` (GA4 native)	`EventMetric.addedToCart` (with `value`)
`search`	`search` (GA4 native)	custom metric (name pass-through)
`screen_view`	`screen_view` (GA4 native)	`app_viewed_page` (custom metric)

The Firebase adapter is a thin wrapper — it passes GA4 names straight through because that's what Firebase expects. The Klaviyo adapter does the real mapping work: translating GA4 names into Klaviyo's EventMetric enum values and restructuring parameters. Google Ads maps events to conversion tracking IDs configured in the adapter.

The key constraint: the canonical event — including its parameter map — carries enough information for every provider to derive what it needs. If a provider requires a parameter that no other provider uses, the adapter adds it internally rather than polluting the canonical format.

Consent: the part everyone gets wrong

Consent in a multi-provider analytics setup requires two distinct mechanisms. Most implementations get one right and miss the other.

Mechanism 1: Per-call gating

The dispatcher checks consent before forwarding each event. If the user hasn't consented to Klaviyo, the Klaviyo adapter never fires. This is the mechanism shown in the _checkConsentAndDispatch method above.

This works for providers that are passive — they only fire when you call them. Klaviyo is one: the SDK has no runtime collection toggle. There's no Klaviyo.setEnabled(false). Once initialized, the SDK is active. The consent gate lives entirely in the dispatch layer.

Mechanism 2: SDK-level consent for auto-collecting providers

Firebase is different. Even if the dispatch layer blocks all trackEvent calls, Firebase auto-collects screen views, session starts, and first opens in the background. Those bypass your code entirely.

To stop that collection, you need FirebaseAnalytics.setConsent() with Google Consent Mode v2 parameters:

analyticsStorage — controls measurement data storage
adStorage — controls ad-related storage
adUserData — controls sending user data for ads
adPersonalization — controls ad personalization signals

The Firebase adapter overrides applyConsent to call setConsent() in addition to setEnabled(). Without this, Firebase collects data even when your dispatch layer thinks it's blocked.

The consent lookup

The consent resolver matches each provider's templateId against the entries in the consent management platform. In this project, Usercentrics stores each data processor (Firebase, Klaviyo, Google Ads) under a unique template ID. The resolver performs an exact-match lookup — the same ID that appears in the Usercentrics dashboard must match the templateId on the AnalyticsProviderId enum.

Proof it works: the next provider was cheap

The clearest validation of an abstraction is what happens when you extend it.

Google Ads was added after Klaviyo. The scope: one new adapter class implementing IAnalyticsAdapter, mapping GA4 events to Google Ads conversion tracking calls, and registering the adapter in the provider list. Zero changes to any call site. Zero changes to the dispatcher. The Google Ads PR touched exactly the files it should have touched — the adapter implementation and the provider registration — and nothing else.

Meta was estimated but not built during this project phase. The estimate for the Meta adapter was ~4.25 PT — but a large portion of that budget was SDK setup, platform configuration (Facebook App ID, iOS privacy manifest, Android manifest entries), and test infrastructure. The analytics wiring itself — the adapter class and the event mapping — was estimated at a fraction of the total. That's the point: the layer already exists. The expensive part of adding a new provider is the provider's own setup, not plugging it into your analytics architecture.

Testing the dispatch layer

The single-interface design makes the analytics layer straightforward to test. Call sites test against a mock dispatcher — no per-provider SDK mocking, no coupling to Firebase or Klaviyo internals. The dispatcher itself is tested with stub adapters that record calls, verifying consent gating (provider skipped when consent is missing), error isolation (one adapter throwing does not prevent others from receiving the event), and fan-out (all consented adapters receive every event). The adapter tests are integration-level: each adapter receives a canonical GA4 event and asserts that the correct SDK method was called with the expected parameters.

Takeaways for your analytics layer

The investment — about 2–3 person-days for the core abstraction — amortizes the moment you add a second provider.

Build the layer before the provider. The analytics dispatcher was the largest work package in the Klaviyo project, but it's the one that keeps paying returns. Every subsequent provider integration is scoped to an adapter class and a registration line.
GA4 as canonical is a no-brainer. Any other naming scheme forces you to invent a translation table that Firebase has already standardized. Start with GA4 names; let adapters translate.
Consent needs two mechanisms, not one — and audit your bypasses before release. The dispatch-layer gate handles providers without runtime toggles. It does not stop auto-collecting SDKs. If your only consent mechanism is "don't call the provider," Firebase is still collecting behind your back. And a hardcoded testing shortcut in the consent resolver is a GDPR incident waiting to happen — treat it like a credential that should never exist on the main branch.

In this project, the second provider was Klaviyo, and the third was Google Ads. Neither required touching a single call site. The Klaviyo Flutter integration overview covers the full integration — push notifications, identity, and consent — that this layer made possible.

Wrangling multiple analytics SDKs in your Flutter app? I've built this exact dispatcher pattern in production — let's grab a coffee and I'll sketch how the adapter layer maps to your provider mix.
See how I approach Flutter app development projects end-to-end.

Frequently Asked Questions

Why not just call each analytics SDK directly in Flutter?

Direct calls couple every screen and controller to every SDK. With ~10 call sites and three providers, that is 30 integration points, each needing its own consent check. A dispatcher reduces this to one call-site contract, with consent and error handling implemented once.

Which design pattern fits a multi-provider analytics layer?

A combination of the Adapter pattern (one adapter per SDK, mapping canonical events to the SDK-specific format) and a Mediator/Facade (the dispatcher that fans events out to all consented adapters in parallel). Observer is over-engineered since providers are fixed at startup. Strategy is wrong because you fan out to all providers, not select one.

What event naming should a Flutter analytics layer use?

GA4 event names (view_item, add_to_cart, begin_checkout, purchase) as the canonical format. They are the industry baseline, Firebase consumes them natively, and every other provider can translate from them internally.

How should consent be handled with multiple analytics providers?

Two mechanisms are needed. Per-call gating in the dispatcher covers providers whose SDK has no runtime toggle (like Klaviyo). Providers that auto-collect in the background (like Firebase with Google Consent Mode v2) additionally need the consent status pushed into the SDK via its native consent API. The dispatcher should support both.

Klaviyo Shopify Integration in Flutter: What to Know First

Khalit Hartmann — Thu, 16 Jul 2026 18:25:07 +0000

For CTOs, tech leads, and senior developers evaluating a Klaviyo integration for a mobile e-commerce app — or about to scope one. If you're looking for a step-by-step SDK installation guide, the Klaviyo docs cover that well. This post is about what happens after installation — the architecture, integration, and scoping decisions that determine whether the project takes two weeks or two months.

Klaviyo × Flutter series (part 1 of 4): planning & scope · the analytics layer · push notification pitfalls · profiles & newsletter.

TL;DR: The klaviyo_flutter_sdk installs in minutes. The production integration for a Shopify-based DTC brand took five weeks and six PRs. The single largest investment was a unified analytics abstraction layer that made Klaviyo a clean adapter plug-in — and the one gap no app-side code can close is purchase tracking, because checkout opens in the browser.

Why "install the SDK" is the wrong mental model

When a client asks about a Klaviyo Shopify integration for their Flutter app, the conversation usually starts with the SDK. "How long to install it?" The answer — an hour, maybe two — is technically correct and completely misleading.

The klaviyo_flutter_sdk wraps the native Klaviyo iOS and Android SDKs. It covers profile identification, event tracking, and push token registration. You add the dependency, call Klaviyo.initialize(apiKey), and the SDK is running. But the SDK is a wire — it doesn't decide what flows through it.

A production integration means answering: How do analytics events reach Klaviyo without duplicating the dispatch logic you already have for Firebase? How do push notifications coexist with your existing firebase_messaging setup? How does the app identify a profile without creating duplicates against Klaviyo's own Shopify sync? And how does any of this respect the user's consent choices?

Those four questions are four workstreams. Each one has at least one non-obvious problem. Here's what they looked like in practice, working on a Shopify-based DTC jewelry brand's Flutter app.

Before you start: what the client must provide

Before a Klaviyo integration can begin, three things need to come from outside the development team:

1. Klaviyo public API key (site ID) — the identifier the SDK uses to associate events and profiles with your Klaviyo account. Found in Klaviyo account settings under API keys.

2. A Usercentrics data-processor entry for Klaviyo — if your app uses a CMP (and in the EU, it does), Klaviyo needs its own entry. This is a legal/compliance configuration, not an SDK task. Without it, the consent gate has nothing to check against.

3. The newsletter list ID — Klaviyo organizes subscribers into lists. The app needs the ID of the specific list to subscribe profiles to. Your marketing team creates the list; the developer gets the ID.

Workstream 1: Building a Flutter analytics layer for Klaviyo

Before touching Klaviyo, the app's analytics needed an abstraction layer. The existing setup had ~10 call sites scattered across the codebase, each calling Firebase Analytics and an attribution service directly. No interface, no shared dispatch — every screen that tracked an event imported the Firebase service, constructed the event payload, and fired it.

Adding Klaviyo into that model would mean visiting every call site, adding a third direct call, and tripling the maintenance surface. The next provider after that — Meta, for example — would do it again.

The solution was an Adapter + Mediator pattern: a single AnalyticsDispatcher that receives events through one API and fans them out to per-provider adapters. Each adapter (Firebase, attribution, Klaviyo, and a Meta stub) implements the same interface. The dispatcher iterates over active adapters, checks consent for each, and forwards the event.

Deep dive: One trackEvent(), Four SDKs — the full architecture →

Workstream 2: Klaviyo push notifications in Flutter

Klaviyo sends push notifications through FCM on Android and APNs on iOS. The klaviyo_flutter_sdk handles push token registration — you pass the token to Klaviyo, and Klaviyo associates it with the identified profile. Straightforward in isolation.

The problem: the app already had a working push setup with firebase_messaging. On Android, three services competed for the com.google.firebase.MESSAGING_EVENT intent filter — the app's own FirebaseMessagingService, Klaviyo's service, and the default FCM service. Android's service resolution dispatches to exactly one. In this case, Klaviyo's service was winning, which meant non-Klaviyo pushes were silently dropped. The fix was routing all incoming messages through a single service and dispatching based on payload markers.

On iOS, the Notification Service Extension was required for Klaviyo's rich push (images, action buttons). The extension intercepts the notification before display, downloads the media, and attaches it. Setting this up means a separate Xcode target, a shared app group, and careful configuration of the mutable-content flag. The tap handler also needed gating: Klaviyo pushes carry a _k marker in the payload, and the app has to distinguish those from its own deep-link pushes to route correctly.

The collision between existing firebase_messaging and the Klaviyo SDK was the most time-consuming debugging session of the project. Push notifications that silently disappear produce no error logs — the message arrives, gets dispatched to the wrong service, and vanishes. If you're dealing with push notification complexity beyond Klaviyo, I've also written about designing context-aware push notification systems.

Deep dive: Klaviyo Push Notifications in Flutter — three pitfalls →

Workstream 3: Klaviyo profile identity & newsletter in Flutter

Klaviyo identifies profiles by email. The Shopify backend also syncs customer data to Klaviyo via the native Shopify-Klaviyo integration. This creates a coordination problem: the app and the backend both write to the same Klaviyo account, and they need to agree on identity.

The initial approach — passing external_id alongside email to link app-created profiles with Shopify-synced ones — backfired. Klaviyo's profile merge logic treated external_id as a strong identifier. Instead of merging profiles, it suppressed auto-merge and created duplicates. The fix was using email-only identification from the app side and letting Klaviyo's own merge logic handle deduplication against the Shopify sync.

Newsletter subscription added another asymmetry. Subscribing a profile to a list works through Klaviyo's client API — the app calls Klaviyo.subscribeToList(listId) and the profile gets added. Unsubscribing, however, is not available through the client SDK. The solution was an asymmetric flow: unsubscribe triggers a custom event from the app, which fires a Klaviyo flow, which calls a webhook to remove the profile from the list. Subscribe is synchronous and direct; unsubscribe is event-driven and indirect.

Deep dive: Klaviyo Profiles & Newsletter — where the docs won't save you →

Workstream 4: Consent management for Klaviyo with Usercentrics

Every analytics provider in the app is gated on user consent, managed through a Usercentrics CMP (Consent Management Platform). No consent, no tracking — GDPR requires it, and in practice it means the consent config blocks or unblocks each provider independently.

Klaviyo doesn't have a runtime collection toggle. There's no Klaviyo.setEnabled(false) — once initialized, the SDK is active. The consent gate lives in the dispatch layer: the AnalyticsDispatcher checks the user's consent state for Klaviyo before forwarding any event to the Klaviyo adapter. If consent isn't granted, the adapter never fires.

Firebase requires a different mechanism. Beyond the dispatch-layer gate, Firebase has auto-collection behaviors (screen views, session starts) that ignore your code-level event calls. Those need FirebaseAnalytics.setConsent() with Google Consent Mode v2 parameters — analyticsStorage, adStorage, adUserData, adPersonalization. Without this, Firebase collects data even when your dispatch layer blocks it.

The dispatcher supports both mechanisms: per-call gating for providers like Klaviyo that lack a native toggle, and SDK-level consent APIs for providers like Firebase that have one. Both check the same consent state from Usercentrics.

The Shopify checkout problem: why Flutter can't track purchases

The app tracks three native Klaviyo metrics: openedApp, viewedProduct, and addedToCart. These fire from app code, flow through the dispatch layer, and land in Klaviyo for segmentation and flow triggers.

There's a fourth metric you'd expect: purchase. It's absent — and it can't be added from the app.

The reason: checkout opens in the system browser. The user taps "Buy now," the app launches a Shopify checkout URL in Safari or Chrome, and the purchase completes there. The app has no callback, no webhook, no way to know that the purchase happened. The browser session is outside the app's process, and Shopify's checkout doesn't call back into the native app.

This means purchase-based flows in Klaviyo — post-purchase emails, win-back sequences based on order history, revenue attribution — can't be triggered from app-side events. The data has to come from somewhere else.

Three options exist, all outside the app's scope:

Shopify web pixels: Shopify's native analytics integration can forward checkout events to Klaviyo. This runs entirely in the Shopify checkout, no app involvement needed.
Order webhooks to a backend: Shopify fires order webhooks (orders/create) to a backend service, which calls Klaviyo's server API to record the purchase event.
Hybrid: Combine web pixels for real-time tracking with webhooks as a fallback for reliability.

The choice depends on the client's infrastructure. If they have a backend that already processes Shopify webhooks, the webhook path is straightforward. If they don't, Shopify web pixels are the lower-maintenance option.

The key point: this decision needs to happen before or during the integration, not after. If the marketing team expects purchase-based flows in Klaviyo and the integration plan only covers app-side code, there's a gap that no amount of Flutter development will close.

Hitting the same Shopify checkout gap? I've navigated this with Shopify-backed Flutter apps — let's map your options in 15 minutes.

The real timeline

The project ran for about five calendar weeks, delivered across six pull requests. The phasing was deliberate: foundation first, then call-site migration, then provider integration, then QA.

Work Package	Scope	Effort
Core abstraction	AnalyticsProvider interface, AnalyticsDispatcher	2 PT
Firebase adapter	Wrap existing service	2.5 PT
Attribution adapter	Wrap existing service + provider	1 PT
Riverpod wiring + consent	Provider setup, ConsentController	0.25 PT
Call-site migration	Replace in ~10 files (~15 call points)	1 PT
Klaviyo SDK integration	Dependency, adapter, native setup	2.5 PT
Meta stub	Placeholder ready for activation	0.25 PT
QA & regression	All events, consent toggling, Klaviyo	1 PT
Total		~10 PT

Five scoping mistakes to avoid

Skipping the abstraction layer. Adding Klaviyo to scattered direct calls creates a migration inside a migration. The dispatch layer was about 4.5 PT upfront, but it made every subsequent provider integration a clean adapter plug-in.
Underestimating push notification conflicts. When two services compete for the same Android intent filter, the loser doesn't crash — it never gets called. No error logs, no exceptions. Budget time for debugging silent push failures.
Using external_id for identity against a Shopify-synced account. It seems right — link app profiles to Shopify profiles by ID. In practice, it suppresses Klaviyo's auto-merge and creates duplicates. Email-only identification is the fix.
Treating consent as a global toggle. Different providers need different consent mechanisms. A dispatch-layer gate works for Klaviyo. Firebase needs its own setConsent() API call on top. Build for per-provider consent from the start.
Discovering the purchase tracking gap after the SDK is integrated. This is the one thing that determines whether the integration meets marketing's expectations. Raise it in the first scoping conversation.

Conclusion

A Klaviyo integration into a production Flutter e-commerce app is four workstreams: analytics abstraction, push notifications, identity and newsletter, and consent. The SDK itself is a small part of the total effort — the architecture around it is where the weeks go. The integration shipped to production and has been running since.

The most important thing to get right isn't code. It's scoping the purchase tracking gap before development starts, so the marketing team's expectations match what the app can deliver. Everything the app can track — opens, product views, cart additions — flows through cleanly. Purchases don't, and that's a Shopify/backend decision, not a Flutter one.

Planning a Klaviyo integration for your Flutter or mobile app? I've done this in production — book a casual coffee chat and I'll walk you through what it takes for your setup. Or continue reading the series: the analytics layer · push notification pitfalls · profiles & newsletter.

See how I approach Flutter app development projects end-to-end.

Frequently Asked Questions

Does Klaviyo have a Flutter SDK?

Yes. The klaviyo_flutter_sdk package wraps the native Klaviyo iOS and Android SDKs and covers profile management, event tracking, and push notifications. It handles push token registration via FCM on Android and APNs on iOS.

How long does a Klaviyo integration into a Flutter app take?

For a production e-commerce app, the realistic scope is several weeks, not days. In the project this article is based on, the work spanned about five weeks and six pull requests across a unified analytics layer, the Klaviyo SDK integration, push notifications, newsletter and identity handling, and consent management. The analytics abstraction alone — building the dispatch layer and migrating existing call sites — accounted for roughly half the total effort.

What does the client need to provide before a Klaviyo integration starts?

Three things: the Klaviyo public API key (site ID), a Klaviyo entry in the consent management platform (e.g. Usercentrics), and the ID of the newsletter list the app should subscribe profiles to. All three require action from someone outside the development team — account settings, legal/compliance configuration, and marketing setup respectively.

Can the app track purchases in Klaviyo if checkout runs in the browser?

Not from the app alone. If checkout opens in an external browser, the app loses context and cannot emit purchase events. The app can track openedApp, viewedProduct, and addedToCart, but purchase tracking requires a Shopify-side or server-side solution. Options include Shopify web pixels, order webhooks to a backend, or a hybrid of both.

Akamai Bot Protection in Flutter: BMP SDK Integration

Khalit Hartmann — Wed, 08 Jul 2026 13:16:24 +0000

For CTOs, tech leads, and senior developers building enterprise mobile apps behind Akamai infrastructure — or planning to.

TL;DR: Akamai sits between your mobile app and your backend - providing CDN, image optimization, and bot protection. The problem: bot detection was designed for browsers, and your native app looks like a bot. Akamai provides a BMP (Bot Manager Premier) SDK for Flutter that collects behavioral sensor data and sends it via HTTP headers. But the SDK gives you the primitives - the orchestration is on you. I spent months integrating the BMP SDK into a Flutter e-commerce app for a Swiss electronics retailer: building a Dio interceptor chain for sensor data injection, handling two tiers of bot responses (428 challenges and 403 blocks), and configuring path-based URL filtering with remote config.

The Setup: Akamai Everywhere

The client is a Swiss electronics retailer. Their infrastructure runs through Akamai - CDN for static assets, Image Manager for responsive image delivery, and Akamai Bot Manager for bot detection and mitigation. Every request from every client passes through Akamai before it reaches the backend.

For their website, this is invisible. The browser handles cookies, executes JavaScript challenges, and maintains session state. Akamai was built for this exact scenario.

For a native Flutter app making HTTP requests with Dio? Different story.

I worked on this project for about ten months, building the app from the ground up. The Akamai integration touched the networking layer, image loading, authentication flow, and checkout. This post covers the four main integration surfaces: Image Manager, the BMP SDK, the interceptor chain, and challenge handling.

Image Manager: Optimized Images from the CDN Edge

Akamai Image Manager transforms images on the CDN edge. You pass parameters as URL query strings, and Akamai returns an optimized image - resized, compressed, format-converted. No image processing server needed.

For CMS content images served through a dedicated asset host, the integration is a string extension that builds the optimized URL:

extension on String {
  String? get toOptimizedContentUrl {
    return Uri.https('assets.example.ch', this, {
      'imdensity': '2',
      'impolicy': 'contentstack',
      'imwidth': '480',
    }).toString();
  }
}

The impolicy parameter selects a transformation preset configured in Akamai's control panel. imwidth sets the target width, and imdensity accounts for high-DPI screens. The CDN caches each variant at the edge, so the second request for the same parameters is instant.

This extension gets applied wherever the app renders CMS-managed content - home feed items, banners, product badges, search suggestions. One centralized transformation, used in over a dozen places across the app.

This was the straightforward part of the Akamai integration. Everything after this required more architecture.

Why the App Got Blocked

Launch was approaching, and with it a deliberate decision: the Akamai rules were tightened. The app needed protection against DDoS attacks and automated abuse. Clients now had to actively prove they weren't bots.

For the web shop, this was a non-issue. Browser traffic brings everything Akamai Bot Manager needs: the _abck session cookie from previous interactions, a recognizable User-Agent like Mozilla/5.0, and the ability to execute Akamai's sensor script — a JavaScript that inventories canvas rendering, WebGL hashes, installed fonts, and dozens of other signals to distinguish real browsers from automation.

A native app on its first API request has none of those signals. No _abck cookie. No behavioral fingerprint. No JavaScript context. And a User-Agent that says something like Dio/5.0 — Dart's HTTP client — instead of Mozilla/5.0. Akamai scores every request with a Bot Score from 0 (human) to 100 (bot). A standard HTTP client without sensor data scores near 100 — maximum bot confidence.

The result: 403 Forbidden. But not everywhere at once. Bot Manager allows transactional endpoints to be configured individually — login, checkout, and account pages can be protected with stricter thresholds than product listings or search endpoints. In practice: product images load, but login fails. Or the cart works, but checkout doesn't. Not consistently reproducible, because the Bot Score is dynamic — the same request can be evaluated differently depending on IP reputation, TLS fingerprint, and time of day.

The BMP SDK: Proving You're Not a Bot

Akamai provides a Bot Manager Premier (BMP) SDK for Flutter - a native plugin that collects behavioral sensor data on the device. Touch events, device motion, screen interactions - the SDK builds a fingerprint that Akamai's edge servers can evaluate to distinguish human users from bots.

The SDK ships as a platform plugin wrapping native libraries (an AAR for Android, an xcframework for iOS). Integration starts in pubspec.yaml:

dependencies:
  bmp_flutter_sdk:
    path: packages/bmp_flutter_sdk

Initialization happens at app startup. You pass the base URL of the protected resource, and optionally enable the challenge action feature:

void _initializeAkamaiSdk(ShopConfig config) {
  AkamaiBMP.configureSDK(baseUrl: config.baseUrl);
  AkamaiBMP.configureChallengeAction(baseUrl: config.baseUrl);
}

Once initialized, the SDK silently collects behavioral data in the background. When you need to make a protected API call, you retrieve the sensor data and send it as an HTTP header:

final sensorData = await AkamaiBMP.getSensorData();
headers['X-acf-sensor-data'] = sensorData;

Akamai's edge server inspects this header, evaluates the sensor data, and decides whether the request looks human. If it does, the request passes through to the origin. If it doesn't, the server responds with either a 428 (challenge) or a 403 (block).

The SDK handles the hard part - native sensor data collection across platforms. But the orchestration - deciding which requests need sensor data, handling challenge responses, retrying failed requests - that's your job.

The Interceptor Chain

The real architecture work is the Dio interceptor chain — the same pattern I use for token refresh and silent logout. Four interceptors, each with a single responsibility, executed in order on every request:

1. Sensor Data Enrichment

The first interceptor checks if the outgoing request targets an Akamai-protected URL. If it does, it retrieves sensor data from the BMP SDK and injects it as the X-acf-sensor-data header:

class AkamaiSensorDataEnrichmentInterceptor extends Interceptor {
  final List<AkamaiProtectedUrlRule> akamaiProtectedUrlRules;

  @override
  Future<void> onRequest(
    RequestOptions options,
    RequestInterceptorHandler handler,
  ) async {
    if (!akamaiProtectedUrlRules.matchUri(options.uri)) {
      handler.next(options);
      return;
    }

    final sensorData = await AkamaiBMP.getSensorData() ?? '';
    if (sensorData.isNotEmpty) {
      options.headers['X-acf-sensor-data'] = sensorData;
    }

    handler.next(options);
  }
}

2. Challenge Action (HTTP 428)

If Akamai isn't sure whether the request is from a human, it returns HTTP 428 (Precondition Required) with an Akamai-BM-Challenge-Context header. The interceptor catches this, presents a native challenge dialog to the user via the SDK, and retries on success:

class AkamaiChallengeActionInterceptor extends Interceptor {
  final Dio _dio;
  final List<AkamaiProtectedUrlRule> _akamaiProtectedUrlRules;

  @override
  Future<void> onError(
    DioException err,
    ErrorInterceptorHandler handler,
  ) async {
    final response = err.response;
    if (response == null ||
        response.statusCode != 428 ||
        !_akamaiProtectedUrlRules.matchUri(response.requestOptions.uri)) {
      handler.next(err);
      return;
    }

    final challengeContext =
        response.headers.value('Akamai-BM-Challenge-Context');

    if (challengeContext != null) {
      final ccaResponse = await AkamaiBMP.showChallengeAction(
        context: challengeContext,
        title: 'Verification Required',
        message: 'Please wait while we verify your request.',
        cancelButtonTitle: 'Cancel',
      );

      final status = ccaResponse?['status']?.toString();
      if (status == '1') {
        // Challenge passed - retry with fresh sensor data
        final sensorData = await AkamaiBMP.getSensorData() ?? '';
        final retryOptions = err.requestOptions.copyWith(
          headers: {
            ...err.requestOptions.headers,
            'X-acf-sensor-data': sensorData,
          },
        );
        final retryResponse = await _dio.fetch<dynamic>(retryOptions);
        return handler.resolve(retryResponse);
      }
    }

    handler.next(err);
  }
}

The challenge dialog is native - the SDK renders it, not a WebView. The user sees a brief verification screen, and on success the request retries transparently.

3. Bot Protection (HTTP 403)

If Akamai is confident the request is from a bot, it returns HTTP 403 with a reference_id in the response body. Unlike the 428 challenge, this is terminal - there's no way to solve it programmatically. The interceptor shows a support dialog with the reference ID so the user can contact support:

class BotProtectionInterceptor extends Interceptor {
  final List<AkamaiProtectedUrlRule> akamaiProtectedUrlRules;

  @override
  void onError(DioException error, ErrorInterceptorHandler handler) {
    final referenceId = switch (error.response?.data) {
      final Map<String, dynamic> data
          when data.containsKey('reference_id') =>
        data['reference_id'] as String?,
      _ => null,
    };

    if (error.response?.statusCode == 403 &&
        referenceId != null &&
        akamaiProtectedUrlRules.matchUri(error.requestOptions.uri)) {
      // Show bot detection dialog with reference ID and support contact
      _showBotDetectionDialog(referenceId);
    }

    handler.next(error);
  }
}

The distinction between 428 and 403 matters. A 428 is a question: "Are you human? Prove it." A 403 with a reference ID is a verdict: "We're blocking you." Different responses, different UX flows.

4. Session Cookie Monitoring

A fourth interceptor monitors the application's session cookie on authenticated requests and logs to crash reporting when it's missing. This isn't Akamai-specific - it catches cases where the session state got corrupted, regardless of cause.

URL-Based Filtering

Not every request needs Akamai protection. Product listings, image URLs, static content - these don't need sensor data. Only high-value endpoints like authentication and checkout warrant the overhead.

The filtering uses path-based rules with three match types:

class AkamaiProtectedUrlRule {
  final RuleType type; // pathEquals, pathContains, pathRegex
  final String rule;

  bool matches(Uri uri) {
    switch (type) {
      case RuleType.pathEquals:
        return uri.path == rule;
      case RuleType.pathContains:
        return uri.path.contains(rule);
      case RuleType.pathRegex:
        return RegExp(rule).hasMatch(uri.path);
    }
  }
}

The protected endpoints in this project:

/api/accounts/authenticate
/api/accounts/registration
/api/accounts/changeemail
/api/accounts/forgotpassword
/api/accounts/resetpassword
/api/checkout/init
/api/checkout/validate
/api/checkout/order

These rules are defined as fallback defaults but can be overridden via Firebase Remote Config. When the security team adjusts which endpoints are protected, the app picks up the change without a release.

Why does this matter? Two reasons. First, getSensorData() has a cost - it's an async call that adds latency. Calling it on every request to every endpoint is wasteful. Second, the SDK docs explicitly say: "Don't call the getSensorData method for non-protected URLs." You're collecting behavioral data, and sending it unnecessarily is both a performance and a privacy concern.

Testing and Debug Tooling

You can't run Akamai's bot detection locally. The evaluation happens on Akamai's edge servers, not on your machine. But you can test the interceptor logic and verify the SDK integration.

The BMP SDK includes built-in integration checks. The app exposes these on a debug page:

// Run integration diagnostics
AkamaiBMP.runIntegrationChecks();
AkamaiBMP.runIntegrationChecksWithCCAEnabled();

These verify that the SDK initialized correctly, sensor data collection works, device motion sensors are accessible, and the challenge action feature is configured. The SDK logs results to the console with a clear pass/fail for each check.

For the interceptor chain, mock interceptors in CI test the retry logic and URL filtering independently of Akamai's edge servers:

test('enriches protected URL with sensor data header', () async {
  final interceptor = AkamaiSensorDataEnrichmentInterceptor(
    akamaiProtectedUrlRules: [
      AkamaiProtectedUrlRule(
        type: RuleType.pathContains,
        rule: '/api/checkout/order',
      ),
    ],
  );

  final options = RequestOptions(path: '/api/checkout/order');
  final handler = MockRequestInterceptorHandler();
  await interceptor.onRequest(options, handler);

  expect(options.headers['X-acf-sensor-data'], isNotNull);
});

A staging environment with Akamai enabled remains the only way to verify the full flow end-to-end. Local development uses mock interceptors, but every change to the networking layer gets tested against staging before merge.

What I Learned

A few things that aren't obvious from the SDK documentation:

The challenge action response has three states, not two. Status 1 means success, 0 means the user canceled, and -1 means the challenge failed. Handle all three explicitly - cancellation and failure need different error messages.

Sensor data should be fresh for retries. After a successful challenge action, don't reuse the sensor data from the failed request. Call getSensorData() again to get fresh behavioral data. The edge server expects sensor data that reflects the current session state.

The SDK needs initialization before the first API call. Call configureSDK() early in the app lifecycle - before any protected API request fires. If the SDK hasn't collected enough behavioral data when the first request goes out, the sensor payload will be thin, and Akamai is more likely to challenge.

URL rule changes require no app release. Making the protected URL rules configurable via remote config was one of the better architectural decisions. When the security team added new protected endpoints mid-sprint, we updated the rules without a release cycle.

Conclusion

Akamai's BMP SDK handles the hard part - native behavioral sensor data collection across iOS and Android. The challenge is everything around it: building the interceptor chain, handling the two-tier response system, configuring URL-based filtering, and building the debug tooling to verify it all works.

The interceptor chain - sensor data enrichment, challenge action handling, bot protection, session monitoring - is compact. Each interceptor has a single responsibility, and the URL rule system ensures they only fire for endpoints that need protection.

Three takeaways from this project:

Plan the Akamai integration from the start. If you know your backend sits behind Akamai, begin with the SDK integration and the interceptor chain - not when the 403 errors start arriving.

Keep the URL rules updatable. Remote config for the protected endpoints isn't an optimization - it's an operational necessity when the security team needs to adjust rules independently of the app release cycle.

The SDK integration itself takes days. The interceptor architecture, URL filtering, remote config, debug tooling, and testing against staging - that's where the real time goes.

I've built this integration end-to-end for a production e-commerce app. If your team is planning a similar integration, let's talk.

Frequently Asked Questions

What is Akamai Bot Manager and how does it affect mobile apps?

Akamai Bot Manager is a bot detection and mitigation service that sits between clients and origin servers. It evaluates incoming requests using behavioral analysis and device fingerprinting. Mobile apps need the BMP SDK to provide sensor data via the X-acf-sensor-data HTTP header, which Akamai's edge servers evaluate to distinguish legitimate app traffic from bots.

Does Akamai provide a mobile SDK for bot protection?

Yes. Akamai provides a Bot Manager Premier (BMP) SDK for Flutter, iOS, and Android. The Flutter SDK (bmp_flutter_sdk) wraps native platform libraries and provides methods for initialization (configureSDK), sensor data collection (getSensorData), and challenge handling (showChallengeAction). You integrate it as a local Flutter plugin package.

What's the difference between a 428 and a 403 from Akamai?

A 428 (Precondition Required) means Akamai wants additional verification. The response includes an Akamai-BM-Challenge-Context header, and the app can present a challenge dialog via the SDK. If the user passes, the request can be retried with fresh sensor data. A 403 (Forbidden) with a reference_id means Akamai has classified the request as a bot - this is terminal and can't be solved programmatically.

Does Akamai Image Manager work with Flutter's image caching?

Yes. Image Manager URLs are deterministic - the same parameters produce the same optimized image. Flutter's image cache (via cached_network_image or similar packages) works normally. The CDN also caches each image variant at the edge, so the combination of client-side and edge caching provides good performance.

How do you test Akamai integration in CI/CD?

The BMP SDK includes integration checks (runIntegrationChecks()) that verify SDK initialization and sensor data collection on-device. For CI, mock the interceptor chain to test URL filtering and retry logic without Akamai's edge servers. A staging environment with Akamai enabled is necessary for end-to-end verification.

Local AI & LLM for Developers: Freelancer Verdict (2026)

Khalit Hartmann — Sat, 04 Jul 2026 12:50:15 +0000

For freelancers, CTOs, and tech leads · Based on real conversations with developers.

TL;DR: I asked freelance developers in Germany how they use local AI. The responses split into four camps — and the strongest argument wasn't the one I expected.

3,000 € in hardware or 90 € a month?

Local AI. Self-hosted models. Running your own LLMs without sending data to external servers. In every developer circle, the same topic keeps surfacing.

The arguments sound good. Data privacy. No recurring API costs. Independence from providers. But does the math work out? Are local LLM models competitive?

I didn't want to answer this theoretically. So I asked freelance developers who work with AI daily and make real money based on their tooling decisions.

Four developer types, four perspectives

The responses split into four positions.

The privacy pragmatist

One developer put it plainly: parts of their work are covered by NDAs. Cloud AI isn't an option because their professional liability insurance doesn't cover data sent to external APIs. Local models aren't an experiment for them. They're a necessity.

That's the strongest use case for local AI. Not because the models are better, but because they're the only option. And for most tasks, the quality is sufficient.

If you're processing data under GDPR constraints or working in regulated industries — especially in the DACH region, where enforcement is strictest — you face the same decision. It stops being about "is it worth it?" and becomes "how do I set it up?". (I wrote about how I handle GDPR requirements in development in this post.)

(If this is your situation — book a free intro call, I'll give you an assessment of what's feasible locally.)

The ROI calculator

Counter-position, equally clear: as long as Claude Max costs 90 €/month, there's little reason to switch to local models. For 90 € you get frontier models that no local setup can touch. No hardware investment, no maintenance, no SSD management.

One participant summed it up: local AI is a fun toy that developers dress up as a business expense.

Harsh. But hard to argue with. The quality gap between Claude, GPT, Gemini and what you can run locally is real. Not at any economically sensible price point.

The hardware tinkerer

Then there are those who invested anyway. One developer configured a Framework Desktop with 128 GB of unified memory and installed Arch Linux. He runs llama.cpp on it. Delivered from Taiwan in five business days, quiet, surprisingly capable.

The setup costs roughly 3,000 € net. The 2 TB SSD fills up fast because each larger model takes 50 to 100 GB. A second SSD is possible, but prices have gone up. He wishes he'd gotten the larger one from the start.

What I liked about the conversation: he openly admits the tinkering instinct was a factor. And that the purchase decision got rationalized as "business" after the fact. Still, for someone who regularly works with local models or handles NDA-bound work, it makes sense. The quick availability of unified memory at that capacity was what sold him.

The hybrid strategist

Not everything needs a large model. One developer runs Qwen 2.5 on a MacBook Pro with 16 GB RAM. Good enough for sub-agents that create DTOs or generate boilerplate. He checks the output with DeepSeek V4 Flash. Only tasks that genuinely need power go through the cloud API.

Another developer gets roughly 40 tokens per second with llama.cpp on an M1 Max with 64 GB RAM. Not as snappy as cloud, but you can get real work done with it.

I find this the most interesting approach — and I'm testing it myself. On a recent project handling sensitive health data, I used Qwen 3 locally for code generation and only sent architecture questions through the cloud API. The separation worked because simple tasks stayed local while only complex reasoning went to the cloud. I wrote about how I use AI in my daily app development work separately. Long-term, I think most developers will end up with a hybrid setup. But today it's still more vision than standard practice.

What hardware do you need for local AI?

If you're interested in running a local LLM, here's what came out of these conversations.

Available VRAM or unified memory is the deciding factor for local inference. Not the GPU, not the CPU cores. Models need to fit entirely in memory, and Apple Silicon shares memory between CPU and GPU. Big advantage over traditional PC setups with discrete GPUs.

What developers actually use:

Setup	RAM	Tokens/s	Price (approx.)	Best for
MacBook Pro M5	16 GB	usable for small models	from 2,000 €	Entry-level, sub-agents
MacBook Pro M1 Max	64 GB	~40 tok/s	from 2,500 € (used)	Solid local setup
Framework Desktop	128 GB	comfortable	~3,000 € net	All-in on local

2 TB SSD sounds like a lot but fills up fast. Models take 50 to 100 GB each, and you'll want to try several.

Local LLM models: which ones actually work?

Not a benchmark table. What developers are actually using:

Model	Use case	Min. RAM	Strength
Qwen 2.5 / Qwen 3	Sub-agents, DTOs, boilerplate	16 GB	Best entry point for local AI coding
DeepSeek V4 Flash	Output checker, second opinion	32 GB	Good as a "review" model
Llama variants (llama.cpp)	All-round on Linux	32–64 GB	Large community, regular updates

Getting started with local AI

Want to try it? The fastest path is Ollama. Install it, run ollama run qwen2.5, done. No Docker, no Python setup. If you want more control, go with llama.cpp — more setup required, but more flexibility with models and parameters.

Running LLMs locally: does the math work?

The numbers behind what the ROI calculator already sensed:

A local setup with a Framework Desktop and 128 GB costs about 3,000 € plus electricity (roughly 30 €/month). Add time for setup, maintenance, and model updates.

Claude Max runs 90 €/month, so 1,080 €/year. No maintenance, frontier quality, immediately ready to use. The API is variable, 20 to 200 €/month depending on volume.

Even if you replace cloud costs entirely with local AI — unrealistic because local models don't match frontier quality — it takes close to three years to recoup the hardware. Without counting the time investment. (Curious what an AI-assisted app project costs overall? Here's my breakdown of app development costs.)

Local AI doesn't replace cloud. It supplements. And whether that supplement is worth it comes down to one thing: do you need to keep data local?

Why this could change soon

What I keep thinking about: the subsidy era won't last forever. Claude Max at 90 €/month is an incredible deal. At some point prices will rise or usage gets more limited. Developers who get familiar with local AI now will be ready when the economics shift.

Local models are also catching up fast. Qwen 3 is significantly better than Qwen 2.5, and the next generation is already in the works. Once local models reach 80% of cloud quality — and for simple tasks, they already do — the calculus tips.

My take

For most freelancers and developers in 2026, cloud AI is the better choice. The models are better, the costs are manageable.

The exception: NDA-bound projects. If you can't send client data to the cloud, local models aren't optional. They're necessary. And the quality is good enough.

My recommendation: don't buy dedicated hardware yet. But install Ollama, run ollama run qwen2.5 on your existing machine, and see what's possible. Getting started costs nothing but half an hour.

Figuring out which AI setup fits your project — local, cloud, or hybrid? Book a free intro call — I'll give you an honest assessment of what makes sense for your setup. More about my approach on the app development page.

Embedding a Website in Your App - Why It Is More Complex Than You Think

Khalit Hartmann — Fri, 03 Jul 2026 09:41:14 +0000

Embedding a Website in Your App -- Why It Is More Complex Than You Think

TL;DR: Embedding WebViews in apps seems easy -- take an existing website and drop it in. In practice, there is hidden complexity behind it: syncing authentication, managing navigation between web and native, building JavaScript bridges. Using a real e-commerce project with Shopify infrastructure, this article shows where the problems are and when WebViews are the right choice.

The Starting Question

"Can't we just embed our website in the app?"

Every mobile developer hears this at some point. It sounds logical: a working online shop already exists, with curated product pages, a functional checkout, and integrated search. Why rebuild everything natively when embedding would be easier?

A WebView is a browser component inside a native app -- essentially an embedded browser without the address bar. According to AppBrain (2025), over 60% of Android applications use some form of WebView technology.

The answer: technically possible, but "easy" it is not.

This article walks through a real project -- a jewelry e-commerce brand with a Shopify backend -- to show what hides behind that single line of code. No theory, just real code examples, real bugs, and real workarounds.

The app is a Flutter implementation with a hybrid strategy: some screens are built natively, others use WebViews. The problems appear exactly at the boundaries between these two worlds.

This is not an argument against WebViews. It is an argument for informed planning.

Hybrid Architecture: What Goes Native, What Goes WebView?

Built natively:

Authentication (login, registration)
Onboarding
Home screen with product highlights
Account management
Settings & preferences

WebView:

Shop browsing (collections, categories)
Product details
Cart
Checkout
Search
Order history

Three reasons for this split:

CMS flexibility: Product pages and collections change constantly. The marketing team manages them through Shopify -- building them natively would mean manually mirroring every CMS change in the app.
PCI Compliance: Building checkout natively requires your own PCI compliance certification. Hosted solutions like Shopify Checkout handle that for you.
Cost-benefit: Not every screen justifies native implementation.

The shop page looks deceptively simple in code:

WebviewPageWidget(initialUrl: shopConfig.baseUrl);

One line. Behind that one line: a 476-line container, five plugins with over 800 lines of code, a JavaScript bridge, cookie management, platform-specific navigation workarounds, and a state machine for the initial page load.

Complexity #1: Auth Sync

The first major challenge in hybrid apps: credentials live in two separate worlds.

Login happens natively. The app communicates directly with the Shopify Storefront API, stores tokens securely via flutter_secure_storage, and manages auth state through a central controller.

Then the user wants to see their cart. The cart is a WebView. The WebView initially knows nothing about the login status.

Tokens to Cookies

Solution: a TokenBag model converts native tokens into WebView-compatible cookies.

class TokenBag {
  final String? cartId;
  final String? shopifyCustomerAccessToken;

  String? get cartToken => cartId?.split('/').last;

  Map<String, String> get cookies {
    return {
      if (cartToken != null) 'cart': cartToken!,
      if (shopifyCustomerAccessToken != null)
        'shopifyCustomerAccessToken': shopifyCustomerAccessToken!,
    };
  }
}

Sounds manageable. But setting these cookies is complex. Every auth state change requires: removing existing session cookies, setting new cookies, and setting additional app-specific cookies.

The Nuclear Option: Destroying the WebView Entirely

Sometimes changing cookies is not enough. The entire WebView has to be destroyed and rebuilt:

final rebuildKey = ValueKey(
  (tokenBag.shopifyCustomerAccessToken ?? 'guest') +
      rebuildIndex.value.toString(),
);

InAppWebView(
  key: rebuildKey,
  // ...
);

Flutter sees the new key, discards the old WebView completely, and creates a new one. Including a fresh page load, a new JavaScript context, new cookie sessions. No graceful transition -- a hard reset.

Web-Initiated Native Login

There is also the other direction: the WebView can trigger a native login. When a user clicks "Sign in" during the web checkout, a JavaScript bridge function opens a native login bottom sheet. After native login, the app updates the auth state, refreshes cookies, and the WebView should reflect that.

One git branch is literally called fix/SHOP-74-login-in-cart. Not login in general -- login from inside the cart. That is how specific the edge cases get.

Complexity #2: Navigation

The shouldOverrideUrlLoading method in the WebView container spans 100 lines of platform-specific logic. Every line exists for a reason.

State Machine for Initial Requests

enum InitialRequestState {
  none,
  loading,
  loaded,
  cancelled,
}

Why? Because shouldOverrideUrlLoading intercepts every URL request -- including the initial one that loads the start page. Without this state machine, the app would block its own initial page load.

iOS vs. Android: Fundamentally Different Event Models

iOS sends NavigationType.BACK_FORWARD for back navigation. Android? Does not fire shouldOverrideUrlLoading during goBack(). Android marks redirects explicitly via an isRedirect flag. iOS does not have this flag.

Every condition in the code exists because a specific bug surfaced on a specific platform. This is not over-engineering -- this is damage control.

The `restartWebView()` Workaround

// TODO(khalit): this feels like a hack. calling restartWebView is needed
// because it prevents shouldOverrideUrl from being called, which would
// cause unexpected behavior.
restartWebView();
await controller.loadUrl(
  urlRequest: URLRequest(url: WebUri(fullUrl)),
);

And back navigation with an artificial delay:

Future.delayed(
  Durations.extralong1, // 700ms
  () async {
    await controller.reload();
  },
);

Waiting 700 milliseconds because an immediate WebView reload would load the previous page instead of the new one. The kind of fix that never shows up in tutorials.

Complexity #3: Five Plugins, Two Worlds, One `window.mobileApp`

The most elegant -- and simultaneously most demanding -- solution in the project is the JavaScript bridge. It connects the native app with the website through a plugin system.

The Five Plugins

Plugin	Lines	Purpose
ConsentPlugin	298	Pass consent data to the WebView
TrackingPlugin	268	Translate web analytics to Firebase Analytics
NavigatePlugin	127	Handle web-side navigation
LoginPlugin	68	Web triggers native login flow
UpdateCartPlugin	55	Web notifies app about cart changes
Total	~816	JavaScript bridge infrastructure

816 lines of plugin code. Plus the 476-line container. For "just embed it."

The Consent Complexity: Three Approaches at Once

The ConsentPlugin uses three simultaneous approaches to make sure the website recognizes the consent state:

Approach 1: URL parameters -- Inject consent data directly into the URL.

Approach 2: JavaScript injection at DOCUMENT_START -- Parse URL parameters during page load and set them globally.

Approach 3: evaluateJavascript after load -- Send consent data again via JS execution.

Three approaches for one piece of information. Why? Because none of them is reliable enough on its own:

URL parameters can disappear during client-side redirects
JavaScript injection fires too early for certain Shopify scripts
evaluateJavascript fires too late for the initial render

So all three together. Full redundancy.

Complexity #4: Details That Keep You Up at Night

1. User-Agent Spoofing

Shopify returns 403 errors when it detects default WebView user agents. The solution: hardcoded browser user agents per platform.

userAgent: Platform.isIOS
    ? 'Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) '
      'AppleWebKit/605.1.15 ...'
    : 'Mozilla/5.0 (Linux; Android 13; Pixel 7) '
      'AppleWebKit/537.36 ...',

Yes, hardcoded strings. Yes, they can go stale. Yes, manual updates are required.

2. Custom WebView SDK Fork

The app uses a custom fork of flutter_inappwebview. Why? The standard version lacks Android Payment Request support -- needed for Google Pay in checkout.

That means: maintaining your own fork, watching upstream changes, checking compatibility on every Flutter update. For a single missing feature.

3. Loading State: Render Invisibly, Then Show

// Step 1: Render invisibly
Opacity(opacity: 0, child: webView),

// Step 2: Measure height (after load)
final height = await controller.evaluateJavascript(
  source: 'Math.max(document.body.scrollHeight, '
          'document.documentElement.scrollHeight)',
);
contentHeight.value = height.toDouble();

// Step 3: Show with measured height
SizedBox(height: contentHeight.value, child: webView);

4. The Abandoned Native Approach

Deep in the codebase lies commented-out code:

//   ref
//       .read(shopifyCartControllerProvider.notifier)
//       .addProductToCart(
//         merchandiseId: selectedVariant.id,
//         product: product,
//         variant: selectedVariant.title,
//       );

An attempt at implementing cart functionality natively. Tried and abandoned -- because syncing between native cart state and web cart state was too fragile.

When WebViews Are the Right Choice

After all this complexity, it would be unfair to write off WebViews entirely.

1. Product Pages & Collections

CMS-managed content that changes weekly? Definitely WebView. The marketing team maintains it through Shopify, and the app shows it instantly -- no app updates needed.

2. Checkout

PCI Compliance, payment provider integration, Shop Pay, Apple Pay, Google Pay, Klarna, PayPal -- implementing all of that natively is a project in itself. The hosted Shopify checkout handles everything.

3. Search

Faceted filtering, autocomplete, search suggestions -- all Shopify strengths with little to gain from a native rebuild.

4. Legal Pages

Practical Decision Matrix

Criterion	Lean native	Lean WebView
Auth/Login	Yes	No
Payment/Checkout	Only if PCI-compliant	Yes (Hosted Solution)
CMS Content	For infrequent updates	For frequent updates
Navigation-critical	Yes	Use with caution
Performance-critical	Yes	No
Offline capability	Yes	No

Conclusion

"Can't we just embed the website?"

Yes, but.

WebViews are a tool, not a shortcut. They are appropriate -- for CMS content, hosted checkouts, anywhere web infrastructure is better than what native can deliver in the available time.

But they come with their own complexity:

Credentials need to be synced between separate systems
Navigation requires platform-specific handling for iOS and Android
JavaScript bridges need to be built, tested, and maintained
Edge cases (user agents, SSL, loading states) eat up time

In numbers: this project needed 476 lines for the WebView container, 816 lines for plugin code, and countless bugfix commits -- for something that started with "just embed it."

The right question is not "embed or build native?" but rather: "Which screens native, which WebView, and how do they communicate?"

If you answer that early in the project -- and know about the hidden complexity -- you will make better architecture decisions and avoid budget surprises.

Frequently Asked Questions

What is a WebView in mobile apps?

A WebView is an embedded browser component in native apps. It renders web content directly -- without a separate browser. Users do not see an address bar and ideally do not notice they are looking at websites.

Are WebView apps cheaper than native apps?

Initially, often yes -- avoiding native reimplementation of existing websites saves money. Long-term, the hidden complexity (auth sync, navigation workarounds, JavaScript bridges) can eat into that cost advantage. This project has 1,290+ lines just for WebView infrastructure.

Does Apple accept WebView apps in the App Store?

Apple rejects apps that are exclusively WebView-based (Guideline 4.2 -- Minimum Functionality). Hybrid apps with native features plus WebViews are accepted -- as long as they offer advantages over mobile websites.

When should you build native instead of WebView?

Rule of thumb: go native for (a) auth, (b) offline requirements, (c) performance-critical functionality, (d) complex native gestures and animations. Use WebView for CMS-managed content, hosted checkouts, and frequently updated screens without native performance requirements.

App Engagement Strategy: Fixing a 0.6% Push Open Rate

Khalit Hartmann — Thu, 02 Jul 2026 16:19:58 +0000

Based on my talk at Flutter Berlin (Flutter OctoberFest). Assumes familiarity with mobile development. No ML or data science background needed.

📺 Watch the full talk on YouTube

TL;DR: Campaign push notifications at MediaMarktSaturn had a 0.6% open rate across 2.7 million sends. The problem wasn't the content. It was timing, relevance, and volume. We found a framework called Just-In-Time Adaptive Interventions (JITAI), originally from medical health apps, and designed a system that decides whether, when, and what to send each user. The system was still in discovery when I gave this talk, but the thinking behind it applies to any mobile app engagement strategy.

Most mobile app engagement strategies treat push notifications as a broadcast channel: pick a segment, write copy, blast it out, hope for clicks. This post shows what happens when that stops working at scale, and how a research-backed framework gives you a better way to improve app engagement through push notifications. The examples come from a real e-commerce app with millions of users.

The numbers that started the conversation

At MediaMarktSaturn, I worked on the consumer apps team, one of the larger Flutter teams in Germany. We maintained apps across 13 countries. The quarter before, we'd also shipped a push notification service.

Here's what a bad campaign looked like:

Metric	Number
Push notifications sent	2,700,000
Opened	~17,000 (0.6%)
Converted (from opens)	66 (0.36%)

That's 66 purchases from 2.7 million interruptions. Not 66 thousand. Sixty-six.

This wasn't even our worst campaign. But it made the question impossible to dodge: are we providing value to our users, or are we just making noise?

Why push notifications fail to drive app engagement

We kept coming back to four problems:

Timing. Send a notification while someone is in a meeting or on the train and it's just a disturbance. Every user has different windows of attention throughout the day.

Relevance. A promotion for kitchen appliances is useful to someone furnishing a new apartment. To everyone else, it's clutter. Batch campaigns don't distinguish between the two.

Volume. Send too many and users go numb. Or they revoke notification permissions entirely. Once that happens, the channel is dead.

Competition. The average user has around 50 apps installed. Each one wants a slice of a limited attention budget. If your notification doesn't earn its place, it gets swiped away.

All four come back to the same thing: receptivity, the user's ability and willingness, right now, to receive and act on an interruption.

What receptivity actually means

Receptivity isn't a toggle. It shifts throughout the day based on two kinds of signals:

Internal: mood, cognitive load, what the user is focused on
External: location, time of day, whether they're driving, walking, or sitting still

The idea is simple: if someone isn't in a position to care about your message, sending it does nothing at best and annoys them at worst. Push to a non-receptive user often enough and they'll opt out.

Our bet: if we time notifications better and make them personal, users will see them as useful instead of annoying. Useful notifications get opened. Opened notifications convert.

What is JITAI? A framework from health research

Just-In-Time Adaptive Interventions (JITAI) comes from medical health research, specifically addiction support and weight loss apps. Those systems monitor a user's internal and external state and only step in when two conditions are met:

The user is in a vulnerable state (in a health app: at risk of relapsing; for us: likely to benefit from a product notification)
The user is in a receptive state (able and willing to process the message right now)

The framework has four parts:

1. Decision points

The moment the system decides whether to show a notification. For server-sent push, this is when the server would normally fire. For on-device local notifications, you can set intervals and check every X minutes whether conditions are right.

The important part: the decision isn't just "send." It's "send, delay, or don't send at all."

2. Tailoring variables

The data that feeds the decision. Two sources:

Passive (no user action needed):

Device type (Android and iOS users often have different notification habits)
Location (is the user near a physical store?)
Time patterns (when does this user typically open the app?)
Sensor data (accelerometer, ambient light, with consent)

Active (user tells us directly):

Wishlist items
Search history
Category preferences

The system has to work with whatever the user consents to share. Someone who only grants location access should still get a noticeably better experience than a batch campaign.

3. Intervention options

What the system can actually do:

Action	Example
Information notification	New arrivals, restocks
Promotional notification	Sales, discounts
Location-based notification	Store-specific offers when nearby
Rich push	Image-heavy, interactive notifications
Reschedule	Delay the notification for a better time
No push	Suppress the notification entirely

That last row matters the most. Sometimes the best notification is none.

4. The decision maker

This is the core. It takes the tailoring variables and intervention options and decides which intervention to offer, to whom, and when.

Two approaches:

Algorithmic: Decision trees and rules. Easier to build, test, and explain. Example: if the user is within 500m of a store AND has a wishlist item on sale at that store, send a location-based push.

Machine learning: An on-device reinforcement learning model that learns from each user's interaction patterns. The model improves per-user over time without sharing data across devices. Harder to build and harder to test, but it can pick up patterns that rules miss.

In practice, you'd start with rules and add ML where the rules stop improving.

Push notification examples that improve app engagement

The store walk-by

You're walking through Alexanderplatz. Your Saturn app knows your wishlist, and you've been eyeing a pair of headphones. In the background, the system checks: does the Saturn store at Alexanderplatz have those headphones in stock? Is there a promotion running?

If yes, send a push. You already wanted the product. The store is 200 meters away. The promotion gives you a reason to walk in now.

You find out about a deal on something you already want. The store gets a walk-in. One notification, no spam.

Distal outcome: purchase in store.
Proximal outcome: user becomes aware of the deal. Even if they don't tap the notification, they've absorbed the information.

The abandoned cart

You're at home, browsing the MediaMarkt app. You add three items to your cart. Your partner walks in, you put the phone down, and the cart just sits there.

The system picks up that the cart has been idle for a few hours. One of the items now has a 20% discount that expires soon. You probably forgot about the cart, and you definitely don't know about the price drop.

Send a notification about the discount. You get a useful reminder. The retailer recovers a sale that would have quietly disappeared.

Both examples follow the same logic: only interrupt someone when you're reasonably confident the notification is worth their attention.

The hard parts of this engagement strategy

Privacy and GDPR

We're in Germany. GDPR isn't a formality, it's the operating environment. The system touches sensitive data: location, purchase history, browsing behavior. The deal with users has to be clear: this data improves your notification experience, full stop. It's never sold or shared.

If users don't trust the system, they won't grant the permissions it needs. And then there's nothing to work with.

Testing tailoring variables

Which variables actually predict receptivity? Device type? Time of day? Distance to a store? Some combination? This needs serious A/B testing and careful measurement. The search space is large, and gut feelings about what matters tend to be wrong.

Incomplete data

The system has to work when users only grant some permissions, or none at all. Someone who shares location, wishlist, and browsing history gives the decision maker plenty of signal. Someone who shares nothing gets the batch experience, same as before, no penalties.

That gap in quality is inherent, and it's fine. But it needs to be measured honestly, not papered over in the dashboard.

Where we left off

When I gave this talk at Flutter Berlin, the system was in the discovery phase. We had research, architecture, and a talk, but no production code yet. The academic literature on JITAI is solid, but applying it to e-commerce push at scale, across 13 countries and millions of users, raises problems the papers don't address.

The thing I keep coming back to: the problem with push notifications isn't push notifications. It's sending the wrong message at the wrong time. And honestly, it's not having the discipline to send nothing when you don't have a good reason.

Most mobile app engagement strategies still treat push as a broadcast channel. The bar for standing out is low: just stop yelling at people who didn't ask.

Thanks to Flutter Berlin and MediaMarktSaturn for hosting the event.

If you're building a mobile app that needs smarter notifications — or rethinking the system you already have — that's the kind of architecture work I do.

Key takeaways

Push notification open rates are a symptom, not the disease. The real problem is sending the wrong message at the wrong time to the wrong user.
The JITAI framework gives structure to personalization. Decision points, tailoring variables, intervention options, and a decision maker — four components that turn "send smarter notifications" into an engineering problem.
Start with rules, add ML later. Algorithmic decision trees are easier to build, test, and explain. Machine learning picks up patterns rules miss, but only after you understand what "better" looks like.
The best notification is sometimes no notification. Suppressing a low-value push preserves the user's trust and keeps the channel alive for when it matters.

Building Apps with AI: What Actually Works (2026)

Khalit Hartmann — Thu, 02 Jul 2026 16:19:57 +0000

For CTOs, founders, and developers who want to know how AI is actually changing app development. No buzzword bingo — experiences from real projects.

TL;DR: "Build an app with AI" can mean two things: using AI tools to develop faster, or adding AI features to your app. I do both daily. The reality: AI coding tools like Claude Code speed up my work by 20–40%, but they don't replace architecture decisions or testing. No-code AI builders like Bolt or FlutterFlow produce decent prototypes, but not production-ready apps. And AI features in apps (chatbots, image recognition, recommendations) are now affordable — if you know which API to use for which problem.

What "build an app with AI" actually means

When clients mention "AI" in their initial inquiry, they usually mean one of two things.

The first: using AI tools to make development itself faster. Claude Code implements entire features from a description, GitHub Copilot suggests inline completions, Cursor navigates the codebase. This affects me as a developer and changes how I work.

The second: adding AI features to the app itself. A chatbot that answers customer questions. Image recognition that identifies products. Personalized recommendations based on user behavior. This affects the product and its features.

Both meanings matter, but they're fundamentally different. I'll cover both.

AI as a development tool: what works, what doesn't

I've been using AI coding tools in my daily work since 2023. Currently it's exclusively Claude Code — as a coding partner that knows the entire codebase and can implement features end-to-end.

What genuinely goes faster: boilerplate code, test cases, data models, regular expressions, and navigating unfamiliar codebases. When I need a new Flutter widget that follows an existing pattern in the app, Claude Code builds it in seconds instead of minutes. Unit tests for a method? Claude Code generates them in the context of the existing test suite and gets the approach right most of the time.

On a recent project — an e-commerce app with a complex shopping cart — I estimate I spent 30% less time on implementation than I would have without AI tools. The gain isn't in single big moments but in hundreds of small time savings spread across the entire project.

What doesn't work: architecture decisions. "Should we use Riverpod or Bloc for state management?" — AI will give you an answer, but whether it's right for your specific project requires someone who understands the context. (More on framework choices in my Flutter vs React Native comparison.) Same goes for security decisions, performance optimization, and anything where context extends beyond a single file.

One point that rarely gets mentioned: AI-generated code needs the same careful review as human-written code. I've accepted AI suggestions that compiled and passed tests but were logically wrong. That happens when you stop reading the output. AI tools make an experienced developer faster. They don't make an inexperienced developer experienced.

Adding AI features to your app: the practical options

The second meaning — putting AI into the product. A lot has changed here in the last two years.

Chatbots and text processing

For chatbots and text processing, the large language models are the obvious choice. Claude API, OpenAI API, or Google Gemini as the backend. The integration is technically straightforward: API call to the provider, display the response. The challenge is in prompt design (what instructions does the model get?), cost control (API calls charge per token), and making sure the responses actually make sense for your context.

Image recognition and computer vision

For image recognition and computer vision, there are on-device options: TensorFlow Lite, Core ML (iOS), and Google's ML Kit. The advantage: processing happens on the device with no server costs and no latency. A concrete example: for a health app, I built text recognition using Google ML Kit that scans product codes from leaflet inserts. The user points their camera, the app recognizes the code via on-device OCR and unlocks content — no server costs, no latency.

Recommendation systems

Recommendation systems — "products you might like" — can now be built with services like AWS Personalize or Google Recommendations AI without training your own ML model. Costs start low and scale with usage. In practice, I haven't needed to train a custom recommendation algorithm on any project so far — the cloud services cover most use cases.

Speech recognition

Speech recognition runs on native platform APIs from Apple and Google — reliable and without server costs. Once you need intent detection or context across multiple sentences, you're back to the LLM APIs.

What each option costs

What each option costs depends heavily on usage volume. For an MVP with a few hundred users, API costs run 10–50 €/month. With hundreds of thousands of users, it can quickly hit four figures. On-device ML has no ongoing costs — but the initial development is more involved.

No-code AI: building apps without programming

Bolt, Lovable, FlutterFlow with AI assistant — I've tested them all. These tools promise to generate apps from text descriptions.

I've tested several of them. My honest take:

For prototypes and demos, they work surprisingly well. Bolt generates a functional web app from a prompt — with UI, navigation, and basic logic. FlutterFlow creates Flutter UIs from descriptions that actually look decent. For a pitch deck prototype or an internal demo, that saves days.

For production-ready apps, they fall short. The codebase is hard to maintain, performance sits below what an experienced developer produces, and the moment you need something beyond standard patterns, you hit walls. Error handling, edge cases, accessibility, performance optimization — these are the things that separate a good app from a mediocre one, and no builder handles them well.

My recommendation: use no-code AI for validation. Build a prototype, show it to potential users, collect feedback. If validation is positive, invest in a professional implementation. The prototype then provides valuable requirements for the developer. (More on this in my post for founders building their first app.)

Want to know what an MVP with AI features actually costs? Here's my honest breakdown.

What AI means for costs and timelines

The honest answer: AI makes app development cheaper and faster, but not to the degree some people promise.

My experience: AI tools save me 20–40% of development time, depending on the project type. A project that would have taken eight weeks now takes six to seven. With heavy custom UI and little boilerplate, the difference is smaller. With API-heavy backend integrations, it's larger.

What doesn't change: the concept and design phase. Understanding what to build takes just as long as before. Same for testing and QA. AI accelerates implementation, not the entire product development process.

For clients, that means concretely: an MVP that previously cost 20,000 € now comes in around 15,000–17,000 €. (More on this in my post about app costs.) Not a paradigm shift, but a noticeable improvement. The bigger change is that I can deliver more functionality in the same time — not that the same functionality costs dramatically less.

Where AI hits its limits

After two years of daily use, I'm clear on what AI can't do in app development — at least not yet.

Business context is the biggest gap. AI can write code, but it can't judge whether the feature priority is right or whether the architecture will still scale in six months. Every decision that goes beyond a single function needs human judgment.

Then there's the missing long-term memory. AI doesn't know the decision from last sprint about why you chose against Redux, or which technical debt you consciously accepted. Context extends beyond the session, and that's missing.

Hallucinations still happen. Less than a year ago, but they do. Non-existent API methods, outdated syntax, packages that don't exist. If you can't verify the output, you won't notice. That's why AI is a tool for developers, not a replacement.

And then the quality question. AI produces code that "works." But working code and good code aren't the same thing. Error handling, accessibility, performance under load, edge cases with poor network connectivity — these are the things that matter, and they don't appear in any AI-generated MVP.

Still: AI is the best tool that's been added to my career as a developer. Not because it replaces me, but because it handles the boring parts and leaves me more time for the interesting ones. If you're considering local AI alternatives to cloud APIs, here's my experience report.

Planning an app with AI features, or want to know how AI can speed up your project? Book a free intro call — I'll give you a realistic assessment of what's possible and what's worth it. More about my approach on the app development page.

AI-Assisted Flutter Development: Claude Code in Production

Khalit Hartmann — Thu, 02 Jul 2026 15:04:00 +0000

AI-Assisted Flutter Development: Claude Code in Production

For senior developers, tech leads, and CTOs wondering whether AI coding tools actually work in production -- or just generate impressive demos.

TL;DR: I used Claude Code across 827 commits in a Flutter e-commerce app for a Swiss retailer. The difference between "vibe coding" and AI-assisted development is not the AI -- it is the infrastructure around it. A CLAUDE.md file defines project context. Custom skills (slash commands) switch the AI between migration mode, legacy mode, and test mode. Architecture guardrails prevent the AI from "improving" code it should not touch. Result: ~30% faster migration timeline. Not because the AI wrote perfect code, but because it handled the mechanical parts while I made the decisions that required judgment.

Vibe Coding vs. AI-Assisted Development

These two terms get used interchangeably in 2026. They should not be.

Vibe coding is prompting and committing. You describe what you want, the AI generates code, you paste it in. Maybe it works. Maybe it compiles. Maybe it follows the same pattern as the rest of your codebase. You don't know until something breaks, and by then three more features are built on top of it.

AI-assisted development is structured collaboration. The AI knows your architecture. It knows which patterns to follow in which parts of the codebase. It knows when to use TaskEither and when to use try/catch. It knows because you told it -- explicitly, in configuration files that it reads before writing a single line.

Both use the same underlying models. The difference is entirely in setup. One produces code that looks right in a PR diff. The other produces code that works in production six months later.

I spent ten months on a project that started as vibe-coded and ended as something far more disciplined.

The Project: 827 Commits, One Codebase

The Customer was a renowned Swiss retailer that had just launched their Mobile E-Commerce App 2 Months prior. I joined their Flutter e-commerce app when it had an 85% crash-free rate -- roughly one in seven sessions ended in a crash. API calls inside widgets, three different error handling styles, state management by tutorial roulette.

Over 22 weeks, I migrated the app to Clean Architecture while shipping features. Crash-free rate past 97%. This post is about the AI tooling that made it possible to move that fast.

My only AI coding tool was Claude Code -- an agentic coding CLI that reads your entire project and executes multi-step development tasks. Not Copilot, not Cursor. The distinction matters because this workflow depends on Claude Code features: CLAUDE.md configuration files and custom skills.

The Context Problem

Here is what happens when you point an AI at a Flutter codebase without project context.

You ask it to fetch product data. It writes a service class with try/catch. You ask it to fetch user data. It writes a repository with TaskEither from fpdart. You ask it to handle cart state. It generates a ChangeNotifier. You already use Riverpod.

Three requests, three different patterns. Each defensible in isolation. Together, a maintenance nightmare.

The AI has no way to know your project uses TaskEither for error handling and AsyncNotifier for state management. It draws from the sum of all Flutter code it has ever seen, and that sum includes every pattern and anti-pattern in existence.

The fix is not a smarter model. The fix is project context.

CLAUDE.md: Your Project's AI Configuration

Claude Code reads a CLAUDE.md file from your project root at the start of every session. Architecture decisions, naming conventions, import rules -- everything the AI needs before it touches your code.

Here is a simplified version from the retailer project:

## Architecture

This project uses Clean Architecture with feature-first organization.

### Decision Matrix

- Touching existing unmigrated code? -> Follow legacy patterns
- Writing a new feature? -> Use Clean Architecture
- Migrating an existing feature? -> Follow migration checklist

### Import Rules

- Domain layer: NO imports from data or presentation
- Presentation layer: imports domain only
- Data layer: implements domain interfaces

### Error Handling

- New code: TaskEither<AppFailure, T> from fpdart
- Legacy code: existing try/catch (do NOT refactor)

### State Management

- New features: Riverpod with code generation
- AsyncNotifier for async state
- Do NOT use ChangeNotifier, StateNotifier, or Bloc

This is not documentation for humans. Humans have context from standups and PR reviews. CLAUDE.md is documentation for the AI -- explicit, unambiguous, with decision trees instead of guidelines.

The decision matrix is the most important part. Without it, the AI defaults to "write the best code possible." During a migration, "best code possible" is context-dependent. A bug fix in unmigrated code should follow legacy patterns. The same logic, written during a migration, should follow Clean Architecture. Same feature, two correct approaches, depending entirely on intent. No model training covers that distinction. It has to be configured per project.

Custom Skills: Different Tasks, Different AI Behavior

A CLAUDE.md sets the baseline context. But different development tasks need the AI to behave differently. That is where custom skills come in.

Custom skills are slash commands in Claude Code. Each one loads a specific set of instructions that override or extend the baseline context. On the retailer project, I used five:

/migration enforces a strict sequence:

When migrating a feature:

1. Create domain layer first (entities, repository interfaces, use cases)
2. Create data layer (implementations, data sources, DTOs)
3. Create presentation layer (providers, pages, widgets)
4. Write tests for each layer
5. Remove legacy code only after tests pass

The AI does not jump ahead to the presentation layer because it is "easier." It starts with the domain, writes the interfaces, and builds outward. Every migrated feature has the same structure.

/legacy-code is the opposite. "Follow existing patterns. Do not introduce Clean Architecture imports. Match the style of surrounding code." This was the hardest skill to get right. The AI's instinct is to improve. It sees a try/catch and wants to refactor it into TaskEither. That instinct is correct in migration mode and catastrophic in legacy mode. A "quick improvement" to a legacy service class can break five widgets that depend on its exact interface.

/ui-component loads design system rules. /riverpod enforces code generation with @riverpod annotation and AsyncNotifier. /test-workflow sets testing conventions -- unit tests for use cases, widget tests for composed components, mock repositories via domain interfaces.

Each skill changes the AI's behavior without changing the AI itself. The model is the same. The context is different. (For more on how AI agents and tool systems like these work, see AI Agents, MCP, and Tools Explained.)

Architecture Guardrails: The Biggest Win

If I had to pick one concept from this entire setup that delivered the most value, it is architecture guardrails.

During a migration, two valid architectural styles coexist for months. Every task requires a decision -- which style applies here? Humans handle this through judgment. AI does not have that judgment. Without explicit guardrails, it sees legacy code and "improves" it. That creates a third style -- half-migrated code that follows neither convention consistently. Worse than legacy code because it is unpredictable.

The decision matrix in CLAUDE.md solved this. Not a suggestion -- a rule. "Touching unmigrated code? Follow legacy patterns." No ambiguity.

Here is what the same task looks like with and without guardrails.

Without guardrails -- fixing a bug in a legacy service:

// AI "improves" the legacy code while fixing the bug
class ProductService {
  TaskEither<AppFailure, Product> getProduct(String id) {
    return TaskEither.tryCatch(
      () => _httpClient.get('/products/$id').then((r) => Product.fromJson(r.data)),
      (error, stack) => AppFailure.unexpected(error.toString()),
    );
  }
}
// Problem: 12 widgets depend on Future<Product>, not TaskEither

With guardrails -- same bug, same service:

// AI fixes the bug using existing patterns
class ProductService {
  Future<Product> getProduct(String id) async {
    try {
      final response = await _httpClient.get('/products/$id');
      return Product.fromJson(response.data);
    } catch (e) {
      if (e is TypeError) throw ProductNotFoundException(id);
      rethrow;
    }
  }
}
// Bug fixed, existing interface preserved

The second version is not "better code" in the abstract. It is the correct code for this context -- context-dependent correctness.

What AI Is Good At (and Where It Falls Short)

After 827 commits using Claude Code, I have a clear picture of where AI pair programming delivers value and where it does not.

Where it excels

Boilerplate is the obvious one. Clean Architecture is verbose by design -- entity classes, repository interfaces, use cases, data sources, DTOs, mappers, provider declarations. The structure is formulaic. Once the AI has seen two migrated features, it generates the scaffolding for the third with minimal correction.

Test generation is close behind. "Write unit tests for this use case" with the project's testing conventions loaded produces usable tests 80% of the time. The remaining 20% need manual adjustment, usually around edge cases the AI cannot infer from the interface alone.

Pattern consistency is something AI handles better than humans. A developer on their fifteenth provider declaration in a week starts taking shortcuts. The AI does not get tired. Every AsyncNotifier follows the same structure. That consistency compounds over months.

Where it falls short

Architectural decisions remain firmly human territory. "Should we introduce a caching layer here?" depends on traffic patterns, backend SLA, and six other factors the AI cannot observe. It will give you a confident answer. That answer may be wrong.

Business context is invisible to the AI. It does not know that the German market has different legal requirements for price display than the Swiss market, or that certain API fields return stale data because the backend redesign is not finished. These are the things that cause real bugs.

Subtle bugs are the dangerous category. The AI writes code that compiles, passes the tests it generated, and looks correct in review. But it might use the wrong comparison operator for a currency calculation or handle a timezone edge case incorrectly. AI-generated code needs the same scrutiny as human-written code. Arguably more, because its confidence makes it easier to rubber-stamp.

The AI also lacks the judgment to not write code. Sometimes the correct response is "this duplicates existing functionality." The AI will always produce something.

The Real Impact: ~30% Faster, Not Magic

The migration took 22 weeks. Without AI-assisted development, my estimate is 30-32 weeks. That is roughly six to eight weeks saved -- not the ten-times productivity claim you see in conference talks.

The 30% comes from two sources. The mechanical parts of each migration step were faster -- scaffolding, boilerplate, initial test suites. And pattern consistency reduced the review cycle. Fewer "why does this feature handle errors differently?" conversations.

What AI did not speed up: architectural planning, debugging production issues via Crashlytics traces, and the final QA pass on each step.

The honest math: 70% of the speed gain came from boilerplate reduction. 30% came from consistency enforcement. Zero percent came from the AI making better architectural choices than I would have. I applied a similar Claude Code workflow in a serverless-to-monolith migration with comparable results.

If your team is planning a similar migration or evaluating how AI tooling fits into production workflows, I have done this before.

Setting This Up for Your Project

This works for any project, not just Flutter -- I use the same CLAUDE.md and custom skills approach on web apps, backend services, and infrastructure projects. For a broader perspective on AI in app development, see Building Apps with AI.

Start with CLAUDE.md. Document your architecture in machine-readable terms. Not "we prefer clean code" -- the AI does not know what you mean by that. Instead: "Domain layer classes live in lib/features/{name}/domain/. They must not import from data/ or presentation/. Error handling uses TaskEither<AppFailure, T>." Concrete paths. Concrete types. Concrete rules.

Add a decision matrix. If your codebase has multiple styles (most do), codify which style applies when. Write it as a decision tree, not prose.

Create your first custom skill for whatever task you do most often. Start with one. Add more as you identify repeated patterns in your AI interactions.

Run the AI on low-risk tasks first. A utility function. A test for an existing module. Review the output carefully -- import paths, naming conventions, whether it followed the CLAUDE.md rules. Update CLAUDE.md when the instructions are ambiguous. Expand to feature work once the context is dialed in.

The CLAUDE.md is a living document. Mine changed over fifty times during the retailer project. Over ten months, it became a remarkably precise description of the project's architecture. A side effect: it is also the best onboarding document the project has.

What This Means for Teams

The CLAUDE.md and custom skills are project-level configuration, not personal preference. When the entire team uses them, a junior developer using /migration gets the same structural scaffolding as a senior developer. The architecture decisions are encoded in the tooling, not locked inside one person's head.

This shifts code review from "did you follow the pattern?" to "is the business logic correct?" And it forces the team to articulate rules that previously lived as tribal knowledge. "When you fix a bug in legacy code, follow legacy patterns" is a nuanced rule most teams never write down. The AI forces you to write it down, and the whole team benefits.

There is a handover benefit too: the CLAUDE.md and custom skills stay with the codebase. When a freelancer finishes an engagement, the team inherits a precise, machine-readable description of their own architecture. No knowledge walks out the door.

Agentic Coding: Where This Is Heading

The current setup -- AI as a careful assistant with explicit guardrails -- is an intermediate step. The next stage is agentic coding: the AI executes multi-step tasks autonomously, creates files, runs tests, fixes failures, and commits the result.

For me, this is already partially reality in 2026. Claude Code can run a migration end-to-end -- create the file structure, generate the code, write tests, run them, and correct failures. I review the outcome instead of every intermediate step.

But the same principle holds: autonomy without guardrails is dangerous. The more autonomy the AI gets, the more important the architecture rules in CLAUDE.md become. Without them, autonomous coding is just vibe coding with extra steps.

Conclusion

AI-assisted development in production is not about the AI being smart. It is about the developer being deliberate.

In a production codebase, AI without project context generates code that looks right and behaves wrong. Without guardrails, it "improves" code that should not be touched. The infrastructure matters more than the model -- CLAUDE.md, custom skills, explicit rules about which patterns apply where. That is what separates vibe coding from production-grade AI development. When this setup becomes your default rather than an experiment, AI is no longer assisting your development -- it is native to it.

My results on the retailer project: 827 commits, crash-free rate from 85% to past 97%, ~30% faster migration timeline. Not because the AI was magic. Because the AI had context.

The bar for AI-assisted development in 2026 is not "can the AI write code?" It can. The bar is: "can the AI write code that belongs in your codebase?" That takes work. The work is worth it.

I help teams set up AI-assisted development workflows for production codebases. If that is relevant for your project, let's talk.

Frequently Asked Questions

What is the difference between vibe coding and AI-assisted development?

Vibe coding means prompting an AI and committing the output with minimal review or structural guidance. AI-assisted development means providing the AI with explicit project context -- architecture rules, conventions, decision matrices -- so that its output is consistent with the existing codebase. Same models, different infrastructure.

What is CLAUDE.md?

A configuration file that Claude Code reads from your project root at the start of every session. It contains architecture descriptions, naming conventions, import rules, and decision trees that guide the AI's behavior -- project documentation written for the AI.

Can AI coding assistants handle architecture migrations?

With guardrails, yes. Unguided, an AI will try to "improve" all code it touches, creating pattern chaos during a migration. Custom skills and decision matrices in CLAUDE.md constrain the AI to follow the correct patterns for each context.

How much faster is AI-assisted Flutter development?

Roughly 20-30% faster for implementation work. Boilerplate-heavy work sees the biggest gains. Architectural planning, debugging, and QA are not meaningfully faster.

Does this approach work with tools other than Claude Code?

The concepts -- project context files, task-specific configurations, architecture guardrails -- apply broadly. The specific implementation (CLAUDE.md, custom skills) is Claude Code. Other tools have their own mechanisms. The principle is the same: give the AI explicit, machine-readable project context.

DEV Community: Khalit Hartmann

Klaviyo Push Notifications in Flutter: 3 Silent Pitfalls

The 10-minute install and the 3-day debug

Pitfall 1: Your Klaviyo pushes are being silently dropped

The fix: a single unified service

Pitfall 2: Push taps stop working on both platforms

The _k marker and the iOS trap

Dart-side handling: skip Klaviyo taps

Pitfall 3: Android channel importance is write-once

The fix: bump the channel ID

What this means for your estimate

The pattern across all three pitfalls

Related reading

Frequently Asked Questions

How do I set up Klaviyo push notifications in Flutter?

Can I test Klaviyo push notifications in the iOS simulator?

Does the MESSAGING_EVENT conflict apply to other push SDKs besides Klaviyo?

Do I need to fix all three pitfalls, or can I skip some?

One trackEvent(), Four SDKs: Analytics Layer for Flutter

The starting point: 10 call sites, 2 SDKs, no abstraction

The design: Adapter + Mediator

The adapter interface

The dispatcher

Patterns rejected on purpose

GA4 names as the canonical event language

How events map across providers

Consent: the part everyone gets wrong

Mechanism 1: Per-call gating

Mechanism 2: SDK-level consent for auto-collecting providers

The consent lookup

Proof it works: the next provider was cheap

Testing the dispatch layer

Takeaways for your analytics layer

Related reading

Frequently Asked Questions

Why not just call each analytics SDK directly in Flutter?

Which design pattern fits a multi-provider analytics layer?

What event naming should a Flutter analytics layer use?

How should consent be handled with multiple analytics providers?

Klaviyo Shopify Integration in Flutter: What to Know First

Why "install the SDK" is the wrong mental model

Before you start: what the client must provide

Workstream 1: Building a Flutter analytics layer for Klaviyo

Workstream 2: Klaviyo push notifications in Flutter

Workstream 3: Klaviyo profile identity & newsletter in Flutter

Workstream 4: Consent management for Klaviyo with Usercentrics

The Shopify checkout problem: why Flutter can't track purchases

The real timeline

Five scoping mistakes to avoid

Conclusion

Related reading

Frequently Asked Questions

Does Klaviyo have a Flutter SDK?

How long does a Klaviyo integration into a Flutter app take?

What does the client need to provide before a Klaviyo integration starts?

Can the app track purchases in Klaviyo if checkout runs in the browser?

Akamai Bot Protection in Flutter: BMP SDK Integration

The Setup: Akamai Everywhere

Image Manager: Optimized Images from the CDN Edge

Why the App Got Blocked

The BMP SDK: Proving You're Not a Bot

The Interceptor Chain

1. Sensor Data Enrichment

2. Challenge Action (HTTP 428)

3. Bot Protection (HTTP 403)

4. Session Cookie Monitoring

URL-Based Filtering

Testing and Debug Tooling

What I Learned

Conclusion

Frequently Asked Questions

What is Akamai Bot Manager and how does it affect mobile apps?

Does Akamai provide a mobile SDK for bot protection?

What's the difference between a 428 and a 403 from Akamai?

Does Akamai Image Manager work with Flutter's image caching?

How do you test Akamai integration in CI/CD?

Local AI & LLM for Developers: Freelancer Verdict (2026)

3,000 € in hardware or 90 € a month?

Four developer types, four perspectives

The privacy pragmatist

The `_k` marker and the iOS trap

The `restartWebView()` Workaround

Complexity #3: Five Plugins, Two Worlds, One `window.mobileApp`