Greasy Fork

Cool to see iterations of A.C.A.S! I don't own an iOS device so the original script was probably garbage on it.

I can implement fixes on the original script if I know what I need to fix specifically :-)

Hey! First of all, thank you for being open to looking into this. I really appreciate it — A.C.A.S is an amazing project, and the fact that you’re willing to improve iOS support means a lot.

I tested the script on Orion + Tampermonkey on iOS, and after comparing my fork/mod with the original script, I think the issues are probably concentrated in a few specific areas rather than requiring a big rewrite.

The main problem seems to be performance around board observation. In `observeNewMoves()`, the `MutationObserver` watches the board with `childList`, `subtree`, and `attributes`, and then calls `determineBoardPositionValidity()` directly. On iOS, especially during piece animations, this can fire many times very quickly. There is also a fallback interval running every 250 ms that calls the same validation, plus `initializeIfSiteReady` running every 100 ms. I think adding a small debounce around the MutationObserver callback and reducing/removing the aggressive fallback polling would probably fix most of the lag, heat, and delayed functions on iPhones/iPads.

There also seem to be a few small memory/state cleanup issues. `clearMetricRenders()` and `clearFeedback()` remove the DOM/SVG elements, but they do not clear `activeMetricRenders` or `activeFeedback`, so references can remain in memory. On iOS WebKit this may become noticeable over time. It may be enough to clear those arrays after removing the elements. `removeMarkings()` may also benefit from making sure temporary square listeners/references are cleaned up properly.

I also noticed one concrete bug in `AutomaticMove`: `activeAutomoves.filter(x => x.id !== this.id)` does not actually modify `activeAutomoves`, because the filtered array is not assigned back. That might leave old automove objects in the array.

Finally, some interaction functions may fail on iOS because the script currently relies mostly on `PointerEvent`/`MouseEvent` for automated board interaction, while mobile Safari/WebKit and some chess sites may expect touch-based behavior. It may be worth adding a more iOS-friendly mobile/touch path and using passive touch listeners where possible.

So, in short, I don’t think this needs a huge rewrite. The most important fixes seem to be:

1. debounce `MutationObserver` before board/FEN validation;
2. reduce or conditionally disable the 250 ms board polling fallback;
3. reduce/stop the 100 ms initialization polling after the board is found;
4. clear visual-render arrays after removing SVG/DOM elements;
5. fix `activeAutomoves.filter(...)` so it actually removes finished moves;
6. review the iOS touch/event path for mobile compatibility.

Thanks again for taking a look at this. I really appreciate your work on A.C.A.S and would love to see better iOS support merged into the main version.

Thanks, I'll look into those for the next updates.

1. The debouncing logic seems like a good idea.
2. I don't think 250ms polling should affect performance too much, it's meant to act as a backup in case mutationObserver fails to catch changes, so I tried to optimize speed and performance.
3. 100ms init polling should be reduced to at least 500ms or 1000ms, or be dynamic, that's true.
4. True, activeFeedback is not cleared at all, that's just bad programming, my bad.
5. The "automove" is a feature I don't wish to develop further, but I'll fix that clear programming error.
6. I'm unsure what "iOS-friendly mobile/touch path" means. PointerEvent/MouseEvent should be up to site specific things (what the site was programmed to listen to). It's hard to simulate "real" presses with userscripts, which is one reason I'm not developing the automove further. Another reason is just that I don't believe botting games is acceptable.

That makes total sense. I really respect the line you’re drawing with automove/botting. Keeping A.C.A.S strictly as a visual assistant is a fair boundary, and honestly, trying to simulate native iOS touch events is a maintenance nightmare anyway.

WebKit wants those cursed touchstart → touchend chains to be perfect, so yeah, probably best to keep that mess out of the main branch.

I’ll keep my experimental touch/delay stuff in a personal fork, just for learning and testing.

Since I’ve been digging into iOS limitations this week, I wanted to share two things I found, in case other mobile users run into the same problems later:

Maia / heavy WASM engines on iOS

Running heavy WebAssembly neural networks like Maia/Lc0 locally on iOS WebKit is basically not viable right now.

Safari tends to kill the background tab or worker because of RAM spikes when loading the weights. It works fine on Android/Chromium, but on iOS it really needs an external backend server with proper COOP/COEP headers to handle the load.

Best iOS setup

For iOS users struggling with performance, I switched from Orion to the official paid Tampermonkey extension for native Safari.

The difference in stability and optimization is massive. For heavy scripts like A.C.A.S, it’s genuinely worth it.

Also, I’m glad the performance and memory cleanup suggestions helped. Thanks again for reading through everything and for all the work you’re putting into A.C.A.S.

Looking forward to the next updates.