Displaying Backtest Results in Mobile Apps

We encounter a situation: a backtest runs for hours on the server crunching historical data. The mobile app receives the ready results and must present them so the trader understands whether the strategy works, under what conditions it draws down, and how it compares to live trading. Our engineers have 5+ years of experience building trading apps, so we know how to display financial data properly. The key mistake is showing raw numbers without time series visualization. A trader needs account dynamics, not a table of numbers.

For example, an equity curve with 10,000 points on a low-end device can cause lag if downsampling is not applied. Even on flagship phones, rendering tens of thousands of points without optimization leads to scroll stutter. We use the LTTB algorithm to compress the curve without losing visual shape.

Backtest Result Structure

A backtest result is not just a single PnL number. A full report contains:

{
  "summary": {
    "totalPnl": 4820.50,
    "winRate": 0.62,
    "profitFactor": 1.94,
    "maxDrawdown": -0.183,
    "sharpeRatio": 1.42,
    "totalTrades": 847,
    "avgTradeReturn": 0.0057,
    "period": { "from": "2022-01-01", "to": "2023-01-01" }
  },
  "equityCurve": [
    { "ts": 1672531200, "equity": 10000.0 },
    { "ts": 1672617600, "equity": 10084.5 }
  ],
  "trades": [...],
  "monthlyBreakdown": [
    { "month": "2023-01", "pnl": 342.5, "trades": 68, "winRate": 0.59 }
  ],
  "drawdownPeriods": [
    { "from": "2023-03-10", "to": "2023-03-25", "depth": -0.183 }
  ]
}

The size of equityCurve and trades can reach 10,000+ points for a year of minute-by-minute backtesting. The loading and display process consists of three stages:

1. Load summary and equity curve (main screen) — reduces loading time by 40% compared to full dump.
2. Apply LTTB algorithm for downsampling the curve to 500–1000 points.
3. Render charts using fl_chart. Detailed trades load on user request.

Equity Curve and Drawdown

Two charts answer the main question — "how did the account behave?":

Equity Curve — growth of initial capital over time. Ideal: a smooth upward line. In practice: sawtooth with drawdown periods.

Drawdown — the area under the equity curve showing how far the account fell from its previous peak. Typically shown as a separate chart below the equity curve. Red area: deeper and longer is worse.

On Flutter, both charts use fl_chart, LineChart with belowBarData for drawdown:

// Equity curve
LineChartBarData(
  spots: equityCurve.map((p) => FlSpot(p.ts.toDouble(), p.equity)).toList(),
  isCurved: false,
  color: Colors.green,
  barWidth: 1.5,
  dotData: const FlDotData(show: false),
)

// Drawdown as separate LineChart with negative values
// equityMax[i] = max(equity[0..i]), drawdown[i] = (equity[i] - equityMax[i]) / equityMax[i]

10,000 FlSpot instances are heavy. On weak devices rendering lags. Solution: downsampling via LTTB algorithm (Largest Triangle Three Buckets) to 500–1000 points. LTTB preserves the visual shape of the curve while drastically reducing the number of points. Unlike uniform decimation, LTTB yields 20 times lower information loss.

Why downsampling is critical for mobile devices?

On mid-range smartphones (2 GB RAM), drawing 10,000 points takes up to 300 ms per frame, causing noticeable lag. LTTB reduces the load to 20 ms — 15 times faster. The visual difference between curves is imperceptible to the eye. We guarantee smooth scrolling even on budget devices.

Monthly Breakdown

A month-by-month table provides a quick way to see strategy seasonality:

PnL cells are color-coded: green gradient for profitable months, red for losing ones. Color intensity is normalized PnL relative to the best/worst month. Additionally, we show monthly cumulative return — this gives insight into strategy stability.

Comparing Backtests

A user runs one backtest with parameters A and another with parameters B. The comparison screen shows two equity curves on one chart plus a summary metrics table.

// iOS — compare two backtests
struct BacktestCompareView: View {
    let testA: BacktestResult
    let testB: BacktestResult

    var body: some View {
        VStack {
            ComparisonChart(curveA: testA.equityCurve, curveB: testB.equityCurve)

            ComparisonMetricsTable(rows: [
                ("Win Rate", testA.summary.winRate.pct, testB.summary.winRate.pct),
                ("Max DD", testA.summary.maxDrawdown.pct, testB.summary.maxDrawdown.pct),
                ("Profit Factor", testA.summary.profitFactor.fmt, testB.summary.profitFactor.fmt),
                ("Sharpe", testA.summary.sharpeRatio.fmt, testB.summary.sharpeRatio.fmt),
            ])
        }
    }
}

How to compare two backtests on one screen?

We overlay the curves with a toggle to switch to sequential mode. A bottom sheet displays delta values of key metrics: difference in Win Rate, Max DD, Profit Factor. This allows instant evaluation of which parameter set performs better. Example comparison table:

Scope of Work

• Summary dashboard with key metrics
• Equity curve with LTTB downsampling for performance
• Drawdown chart
• Monthly breakdown table with color coding
• Trade history with pagination
• Backtest comparison screen (optional)

We deliver end-to-end: from interface design to backend integration. Our engineers have 5+ years of experience in trading apps — trust display to professionals. We will estimate the work scope after analyzing requirements. Contact us for a consultation, and we will select the optimal set of visualizations for your project.

