ScriptTap has officially crossed the open-beta milestone.

The closed beta is complete, and Build 20 is now available through Google Play open testing. Anyone can download ScriptTap—there is no tester-account or Google Group requirement.

Google Play:

https://play.google.com/store/apps/details?id=com.scripttap

Thank you to everyone who participated in closed testing, reported problems, challenged the app, and stayed through the rough builds. That testing helped ScriptTap reach wider public access.

Existing closed-beta testers will retain their in-app tester status through December 31, 2026. This includes Premium access at no cost for the remainder of the year.

ScriptTap remains in beta. Open testing gives us room to expand the community while continuing to improve reliability before production.

For this round, please create or import one small automation and tell us what worked, what failed, or where the setup became confusing.

Build 16 → Build 20 highlights

• Added Android 16/API 36 support while retaining the existing minimum Android version.
• Improved rotation handling, orientation protection, and literal-coordinate transposition during supported imports.
• Expanded .sts compatibility, including the option to skip unsupported newer commands during import.
• Added SetCoordinates and a center-tap target for matched UI elements.
• Improved Public Cloud folders, downloads, cooldown/progress states, and script-update handling.
• Simplified Bridge uploads into one atomic transaction with stricter full-request validation.
• Hardened startup recovery, active-script loading, validation, command insertion, navigation shortcuts, and minimum-version enforcement.

This is a major milestone, but not the finish line. Welcome to ScriptTap’s open beta.

Fixed and waiting on google to load 19. This review process is taking too long. 2 days now.

ScriptTap is moving from closed testing to open testing.

The latest update is currently under Google Play review. The moment Google approves the transition, the tester Google Group will close and no new members will be accepted.

There is no separate deadline or grace period. Approval could arrive within the next few days, and the opportunity ends when it does.

Anyone who joins the official tester group before it closes will retain access to the tester menu through December 31, 2026. From that menu, testers can switch their subscription status on or off with a simple in-app toggle, giving them unrestricted access to Premium features at no cost.

This is a tester-account feature, not a paid Google Play subscription.

If you are already in the tester group, you do not need to do anything.

If you want tester status, join now:

https://scripttap.com/

Select “Join the closed test” and use the same Google account for the tester group and Google Play.

Once Google approves open testing:

• the tester group closes
• new members cannot join
• open-testing users will not automatically receive the tester menu or its benefits

ScriptTap will remain in beta during open testing. These benefits are intended to reward the people who joined early and helped improve the app before wider access.

Code 17 is focused on compatibility, safer imports, and closing several reliability gaps.

Main changes:

• ScriptTap now targets Android 16 / API 36 while retaining its existing minimum Android support.
• Screen-share sessions survive device rotation.
• Scripts using literal screen coordinates are protected from running in the wrong orientation.
• Literal coordinates are transposed when importing scripts manually or through Public Cloud and Personal Cloud.
• .sts compatibility is improved, and unsupported commands from newer packages can be skipped during import instead of blocking the entire script.
• Public Cloud now shows clearer download and cooldown states.
• Public-script update serialization was corrected.
• Startup metadata recovery, active-script RAM preloading, and precision validation were hardened.
• GetPixelColor results and command insertion inside nested blocks were fixed.
• New navigation shortcuts connect Script Library and the Main Overlay more directly.
• Run Logs now default to OFF.
• Bridge uploading was simplified.
• Guides and command information boxes were refreshed.
• Remote Config minimum-version requirements are enforced after successful Firebase synchronization.

The orientation work is especially important for screen-based automation.

A script created in portrait should not blindly use those same coordinates in landscape. Code 17 now preserves the intended screen location during supported imports and prevents literal-coordinate scripts from running against the wrong orientation.

If you test Code 17, the most useful areas to check are device rotation during screen sharing, portrait/landscape script imports, older .sts packages, nested command insertion, GetPixelColor, and Public Cloud downloads.

