Forem: Gautier 💙

Send Meta Ad Events from Flutter with AEM Support

Gautier 💙 — Wed, 15 Apr 2026 06:19:22 +0000

If you run ads for a mobile app, iOS is where the money is.
iOS users spend 2 to 3 times more than Android users on in-app purchases and subscriptions.
They convert better, retain longer, and have higher lifetime value. In most markets, the top revenue apps make 60-70% of their income from iOS — even when Android has more downloads.

If you are spending money on Meta ads, iOS users are the ones you want to reach.
And that is exactly where the problem starts.

I spent tons of money on Meta ads last year.

A big chunk of that was wasted.
Not because the ads were bad, but because Facebook never saw the conversions.
My campaigns could not optimize because the conversions events were not getting through.

If you are running Meta ads for a Flutter app on iOS, you have probably seen this: your app is making sales, but Events Manager shows almost nothing.
Your ROAS looks terrible. Your campaigns stay stuck in learning phase.

The problem is not your ads (or it might be). The problem is your event pipeline.

The iOS 14+ problem nobody talks about

When Apple introduced App Tracking Transparency (ATT), it changed everything for mobile advertisers. Users can now opt out of tracking — and most of them do. On average, only 20-30% of iOS users opt in.

That means 70-80% of your conversions are invisible to Meta.

Meta's answer to this is AEM — Aggregated Event Measurement. It is a protocol that lets Meta receive conversion data in a privacy-compliant way, even from users who opted out of tracking. Without AEM, Meta literally cannot see most of your iOS purchases.

Here is what happens without AEM:

use Apple SkanNetwork for attribution, which only reports app installs and a few post-install events with heavy limitations
You spend $100 on ads
10 users buy your app
Meta sees 2 or 3 of those purchases (the ones who opted in but with 24-48 hours delay)
Meta thinks your ads are performing terribly
The algorithm stops showing your ads to good prospects
You waste more money

With AEM:

You spend $100 on ads
10 users buy your app
Meta sees 2-3 purchases directly from opted-in users (same as before but only 30 mn to 24 hours delay)
For the other 7-8, AEM provides aggregated, delayed signals — not full conversion records, but enough for Meta's algorithm to estimate total conversions
Meta uses statistical modeling on top of these signals to better optimize your campaigns
Your campaigns improve over time — not perfectly, but dramatically better than flying blind

To be clear: AEM does not magically bypass ATT. It does not send individual conversion data for users who opted out. What it does is give Meta enough aggregated signal to work with. There are real limitations:

You are limited to 8 prioritized conversion events per app — only the highest-priority event per user gets reported
Data from opted-out users is delayed 24-72 hours, not real-time
Meta fills gaps with modeling and estimation, not actual tracked data
It works alongside Apple's SKAdNetwork postbacks

The bottom line: without AEM, Meta sees almost nothing. With AEM, Meta gets enough signal to actually optimize. It is not perfect, but it is the difference between campaigns that learn and campaigns that burn money.

This is not optional if you are serious about running ads.

Why I built facebook_flutter_sdk

The existing flutter_facebook_app_events plugin is solid and works well for basic event tracking. But it does not support AEM.

I needed AEM for my own campaigns. I submitted a PR to add it, but the maintainer had different priorities — totally fair, it is their project. So I forked it and published facebook_flutter_sdk with AEM built in.

To be clear:

If you don't run Meta ads or don't need AEM, flutter_facebook_app_events works great
If you run Meta ads and need accurate iOS conversion tracking, facebook_flutter_sdk fills that gap

The API is compatible. Switching is a one-line change in your pubspec.

Setup

1. Install the package

flutter pub add facebook_flutter_sdk

2. Get your Facebook credentials

Go to Meta for Developers, open your app, and grab:

App ID — found in Settings > Basic
Client Token — found in Settings > Advanced

3. Android configuration

Add your credentials to android/app/src/main/res/values/strings.xml:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string name="facebook_app_id">YOUR_APP_ID</string>
    <string name="facebook_client_token">YOUR_CLIENT_TOKEN</string>
</resources>

Then reference them in your AndroidManifest.xml inside the <application> tag:

<meta-data
    android:name="com.facebook.sdk.ApplicationId"
    android:value="@string/facebook_app_id" />
<meta-data
    android:name="com.facebook.sdk.ClientToken"
    android:value="@string/facebook_client_token" />

4. iOS configuration

Update your ios/Runner/Info.plist:

<key>FacebookAppID</key>
<string>YOUR_APP_ID</string>
<key>FacebookClientToken</key>
<string>YOUR_CLIENT_TOKEN</string>
<key>FacebookDisplayName</key>
<string>Your App Name</string>
<key>CFBundleURLTypes</key>
<array>
  <dict>
    <key>CFBundleURLSchemes</key>
    <array>
      <string>fbYOUR_APP_ID</string>
    </array>
  </dict>
</array>

Note the fb prefix before your App ID in the URL scheme. This is required by the Facebook SDK.

5. Request ATT permission (iOS)

You need to ask users for tracking permission before sending events. You probably already use permission_handler in your app — it supports ATT out of the box:

flutter pub add permission_handler

Add the usage description to your Info.plist:

<key>NSUserTrackingUsageDescription</key>
<string>This identifier will be used to deliver personalized ads to you.</string>

Then request permission early in your app — typically after onboarding:

import 'package:permission_handler/permission_handler.dart';
import 'package:facebook_flutter_sdk/facebook_flutter_sdk.dart';

Future<void> requestTracking() async {
  final status = await Permission.appTrackingTransparency.request();
  final facebookAppEvents = FacebookAppEvents();

  // Tell Facebook SDK whether the user opted in
  await facebookAppEvents.setAdvertiserTracking(
    enabled: status.isGranted,
  );
}

Sending events

Initialize the SDK

final facebookAppEvents = FacebookAppEvents();

Log custom events

await facebookAppEvents.logEvent(
  name: 'level_completed',
  parameters: {
    'level': '5',
    'score': '1200',
  },
);

Log purchases

This is the most important event for ad optimization.

Use the eventId parameter for deduplication:

await facebookAppEvents.logPurchase(
  amount: 9.99,
  currency: 'USD',
  eventId: transactionId, // unique ID for deduplication
);

The eventId is critical. If you also send purchase events server-side via the Conversions API (you should), Meta uses this ID to deduplicate and avoid counting the same purchase twice.

Log add-to-cart events

