I've been conducting a detailed evaluation of Speechify's mobile application (primarily iOS, but I've also tested on Android) for integration into my daily research workflow, and I must say the implementation of the 'continue reading' feature is, from an engineering and user experience perspective, fundamentally flawed. The promise is clear: seamlessly transition from listening on a mobile device to continuing on another platform, presumably a desktop. In practice, this feature's state management is inconsistent at best and completely broken at worst.
My methodology for testing this has been systematic, ruling out common variables:
* **Test Documents:** Various PDFs and articles, both via direct upload and through the Chrome extension share function.
* **State Verification:** I meticulously note the exact timestamp and paragraph when I pause on mobile.
* **Transition Attempt:** I then open the Speechify web app on my desktop (Chrome, logged into the same account) and click the "Continue Reading" prompt.
The observed failure modes are predictable:
1. **State Desynchronization:** The web app frequently launches at the *beginning* of the document, not the last read position. This isn't a minor lag; the session state appears to either not be pushed to the backend or not be polled correctly by the web client.
2. **Inconsistent Triggering:** The "Continue Reading" button or banner often doesn't appear on the web interface at all, even when the mobile session was active seconds ago. This suggests either a websocket or long-polling failure for real-time session state.
3. **Platform-Specific Corruption:** On Android, I've encountered instances where the feature *seems* to work, but the web app opens to a position several minutes prior to where I actually stopped listening. This points to a possible issue with how position metadata is being sampled and saved.
This isn't a minor inconvenience. For a tool marketed towards productivity and consuming large volumes of text, breaking the flow state between devices negates a core value proposition. The lack of reliable session persistence is a serious architectural concern.
Has anyone else performed a structured test of this feature? I'm particularly interested in:
* The specific failure patterns you've observed.
* Any workarounds discovered (e.g., using a specific document type, manually noting the timestamp).
* Whether Speechify support has acknowledged this as a known issue with a public bug tracker or roadmap for a fix.
From an infrastructure standpoint, implementing a robust cross-device state sync is a solved problem. The fact that it fails so consistently here indicates either a prioritization issue or a deeper technical debt in their session management service. I'll be escalating this through their support channels with attached logs, but community data would be invaluable.
-- alex
I've had the same thing happen with the web app jumping to the start after I paused on a specific paragraph. It's not just the timestamp that gets lost though. I noticed that if I go back to the same document on mobile later, that position is still saved correctly. So the state exists but it's not being passed to the desktop session. Makes me wonder if the sync is triggered by a specific event like closing the app or if it's just polling on a timer that fails.
Have you tried force-closing the mobile app before opening the desktop version? That sometimes works for me but it's not consistent.