MyClippy test results on real devices
We test MyClippy by copying synthetic text on one real device and checking that the other device’s clipboard matches it byte-for-byte. On 24 September 2026, 24 of 26 checks between a Pixel 7 and a Mac passed, 1 failed and 1 was inconclusive. In a three-device run with a Windows laptop, all six copy directions passed once the laptop’s clock was synchronized, and four of five checks failed before it was.
How we test
- Only synthetic sample text is used; no personal clipboard content is recorded.
- On Android, a separate foreground test app copies and reads text with Android’s normal clipboard APIs. MyClippy itself is the installed Google Play build, not modified for testing.
- A check passes only when the receiving clipboard’s SHA-256 digest matches the text that was copied. Android → Mac copies had up to 12 seconds to arrive; Mac → Android copies were checked 2 seconds after copying.
- The Android emulator’s host clipboard bridge is switched off so it can’t fake a transfer, and emulator runs are not counted here.
- These are pass or fail checks, not a reliability percentage or a latency benchmark. A small number of runs on one phone model can’t represent every phone, app or network.
Pixel 7 and Mac
Setup: Google Pixel 7 on Android 17 with MyClippy 0.3.2 installed from Google Play; Apple M1 Pro Mac on macOS 26 with MyClippy 0.3.0; both on the same private Wi-Fi.
Result: 24 passed, 1 failed, 1 inconclusive of 26. Copies in both directions, size limits, pause and resume, host restart and Wi-Fi recovery passed. The first Android copy after a phone reboot was lost because it was made before MyClippy reconnected.
| Check | Outcome | Notes |
|---|---|---|
| Android → Mac, sample 1 | Passed | |
| Mac → Android, sample 1 | Passed | |
| Android → Mac, sample 2 | Passed | |
| Mac → Android, sample 2 | Passed | |
| Android → Mac, sample 3 | Passed | |
| Mac → Android, sample 3 | Passed | |
| Repeated A → B → A | Passed | |
| Copy marked sensitive is not sent | Passed | |
| Mac paused: nothing syncs in either direction | Passed | |
| Resume does not replay copies made while paused | Passed | |
| Fresh Android copy after resume | Passed | |
| Fresh Mac copy after resume | Passed | |
| Mac app restarted: both directions recover automatically | Passed | |
| A Mac copy received on Android is not sent back | Passed | |
| 32,768-byte Android copy | Passed | |
| 32,769-byte Android copy is rejected | Passed | Over the 32,768-byte limit, as designed |
| 32,768-byte Mac copy | Passed | |
| Text copied in WhatsApp matches on the Mac | Passed | Copied by a person; compared by hash |
| Mac copy made while the phone was locked pastes after unlock | Passed | |
| Android copy after unlocking | Passed | |
| First Android copy after a phone reboot reaches the Mac | Failed | Made before MyClippy reconnected; did not arrive within 12 seconds |
| Mac → Android after a phone reboot | Passed | |
| Fresh Android copy after reboot, once connected | Passed | |
| Mac copy during a phone Wi-Fi outage arrives after reconnecting | Inconclusive | The test helper could not get focus in time; later copies replaced the sample |
| Fresh Android copy after Wi-Fi reconnects | Passed | |
| Fresh Mac copy after Wi-Fi reconnects | Passed |
Windows, Mac and Pixel 7 — before the Windows clock was synchronized
Setup: Windows laptop (x64), Apple M1 Pro Mac and Pixel 7 (Android 17, MyClippy 0.3.2 from Google Play). Mac and Windows apps were local development builds made during the session. Each copy had to reach both other devices.
Result: 1 passed, 4 failed of 5. Four of five checks failed while the Windows clock was wrong. MyClippy orders clips by copy time, so device clocks must agree.
| Check | Outcome | Notes |
|---|---|---|
| Mac → Windows and Android | Passed | |
| Windows → Mac and Android | Failed | Android clipboard did not match |
| Android → Windows and Mac | Failed | Did not reach the Mac within 12 seconds |
| Windows Unicode multiline text → both | Failed | Android clipboard did not match |
| Windows repeated A → B → A → both | Failed | Android clipboard did not match |
Windows, Mac and Pixel 7 — after synchronizing the clock
Setup: Same three devices, after the Windows system clock was synchronized.
Result: 5 passed, 0 failed of 5. All six copy directions passed, including Unicode, multiline text and repeated A → B → A copies.
| Check | Outcome | Notes |
|---|---|---|
| Mac → Windows and Android | Passed | |
| Windows → Mac and Android | Passed | |
| Android → Windows and Mac | Passed | |
| Windows Unicode multiline text → both | Passed | |
| Windows repeated A → B → A → both | Passed |
Windows, Mac and Pixel 7 — additional checks
Setup: Same three devices, synchronized clocks.
Result: 8 passed, 0 failed, 1 blocked of 9. Pause, restart, near-simultaneous copies and a 25-copy burst passed. One check could not run because the phone was locked.
| Check | Outcome | Notes |
|---|---|---|
| Mac → Windows and Android | Blocked | Phone locked; the test helper could not run. Not counted as a pass or a failure |
| Windows → Mac and Android | Passed | |
| Android → Windows and Mac | Passed | |
| Windows Unicode multiline text → both | Passed | |
| Windows paused: isolated; resume restores fresh transfers | Passed | |
| Near-simultaneous Mac and Windows copies settle on the same text everywhere | Passed | |
| Windows app restarted: rejoins and transfers both ways | Passed | |
| 25 rapid copies: the final one reaches Windows and Android | Passed | Checks the final value, not every intermediate copy |
| Windows copy after an interface update reaches both | Passed |
What these results tell you
- Copying works in both directions between Android, Mac and Windows on the same private Wi-Fi, including Unicode, emoji, multiline text and repeated values.
- Keep automatic date and time on every device. MyClippy orders copies by when they were made, and a wrong clock caused the Windows failures above.
- After restarting your phone, open MyClippy and wait for Connected before copying. A copy made before it reconnects is not queued.
Not tested yet
Other Android brands and versions, Intel Macs, Windows on Arm, long periods in the background, battery impact, Android force-stop, and networks with client isolation. A four-device run that added an Android emulator was not completed reliably and is not counted. Read the troubleshooting guide for known limits, or email intelligentiastudios@gmail.com to report your own results.