await facebookAppEvents.logAddToCart(
  id: 'premium_yearly',
  type: 'product',
  price: 49.99,
  currency: 'USD',
);

Set user data for advanced matching

Advanced matching improves attribution accuracy by letting Meta match events to users across devices:

await facebookAppEvents.setUserData(
  email: user.email,
  firstName: user.firstName,
  lastName: user.lastName,
  country: user.country,
);

Hash the data yourself if you prefer — Meta also accepts pre-hashed values.

RevenueCat integration

If you use RevenueCat for subscriptions, here is how to log purchases to Meta:

...
final facebookAppEvents = FacebookAppEvents();

final purchaseParams = PurchaseParams.package(package);
final res = await Purchases.purchase(purchaseParams);
if (res.purchaserInfo.entitlements.all.isNotEmpty) {
  final transactionId = res.storeTransaction.transactionIdentifier;

  await logMetaPurchase(transactionId, package.storeProduct.price, package.storeProduct.currencyCode);
}

The transactionIdentifier from RevenueCat is perfect as an eventId.

If you also send this purchase server-side via RevenueCat's webhook to your backend (which then calls the Conversions API), use the same transaction ID.
Meta will deduplicate automatically.

Event deduplication with Conversions API

Client-side events alone are not enough. Some events get lost due to network issues, app crashes, or ad blockers. That is why Meta recommends sending events from both client and server.

The flow:

Client-side: your Flutter app sends the event via facebook_flutter_sdk with an eventId
Server-side: your backend sends the same event via the Conversions API with the same eventId
Meta deduplicates: if both events arrive, Meta keeps one and discards the duplicate

This gives you the best of both worlds — real-time client events plus reliable server events as a fallback.

If you use RevenueCat, you can set up a webhook from RevenueCat to your server, then forward purchase events to the Conversions API with the same transaction ID.

Why you probably don't need an MMP

When I was trying to figure out why my events were not working, every article told the same thing: use an MMP.

MMPs like Adjust, AppsFlyer, or Branch are tools that sit between your app and ad networks.
They handle attribution, event forwarding, and reporting.
They are powerful. They are also expensive — $500 to $2,000+ per month after 10k monthly active users.

But they are not magic, and most of the. time they are really hard to set up correctly.

Here is the thing: if Meta is your primary ad channel, you don't need one.

The facebook_flutter_sdk + Conversions API combo gives you:

Accurate conversion tracking with AEM
Event deduplication
Advanced matching
Full control over your data

MMPs make sense when you run campaigns across 5+ ad networks simultaneously and need unified attribution.
For most indie developers and small teams running Meta ads, direct integration is enough.

Common mistakes

Not requesting ATT early enough

If you request ATT after the user has already triggered events, those early events are sent without tracking authorization. Request it during onboarding, before any purchase flow.

Forgetting the eventId on purchases

Without eventId, Meta cannot deduplicate client and server events. You either miss events or double-count them. Both destroy your campaign optimization.

Volume of Advertiser Tracking Enabled parameter out of range

Many sees this error in their facebook events manager. The error is not really understandable. But this is what you get when plugin is not properly implementing AEM protocol.
When you get this error you can't start a campaign to optimize for purchases. You can only optimize for install or user SKAdNetwork events. That is a problem because purchase optimization is where the money is.
So if you see this error, switch to facebook_flutter_sdk and it should fix it.

Go further with Meta Ads

Setting up events is step one.
But creating campaigns that actually convert — choosing the right objective, structuring ad sets, estimating budgets, analyzing results — that is a whole other skill.

I put everything I learned from spending $$$ on Meta ads into a complete guide for Flutter developers.

It covers setup, campaign strategy, budget estimation, and how to avoid the mistakes that cost me thousands.

If you are serious about growing your app with ads, check it out.

Stop flying blind

Every day you run Meta ads without AEM, you are paying for data that never reaches the algorithm. Your campaigns cannot optimize. Your ROAS stays flat. You burn money.

The fix is straightforward: install facebook_flutter_sdk, set up your events with proper deduplication, and let Meta actually see your conversions.

One package. A few lines of code. Campaigns that finally learn.

Automate Your Flutter iOS Deployment with Fastlane

Gautier 💙 — Tue, 14 Apr 2026 08:03:18 +0000

If you have ever shipped a Flutter app to the App Store, you know the pain.

Open Xcode. Wait for indexing. Archive. Wait again. Upload. Fill in release notes manually for every locale. Click through 15 screens. Hope nothing breaks.

Now imagine doing that every week. Or every time you fix a critical bug.

There is a better way. Fastlane lets you automate the entire iOS deployment process with a single terminal command. No Xcode GUI, no manual uploads, no copy-pasting release notes.

In this guide, I will walk you through a real Fastlane setup that I use to deploy my own Flutter apps. Not a toy example. A production config that handles API authentication, localized metadata, and App Store uploads.

Why Fastlane for Flutter iOS deployment

Flutter builds your app. Fastlane ships it.

Flutter's flutter build ipa gives you a binary. But getting that binary to the App Store with the right metadata, release notes, and screenshots is a whole separate job. That is where Fastlane comes in.

Here is what Fastlane handles for you:

Authentication with App Store Connect (no 2FA prompts)
Metadata management — descriptions, keywords, release notes for every locale
Binary uploads — push your IPA directly to App Store Connect
Version creation — create new app versions programmatically
Submission — optionally submit for review automatically

All from one command in your terminal.

Prerequisites

Before we start, make sure you have:

A Flutter app that builds successfully with flutter build ipa
An Apple Developer account with App Store Connect access
Ruby installed (macOS comes with it, or use rbenv)
Fastlane installed:

gem install fastlane

Then initialize Fastlane in your Flutter project's ios/ directory:

cd ios
fastlane init

Choose option 4 (manual setup) when prompted. This creates the ios/fastlane/ directory with a Fastfile and Appfile.

Step 1 — Set up App Store Connect API key

The first thing you want to do is stop using your Apple ID to authenticate. Apple's 2FA will block your automation every time.

Instead, create an App Store Connect API key:

Go to App Store Connect > Users and Access > Integrations > App Store Connect API
Click the + button to generate a new key
Give it a name like "Fastlane CI" and select the App Manager role
Download the .p8 key file — you can only download it once

Now store these values as environment variables. Add them to your .zshrc, .bashrc, or CI secrets:

