Devarsh Panchal

A candle chart in Flutter falls apart at scale. Every repaint walks the layer tree, so tens of thousands of candles with continuous pan and zoom drops frames. I hit this wall building a trading app, fixed it there with CustomPainter, then built the version that does not need the workaround.

• One C++ engine drives both platforms. Metal and MetalKit on iOS with shaders compiled to a .metallib at build time, GLES3 and GLSL ES 3.0 on Android through JNI, both submitting batched vertex buffers instead of per-primitive Canvas calls
• Exactly one MethodChannel call exists in the whole package: getEngineHandle, once per view, so Dart can attach the FFI engine. After that no chart data touches a platform channel, and there is no EventChannel at all
• Bulk history goes over dart:ffi as a Float64List of six contiguous doubles per candle, so a hundred thousand bars land in native memory without paying per-bar codec cost
• Live ticks stream through updateLivePrice into rolling one-minute buckets, with a price tracer drawn as a GPU line primitive and a Y-axis badge projected into screen space so it stays aligned through pan and zoom
• The native axis, legend and tooltip overlay polls engine revisions rather than having overlay state pushed over a channel on every label change
• Candle, line and area series, and no Material import required. The Dart side depends on ffi and the Flutter SDK, nothing else
• The README states the honest limit: the CPU still runs viewport math, input, overlay text and vertex building. Nothing here is zero CPU, the win is not paying Dart Canvas repaints per frame

Android · iOSDart FFIC++MetalGLES3KotlinSwift

Google abandoned Android File Transfer years ago, and the alternatives want a cloud account for a cable you already plugged in. Moving a file off your own phone should not require an upload.

• Two transports behind one contract. USB over MTP is native Swift against libmtp, Wi-Fi over FTP is pure Dart, and both implement the same six commands: listDirectory, pushFile, pullFile, deleteRemote, makeRemoteDir, remoteFreeSpace
• Both emit identical transferProgress, transferDone and devicesChanged events into a single merged stream, so the file browser and the transfer queue never know or care which transport is live
• The phone-side FTP server is a hand-written FTP engine in Kotlin, shipped as a companion app rather than depending on whatever the user already installed
• FTP is a deliberate choice, not a shortcut. It is the most widely supported phone-side protocol and its raw binary data channel is the fastest thing available for bulk transfer
• Neither path needs ADB or Developer Options. Plug in and set the phone to file transfer, or stay on the cable-free path over your own LAN
• Finder drag and drop both directions, recursive folder upload, and a queue with live speed, cancel, and queued or parallel modes
• Entirely local. No account, no cloud, no telemetry

The Dart Socket.IO clients I tried could not listen to messages emitted into a room, and they parsed frames on the main isolate, so a busy socket showed up as jank.

• Wraps the official Socket.IO client libraries on Android and iOS rather than reimplementing the protocol in Dart, so it tracks whatever the server is running instead of lagging a spec version behind
• Listens to room-emitted messages directly, which is the specific thing the Dart wrappers could not do and the reason this exists
• Native code runs on background threads, so frame decoding never lands on the Flutter main thread and a busy socket stops showing up as dropped frames
• A SocketIoNative singleton holds one connection for the whole app, with connect, on, off, emit, disconnect and dispose, plus onConnected, onDisconnected and onError
• Per-platform escape hatches through ExtraAndroidSocketOptions and ExtraIOSSocketOptions, because the two native clients do not expose an identical option set and pretending otherwise would leak
• A ConnectionStatus enum covering connecting, connected, disconnected and error, so reconnection UI has something real to bind to

Android 21+ · iOS 15+ · Java 11+KotlinSwiftPlatform Channels

Encrypting request and response bodies is a requirement in finance work, and doing it consistently across Android, iOS and web usually means three different implementations that disagree at the edges.

• One Dart surface over RNCryptor running natively on Android and iOS, and crypto-js on web, so the three platforms agree on the wire instead of drifting apart at the edges
• Handles strings, maps, lists, integers and doubles, so a whole request body encrypts without hand-rolling serialisation at each call site
• The same input produces different ciphertext every time, so an observer cannot recognise a repeated payload by its shape
• Native execution rather than a Dart implementation, which is what keeps large bodies off the critical path
• The README names the sharp edge instead of hiding it: maps and lists must not contain nulls

Android · iOS · WebKotlinSwiftRNCryptorcrypto-js