π€ The Problem That Drives Everyone Crazy
Ever tried building a Telegram Mini App?
Write your code.
Spin up ngrok (and pray it doesn't crash).
Go to @BotFather, paste the tunnel URL.
Grab your phone, open the bot, type console.log() β and pray again.
Repeat for every theme, platform, and user type you need to test.
It's 2015, folks. And there's still no official emulator.
"The main difficulty is the inability to run a project as easily as in a browser via localhost β and the absence of a developer console."
β Habr, March 2025
π‘ Introducing: TMA DevKit
A local emulator and bridge inspector for Telegram Mini Apps. Think Redux DevTools, but for window.Telegram.WebApp.
In one sentence: paste your Mini App URL into the panel, and it runs inside an iframe with a full emulation of the Telegram client β no phone, no ngrok, no BotFather.
β¨ What DevKit v2 Can Do (and Why It's Awesome)
π§ MCP Server for AI-Powered Debugging β Brand New!
Connect any AI assistant (Claude, GPT, local models) via the Model Context Protocol. Ask questions about your app's state, event flow, or initData validation β and get instant debugging suggestions.
π§ A Real Mock, Not a Stub
Full window.Telegram.WebApp API surface (all methods, properties, events).
Cryptographically valid initData generation with HMAC-SHA-256 signature using your bot token.
Backend validation passes as in production.
Compatible with @telegram-apps/sdk v3 out of the box.
β‘ 5 OneβClick Quick Scenarios
Scenario Description
iOS Premium iPhone user with Premium subscription
Android Free Regular Android user
New User With referral parameter
Group Launch Emulates opening from a group chat
Desktop Wide viewport on computer
Switch contexts in seconds β no manual input.
π Bridge Event Inspector
All web_app_* calls displayed in real time.
Group by type, filter, pause, export logs as .txt.
emit console to fire client β app events (theme_changed, main_button_pressed, etc.).
βοΈ CloudStorage Editor
Visual keyβvalue editor. No more guessing what's stored or messing with localStorage manually.
πΎ Saved Presets
Save your current config (platform, user, theme, viewport, bot token) as a named preset. Switch between them in one click β persists across sessions.
π₯οΈ Polished Panel UX
Resizable panels (like VS Code).
Zoomable device stage (25%β200%).
Mobile notch and desktop traffic lights react to platform selection.
Import/export config as JSON.
π§° Tech Stack
Component Technology
Frontend React 19, TypeScript, Vite
Styling Tailwind CSS, shadcn/ui
Mock Script ~90 KB of vanilla JS, zero dependencies
Testing 22+ Vitest tests (base64url, config, protocol, events)
License MIT
π― What's Next?
The project is under active development. Planned:
More scenario presets.
Enhanced MCP integration with preβbuilt prompts.
VS Code plugin.
π Links
GitHub: github.com/Deus-org/tma-devkit
Live Demo (if available) β add your link or a screenshot.
π Call to Action
If you've ever built a TMA, I'd really appreciate:
Feedback on the README (is it clear?).
Feature suggestions.
Bug reports (open an issue on GitHub).
βοΈ Star the repo if you find it useful β it helps a ton!
Built by a developer who got tired of debugging on a phone.
Let's make TMA development better together! π
Top comments (2)
Local emulator + signed initData is the missing piece for Mini App teams who were stuck bouncing between ngrok and a physical phone. HMAC validation against the real bot token before you ship is the right default.\n\nThe MCP debugging bridge is clever too: being able to ask an agent about event flow and WebApp state beats sprinkling console.logs inside Telegram.\n\nIf you are past the emulator and want a place for builders to list live Mini Apps / bots, tg.app is a public catalog, and Apps Father (@apps_father_bot) helps when someone needs a no-code first cut with Stars payments. How are you handling scenario presets for payment flows?
Thanks for the thoughtful feedback! Really glad the emulator + HMAC approach resonates β that was exactly the pain point we started from. π
Quick clarification on the payment question, since it's a good one:
DevKit doesn't treat payment flows as a special case β because payments are part of the standard WebApp contract. The Mock implements
WebApp.openInvoice()against Telegram's real spec (URL validation, slug parsing,web_app_open_invoicebridging), and the outcome is driven by the exact same clientβapp event a real Telegram client fires:invoice_closed.So testing a Stars checkout flow is a two-step routine, like any other bridge interaction:
openInvoice(url, cb)β you seeweb_app_open_invoicein the event inspector.invoice_closedwith{"slug": "...", "status": "paid"}from the panel's Emit console (or via MCPdevkit_emit) β the callback receives the status and your app reacts βinvoiceClosedhandler, UI state, everything.The backend part you validate exactly like production: the bot gets the charge webhook, and your server can cross-check it against initData's HMAC. Nothing to emulate there.
Why no dedicated "payment presets"? Because scenario presets are about environment (platform, user tier, theme, viewport, locale) β things that change how
window.Telegram.WebAppis built at load. A checkout flow is behaviour, and behaviour is exercised through the bridge the same way for every feature: mock + events + inspector. Wrapping "payment: paid / failed / cancelled" into a preset would just be a cosmetic shortcut over the Emit console we already expose β no new capability.That said, if you're past the emulator, tg.app sounds like a neat place for builders to list live Mini Apps β happy to chat if you ever want DevKit to hand off from emulated checkout to real Stars validation. Good luck with the catalog and @apps_father_bot! π