I can think of a number of reasons this is not an ideal approach. The biggest is nature of mobile apps; they must ensure security in a climate with many more attack surfaces than a desktop browser must endure. As such, any kind of scripting is likely to raise a number of challenges that are easily overcome in a non-mobile-based web browser.
Another challenge is script running at the edge. While desktops typically have lots of memory for performing dynamic [late binding] processes, mobile devices are limited and constrained in ways the desktop is not.
Lastly, connectedness. Mobile devices are typically not in the most favored connected devices and this could put added pressure on server-side data requests and updates. Imagine a script process designed to expect an always-stable connection and what would happen with just a few timeouts because the connection cannot be sustained. You’d likely have to write the script one way for desktop browser and completely different with error and completion-handling logic differently for the mobile app. Should Airtable endure the likely support obligations, training, script examples and primitives to make this possible? I think it’s a risky idea if the goal is profitiability.
Ergo, my feeling is that you will never see dynamic (lately bound) script-building or script-running features in Airtable’s mobile app.
As I mentioned earlier in this thread, execution of any manual or automated process based on custom scripts should be performed through indirection - i.e., establish conditions for said custom actions to fire and allow the servers to perform these processes because - well - that’s what they do well and the infrastructure is already in place.