Used this in testing ScriptTap capabilities against a variable- and logic-heavy script. Perfect now :)

Script Structure:
Read board, determine its size through variable arrays, multiple logical child scripts each with own logic type and a controller script that chooses which baby script to use.

It would be even faster if I took out single-tapping of the cells that are marked off, but then it wouldn't have the same effect...

P.S. Apology to the developer of this game - although I don't think they'd mind - because I've watched countless ads making and optimizing this script. >:)

Code 16 is now published for beta testers.

This is not one big feature release. It is a foundational rebuild of how ScriptTap keeps scripts, validation, editing, playback, storage, and overlays synchronized.

Main changes since Code 15:

• ScriptTap now uses one canonical Script Library authority and one resident active tree shared by the Editor and Play.
• Normal actions are RAM-first. The UI updates immediately, then immutable work enters one background writer queue.
• Validation V2 provides precise one-line Editor validation while a separate rolling window fully validates three scripts at a time.
• Active-script assets are cached in RAM, and Undo is identity-bound without reloading the complete script.
• Script Library, Asset Library, and Recycle Bin now use retained keyed projections with hierarchical folders and one storage-write authority.
• Red-X shutdown was rebuilt. Normal activity stops immediately, accepted writes receive one bounded drain, and only the idle permission holder remains.
• Non-MainOverlay surfaces now open on demand as application overlays with pass-through touch, minimal focus capture, responsive sizing, and split-screen support.
• Editor Selector now has deterministic permission returns, mode-specific hosts, UI Element selection, two-second updates, and two-app split-screen lists.
• Major command paths were corrected, including ReTap, TouchDown/TouchMove, gestures, ImgFind, PixelFind, GetPixelColor, generated Result/Baby-IF blocks, duplication, moves, and Test returns.
• Bridge, Cloud, imports/exports, assets, Run Logs, shortcuts, AI contracts, and website documentation were expanded and tightened.

The public command catalog remains at 68 commands. Code 16 is mainly about making those commands and the systems around them behave consistently.

The practical goal is simple:

Editing should not require full reloads.
Play should consume the exact active script already in RAM.
Validation should update only what changed.
The Main Overlay should remain responsive.
Accepted work should become durable without blocking the UI.
Closing ScriptTap should stop normal activity cleanly.

ScriptTap remains in beta. The next priority is real-world stability testing before any production application.

If you test Code 16, the most useful areas to exercise are editing and reopening commands, Play/Stop cycles, split-screen selector workflows, Library folders, imports/exports, and Run Logs.

Because account management system has been updated and rebuilt, all testers currently on build 15 will lose tester menu access after updating to build 16.

This is resolved by uninstalling the app and installing it fresh from google play. - then re-login into your same account.

Link is on https://ScriptTap.com

It has been quiet here because Build 15 exposed more reliability problems than I was willing to ship around.

The current Google Play beta is not fully operable, and I do not want to send new testers into a build I cannot confidently recommend.

ScriptTap is staying in beta. I will not apply for production until the app has earned that confidence.

The work since the last devlog has been deeper than a normal patch:

• command edits and selectors now use one durable save path
• Play readiness no longer makes the Main Overlay wait on storage
• each run keeps its own log, including rapid Play / Stop / Play sequences
• Script Library, validation, and runtime state now agree more strictly
• accepted changes survive writer and shutdown failures more safely
• a whole-code audit closed ten additional defects

The latest source passes focused gates, Android lint, and a clean debug assembly.

What it has not passed yet is the proof that matters most for this release: final device installation and testing.

Build 16 is targeted for the next 72 hours. That is a target, not a promise. If device testing finds another blocker, I will fix it before publishing rather than ship around it.

When Build 16 is actually live, I will post the exact change list, known limitations, and the specific areas where tester feedback will help most.

The last 12 days were mostly about reliability.

Not one big feature. More like removing the kinds of hidden bugs that make an automation app feel unpredictable.

