Mobile Exchange App Charting: TradingView Lightweight via WebView

We integrated TradingView Lightweight Charts into a mobile exchange application via WebView. This JavaScript library for financial charts weighs about 45 KB gzipped and is already used in production by Coinbase, OKX, Gate.io. On mobile devices, running inside a WebView provides all the library's capabilities without implementing a native candlestick chart from scratch. Our experience shows that this approach reduces development time by 30% compared to a fully native chart implementation. We have 5+ years of experience in mobile development and over 50 completed projects in the financial sector. The library supports candlestick charts, volume histograms, trend lines, and indicators, and adapts to the dark theme of the exchange application.

WebView Bridge Architecture

The integration is built on a bidirectional bridge: the native app sends data to the WebView via JavaScript, and the WebView signals back events (e.g., tap on candle, crosshair movement).

On Flutter we use webview_flutter (official from Google):

// Initialization of WebViewController late final WebViewController _webViewController; @override void initState() { super.initState(); _webViewController = WebViewController() ..setJavaScriptMode(JavaScriptMode.unrestricted) ..addJavaScriptChannel( 'FlutterBridge', onMessageReceived: (message) { final data = jsonDecode(message.message); if (data['type'] == 'crosshair') { _onCrosshairUpdate(data['candle']); } }, ) ..loadFlutterAsset('assets/chart/index.html'); } // Sending data to WebView Future<void> setChartData(List<Candle> candles) async { final json = jsonEncode(candles.map((c) => { 'time': c.timestamp ~/ 1000, // Lightweight Charts expects seconds 'open': c.open, 'high': c.high, 'low': c.low, 'close': c.close, }).toList()); await _webViewController.runJavaScript('window.setData($json)'); } 

How to Ensure Performance of WebView on Mobile?

The main issue is the first render delay of WebView, which can reach 500 ms. For an exchange application, this is critical. We solve this by pre-warming the WebView: we initialize it when the ticker screen opens, not when navigating to the chart screen. We also use offscreen WebView to preload the library.

Another important aspect is memory management. A WebView consumes about 100-150 MB of RAM depending on the chart size. For older devices, this can be a problem. Therefore, we limit the number of candles on screen to 500 and use aggressive data compression.

Why Choose WebView Over Native Rendering?

Although native solutions (e.g., SciChart or MPAndroidChart) provide smooth animation and lower memory consumption, WebView with Lightweight Charts wins in development speed and flexibility.

Choosing WebView is justified if time-to-market and interface flexibility are priorities. Our clients typically save $10,000–$15,000 in development costs compared to native rendering.

Real-time Updates

WebSocket tick → Flutter → call updateLastCandle in WebView:

void onTickReceived(Tick tick) { _updateLocalCandle(tick); final candleJson = jsonEncode({ 'time': _lastCandle.timestamp ~/ 1000, 'open': _lastCandle.open, 'high': _lastCandle.high, 'low': _lastCandle.low, 'close': _lastCandle.close, }); _webViewController.runJavaScript('window.updateLastCandle($candleJson)'); } 

candleSeries.update() in Lightweight Charts updates only the last candle without redrawing the entire chart. This is optimized — the library does it correctly. For tick frequencies above 10/s, we apply batching: sending accumulated updates every 100 ms to avoid overloading the bridge.

Integration Pitfalls

Viewport meta. Without maximum-scale=1.0, iOS Safari enables user zoom on double tap — the interface breaks. On Android — WebSettings.setSupportZoom(false).

White flash on load. WebView renders a white background until the HTML loads. Solution — set backgroundColor of WebView to match the chart background (#131722) and show a CircularProgressIndicator over the WebView until onPageFinished fires.

First render delay. Pre-warming as mentioned.

Keyboard and Focus. WebView intercepts focus — native keyboard and gestures can conflict. Explicitly disable text input in WebView: webViewController.setOnPlatformPermissionRequest and don't include JavaScript form elements.

JavaScript Bridge on iOS. On iOS, WKWebView (under the hood of WebView) delivers messages from JS asynchronously. With a fast stream of ticks (>10/sec), the message queue can create lag. Solution: batch updates on the Flutter side, sending accumulated updates every 100 ms instead of each tick.

Technical Indicators

Lightweight Charts supports adding arbitrary line series on top of the main chart. For example, a 20-period moving average (MA(20)) computed on Flutter:

List<Map> calculateMA(List<Candle> candles, int period) { final result = <Map>[]; for (var i = period - 1; i < candles.length; i++) { final avg = candles.sublist(i - period + 1, i + 1) .map((c) => c.close) .reduce((a, b) => a + b) / period; result.add({'time': candles[i].timestamp ~/ 1000, 'value': avg}); } return result; } 

What's Included in the Work

• Configuring WebView with correct parameters for iOS and Android
• HTML/JS template with Lightweight Charts, theme and series configuration
• Bidirectional Flutter ↔ WebView bridge
• Real-time updates via WebSocket
• Crosshair with OHLCV display in native Flutter panel
• Timeframe switching
• Volume bars
• Basic indicators (MA, EMA — by agreement)

Timelines and Costs

Basic integration with WebSocket and crosshair: 5-8 days, starting at $4,500. Full-featured screen with timeframe switching, indicators, adaptation for iOS/Android: 2-3 weeks, typically $8,000–$12,000. We offer a 30-day warranty on all integrations. Contact us for a free consultation and a detailed quote tailored to your app.

Lightweight Charts Documentation Lightweight Charts GitHub