export FASTLANE_APP_STORE_CONNECT_API_KEY_ID="YOUR_KEY_ID"
export FASTLANE_APP_STORE_CONNECT_API_ISSUER_ID="YOUR_ISSUER_ID"
export FASTLANE_APP_STORE_CONNECT_API_KEY_PATH="/path/to/AuthKey.p8"

In your Fastfile, create a helper function that loads this key:

def load_api_key
  app_store_connect_api_key(
    key_id: ENV["FASTLANE_APP_STORE_CONNECT_API_KEY_ID"],
    issuer_id: ENV["FASTLANE_APP_STORE_CONNECT_API_ISSUER_ID"],
    key_filepath: ENV["FASTLANE_APP_STORE_CONNECT_API_KEY_PATH"],
    in_house: false,
  )
end

Every lane calls load_api_key first. No passwords, no 2FA, no session tokens that expire.

Step 2 — Organize your metadata

Fastlane uses a folder structure to manage your App Store metadata. Each locale gets its own folder with text files for the different fields.

fastlane/metadata/
  en-US/
    release_notes.txt
    description.txt
    keywords.txt
  fr-FR/
    release_notes.txt
    description.txt
  de-DE/
    release_notes.txt
  ...

You can bootstrap this structure by pulling your existing metadata from App Store Connect:

desc "Download metadata from App Store Connect"
lane :download_app_metadata do
  load_api_key
  deliver(
    download_metadata: true,
    download_screenshots: false,
    force: true,
  )
end

Run it with:

fastlane download_app_metadata

This downloads all your current descriptions, keywords, and release notes into the metadata/ folder.

Now you can edit them locally and push updates without touching App Store Connect.

(I tend to split screenshots and metadata into separate lanes, so I can update text without worrying about images, and vice versa.)

Handling localized release notes

If you support multiple languages, you need release notes for each locale. Here is a helper that loads them all, with a fallback to English:

def load_release_notes(metadata_path = nil)
  metadata_path ||= File.join(__dir__, "metadata")
  fallback = File.read(File.join(metadata_path, 'en-US/release_notes.txt'))
  locales = %w[ar-SA ca cs da de-DE el en-AU en-CA en-GB en-US
               es-ES es-MX fi fr-CA fr-FR he hi hr hu id it ja
               ko ms nl-NL no pl pt-BR pt-PT ro ru sk sv th tr
               uk vi zh-Hans zh-Hant]
  locales.each_with_object({}) do |locale, hash|
    file = File.join(metadata_path, locale, 'release_notes.txt')
    hash[locale] = File.exist?(file) ? File.read(file) : fallback
  end
end

This is important. If you forget a locale, Apple will reject your submission or show stale release notes. This helper makes sure every supported locale has content.
You can remove any locale you don't support, but keep the fallback to avoid submission failures.

Note:
You can create a translations script to automatically translate your release notes from English to all your other languages.

All Apple App Store locales by priority

Not all locales are equal. Some cover massive markets with high App Store spending. Others are nice-to-have. Here is a prioritization to help you decide what to translate first.

Tier 1 — Cover these first. These locales represent the largest App Store markets by revenue and downloads. Skipping any of them means leaving money on the table.