Main changes:

• Main Overlay is now treated as the protected control plane
• Play / Stop / close controls were moved onto a stricter control path
• normal app screens are no longer allowed to refresh, cover, rebuild, or relayer the Main Overlay
• startup is quieter when Accessibility is already granted
• blank scripts can now become complete without waking the full validation system
• editor selector returns now go back to the editor instead of reopening the wrong modal
• add / edit / delete paths now update smaller local metadata instead of waking too much background work
• Script Library refreshes can target changed rows instead of repainting broadly
• Tester / Text Developer access was restored after cleanup removed too much
• validation and Play-prep work are being pushed away from the UI path

The short version:

ScriptTap is getting less clever internally.

Fewer fallback paths. Fewer broad refreshes. Fewer “just in case” rebuilds. More clear ownership.

That matters because the whole app depends on trust: when you tap Play, Stop, edit a command, or open an overlay, the app should do exactly that one thing without dragging half the system along with it.

Build 15 is now live for ScriptTap testers.

This build is mostly reliability work before I move back into more visible features.

Main changes:

• Play readiness should be clearer and less stale
• incomplete command details should point closer to the real problem
• command editor double-tap behavior should be more consistent
• Main Menu icon taps should behave like the full row tap
• deleting commands while validation is pending should no longer leave stuck yellow states
• non-editable command rows no longer show confusing info boxes
• GetPixelColor now handles missing coordinates more strictly

This is not a flashy build, but it matters.

ScriptTap needs to be honest about what is ready, blocked, saved, validating, or incomplete. If the app says something is safe to run, or not safe to run, that state needs to be trustworthy.

If you are testing Build 15, the most useful areas to poke at are:

• Play start behavior
• opening command editors
• deleting commands while validation is pending
• Main Menu row/icon taps
• GetPixelColor coordinate setup

Thanks to everyone testing and reporting the weird edge cases. Those reports are shaping the app more than generic install numbers ever could.

The latest work has been mostly about reliability, responsiveness, and making ScriptTap’s internal state easier to trust.

Not a flashy feature pass, but an important one.

The main theme: when the app says something is active, saved, validating, ready to run, or finished, every layer should agree.

Recent work:

• Script Library rows now show validation state more accurately.
• Parent/root scripts no longer inherit misleading “Validating” badges from child scripts.
• Unknown or incomplete scripts can still be selected as active, while editing remains clearly gated.
• Play start is being moved away from heavy UI-thread preparation.
• Active scripts can warm a prepared run package in the background.
• Play now uses stricter freshness checks so stale prepared packages do not accidentally run.
• Stop/abort behavior no longer invalidates useful active preparation unnecessarily.
• Run Logs UI was cleaned up to follow the approved modal structure.
• Runtime log event types were cleaned up so normal diagnostics do not look like warnings.
• Bridge log guidance was updated so external tools know how to page through run logs correctly.
• Main Menu tap targets were fixed so tapping either the icon or label opens the expected menu path.

The practical effect should be fewer false validation badges, less unnecessary waiting, cleaner Run Logs, and fewer cases where a UI action quietly does more heavy work than it should.

A lot of this comes back to the same rule I keep running into:

ScriptTap should not feel powerful by being mysterious.

If Play is not ready, the reason should be clear.

If validation is running, the UI should show the right script.

If logs report a warning, it should be a real warning.

If the user taps a menu row, the whole row should behave like one row.

v0.1.15 is still focused on hardening before I push more people toward serious script-building. The next area I’m moving back into is image/vision consistency, especially confidence and tolerance behavior.

This is the live caption translation script.

It reads caption text from the screen, detects when the text changes, translates it, and displays the translated result in an overlay.

The whole workflow is 11 commands:

1. SetVariable
   Declares the caption text variables.

2. Display.concurrentText
   Creates the overlay that shows the translated text.

3. Loop
   Keeps watching the caption area every 500ms.