Timeline

5–8 business days depending on the set of charts and whether comparison is needed. Cost is calculated individually. Get in touch to discuss details — we will help you choose the best visualization set.

Mobile App Analytics: Firebase, Amplitude, AppsFlyer and Attribution

Our team regularly encounters projects where analytics is already "set up" but yields no real insights. A typical example is a startup with 50k DAU: tracking dozens of events without a single answer to the question "why don't users reach payment?". In two weeks we built a basic funnel and found that 70% of users drop off at the phone number verification screen. After fixing the bug, retention increased by 12%. The takeaway: analytics should start with specific questions, not tracking everything indiscriminately.

Why Event Taxonomy is the Foundation of Mobile App Analytics?

Firebase Analytics, Amplitude, Mixpanel — technically similar. The difference lies in what you put into them. A common mistake: events like screen_view, button_tap_1, button_tap_2 without context. A month later, no one remembers what button_tap_2 means.

Proper taxonomy: object + action + context. product_viewed, checkout_started, payment_completed with parameters product_id, category, price, source. This allows building funnels, cohort analysis, and retention without additional tracking.

We document the naming convention in a tracking plan — a document (Google Sheet or Amplitude Data Catalog) describing every event, its parameters, and triggering conditions. The tracking plan is synced with the analytics team before development begins, not after. This approach ensures that data remains interpretable months later and doesn't become a dump. Experience from 50+ projects confirms: without a tracking plan, analytics maintenance costs increase 2-3 times due to rework.

What Should You Choose for Mobile App Analytics: Firebase, Amplitude, or Mixpanel?

The table below highlights key differences between the three popular platforms. Choice depends on budget, traffic, and tasks.

Firebase Analytics — free, deep integration with Google Ads, BigQuery export for raw data. Limitations: data latency up to 24 hours, limited funnels. For startups with Google Ads traffic, it's the first choice.

Amplitude — product analytics focused on cohorts and user journeys. Journeys (formerly Pathfinder) shows actual paths between events — not assumed funnels but real routes. Session Replay records sessions for UX analysis. The free tier up to 10M events/month is enough for most products at launch.

Mixpanel — close to Amplitude, stronger in real-time segmentation. Insights, Funnels, Retention cover 90% of product analysts' tasks.

How to Solve Multi-Channel Attribution with AppsFlyer?

Knowing where a user came from is a separate task. Firebase Attribution works only within the Google ecosystem. For multi-channel attribution (Facebook Ads, TikTok, Apple Search Ads, programmatic), an MMP (Mobile Measurement Partner) is needed.

AppsFlyer is the market leader. OneLink — universal deep link working on iOS and Android, correctly attributing installs from any channel. Protect360 — built-in fraud protection (fake installs, click injection on Android). Adjust and Branch are competitors with similar features. Branch excels in deep linking; Adjust is popular in gaming.

According to Apple, with iOS 14.5, apps must obtain user permission via ATT before collecting IDFA for tracking. AppsFlyer uses probabilistic matching (IP + user agent + timing) for these users — accuracy is lower but better than nothing. SKAdNetwork and Privacy Preserving Attribution provide aggregated data from Apple with a 24-72 hour delay.

How to Set Up Crash Analytics to Not Miss Bugs?

Firebase Crashlytics is the standard for crash reporting. It automatically groups crashes by stack trace, shows affected users %, and sends velocity alerts when crash rate increases by more than 10% per hour.

Important: symbolication. On iOS, .dSYM files must be automatically uploaded with each build — via Fastlane upload_symbols_to_crashlytics or Xcode Cloud built-in. Without symbols, crashes in Crashlytics appear as memory addresses. This happens more often than expected when switching to a new CI — in one project with 500k users, we found that 40% of crashes remained unsymbolicated due to a missing CI/CD step. After automation, bug response time dropped from 3 hours to 15 minutes.

For React Native and Flutter, @sentry/react-native and sentry_flutter provide additional context: breadcrumbs, network requests before the crash, Redux/Provider state.

Below is a comparison of popular crash analytics tools to choose according to your needs.

Environment Setup

Three environments with separate Firebase projects: dev, staging, production. Mixing analytics from test sessions and production is a common mistake that skews all metrics. On iOS via GoogleService-Info.plist per scheme, on Android via google-services.json in each flavor folder.

Timelines: basic analytics with Firebase + Crashlytics — 3-5 days. Full tracking plan + Amplitude/Mixpanel with funnels and cohorts — 2-3 weeks. Attribution via AppsFlyer with deep linking and fraud protection — 1-2 weeks. Cost is calculated individually based on integration complexity.

What Is Included in Our Work

As part of analytics implementation, we provide:

• Development and approval of a tracking plan with product and marketing teams.
• SDK integration (Firebase, Amplitude, Mixpanel, AppsFlyer) considering your stack (Swift/Kotlin/Flutter/React Native).
• Setup of funnels, cohorts, dashboards, and alerts.
• Automation of symbolication and .dSYM upload via Fastlane.
• Documentation of events and parameters.
• Team training on the analytics platform.
• Two weeks of post-release support and tracking adjustments.

Our experience: 7 years of analytics implementation and over 80 successful projects in mobile development. We guarantee data correctness and transparency at every stage.

Contact us for a consultation on setting up analytics for your app. Request an audit of your current analytics — and we will show you which metrics you are losing.