Locale	Language	Why
en-US	English (US)	Largest App Store market by revenue
en-GB	English (UK)	Second-largest English-speaking market (optionnal as it's covered by en-US)
ja	Japanese	Japan is the #2 App Store market worldwide
zh-Hans	Chinese Simplified	Massive user base, high spending on in-app purchases
ko	Korean	South Korea has one of the highest ARPU
de-DE	German	Germany is the top European market
fr-FR	French (France)	Major European market and 2nd language impact on surrounding countries
es-ES	Spanish (Spain)	Gateway to all Spanish-speaking countries
pt-BR	Portuguese (Brazil)	Largest Latin American market
en-AU	English (Australia)	High ARPU English-speaking market

Tier 2 — Add these next. Strong markets that will move the needle once Tier 1 is covered.

Locale	Language	Why
zh-Hant	Chinese Traditional	Covers Taiwan and Hong Kong
it	Italian	Large European economy
nl-NL	Dutch	High smartphone penetration
sv	Swedish	High ARPU Nordic market
da	Danish	High ARPU Nordic market
no	Norwegian	High ARPU Nordic market
tr	Turkish	Large and growing mobile market
pl	Polish	Biggest Central European market
ar-SA	Arabic (Saudi Arabia)	High spending Gulf market
he	Hebrew	Israel is a strong tech market
en-CA	English (Canada)	High ARPU North American market
fr-CA	French (Canada)	Required for Quebec App Store visibility
es-MX	Spanish (Mexico)	Second-largest Latin American market
pt-PT	Portuguese (Portugal)	Completes Portuguese coverage

Tier 3 — Nice to have. Smaller markets or languages where English metadata often performs just as well. Add them when you have the bandwidth.

Locale	Language	why
ca	Catalan
cs	Czech
ru	Russian	Large user base but currently can't pay for apps
el	Greek
fi	Finnish
hi	Hindi
hr	Croatian
hu	Hungarian
id	Indonesian
ms	Malay
ro	Romanian
sk	Slovak
th	Thai
uk	Ukrainian
vi	Vietnamese	can be used to impact US market

A practical approach: start with Tier 1 using quality translations, cover Tier 2 with machine translation reviewed by a native speaker, and use English fallbacks for Tier 3 until your app gains traction in those markets.

Step 3 — Create the "release new version" lane

This lane creates a new app version on App Store Connect and pushes your metadata — without uploading a binary. This is useful when you want to update release notes, descriptions, or keywords independently.

desc "Create a new version and push metadata"
lane :release_new_version do |options|
  load_api_key

  produce(
    app_identifier: "com.yourcompany.yourapp",
    app_version: options[:version],
  )

  release_notes = load_release_notes('./metadata')

  deliver(
    app_version: options[:version],
    skip_binary_upload: true,
    force: true,
    submit_for_review: false,
    automatic_release: false,
    metadata_path: "./fastlane/metadata",
    release_notes: release_notes,
    precheck_include_in_app_purchases: false,
    skip_screenshots: true,
  )
end

Run it:

fastlane release_new_version version:"1.2.0"

One command. New version created. Metadata pushed. Release notes in 20+ languages. Done.

Step 4 — Create the deploy lane

This is the main lane. It takes your Flutter IPA, uploads it to App Store Connect, and optionally submits for review.

First, build your Flutter app:

flutter build ipa --release

This generates an IPA file in build/ios/ipa/. Now the deploy lane picks it up:

desc "Build and deploy app to App Store Connect"
lane :deploy do |options|
  load_api_key
  get_push_certificate

  project_root = File.expand_path("../../", __dir__)
  ipa_path = Dir.glob(
    File.join(project_root, "build/ios/ipa/*.ipa")
  ).first

  if ipa_path.nil?
    UI.user_error!("Could not find IPA file.")
  end

  UI.success("Found IPA at: #{ipa_path}")

  release_notes = options[:version] ? load_release_notes : nil

  upload_to_app_store(
    ipa: ipa_path,
    skip_metadata: true,
    skip_screenshots: true,
    force: true,
    submit_for_review: options[:submit_for_review] || false,
    automatic_release: options[:automatic_release] || false,
    metadata_path: "./fastlane/metadata",
    release_notes: release_notes,
    precheck_include_in_app_purchases: false,
    submission_information: {
      export_compliance_uses_encryption: false,
      export_compliance_encryption_updated: false,
    },
  )
end

Deploy without submitting for review:

fastlane deploy

Deploy and submit for review in one shot:

fastlane deploy submit_for_review:true

The submission_information block handles Apple's export compliance questions automatically. No more clicking through those dialogs.

The full Fastfile

Here is the complete Fastfile putting it all together:

default_platform(:ios)

platform :ios do
  def load_api_key
    app_store_connect_api_key(
      key_id: ENV["FASTLANE_APP_STORE_CONNECT_API_KEY_ID"],
      issuer_id: ENV["FASTLANE_APP_STORE_CONNECT_API_ISSUER_ID"],
      key_filepath: ENV["FASTLANE_APP_STORE_CONNECT_API_KEY_PATH"],
      in_house: false,
    )
  end

  def load_release_notes(metadata_path = nil)
    metadata_path ||= File.join(__dir__, "metadata")
    fallback = File.read(
      File.join(metadata_path, 'en-US/release_notes.txt')
    )
    locales = %w[ar-SA ca cs da de-DE el en-AU en-CA en-GB en-US
                 es-ES es-MX fi fr-CA fr-FR he hi hr hu id it ja
                 ko ms nl-NL no pl pt-BR pt-PT ro ru sk sv th tr
                 uk vi zh-Hans zh-Hant]
    locales.each_with_object({}) do |locale, hash|
      file = File.join(metadata_path, locale, 'release_notes.txt')
      hash[locale] = File.exist?(file) ? File.read(file) : fallback
    end
  end

  lane :download_app_metadata do
    load_api_key
    deliver(
      download_metadata: true,
      download_screenshots: false,
      force: true,
    )
  end

  lane :release_new_version do |options|
    load_api_key
    produce(
      app_identifier: "com.yourcompany.yourapp",
      app_version: options[:version],
    )
    release_notes = load_release_notes('./metadata')
    deliver(
      app_version: options[:version],
      skip_binary_upload: true,
      force: true,
      submit_for_review: false,
      automatic_release: false,
      metadata_path: "./fastlane/metadata",
      release_notes: release_notes,
      precheck_include_in_app_purchases: false,
      skip_screenshots: true,
    )
  end

  lane :deploy do |options|
    load_api_key
    get_push_certificate
    project_root = File.expand_path("../../", __dir__)
    ipa_path = Dir.glob(
      File.join(project_root, "build/ios/ipa/*.ipa")
    ).first
    if ipa_path.nil?
      UI.user_error!("Could not find IPA file.")
    end
    release_notes = options[:version] ? load_release_notes : nil
    upload_to_app_store(
      ipa: ipa_path,
      skip_metadata: true,
      skip_screenshots: true,
      force: true,
      submit_for_review: options[:submit_for_review] || false,
      automatic_release: options[:automatic_release] || false,
      metadata_path: "./fastlane/metadata",
      release_notes: release_notes,
      precheck_include_in_app_purchases: false,
      submission_information: {
        export_compliance_uses_encryption: false,
        export_compliance_encryption_updated: false,
      },
    )
  end
end

No reasons to not have metadata for all locales

One of the best reason to handle metadata with Fastlane is that you can version control your ASO.
(ASO = App Store Optimization. The art of writing good descriptions, release notes, and keywords to rank higher in search results. This is SEO for the App Store.)

When your metadata is in git, you can see the history of every change, revert if needed, and even have translators submit PRs with updated descriptions and release notes.

But don't translate litterally everything.
Some countries, even if they are non-English, will have better ASO with English metadata.

I'll write another article about ASO best practices.

My typical deploy workflow

Here is what a release looks like in practice:

# 1. Build the Flutter app
flutter build ipa

# 2. Update release notes in metadata/en-US/release_notes.txt
# (and other locales if needed)

# 3. Deploy to App Store Connect
cd ios
fastlane deploy version:"1.2.0" submit_for_review:true

Three commands. That is it. No Xcode, no web browser, no manual form filling.

What used to take 20-30 minutes of clicking through App Store Connect now takes under 2 minutes of actual work.
The upload itself still takes a few minutes depending on your binary size, but you are free to do something else while it runs.

Bonus I also made a script to fetch the pubspec version and run all commands in one go.
And for Android too but this article is about iOS so I won't go into that.

What about first release?

Start by making all metadata research for US market. Write your description, release notes, and keywords in English.

Then use a script to translate description, promotional text to all other languages.
For title, subtitle, and keywords I tend to keep writing them manually as they require some research and creativity for each market.

Don't forget screenshots.
I made a plugin to automate screenshot translations using figma. If that interests you, let me know and I can write an article about it.

Tips and common pitfalls

Store your API key securely

Never commit the .p8 file to git. Add it to .gitignore and use environment variables or your CI's secret store.

Use `force: true` carefully

The force: true flag skips Fastlane's HTML report preview. This is fine for CI, but when running locally for the first time, remove it to double-check what Fastlane will push.

Keep metadata in version control

Your metadata/ folder should be committed to git. This gives you a history of every release note change and makes it easy for translators to submit PRs.

Handle missing locales gracefully

The load_release_notes helper above falls back to English for any missing locale. This prevents submission failures when you add a new language to your app but haven't translated the release notes yet.

Export compliance

The submission_information block in the deploy lane answers Apple's export compliance questions automatically. If your app uses encryption beyond standard HTTPS, you will need to adjust these values.

Stop deploying manually

Every minute you spend clicking through Xcode and App Store Connect is a minute you are not building features or fixing bugs.

Fastlane is a one-time setup that pays for itself on every single release. If you are shipping a Flutter app to the App Store, this is not optional. It is infrastructure.

Set it up once. Deploy with one command. Move on to the work that actually matters.

If you want to skip the boilerplate entirely and start with a Flutter project that already includes deployment automation, authentication, subscriptions, and everything else you need to ship, check out ApparenceKit. It is built for developers who want to ship fast and focus on their product.

How to Monetize a Mobile App — 6 Proven Strategies That Actually Work

Gautier 💙 — Mon, 13 Apr 2026 08:38:03 +0000

Most apps don't fail because of bad code.

They fail because the developer never figured out how to make money from them.

After building and shipping apps for years at our agency, I can tell you this.

The monetization strategy matters more than the tech stack. More than most things developers spend their time on.

Yet most developers treat monetization as an afterthought.
They build for months, then slap a paywall at the end and wonder why nobody pays.

So if you're wondering how to monetize a mobile app, this is what actually works in 2026.

Before monetization: the 3 pillars of a successful app

Check if people actually use your app

Put analytics in from day one. Track user behavior. Which screens do they visit? Where do they drop off? How long do they stay?
Your first app version is not about making money. It's about proving that people actually use your app and find value in it.
If you don't have users, you don't have a business. So focus on retention and engagement before worrying about monetization.

Build a great onboarding flow

Onboarding is the first experience users have with your app. It's your chance to show them the value.

"Don't tell them, show them."

That's what ex Apple designer Mike Stern says. Don't just explain what your app does. Let users experience it right away. Show them the core value in the first session.
A good onboarding flow can increase retention and conversion dramatically. It sets the stage for monetization later on.
You don't have to show and explain all your features. Just find the one or two core benefits and make sure users experience them during onboarding.

How to monetize apps: 6 models that work

Before diving in, here's a quick overview of the 6 main ways to make money by making apps.

Subscriptions — recurring revenue, highest lifetime value. The king.
Freemium — free core experience, paid premium features
In-app purchases — consumable credits or one-time unlocks
Ads — display, interstitial, or rewarded video
One-time purchase — pay upfront to download
Sponsorships / affiliate — partner revenue

I'll break down the top 3 in detail, then cover the rest.

Subscriptions — the king of app revenue

If your app has any kind of recurring usage, subscriptions are the way to go.

Predictable revenue. Higher lifetime value. And both Apple and Google actively push subscription apps in their stores.

Weekly, monthly, or yearly?

This depends on your app.

Weekly works for apps with daily usage and high engagement (fitness, AI assistants). Downside is higher churn.
Monthly not the best in 2026. All report show a drop in conversion compared to weekly. Users prefer shorter commitments.
Yearly works when users trust the value — offer a discount to push them here

💡 Test your prices. Don't guess.

$4.99/week vs $9.99/month can make a 3x difference in revenue. Start with a hypothesis, measure, and iterate.

Using revenuecat, superwall, adapty... you can A/B test different price points and billing intervals to find what converts best for your audience.

After testing a lot of apps and paywalls

copy is less important than your offer
the price and billing interval are the main levers to increase conversion and revenue.
the design of your paywall matters less than showing it at the right time and demonstrating value before asking for money. But you can't sell high prices if your paywall looks cheap.

Show value before the paywall

This is critical.

If your users hit a paywall before understanding what the app does, they will just uninstall.

The flow should always be: Onboarding → Value → Paywall.

Show them what your app can do first. Let them feel the benefit. Then ask for money.

Hard paywall or soft paywall?

Hard paywall — users can't access any content or features until they subscribe.
Soft paywall — users can access some content or features for free, but need to subscribe for full access.

Hard paywalls convert better but can lead to higher churn if users don't understand the value.
Also I advise you to always test. Hard paywall doesn't work for every app. Data is always king.
I personnaly prefer freemium but if you have a strong onboarding that shows the value, a hard paywall can work well too.

Show your paywall during onboarding

This is a controversial one. Many developers think they need to wait until users have "discovered" the app.

Here's the thing most developers get wrong.

They wait for day 3 or day 7 to show the paywall. Thinking the user needs time to "discover" the app.

Most of your paid users will come from the first session.

Users who never see your paywall never convert. So show it during onboarding, right after you demonstrated value.

Don't wait. Don't hope they'll come back. Show the paywall on first use.

When you go at a restaurant and the waiter comes to your table, do you say "I need to discover the menu first, come back later"? No. You look at the menu, see the value, and decide if you want to order. It's the same with your app.

I wrote a full article on how to create a good paywall if you want to go deeper on this.

Freemium — let users try before they pay

Freemium is simple.

And hard.

Give enough value for free to hook users. Gate enough to make them want to pay.

The hard part is finding the balance.

What to gate

Features — free users get basic features, paid users get advanced ones
Usage limits — free users get 5 exports per month, paid get unlimited
Content — free users see previews, paid users get full access
Remove ads — if you use ads, let users pay to remove them

Ex :

Spotify does it well. Free with ads. Paid without. Simple and effective.

Conversion benchmarks

Typical freemium conversion is 2-5%.

Good is 5-10%. If you're above 10% you're doing great.

The key to conversion? A strong onboarding that shows the value of your app before users decide to stay or leave.

In-app purchases, ads, and other models

In-app purchases

Two types:

Consumables — credits, tokens, coins. Users buy them, use them, buy more. This works great for AI apps (token-based), games, and content apps.
Non-consumables — unlock a feature or content forever. One-time purchase inside the app.

If you're building an AI-powered app, token-based IAP is a very natural fit.

Users pay for what they use. No commitment. Low friction.

Check out the in-app purchase template if you want to see how this works in practice.

Let's be honest.

Ads are the default for lazy monetization.

If your app solves a real problem, subscriptions or freemium will always earn more per user.

Ads make sense when you have high volume and low engagement — utility apps, games, content aggregators.

Rewarded ads are the exception. Users watch a video in exchange for a bonus or feature unlock. This works well as a complement to IAP or freemium.

But don't build your entire business on ad revenue. It's volatile and you need massive scale.

One-time purchase

The paid upfront model is dying for most categories.

Users expect to try before they pay. And a $4.99 upfront purchase has a much lower lifetime value than a $4.99/month subscription.

It still works for specific utilities and tools where users need the app once or occasionally. But for most apps, skip this model.

App ideas to make money in 2026

The best app ideas solve a specific problem for a specific group of people.

The more niche and specific, the better.

Ex:
Running app -> Running app for women -> Running app for pregnant women...

Don't try to build the next Instagram. Build something useful for 1,000 people who are willing to pay.

Here are some ideas that work well with a subscription or freemium model:

AI-powered meal planner — generate weekly meal plans and grocery lists based on preferences and budget. Health niche is huge and people pay for convenience. Subscription model.
Niche tracker — not a generic one. One for new parents tracking baby sleep. Or for musicians tracking practice sessions. The more specific, the more people pay. Freemium.
B2B inspection or checklist app — this is a goldmine. Businesses pay without thinking twice. Construction inspections, restaurant health checks, fleet maintenance logs. Subscription.
AI writing assistant for a specific niche — not a general ChatGPT wrapper. One for real estate agents writing listings. Or for teachers creating lesson plans. Token-based IAP or subscription.
Budget tracker for freelancers — free basic tracking, paid for tax reports and invoice generation. Freemium.
Digital wellness coach — screen time tracking with actionable suggestions. Guided digital detox challenges. Subscription. (careful this is a saturated niche, but if you find an original concept there is always some space. People love to try new ideas in this category)

The common thread?

All of these can be built and launched in weeks if you don't waste time building auth, payments, and infrastructure from scratch.

How to make money from mobile apps — checklist

After seeing many apps succeed and fail, here's what actually matters.

Pick a niche with willingness to pay. B2B pays more than B2C. Health pays more than entertainment. Niche pays more than generic.
Choose your monetization model before writing code. If you don't know how you'll make money, don't start building.
Build your paywall into the MVP. Not after launch. Not in v2. In the first version. Monetization is not a feature — it's the foundation.
Track events from day one. Which screens do users visit? Where do they drop off? What triggers a purchase? You need this data from the start. Read more about managing events in your app.
Forget ASO in 2026. You can't rely on App Store search to get discovered anymore. The stores are saturated. Everyone is optimizing for the same keywords. ASO alone won't save you.
Test your market with ads. Before building for months, spend $50-100 on Meta or TikTok ads pointing to your App Store page. If you can get your first 100 installs cheaply, your idea has legs. If not, pivot before wasting more time.
Launch fast, iterate based on data. Your first version will not be perfect. That's fine. Get it out, see what converts, and improve weekly.

How to create an app and make money — without building everything from scratch

Here's the uncomfortable truth.

Building auth, subscriptions, paywalls, push notifications, onboarding, and analytics from scratch takes 2-3 months minimum.

And that's just the boring stuff. The stuff that has nothing to do with your actual idea.

This is exactly why we built ApparenceKit.

It's a Flutter template that ships with everything you need to monetize your app from day one:

Paywall and subscription management (Apple and Google validated)
In-app purchases
Authentication (email, social, anonymous)
Push notifications
Onboarding flow
Analytics and event tracking

You buy it once, you own the code, and you focus on what makes your app unique.

The developers making money from apps aren't the ones writing the best code.

They're the ones who ship first and iterate fast.

Flutter theme made easy

Gautier 💙 — Tue, 24 Oct 2023 14:24:34 +0000

Flutter provides you with a way to customize your app theme.

It is extremely focused on material design but you can still customize it to fit your needs.

The problem

Flutter provides you with a great theme to let you customize your app.

The problem is when you want to start getting out of material and customize your app theme.

Most designers will want to customize the theme to fit their needs and tastes.

You create your theme directly without any factory.
This means you will have many developers copy-pasting colors throughout the app and the themeData file.

You can't switch the theme without restarting the app (dark/light?).

You don't have a way to set different themes for different platforms.

The good news is that we can fix all of this.

Handling Dark and Light theme

Switching from light to dark mode should be easy.

The best way to do this is to not duplicate your theme but to create a factory that will create the theme from a color palette.

Flutter and Material provide you with a nice logical way to handle an app theme.
Every color is an 'on' color.

Meaning that if you have a white background you should have a black text color.

Switching from light to dark should only rely on switching some colors.

You should not have to handle if case in your code.

Limit the number of colors

The more colors you have the more difficult it will be to maintain your app.

Simplicity is oftenly the best way to go.

Instead of having primary, secondary, accent, secondaryAccent, ...

Try making your app with one or two colors.

The more colors you incorporate, the more challenging it becomes to maintain your app.
Simplicity is often the best approach. Instead of using primary, secondary, accent, secondaryAccent, and so forth, consider designing your app with just one or two colors.

(Please note that black, white, and greys are exceptions and are not considered as colors.)

For example, you can check some of the most popular apps.

Facebook, Instagram, Twitter, Youtube, ...

They don't use a lot of colors.

Creating a theme factory

As we want to create our theme for maybe different platforms or different color palettes we will create a factory.

abstract class ApparenceKitThemeDataFactory {
  const ApparenceKitThemeDataFactory();

  ApparenceKitThemeData build({
    required ApparenceKitColors colors,
    required ApparenceKitTextTheme defaultTextStyle,
  });
}

This factory will take a color palette and a default text theme and will create a theme.

The default text theme contains the default text style and fonts for all our text.
As the colors I also recommend to limit the number of fonts you use.

Our designer at Apparence tend to limit his usage to 2 fonts.

(There is some website that give you inspirations for 2 fonts that go well together...)

Using our factory

Now that we have our factory we can use it to create our theme.

class UniversalThemeFactory extends ApparenceKitThemeDataFactory {
  const UniversalThemeFactory();

  @override
  ApparenceKitThemeData build({
    required ApparenceKitColors colors,
    required ApparenceKitTextTheme defaultTextStyle,
  }) {
    return ApparenceKitThemeData(
      colors: colors,
      defaultTextTheme: defaultTextStyle,
      materialTheme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: colors.primary).copyWith(
          surface: colors.surface,
          onSurface: colors.onSurface,
          background: colors.background,
          onBackground: colors.onBackground,
          primary: colors.primary,
          error: colors.error,
        ),
        elevatedButtonTheme: elevatedButtonTheme(
          colors: colors,
          textTheme: defaultTextStyle,
        ),
        inputDecorationTheme: inputDecorationTheme(
          colors: colors,
          textTheme: defaultTextStyle,
        ),
        textTheme: textTheme(
          colors: colors,
          defaultTextStyle: defaultTextStyle,
        ),
      ),
      ...
    );
  }