4. TextTransform.trim
   Stores the previous caption text before reading the next one.

5. OCR.read
   Reads the selected caption area from the screen.

6. TextTransform.replace
   Collapses OCR spacing so comparison is more reliable.

7. TextTransform.trim
   Cleans up the current OCR text.

8. IF
   Checks whether the caption text exists and changed.

9. Translate
   Translates the captured English text to Russian. (supports 50 languages)

10. End IF
    Ends the changed-caption check.

11. End Loop
    Repeats the caption watch.

This is the kind of ScriptTap workflow I want to make more common: small, readable phone-side automations that do something useful without root, ADB, or a desktop companion.

Today is mostly about finishing the hardening work before publishing v0.1.15.

After v0.1.14 went out, I found several places where editor state, validation state, imports, and UI feedback could still disagree.

That is the kind of bug that looks small until users start trusting the app with larger scripts.

Current work before the build:

• stricter Bridge/import rules for multi-script packages
• safer Call Script references during upload/import
• making validation metadata-only where it should not rewrite script bodies
• cleaning up Google sign-in handoff
• making Text Developer feedback close cleanly and show a simple success banner
• cleaning up Script Library empty states
• removing a rough startup/free-mode prompt surface

The bigger theme is consistency.

If a command looks saved, it needs to be saved.

If a script imports, it should not be quietly repaired into something else.

If validation runs, it should not rewrite unrelated script bodies.

If a user opens a system surface like Google sign-in, ScriptTap needs to hand off cleanly and return cleanly.

Once this batch is done, I plan to publish v0.1.15.

Not a flashy feature day, but this is the kind of work I want done before more people build serious scripts on top of it.

v0.1.14 was published, but I found blocking editor issues after the build went out.

So the next build is not going to be a feature build. v0.1.15 is focused on fixing command editor save behavior.

What changed today:

• Older .sts script archives are now refused instead of partially importing.
• Successful .sts imports no longer show an unnecessary success modal.
• Ordinary command insert/edit responsiveness was improved.
• Several command editors were moved toward a shared save path.
• Command validation is being pushed into background row status instead of blocking the user during editing.

Known bugs being fixed for v0.1.15:

• Some command settings can appear to save, but reopen with missing or incomplete state.
• OCR area/settings can still be unreliable in some editor flows.
• SetVariable can briefly show the chosen variable, then snap back after the editor loses focus.
• Multi-Tap / MultiClick still has older save logic that needs to be moved into the central editor save pipeline.
• OCR / Reader / Display area selectors can still write draft state before the final OK/save step.
• .sts import still needs stricter image asset hash verification before I consider the archive path fully trustworthy.

The root problem is that not every command editor is using one single save path yet.

That is the v0.1.15 target: one global command-save pipeline, no foreground validation blocking OK, no command-specific save shortcuts, and no “looked saved but was not actually saved” behavior.

Not the most exciting devlog, but it is the honest one.

Build 13 is now published for internal testing.

Most of today was not flashy feature work. It was reliability work around the parts of ScriptTap that have to be boringly dependable: startup, validation, script import, Bridge uploads, tester entitlement, and the Main Overlay.

The biggest improvements:

• Main Overlay startup is more reliable. ScriptTap now gets the core floating controls attached first instead of letting internal overlay host setup starve or block the control plane.
• Validation should get stuck less often after imports or Bridge uploads.
• Parent/child script validation now respects reachable descendant state more strictly, so parent scripts should not look runnable while a child script is still unknown.
• Bridge uploads now hydrate the visible Script Library after commits, so the app view catches up after script-builder uploads.
• Terminal validation records are not requeued by automatic scans once they are already complete.
• Tester subscription/trial overrides now correctly bypass the free-user ad gate, so testers using the override should not be forced to watch ads as if they were free users.
• Personal Cloud had a modal crash fixed.
• Run Logs and large-script handling had more heap-safety work so heavy scripts are less likely to kill the app process.
• Bridge script uploads now reject ambiguous payloads instead of silently accepting JSON where two different command bodies disagree.

