Customization

floot create my_app --org com.acme already wrote your name into more places than you would guess: the Android package, the iOS bundle identifier, the deep-link scheme, the window titles, the "from" address on transactional emails. What it could not invent is everything with a picture or a lawyer attached, the icon, the splash screen, the logo and the two legal documents are still placeholders, and this page is about replacing them.

The app name

Two forms of the name are in circulation: the Dart-style package name you typed (my_app) and the human-facing display name (My App). floot create writes the display name into every platform's own idea of an application name at generation time — it defaults to the title-cased project name, and --display-name "My App" overrides it:

floot create my_app --display-name "My App"

There is no floot rename, so changing it after generation means editing the files below by hand. Everything in the first group is already correct in a freshly generated project; the table is what to edit if you change your mind.

The rest of the name-shaped fields identify the build, not the app, and stay derived from the package name — floot create deliberately leaves them alone:

The support address is not covered by any of this

--org com.acme gives you support@acme.com and noreply@acme.com, which are plausible enough to slip through review and wrong unless you actually own that domain. Open both regardless of what you did with the name:

export const appName = 'My App';
export const supportEmail = 'support@myapp.com';

App icon

dart run flutter_launcher_icons

Splash screen

Same story: floot create already ran flutter_native_splash:create, so the native splash exists. It reuses the icon sources rather than introducing new ones: assets/icons/app_icon_transparent.png everywhere, and assets/icons/android/android_app_icon_foreground.png for the Android 12+ splash API, which insists on a foreground layer it can mask into a circle.

flutter_native_splash:
  color: '#ffffff'
  color_android: '#ffffff'
  color_dark_android: '#111111'
  color_ios: '#ffffff'
  color_dark_ios: '#111111'
  image: 'assets/icons/app_icon_transparent.png'
  android_12:
    color: '#ffffff'
    icon_background_color: '#ffffff'
    image: 'assets/icons/android/android_app_icon_foreground.png'
    color_dark: '#111111'
    icon_background_color_dark: '#111111'
    image_dark: 'assets/icons/android/android_app_icon_foreground.png'
  web: false

Then regenerate:

dart run flutter_native_splash:create

Logo

The logo exists twice, because two different runtimes need it and neither can reach the other's copy. The Flutter app loads it from its bundled assets; the transactional email templates cannot bundle anything, so they reference a publicly readable URL served by Supabase Storage.

Replace both. If you keep the filename and the .svg extension, that is the whole job, nothing else needs editing.

If you change the filename or format

Two constants name the file, one per runtime.

final class AppAssets {
  const AppAssets._();

  /// The logo of the app.
  static const String logo = 'assets/app/logo.png'; // was logo.svg
}

export abstract class Assets {
  /** App logo */
  static readonly LOGO = `${env.SB_STORAGE_URL}/public/assets/app/logo.png`;
}

Storage seeds

supabase/storage_seeds/assets/ is the local contents of the public assets bucket. supabase/config.toml points the bucket at it:

[storage.buckets.assets]
public = true
file_size_limit = "2MiB"
allowed_mime_types = ["image/png", "image/jpeg", "image/svg+xml"]
objects_path = "./storage_seeds/assets"

Three objects ship in it:

Two constraints in that config bite quietly. allowed_mime_types rejects anything that is not PNG, JPEG or SVG (a WebP logo is refused at seed time, not at render time), and file_size_limit caps each object at 2 MiB.

supabase stop --no-backup && supabase start

Legal documents

A new project ships a privacy policy and terms of use written for a fictional company.

You have two ways to present them, and the choice changes the user experience more than you would expect.

Option 1: bundled Markdown (the default)

Two Markdown files, loaded from the app bundle and rendered in a dialog.

This is the mode that gives you a consent moment. When the user taps Terms of use or Privacy policy under the sign-up form, on the paywall or in the feedback composer, the document opens in a dialog that is deliberately not dismissible by tapping outside it, and whose only action is labelled Confirm. Reaching the app again requires pressing that button.

That is the whole of the mechanism, so be clear-eyed about it: the dialog is a deliberate friction point, not a recorded agreement. Nothing is written down, and sign-up is not blocked on having opened it. The Account → About entries use the same documents through an ordinary dismissible dialog, because they are reference material rather than consent.

Option 2: hosted URLs

Set either variable in the app's .env.local and that document is fetched from your website instead of the bundle:

# The URL of the hosted terms of use document.
TERMS_OF_USE_URL="https://myapp.com/terms"
# The URL of the hosted privacy policy document.
PRIVACY_POLICY_URL="https://myapp.com/privacy"

The upside is real: legal text you can correct without shipping a build.

Three more behaviours worth knowing before you set these:

• The choice is per document. Set PRIVACY_POLICY_URL and leave TERMS_OF_USE_URL empty and you get exactly that: a browser view for the privacy policy, the consent dialog for the terms. An empty value means "bundled", and that is the shipped default for both.
• A bad URL fails loudly, it does not fall back. The value must parse as an http or https URI. Anything else, a typo, a mailto:, a bare myapp.com/terms, shows an error toast and opens nothing. It never quietly reverts to the bundled document.
• Release builds read .env, not .env.local. If you set these for production, set them in .env too, or your store build will show the placeholder documents. See Building for release.

Where the links appear

Four places, so one edit is visible in all of them: under the sign-up form and on the paywall (both documents), in the feedback composer (privacy policy only), and in Account → About (both, as permanent entries).

What's next?