As you can see we are using the color palette and the default text theme to create our theme.

Now changing colors or text style won't be done here.

We have defined our own color palette and default text files separetly.

Providing our theme through the app

As we want to access our theme from anywhere in our app we will use an InheritedNotifier.

This will allow us to access our theme from the BuildContext.

But also to switch the mode of our theme without restarting the app.

/// We use this to access the theme from the BuildContext in all our widgets
/// We don't use riverpod here so we can get the theme from the context and regular widgets
class ThemeProvider extends InheritedNotifier<AppTheme> {
  const ThemeProvider({
    super.key,
    super.notifier,
    required super.child,
  });

  @override
  bool updateShouldNotify(covariant InheritedNotifier<AppTheme> oldWidget) {
    ...
  }

  static AppTheme of(BuildContext context) =>
      context.dependOnInheritedWidgetOfExactType<ThemeProvider>()!.notifier!;
}

Using our theme ThemeProvider

Now that we have our ThemeProvider we can use it in our app.

It will be above our MaterialApp.

class MyApp extends StatelessWidget {
  const MyApp({
    super.key,
  });

  // This widget is the root of your application.
  @override
  Widget build(BuildContext context, WidgetRef ref) {
    return ThemeProvider(
      notifier: AppTheme.uniform(
        themeFactory: const UniversalThemeFactory(),
        lightColors: ApparenceKitColors.light(),
        darkColors: ApparenceKitColors.dark(),
        textTheme: ApparenceKitTextTheme.build(),
        defaultMode: ThemeMode.light,
      ),
      child: Builder(builder: (context) {
        return MaterialApp(
          title: 'Flutter Pro Starter Kit',
          initialRoute: 'home',
          theme: ThemeProvider.of(context).light,
          darkTheme: ThemeProvider.of(context).dark,
          themeMode: ThemeProvider.of(context).mode,

If you don't want to use dark mode you can just remove it.

This way we can access our theme from anywhere in our app.

Using for example

ThemeProvider.of(context).current

or still using the regular Theme.of(context)

Theme.of(context).textTheme.headline1

Creating theme shortcuts

As we want to access our theme from anywhere in our app we will create some shortcuts.

This will allow us to access our theme from the BuildContext.

But also to switch the mode of our theme without restarting the app.

extension ThemeExtension on BuildContext {
  // access the theme from anywhere in the app using context.theme  
  ApparenceKitThemeData get theme => ThemeProvider.of(this).current;
  // access the color palette from anywhere in the app using context.colors  
  ApparenceKitColors get colors => ThemeProvider.of(this).current.colors;
  // access the text theme from anywhere in the app using context.textTheme
  ApparenceKitTextTheme get textTheme => ThemeProvider.of(this).current.textTheme;
  // access the theme mode from anywhere in the app using context.themeMode
  ThemeMode get themeMode => ThemeProvider.of(this).mode;
  // toggle the theme mode from anywhere in the app using context.toggleTheme
  void toggleTheme() => ThemeProvider.of(this).toggle();
}

Conclusion

There is tons of things to say about handling theme from design to code.

multiplatform theme, gradients, shadows, ...

I hope this article will help you to get started with creating a great multiplatform theme.

This way of handling theme is the one we use at Apparence and we included it in our starter kit.

Our Flutter Template is Here!

Gautier 💙 — Fri, 13 Oct 2023 12:28:23 +0000

In the dynamic realm of mobile app development, speed, efficiency, and feature-rich applications are the benchmarks of success.
If you're part of the ever-growing Flutter community, brace yourself for a game-changing announcement!
I am thrilled to introduce our "Flutter Template," a comprehensive solution designed to catapult your app development journey to new heights.
Whether you're an experienced developer or just beginning your Flutter adventure, this template is your passport to creating Flutter apps faster and with unprecedented ease.

Why use a Flutter Template?

Instead of reinventing the wheel with every project, a Flutter Template allows you to jumpstart your development.
Whether you're a seasoned developer looking to accelerate your workflow or a newcomer seeking a structured approach to Flutter.

What's included in the Flutter Template?

The ApparenceKit Flutter Template is a comprehensive solution that includes everything you need to build a Flutter app.

1. Notifications Integration

What's a mobile app without notifications?

The ApparenceKit Flutter Template includes a fully integrated notifications system that allows you to receive push notifications.
It's easy to set up and works with both Android and iOS.
We handle device registration, message handling, and more, so you can focus on building your app.

2. Authentication

Authentication is a critical component of any app, and the ApparenceKit Flutter Template makes it easy to add authentication to your app.
You can choose between email/password authentication or social login with Facebook, Google, or Twitter.
We handle all the heavy lifting so you can focus on building your app.

Bonus: we also provide a CLI to switch between firebase and custom backend.

3. Environments Made Simple

Enjoy a seamless development journey with predefined environments for dev, staging, and production, streamlining your workflow.

4. In-App Rating and Reviews

Gather valuable user feedback and enhance your app's ratings with our integrated in-app rating and review features.
Asking for feedback is a great way to improve your app and increase user engagement.
But you have to do it right.

For example you don't want to ask for feedback too often or at the wrong time.
Apple and Google have strict guidelines on how often you can ask for feedback.
So you should ask for feedback at the right time and in the right way.

We handle all of this for you.
We provide a customizable in-app rating and review system that is easy to integrate into your app.

5. Monetization Made Easy

Handling subscriptions on iOS and Android can be a pain.
You have to deal with different APIs, different payment methods, and different rules.
We made a customizable subscription system with ready-to-use screens.
You can easily integrate it into your app and start monetizing it.

As this is a template you can customize it to your needs.
A complete documentation is available to help you with that.

6. CI/CD

Continuous Integration and Continuous Delivery (CI/CD) is a software development practice that enables developers to build, test, and deploy code changes more frequently and reliably.
We provides a complete CI/CD guide and Gitlab templates for your Flutter app.
We used a custom Gitlab runner for 4 years to build and deploy all our apps. This template is the result of this experience.

Github templates are also available but not as complete as the Gitlab ones.
(Basically we don't build and deploy on stores with Github).
But a dependabot configuration is available to keep your dependencies up to date.

7. Complete documentation

We provide complete documentation to help you with the template.
It includes a getting started guide, notifications setup guide, social auth setup guide, how to write great tests, release on stores guide...
And tons of others.

Conclusion

In the competitive world of app development, our Flutter Template is your secret weapon, allowing you to create exceptional apps quickly and efficiently.
Whether you're working on a personal project or developing for clients, our feature-rich template equips you with the tools and support you need to thrive.
Don't miss this opportunity to revolutionize your Flutter app development.

Start using our template today and unleash the full potential of your Flutter creations!

Note: if you aren't satisfied with the kit, reach out and you'll get a full refund. No questions asked.

Flutter - In-app education plugin

Gautier 💙 — Wed, 10 Nov 2021 09:43:57 +0000

Close the gap between content and adoption. Provide your users a way to know what they don't know.

Some months ago we created Pal.
The vision was to create a complete solution to help developers and market team create better app experience.
We went a bit too far so today we goes back to a simpler solution. This is the first step of this rework.

Introducing Pal widgets

Pal widgets is an open source plugin that lets you just create helper without any server. This is a complete open source plugin just aiming giving you designed widgets.
When Pal required you to use a no code solution to create helpers. Pal-widgets let you make helpers with code anywhere you want in your app.

Hole Anchored Helper

This is the first widget from Pal that is now available in Pal widgets plugin. This lets you create a designed tuto (inspired by google tutorials) which creates a fullscreen overlay with just a hole above the widget you wants to explain.
Nearly everything is optional so you can create the experience you want.
Here is an example of anchored helper that will pop out when user tap on the hole.

Here is the widget code

Pal widget hole anchored helper without buttons. You can freely choose to show or not buttons or customize the onTapAnchor action.

Here is a demo of a tuto with 2 buttons.

Wants to change the design ?

You can create your own anchored helper factory
But we wants to go further and let you the ability to way more customize your tuto.

What's next

First we are all open for your suggestions on this project. The goal of pal-plugins is to provide you a complete set of widgets to create your experience.
Next we are looking to create more design, more customization, more widgets with the same vision.
Hope you enjoy and creates amazing onboarding experience within your app.
Share with us what you create.
We loves to see what you do using Pal.

Package links

Pub dev package link
Github repository

Pal - our flutter no code editor for in app messages is out

Gautier 💙 — Fri, 15 Jan 2021 09:19:12 +0000

Ever wanted to show an onboarding without code ? Show a marketing message on a click of button ? Now you got pal.

Who has never been frustrated with having to code, repost on the stores just to display help or a personalized message on their application?

50% of our uninstall come from the frustration of the first application opening

That’s a fact, we love to get introduced to the new things. Even more if this introduction seems personalized.
Guiding user through your app makes the user feel you are helping him and you are concerned about him.
That’s exactly why there is people in stores to help you choose and get advices. So why not apply this to your mobile application ?

Guide users through their first experience

Some of us call this onboarding. But a good onboarding is not just at the beginning. You can makes some anywhere on your app (after user made an action, the first time he goes to a page, after new update…).
Hubspot breaks down retention into three phases: short-term retention, mid-term retention, and long-term retention. According to their research, the biggest drop-off in usage happens during the short-term retention period between Week 0 and Week 1. Retention drops nearly 75 percentage points down to just above 25% in a single week.
Imagine if you could keep them ?

Here is a perfect way to introduce our new users, let’s show him what he can do and what we wants him to do with our app.  Of course we won’t show him this again, this won’t bother him again.

Pal is helping you doing this without having to code anything.

Guide user after important updates

How many of your users knows why their app changes or that you worked for 1 month to give them new amazing features ?
If you knew, this could certainly depress you…

What about just show them the big lines of your update when they re-open their app?

And of course doing this without code

Keep your user all along

You guided your users through his first experience. He is completely happy with your app. What about keeping his feeling that you are concerned about him ?
Yes that’s what we are aiming with personalized messages. You can keep showing some messages less frequently to your best users using Pal.

Personalized messages

Your worked for month to create a really sexy app so we know you want this to stay perfect. You got your fonts, colors, sizes…
Also for all messages you wants a special experience so we made different types of messages experiences.

Forem: Gautier 💙

Send Meta Ad Events from Flutter with AEM Support

The iOS 14+ problem nobody talks about

Why I built facebook_flutter_sdk

Setup

1. Install the package

2. Get your Facebook credentials

3. Android configuration

4. iOS configuration

5. Request ATT permission (iOS)

Sending events

Initialize the SDK

Log custom events

Log purchases

Log add-to-cart events

Set user data for advanced matching

RevenueCat integration

Event deduplication with Conversions API

Why you probably don't need an MMP

Common mistakes

Not requesting ATT early enough

Forgetting the eventId on purchases

Volume of Advertiser Tracking Enabled parameter out of range

Go further with Meta Ads

Stop flying blind

Automate Your Flutter iOS Deployment with Fastlane

Why Fastlane for Flutter iOS deployment

Prerequisites

Step 1 — Set up App Store Connect API key

Step 2 — Organize your metadata

Handling localized release notes

All Apple App Store locales by priority

Step 3 — Create the "release new version" lane

Step 4 — Create the deploy lane

The full Fastfile

No reasons to not have metadata for all locales

My typical deploy workflow

What about first release?

Tips and common pitfalls

Store your API key securely

Use force: true carefully

Keep metadata in version control

Handle missing locales gracefully

Export compliance

Stop deploying manually

How to Monetize a Mobile App — 6 Proven Strategies That Actually Work

Before monetization: the 3 pillars of a successful app

Check if people actually use your app

Build a great onboarding flow

How to monetize apps: 6 models that work

Subscriptions — the king of app revenue

Weekly, monthly, or yearly?

💡 Test your prices. Don't guess.

Show value before the paywall

Hard paywall or soft paywall?

Show your paywall during onboarding

Freemium — let users try before they pay

What to gate

Conversion benchmarks

In-app purchases, ads, and other models

In-app purchases

Ads

One-time purchase

App ideas to make money in 2026

How to make money from mobile apps — checklist

How to create an app and make money — without building everything from scratch

Flutter theme made easy

The problem

Handling Dark and Light theme

Limit the number of colors

Creating a theme factory

Using our factory

Providing our theme through the app

Using our theme ThemeProvider

Creating theme shortcuts

Conclusion

Our Flutter Template is Here!

Why use a Flutter Template?

What's included in the Flutter Template?

1. Notifications Integration

Use `force: true` carefully