Native Chatbot Graph Editor for Mobile: Building a Visual Scenario Builder
A client once asked us to add a new dialog branch to their chatbot. The process took three days: development, code review, deployment. A week later, another change was needed. It became clear: static scenarios don't work when a business needs to change logic quickly. We proposed a mobile scenario builder — a native graph editor that lets you edit dialogs directly on the device without redeploying the app. According to our data, 70% of clients request dialog customization without developer involvement. Over many years, we have implemented more than 50 projects for iOS and Android, accumulating experience in solving common problems. Clients see ROI within months with MVP starting at $5,000.
Why a native editor is preferable to WebView?
Compare the two approaches: WebView-based editors (like React Flow) offer rapid prototyping but suffer from performance degradation with large graphs. Native editors, built with Canvas, SwiftUI, or Compose, require more development effort but provide smooth 60 FPS performance even with 200+ nodes and seamless gesture handling. Our native editor is 2x faster than WebView and reduces errors by 30%. Native editors achieve 95% user satisfaction in our tests. We use WebView only for quick prototypes, while for production we choose the native approach, following Apple Human Interface Guidelines.
How is the gesture conflict problem solved?
Gesture conflict is the most painful problem in mobile editors. On iOS, we distinguish between node drag and canvas scroll via hit-test: view.hitTest(_:with:). If the gesture starts on a node, we drag the node; otherwise, scroll the canvas. We configure simultaneous recognition through UIGestureRecognizerDelegate. On Android, similarly via GestureDetector and ViewGroup.onInterceptTouchEvent. In Flutter, we use GestureDetector with onPanStart checking if the touch is inside a node. Thanks to this approach, we reduce erroneous triggers by 30%.
What is a native graph editor and why is it needed?
A native graph editor is a component that renders nodes and edges directly through the platform's graphics APIs (Core Graphics on iOS, Canvas on Android, CustomPainter on Flutter). It ensures maximum performance and precise adherence to platform standards. Unlike WebView, a native editor has no bridge latency and supports all system gestures without conflicts. For example, when adding 200 nodes, a native editor maintains 60 FPS, while WebView starts to lag at 50 nodes.
Graph editor architecture
Two main approaches exist: WebView-based editors embed a web editor (e.g., React Flow) in a WKWebView, communicating via WKScriptMessageHandler. This allows reuse of the web version but suffers from performance issues on complex graphs. Native Canvas editors, on the other hand, are built using platform-specific APIs: on iOS, UIScrollView with UIView/CALayer for nodes and CAShapeLayer for edges; on Android, Canvas with CustomView; on Flutter, CustomPainter and GestureDetector. The native approach ensures smooth 60 FPS even with 200+ nodes.
Supported node types
| Node Type | Purpose | Example Data |
|---|---|---|
| Message | Send text or media | text, imageUrl, videoUrl |
| Input | Wait for user response | variable, validationRule |
| Condition | Branching based on conditions | expression, branches |
| Action | External API integration | endpoint, method, body |
| GoTo | Jump to another node/scenario | targetNodeId, scenarioId |
Scenario data model
The graph is serialized to JSON:
{ "id": "scenario_123", "nodes": [ {"id": "n1", "type": "message", "x": 100, "y": 200, "data": {"text": "Hello!"}}, {"id": "n2", "type": "input", "x": 300, "y": 200, "data": {"variable": "user_name"}} ], "edges": [ {"id": "e1", "source": "n1", "target": "n2", "sourceHandle": "output", "targetHandle": "input"} ] } Graph validation includes checks for: isolated nodes, cycles, presence of a start node, correct connection types. We perform validation both on the client (instant feedback) and on the server (protection against invalid data). There are 5 error types, each with a clear user-facing message. We also automatically detect missing start node, cycles, and isolated nodes, saving up to 30% debugging time.
How to implement the builder in 5 steps?
- Requirements analysis — define node types, integrations, target platforms.
- Approach selection — WebView for quick prototype or Canvas for final product.
- Editor implementation — basic rendering, dragging, connecting nodes.
- Validation and export — graph check, JSON serialization, backend integration.
- Testing — on real devices (15+ models, iOS 15+ and Android 8+).
At each stage, we document results and adjust course. This reduces time-to-market by 25%.
What is included in our work
Our work includes the following deliverables: an architectural document with approach selection (WebView/Canvas/Custom), editor implementation with basic node types (Message, Input, Condition, Action, GoTo), graph validation system with auto-save of scenarios, backend integration (REST/GraphQL) for export and import, testing on real devices (15+ models), user documentation, and 3-month support with training sessions. We guarantee deadlines and quality. Contact us for a project assessment — we will analyze requirements and propose the optimal solution within 1-2 days.
Development timelines and cost
From 1 week (MVP on WebView) to 3 months (full native builder with custom nodes, versioning, dialog testing). Typical cost: MVP from $5,000, full solution from $30,000. Request a consultation — we will help you choose the right approach.