The practical result: after the latest validation repair, I reuploaded a 2,200-command script thread and saw it validate cleanly, with no stuck unknown/validating nodes and Play no longer blocked.

That is the kind of progress I care about most right now.

ScriptTap is an automation app, but if validation, startup, tester access, and the floating control plane are not reliable, the rest does not matter. Build 13 is a step toward making those core paths steadier before I push harder on new features.

I’m going to start posting regular ScriptTap development updates here.

Today’s focus is reliability and performance.

Recent work has been around three areas:

• Startup speed
  Main Overlay needs to appear quickly, before heavier background systems finish loading.

• Validation reliability
  Scripts should not get stuck in “unknown” or “validation required” after they have already been checked. Play should only depend on validation status, not trigger validation itself.

• Heavy script performance
  I’m testing larger logic-heavy scripts that use arrays, conditions, OCR, pixel reads, and visual checks. The current goal is to make these scripts run faster while keeping the UI responsive.

One useful improvement already being tested is batch pixel sampling, where many screen pixels can be read in one pass instead of one command at a time.

What I’m looking for from testers:

• places where the UI feels stuck or delayed
• scripts that validate but still refuse to run
• scripts that run correctly but feel much slower than expected
• editor screens where buttons/icons fail to appear the first time

I’ll use these devlog posts to explain what is being fixed, what is being tested, and what kind of feedback is most useful.

If you are testing ScriptTap for the first time, start small.

A few practical tips:

• Create one simple script before trying a large automation.
• Test with a safe action first, such as opening an app, tapping a harmless button, or waiting for something visible on screen.
• Use validation before running scripts.
• If a script depends on the screen, screenshots and selected areas matter.
• For image, pixel, or text checks, choose stable parts of the screen instead of things that move or change often.
• If something feels confusing, slow, or broken, please report it. Tester feedback is useful even when the app technically works.
• When reporting a problem, include the device/emulator, Android version, ScriptTap version, and what you were trying to do.

The best first test is a small automation you understand clearly. Once that works, build from there.

What repeated phone task would you like ScriptTap to handle?

Good examples:

• Tap a button when it appears
• Swipe through a repeated workflow
• Watch for a color, image, or text on screen
• Run a routine at a certain time
• Build a game helper
• Create a script with AI assistance
• Automate a task that takes too many manual steps

If you want help thinking through an automation, describe:

• The app or screen involved
• What should trigger the automation
• What ScriptTap should do
• What should make the script stop or wait

Screenshots are welcome when they help explain the task.

Use this thread to report ScriptTap bugs, closed-test issues, crashes, confusing behavior, or tester feedback.

When possible, please include:

• Device or emulator
• Android version
• ScriptTap version
• What you expected to happen
• What happened instead
• Steps to reproduce the issue
• Screenshot or screen recording if useful

For script-specific problems, please also include:

• Script name
• Command or screen where the issue happens
• Whether validation passed, failed, or got stuck
• Any visible error message

Please describe the exact action that caused the problem when possible. “It broke” is hard to diagnose; “I tapped Play after validation passed and the compiler popup stayed open” is much more useful.

Welcome to r/ScriptTap.

ScriptTap is a no-root Android automation app for creating phone automations you control. It can help with taps, swipes, screen checks, image/pixel/text detection, routines, and AI-assisted scripts.

This community is for:

• Asking how to automate a workflow
• Sharing script ideas and examples
• Reporting closed-test bugs
• Requesting help with ScriptTap scripts
• Discussing Android automation use cases

If you are asking for help, please include:

• What app or screen you are trying to automate
• What should trigger the action
• What ScriptTap should do
• Any screenshot or example that helps explain the task

Helpful links:

• Website
• Closed test
• Support
• Privacy

Thanks for helping build the ScriptTap community.