Looking for Clubhouse? You've found it. But as of September 7th ournewnameisShortcut.

Evolving our mobile experience

Andrew Childs

You may have heard we’re changing our name to Shortcut in September. As we evolve, we've also been doing a lot of thinking about the direction of our product and what functionality is most important to our users. The mobile experience was critical to all of that. Here’s what we considered.

We currently provide three different mobile experiences:

  1. A native iOS app
  2. A native Android app 
  3. A mobile web app 

Of these three, the most fully-featured option at this point in time is the mobile web app. This isn’t because the native apps have fallen behind where we wanted them to be, but instead because of conscious design choices we’ve made with our desktop web app. The long-term plan for our product has always been to create views that work just as well on a mobile device as they do on a desktop.

So we want to put even more emphasis on ensuring our mobile experience is perfectly aligned as a companion experience to our desktop web app. This is why we’ve decided to sunset our native apps at the end of August. This will enable us to deliver mobile functionality that is most useful to customers, faster than how we currently deliver it to three separate places. Also, why should we encourage customers to use native apps on their phones that aren’t as complete of an experience as simply logging in through their browser?

What does this mean for the native apps? 

On August 31st, currently installed iOS and Android apps will stop functioning. Of course, any and all work you’ve done, and data you’ve entered, through these native mobile apps will continue to show up in the browser version of Shortcut. Unless you have a draft saved just within an app, as that won’t have been submitted outside of it.

It’s worth noting here that the one feature the native apps have that the mobile browser version does not is built-in mobile notifications. We recommend replacing these with either Slack or email notifications if you don’t already use them.

The evolution of our mobile strategy

The nature of being “on the go” changed with Covid. And while the remote-first work environment may become less and less “remote-first” over time, we don’t expect a remote hybrid work environment to disappear any time soon. Few people are getting on their phones to work for 45 minutes while on a train commuting to the office (no one should be working on the train anyway, that’s when you listen to music and stare off into space).

As noted above, the long-term vision for our product is to create views that work just as well on mobile devices as they do on the web and desktop. Sunsetting the native mobile apps allows us to focus on providing the same great experience on every device, with the same features and improvements we’re releasing to the web app. 

We can now better consolidate our codebase and focus our attention and strategy on building a truly great web app and mobile web browser experience.

What's next

There is a lot more we can and will be doing to make our software truly accessible on mobile and touchscreen devices by focusing our efforts in one place.

Evolving our mobile strategy is key as we’re making significant, long-term investments in our web app. This includes many new features (like Teams, Roadmap, and Custom Reports) and all-around improvements, like rolling out a new GraphQL data layer and building reusable, accessible, high-performance components.

We’ve also done a usability audit of the mobile web app, and identified 20 UX improvements we want to make. We’ll be prioritizing and working on them in the coming months to ensure our mobile web app experience continues to get even better.

But even as we do so, this is a good spot to again note that the mobile-web experience is now more feature-rich than the experience provided by our native apps. This will only get better as we continue to build out a robust component library.

All that said, this doesn’t mean we’ll never return to having native mobile apps. Particularly as we consider the possibility of a desktop app and continue to further invest in React components within our web app. For now, though, we want to ensure our mobile experience is perfectly aligned as a companion experience to our web app. Taking these steps will enable us to work together to do that, instead of building two apps (web & mobile) concurrently. More teamwork, better results!

Now we can put even more resources and energy to evolving that mobile experience to make it even better.