Languages and appearance

The app ships in English only, with no language picker — which strings are ready for translation and how to add a language; the dark default and the Profile light/dark toggle; the portrait lock and the one landscape screen; tablets; and the phone's text size.

7 min readUpdated 26 September 2026mobile, localisation, languages, theme, dark-mode, orientation, tablets, accessibility

The app speaks English, starts in dark mode and stays upright. None of that is a setting in app_config.json or on your server: language comes from the translation files compiled into the build, the theme is the customer's own choice on their phone, and orientation is fixed in the code. This page says what each one does and what it takes to change it.

Language: English, with no picker

The app ships one language, English, and has no language picker. Your website's language settings and translations do not reach it: a customer who uses your website in Spanish sees the app in English.

Only a small part of the app is set up for translation. The translation file, lib/l10n/app_en.arb, holds 52 strings, mostly:

the sign-in and registration screens, with their field labels and validation messages;
a few shared error messages and button words — Retry, Cancel, Confirm and the like;
the Stay informed sheet that asks about notifications after sign-in. Its single Continue button on an iPhone is Flutter's own word, which Flutter translates itself;
the notice shown when a session ends: "Your session has ended. Please sign in again."

Two of the 52 are not shown anywhere: appName (see the note below) and rememberMe, left over from the Remember me box that this release removed from the sign-in screen because it did nothing.

Every other screen — Home, trading, the wallet, Profile, every addon — has its English text written directly into the Dart code. Messages your server sends, such as refusals and error text, arrive in the server's own words.

So adding a translation file today translates the sign-in and registration screens, plus the text inside Flutter's built-in controls (date pickers, the text-selection menu, system dialog buttons), which Flutter translates itself once the language is one the app supports. The rest of the app stays English until its text is moved into the translation files, which is a code change screen by screen.

When more than one language is present, the app follows the language set on the phone. There is still no picker inside the app.

Adding a language

Copy the English file. In lib/l10n/, copy app_en.arb to app_<code>.arb — app_es.arb for Spanish, app_fr.arb for French. Change the "@@locale" line at the top from "en" to the same code.
Translate the values. Keep every key as it is, and keep placeholders in braces, such as {count} or {terms}, exactly as they appear. The entries starting with @ describe each string for translators; they are not shown to anyone.
Generate the code. From the project root:
```
flutter gen-l10n
```
The project has generate: true in pubspec.yaml, so flutter pub get, flutter run and flutter build run the same step. The generated files are written into lib/l10n/ next to the translations and belong to your source; the new language joins the app's supported list automatically.
Look for gaps. Keys missing from your file are listed in l10n-untranslated.json in the project root. A missing key shows its English text rather than failing.
iOS: declare the language. Flutter's internationalisation guide also asks iOS apps to list their languages under CFBundleLocalizations in ios/Runner/Info.plist. The project's Info.plist has no such entry today, so add one listing English and your new language.
Build and check on a phone set to the new language.

The translation file carries an appName string, but nothing in the app reads it. Your app's name comes from appName in app_config.json — see Branding.

Store listings are separate. The languages of your App Store and Google Play listings are set in App Store Connect and Play Console, and nothing in the package produces listing text.

Theme: dark first, one toggle

On first launch the app starts in dark mode, whatever the phone's own light/dark setting.

The customer switches between light and dark with one button: on Profile (the gear icon at the top right of Home), the sun/moon icon in the top bar. A sun means the app is dark and a tap turns it light; a moon means the reverse. The choice is saved on the phone and kept across restarts. It belongs to that phone, not to the account, so it does not follow the customer to another device or to your website.

The app offers no "follow the phone" option, and your website's theme settings do not reach it. The phone's status and navigation bar icons follow the app's theme rather than the phone's.

The dark default is one line of code, not a setting: getSavedTheme() in lib/features/theme/data/datasources/theme_local_datasource.dart returns AppThemeType.dark when nothing has been saved. Change it to AppThemeType.light for a light first launch. _ThemedApp in lib/main.dart also uses the dark theme until the saved choice has been read (ThemeData currentTheme = AppThemes.darkTheme;); change that line too. Carry both edits forward when you take a new source release.

Colours

Your brand colours come from app_config.json — primaryColor, buyColor, sellColor and accentColor — and apply to both themes. Buy/sell and price up/down follow buyColor and sellColor; errors stay red (#FF5A5F) and success stays green (#0ECE7A); text on primary-coloured buttons switches to dark on a very light primary. The exception in this release is the Transfer screens and the wallet's Deposit screens: they still take their success and error colours from buyColor and sellColor, and some of their buttons keep white text on the primary colour. The keys, their formats and defaults are on Branding.

Orientation: portrait, except the full-screen chart

The whole app is locked to portrait. The one exception is the full-screen chart: the full-screen button on a market's chart turns the phone to landscape and hides the system bars. Closing it returns to portrait.

The lock is applied by the app when it starts, not by the native projects. The iOS project still declares landscape for iPhone and all four orientations for iPad, and the Android project sets no orientation. That matters only if you change the code.

How the portrait lock behaves on an iPad — which lets apps run side by side with others — has not been confirmed on a device.

Tablets

The app installs on iPads, Android tablets and foldables. It has no tablet layout: every screen is the phone layout stretched to the width, except the futures trading screen, which puts the order book and the order form side by side when the screen is wider than 600 logical pixels.

The iOS project is built for iPhone and iPad (the Runner target's TARGETED_DEVICE_FAMILY is 1,2), so the App Store treats it as an iPad app as well, and App Store Connect will want iPad screenshots. If you would rather publish for iPhone only, set that build setting to 1 in Xcode — and set it again whenever a new source release replaces the Xcode project.

The app follows the phone's text-size setting on every screen; nothing caps it. The only text that ignores it is the letters drawn in place of a missing coin logo. How every layout copes at the very largest sizes has not been checked on a device, so try your busiest screens at the largest setting before you publish.

Screen-reader support is mostly Flutter's default reading of text and buttons; few controls carry labels of their own.

What it deliberately does not do

It does not offer a language picker, and does not follow your website's language.
It does not translate most screens yet. Apart from sign-in, registration and a few shared messages, the text is fixed English.
It does not follow the phone's light/dark setting. Dark first, then the customer's own choice.
It does not rotate, apart from the full-screen chart.
It does not lay out for tablets, apart from the futures screen.