Hyy,
i am new to open source, i found MIT app inventor organisation interesting and wanted to contribute in the same with the goal of applying to GSOC'26. Can you plz help me out and guide so that i start contributing? When i was reading the post of 'Google Summer of Code(GSOC)2025', one thing which i didnt understand was 'Before sumbitting a gsoc proposal, you will need to be able to successfully build your own copy of app inventor and build a sufficiently complex app to show your grasp of how App Inventor works'.Can you plz explain this to me? Do we have to make a clone project of app inventor before sumbitting the proposal?
Thank you for sparing your precious time!!
Aditya Pyasi Misra
It is required that you have a version of App Inventor on your machine to test and develop locally. The build instructions are in the README.md file.
You need Google Cloud App Engine and Ant installed on your PC to run App Inventor. If you have any problems setting up a local version, please reply here.
Hi everyone,
My name is Ayush Kumar, a third-year B.Tech student in Electronics and Communication
Engineering at NIT Hamirpur, India. I'm applying for the GSoC 2026 TrainableChatBot project
under MIT App Inventor, mentored by Natalie Lao, and wanted to introduce myself to the
community.
How I Found App Inventor
I came across MIT App Inventor while exploring platforms that make programming accessible to
people without a CS background. I expected a toy environment. What I found instead was a
genuinely thoughtful piece of software — and the AI Magic components stopped me completely.
The PIC and PAC pattern — train in a browser, export a file, infer on a device — is one of the most
elegant approaches to democratizing ML I've encountered. It doesn't abstract away what's
happening; it makes the structure legible to a learner while still being real and deployable. That
combination is rare.
Going Deeper into the Codebase
Once I decided to apply for TrainableChatBot, I didn't want to propose something I hadn't actually
understood from the inside. I spent several weeks reading the source carefully:
• Read ChatBot.java end-to-end and traced exactly how queries are routed through
chatbot.appinventor.mit.edu to understand the structural limitations — not just the surface
ones.
• Read PersonalAudioClassifier.java and the PIC extension code to understand the
WebView bridge pattern: how addJavascriptInterface and postMessage are used, and where
the seams are.
• Found and studied PAC Issue #39 (WebView postMessage reliability failures on certain
devices), which directly shaped my proposal — it's why I chose MediaPipe's native Java API
for SLM inference rather than replicating the WebView bridge.
• Built a working RAG proof-of-concept using all-MiniLM-L6-v2 and Gemma 1B to validate that
the same embedding model can serve both the browser training phase and on-device retrieval
without semantic drift.• Ran the local App Inventor dev server, built a working app with the existing ChatBot
component, and tested MediaPipe initialization on a physical device to understand the
memory lifecycle before writing a line of proposal text.
The more I read, the more the TrainableChatBot project felt like the right next piece —
architecturally consistent with what already exists, solving a real gap that affects the users App
Inventor was built for.
Looking Forward to the Community's Feedback
I'm happy to discuss any aspect of the technical approach here — the RAG pipeline, the .chatbot
export format, the MediaPipe integration, or the embedding model choice. If anyone has context
on how PIC or PAC were received by users, or constraints I should be aware of from prior work, I'd
genuinely appreciate it.
Thanks for building something worth contributing to.
Ayush Kumar
GitHub: httpsAKayush (Ayush Kumar) · GitHub
NIT Hamirpur | ECE, Year 3 | IST (UTC+5:30)