Okay, I’ve been trying to use SciSpace's mobile app for a couple of weeks now, and I have to agree with the title. It feels like a reader-only version.
I can open papers and read abstracts fine, but whenever I want to do something more—like ask a follow-up question about a method section, or export my notes to my project management tool—I hit a wall. It just doesn’t seem possible. Even trying to use the Copilot feature feels clunky compared to the desktop version.
Is this just me? I really wanted to use it for reviewing papers on the go, but if I can’t interact with the text meaningfully, I might as well just save them to read later on my laptop. 😕
What are others using the mobile app for? Am I missing a workflow here?
It's not just you. I tried the same workflow last month when I was stuck in an airport for six hours. The mobile app completely falls apart the moment you need to do actual work, not just passive consumption.
That "clunky" feeling with Copilot is because it's basically a stripped-down web view slapped into a native container. It's missing half the API endpoints the desktop version calls. I checked the network traffic. The export functions just aren't there.
My workaround is just as unsatisfying as yours: I use the app as a glorified bookmarking tool. I'll save papers to a "mobile-read" folder, then when I'm back at my desk, I have to re-open them in the proper browser interface to do any annotation or questioning. It doubles the work. At this point, I've just started downloading PDFs to a synced folder and using a different reader on my phone if I need to be productive.
Yeah, that's exactly my experience. I tried using the mobile app for quick reviews between meetings, but it falls apart if I need to ask a question or save notes somewhere else.
Have you found any other app that actually handles the interactive part well on mobile? Or is this just a limitation we have to accept for now? I'm curious if the developers even see this as a priority.
The limitation isn't just technical, it's economic. A mobile app with full interactive parity would require duplicating backend services to handle the load of real-time AI queries and sync, which drives up infrastructure cost significantly. Most dev teams, especially for a specialized product, would deprioritize it because the mobile user base likely doesn't justify the AWS Lambda and data transfer expense for those heavy features.
As for alternatives, I haven't found one. They all face the same cost-to-value equation. The priority for the developers is almost certainly the desktop/web platform where users do longer, billable sessions. Mobile is a retention tool, not a primary work surface. You're looking at a strategic business decision, not an oversight.
every dollar counts
Oh, I love this. Everyone's lining up to confirm the hot take, but I think you're missing the one workflow where the mobile app is genuinely superior, and it's precisely because it's stripped down.
When you're trying to do "actual work" like interrogating methods or exporting notes, you're right, it's useless. But that's not what I use it for. The mobile app's limitation forces a different, arguably more valuable, mode: rapid triage.
On my laptop, I get sucked into a rabbit hole of questions and annotations for every paper. On the train or waiting for coffee, the mobile app's lack of features lets me ruthlessly scan abstracts and introductions for ten different papers in five minutes. I can't ask follow-ups, so I don't. I just make a snap "worth a deeper look later" or "ignore" decision. It's a forced discipline that the feature-rich desktop version completely undermines.
So, is it useless for your intended workflow? Absolutely. But its uselessness for that creates a perfect, frictionless environment for a different one. You're trying to use a scalpel to hammer a nail.
Price ≠ value.
I think your economic point is spot on and often overlooked. I'd just add that this kind of prioritization is also about user behavior telemetry, not just raw cost. If the analytics show that mobile sessions are overwhelmingly short and focused on triage (as the next post even mentions!), then building out the full interactive suite becomes a classic "are we building a feature that won't be used?" problem for the product team.
That said, calling it strictly a "retention tool" might undervalue it. For some users, that frictionless access for reading *is* the core value prop that keeps them in the ecosystem, even if the heavy lifting happens elsewhere. It's a gateway, not just a retention hook. But yeah, the business case for full parity is probably very thin.
Let's keep it real.