Automattic Unveils Open Source Desktop Application for the Mac

In the last two years, Automattic has made significant improvements to and Jetpack. From managing plugins, themes, and other updates to New Dash and a revamped post editor. The individual changes represent iteration but when seen as a whole, show off an entirely new

Automattic has announced that the improvements its made in the last two years are part of an internal project named Calypso. The company also released a desktop application for the Mac and open sourced the code on GitHub.

The application is written entirely in JavaScript using the Node and React libraries. It’s also 100% reliant on APIs, including the REST API.

My Experience with Calypso

Over the weekend, I tested the application on my Macbook Pro. I initially thought it was inconsistent as there were many instances where a button opened a browser and took me outside the app. However, Calypso has gone through a number of updates and most of the inconsistencies have disappeared.


Most of what you’re able to accomplish in the WordPress backend you can do in the app including, editing posts, creating drafts, and moderating comments.

Calypso2Although there is the occasional Beep….Beep….Boop, the application is fast. Some of the pages within the app feel like they load faster than their browser counterparts. Some things still require action from within a browser such as applying updates. This doesn’t make sense considering the Jetpack Manage module is enabled.

When managing themes, I noticed at least two of the them don’t include the white bottom bar making the titles difficult to read. Also, the details link loads a browser window to the backend of the site I’m managing. It feels like an interruption instead of a seamless experience. There should be no reason to load a browser window except for previewing a post.

Managing Themes in Calypso

If you’re familiar with or use the post editor, the editor in Calypso is pretty much the same.

For years I’ve written posts with meta boxes on the right and getting used to them on the left will take a while. The editor has most of the features available in WordPress. For example, oEmbed support which many other third-party WordPress apps don’t have.

When the application is in full-screen mode, it looks great and blocks out distractions. In the most recent update however, the Preview button acts like a Save button and doesn’t show a preview of the post. This is likely a bug and will be fixed in a later version.

CalypsoPostEditingScreenCalypso is a great example of what’s possible with the WordPress REST API. There are still a few instances when clicking a button takes you outside the app but those will be fixed in future updates.

Overall, it’s convenient to have access to most of WordPress’ features without interacting with a browser. For those who use a Mac, I can easily see Calypso being the preferred way to interact and manage WordPress sites.

As Matt Mullenweg mentions in his post, there’s still a lot of work left to do, “This is a beginning, not an ending. (1.0 is the loneliest.) Better things are yet to come, as all of you dig in.” Calypso is available for free but you’ll need a account which is also free.

If you own a Mac and test drive Calypso, please share your experience with us in the comments.


74 responses to “Automattic Unveils Open Source Desktop Application for the Mac”

  1. It’s interesting to see Automattic continuing to build a completely alternate user interface for WordPress. It’s a nice looking interface. I haven’t tried it yet but from a UI standpoint it definitely looks cleaner than the WordPress admin.

    With this and the other updates they’ve been making and putting into Jetpack, it’s becoming clear that we’re now into a world with two WordPresses: the one you get from, and the one you get if you add a boatload of Automattic features on top of it.

    Part of why I use WordPress is that I don’t want huge portions of my publishing experience under the realm of a single company.

    • Replace “company” with “organization”, and using WordPress itself is already coming from a single place. It’s usually not the originator that’s the issue, it’s your rights and freedoms inherit in the experience today, and down the line.

      Automattic is a commercial company, but I hope that the experiences are as open and free as pretty much any company out there. And at the end because things are open source you have control even if Automattic went a direction you didn’t like. Today things in Calypso rely on Jetpack and the .com APIs, but I bet within a year that won’t be the case any more, especially now that the code is public and open source.

      • Right – I’m psyched that Automattic has not only created Calypso, but also kept it GPL. That’s going to be a huge leg up for developers wanting to create .org-specific desktop apps. Kudos for that.

        I’m picking it apart already :)

      • Thanks so much, Matt, for making it Open Source!

        I did see it coming- was wondering how long it would take to push within WordPress itself.

        You’ve done a great job to push it faster from Automattic instead- my grateful gratitude to you and the team.

  2. I’ve been expecting this for some time. Excited to see that it is available. Haven’t had opportunity to test, yet. Anyone know whether offline drafting is allowed, as on the iOS app?

    • Offline mode is the first thing I tried and sadly, it’s not supported yet. However, members of the team told me it’s being discussed/worked on.

      • Now that I’ve played with it, it looks like they took the Slack approach for developing this app, which is not a bad thing at all.

        It will be really interesting to see where this goes in the future. It will also be interesting to see what the community adds to it or if anyone forks it and develops alternative interfaces and solutions.

        I mean this totally opens the door for a whole new class of WordPress apps. Now someone could theoretically create a desktop style application for building themes / websites now without the user ever having to touch a line of code.

        This is also a really great approach to phase out the current WordPress approaches, and slowly introduce a new way of doing things.

  3. Since Calypso (parts, at least) uses REST is there any technical reason it should require Jetpack?

    Does anything think there is hope for a Jetpack-free implementation?

    • Currently the various endpoints needed to power Calypso are not yet attainable with the REST API planned for core. However, as the core API matures, covering more and more of these needs, it would be absolutely feasible to make it work. Having Calypso in the open is also a way to communicate these needs so we can help shape an API that people can eventually use directly to power their WP app.

  4. Some things still require action from within a browser such as applying updates. This doesn’t make sense considering the Jetpack Manage module is enabled.

    To clarify, Jetpack Manage allows you to update plugins, but you can’t update themes, translations or Core yet. That’s why you still need to go to the dashboard for those.

    That may change soon, though :)

    I noticed at least two of the them don’t include the white bottom bar making the titles difficult to read.

    I checked that issue, and it seems that Hybrid News’ theme screenshot is a bit higher than the standard (300x435px instead of 300x225px). That doesn’t mean we can’t do something about it, though! I logged the issue here, thanks for the report!

    Also, the details link loads a browser window to the backend of the site I’m managing. It feels like an interruption instead of a seamless experience.

    I took note of this here:

    Thanks for the feedback!

  5. My personal opinion is that non-native apps really doesn’t nail the proper user-experience. This is a sort of hybrid between a web-app and something desktopy, so why not just have a web-app? Don’t see the need for it.
    The same with Slack for OSX. Its shait.

      • But why the hell use time on developing some half-baked non native, UI-frankenstein (cr)app? It is bloated and slow. Fokus on what matters.

        • It’s not the end of the world. I hear what you’re saying but I think Calypso is far from crapp. This is the first public version, it will get better with time and sooner rather than later, will have a native feel to it. It doesn’t make sense not too. Although, I think it will be native to and not self hosted WordPress which will be a turnoff for many.

        • By running it natively, you don’t need to have all your browser extensions running in it, which tend to be resource hogs. It also keeps all the JS and CSS locally, which will makes things load a little more snappily.

          I wouldn’t bother downloading it for that reason, but those are some advantages I can think of for going down that route.

          In future, it will allow them to store a lot more data offline too. Most browsers don’t allow you to store more than about 5 MB of data offline per site, which would be quite limiting, whereas a native app. can ramp that up as high as it wants.

        • I have to agree a bit.

          While I understand this showcases what can be done with REST API, and is a great launching point for people building custom interfaces into WordPress (important, for sure)… I’m frustrated to see this kind of work prioritized over other stuff that would seem to be more basic. For example, a better comment system. Or putting more resources into bbPress/BuddyPress. Or (from a post or two back) making a better repository to make life easier for developers.

        • @Steve I think it’s worth noting that the projects you mention are developed by different people:

          bbPress, BuddyPress, and the upcoming WP REST API are all community projects; if you’re interested in one of those projects you can join them and help with developing, testing, or documenting. For the people contributing to those projects, I don’t think it’s a question of prioritization; they contribute because they like the project and would like to bring it further. That’s how WordPress works!
          The interface and the desktop app mentioned in this post are developed by Automattic, the company making, and consequently prioritizing ?

          I don’t think there is any work being done to improve WordPress’ commenting system, though. If you’re interested, do not hesitate to start looking for people who would want to help with that, and start working on a Feature plugin that could be merged into WordPress Core some day!

        • Hey Jeremy… but isn’t that somewhat problematic?

          I mean, I assume the comment system is something utilized by folks too (can they even change to anything 3rd party?). I mean, it’s a platform – that while much more than a blogging platform – you’d think would have solid core blogging/communication components after being over 10 years old and composing 25% of the Internet, right?

          I guess what I’m saying is that I realize all these things are community projects, with some getting little to no attention… and I’m confused why that is the case. Is the concept that we should be moving to 3rd party solutions if we need more than crude functionality in that regard?

          I’m going to switch my sites to Disqus in the near future, but I just don’t get why that should be necessary.

        • @Steve These are legitimate questions. I don’t have an answer for you, as I honestly have no issues with the current commenting system in WordPress. The default could obviously be a bit better, but it’s simple enough, it works, and it’s easy enough to extend it through plugins and the different filters the comment form offers.

          But if you have ideas for improvements, or find bugs that should be fixed, I’d suggest opening tickets on You’ll see if others share your opinions, can reproduce the issues, and are interested in improving the current system.

  6. I tried it out this afternoon and it looks promising, but what about those of us who manage many different WordPress websites – each tied to a unique Jetpack/ account?

    I have always had my clients sign up for their own Jetpack account so that they can keep full ownership over their data.

    Maybe I’m doing it wrong?

    • I’d recommend creating 2 accounts on your client’s site:
      * A master account for your client, connected to their own account, so they own everything.
      * another admin account for you, connected to your own account, allowing you to manage their site for them.

      With this method, your client knows you have access by going to the Users menu in their dashboard. And if you don’t work with them anymore, you can delete your account without breaking their Jetpack connection or losing any of their data.

        • Each registered user on a WordPress site using Jetpack can go to the Jetpack menu and connect their account to their own account. There is no limit to the number of users that can connect.

          The first admin connecting Jetpack to their account will be considered as the master Jetpack user, but all other admins who connected their own account will have the exact same privileges on If someone can activate / deactivate / update plugins on the self-hosted site, they’ll be able to do it on as well once they connected their account.

          Once you’ve connected more than one account, you can monitor and manage the list of connected Jetpack users by going to the Jetpack menu in your dashboard, and clicking on “My Jetpack”.

        • Interesting… I didn’t know that. Thanks!

          When you say ‘the first admin to connect’ is that the very first time, or each time? (i.e.: on a couple sites I manage, we’ve used both my account and the client’s account after updates and such… are we messing up their stats? We were just trying to make the plugin happy. :) I guess we don’t care about those stats that much anyway, but you’ve got me curious now.)

        • When you say ‘the first admin to connect’ is that the very first time, or each time

          The first time Jetpack is connected to You can go to the “My Jetpack” menu to see the current status of your site, and switch master users if necessary.

      • Thanks for the tip Jeremy! I’m not a big-time Jetpack user and I wasn’t aware of the “multiple admin” feature or the ability to switch the primary admin. This is great news!

  7. I am really excited to try out the desktop app. I think this could be very helpful for bloggers who write on multiple sites and for Agencies that manage multiple sites.

  8. I am liking the concept and can’t wait to dive into it. I know the love/hate relationship with Jetpack that is out there. I also know that most of the love comes from the user side.

    And for many reasons over the last couple of years, I have become fond of it more and more :)

    Interesting as I did a workshop specifically on Jetpack a bit ago. The feedback was what I really wanted to hear. Going through each module, step by step, opened up a lot of eyes, and I believe I won a few over in the workshop that we otherwise skeptical.

    Specifically the Management module was something that surprised people, even those that use Jetpack. From reading the posts today I feel this has just empowered that piece and it looks pretty amazing.

    Excited to see how this grows and what is next. :)

    • I certainly have warmed up to Jetpack as well. So long as it only runs the modules I turn on, I’m pretty happy having it around. I guess my main complaint is that so many of the modules are only kind of useful, and have better stand-alone plugins out there which I use instead. (And, since I run on premium hosting… a bunch of them just aren’t necessary for me, I guess.)

      I can see something like Calypso being useful for site-end users. It should be easy to build a unique app front-end suited to particular job duties of adding content to a site. That’s what has me most excited. Though, if it eventually gets good enough, maybe I’ll consider it for managing sites too.

  9. According to Wired, this thing uses Node on the backend.

    I can’t think of a reason Node would be needed on the backend of this though. WordPress uses PHP, so adding server-side Node into the mix seems kinda pointless. The only reason I can think of for using Node server-side, would be for replacing the PHP in WordPress. But at that point, it’s just a fork of WordPress. And I somehow don’t think that’s what this is :P

    Or am I missing something obvious here?

    • Looking at the repo it’s a lot of development/build related stuff. Websockets is used as well. Another cool thing its modern ES6+ code with new module import export capabilities. Very nice.

      When deploying it as a desktop app, node adds a ton, working with the filesystem for example. Would be really cool to see it completely offline capable. I wonder if Simperium will come into play somehow. WordPress as a backend and simperium to manage syncing between local and server, that would be awesome.

    • My guess is node.js is being used to run the same JavaScript code of the client on the server, isomorphic JavaScript as it is known. I think they do this so the server can answer a request from a browser instead of serving a blank page and then have the browser send a request back to the server to get the data to render the page. It saves a trip and makes things faster.

    • I have a (possibly crazy) theory on why this might be the case.

      Perhaps is attempting to dump PHP entirely?

      From their perspective, they could rebuild WordPress entirely from scratch in Node, yet still hook into the original PHP software us unwashed masses are using via the new REST API.

      This would allow them to totally ditch all of the excess backwards compatibility baggage that WordPress carries around, yet still allow us unwashed masses to continue using the original PHP setup.

      I was already seriously considering learning Node, so this would suit me quite well :)

    • From the ycombinator thread:

      The node.js aspect of Calypso is actually pretty minimal, basically to build the shell of the web page. WordPress and PHP still power the API behind Calypso as well as the entire front-end of the site (i.e., what your readers see when they visit your blog). I don’t think either of them are going away anytime soon.
      The .org community (self-hosted WordPress) is also getting serious about API-based interactions, so this isn’t an entirely new direction. I think we’ll be seeing front-end JavaScript becoming more and more important there as well. There’s still a lot to figure out, but I think the open-sourcing of Calypso that happened today will make it easier to share ideas with the greater WordPress community.


      • What I would love to see is work on custom dashboards. Right now there is a big need for an enterprise dashboard where speed and effectiveness is the prime focus (faster page loads and more javascript based, which is exactly what we see with Kalypso). A lot of my clients would love a faster editing experience and for bigger companies this means money saved.

  10. Oh wow! It’s amazing what kinds of stuff people can make now as desktop apps without having to write desktop code. Although, I kind of wish it was native a bit, but that’s just me. I’m going to give it a test run through for my own blog ( on full screen mode!

    I love full screen mode on my own OS X machine, so it’ll be great to have a WordPress native app going full screen. I think this will be simpler in some respects than having to access all of my blog(s)… although I hope my custom login plugin doesn’t cause a problem.

    I’ll let you know when I get it running whether I’ve had a problem with a custom login plugin. Until then, good work Automattic!

  11. Write more content, manage it less. I’m for whatever makes things easier for the end user and this looks like it’s going in the right direction. I look forward to testing driving this!

    • The significance of this is not that it’s a desktop app, but the fact that they’ve open sourced the editor they use on (and happen to have wrapped it into a desktop app intially).

      Their new editor is possibly more efficient and easier to use than the wp-admin editor.

    • There are some advantages to a desktop app BTW. They usually run a little quicker, as they’re not bogged down by browser extensions, and some people seem to like having things in their own window, without the browser omnibox.

      In future I can see advantages too, such as not being affected by the browsers offline storage limitations.

      None of this is going to make me download a desktop app. just so that I can edit a site though :P The current wp-admin interface works just fine for me.

      • I started out not really sure how/why I would use it day-to-day (outside of purely Automattic work), but it grew on me first as a consumption tool (wrote a little about that on my site), then, since I already had it open, started doing more and more editing/management via the app.

        I still love wp-admin—don’t get me wrong—and use plenty of plugins that require me to still, but it has been nice to be able to write up a quick initial draft of posts on different sites in one place without having a dozen browser tabs open for each, which is how I usually end up.

        (Full disclosure: Automattic employee)

        • But that doesn’t explain why you prefer a native app instead of a web app. You could do the same via a plain old web app if you wanted to.

        • @Ryann, because every generation has to redo the mistakes of the previous one. Web app is just not challenging enough, they are lacking the excitement of supporting 20 versions of the same app on 20 OSs both at the software side and on support forums. :)

        • @mark k. – I don’t think that really applies here. It’s just a web app. wrapped into a desktop app. It’s presumably simple to port to other platforms and won’t suffer the same platform compatibility problems that “real native apps” do.

  12. I am not sure if desktop app for one platform is a great idea. WordPress used to be WordPress on any platform. There was no favoritism. Folks on different platform will have different experience. You can say that web app is not going anywhere but sure the resources has been divided that’s gotta show up in end user experience.

    • It’s pretty much the same code that will run everywhere on the web or desktop on any platform, so it’s not like a particular platform will have to draw away a lot of time from stuff that benefits the whole project. The only favoritism on display here is that they opened with a mac app, it would not have been that hard to launch it on windows and linux at the same time.

  13. Wow, great move by Automattic.

    Open sourcing front-end that among other things connects to WP REST API? Brilliant!

    And the Mac app? Slick. Like Slack on Mac.

    I reckon that in the future Jetpack connection for self-hosted sites will be made entirely obsolete and that Calypso will fully communicate through REST API endpoints. And Calypso forks that will communicate to endpoints published by plugins and themes? Heck, perhaps ManageWP is getting serious competition this time :)

    Only surprised by the sensationalist reports that WordPress is “dumping PHP for Javascript” which have nothing to do with this.

    • Really interesting to hear your opinion on this Valdimir. I’ve understood that you are very open to competition and I can easily see how ManageWP might be getting some of it with Calypso.

      Haven’t looked into how well Calypso handles remote upgrades, for me that’s the killer feature that could make people prefer one solution over the other.

      Looking forward to reading about Calypso on the ManageWP blog to hear more about your opinions.

      • I’ve beat Vladimir to it :)

        Calypso is awesome news for everyone, including ManageWP, for both personal and business reasons.


        Personal: we love WordPress, and Calypso is the first step in an exciting new direction.

        Business: Target audience and market share.

        Here’s more on an article I just published:

    • I haven’t read the article you linked to, but I did post a theory above about how perhaps this is the first step in a move by Automattic to migrate their own site from PHP to JavaScript without disrupting dot org. I am probably totally wrong of course, but I don’t think it’s an entirely impossible concept.

  14. Reading this I was thinking that it would be great if we had a similar app focused solely on content creation and editing (no “Discovery” options or changing site-wide options), pretty much like the excellent but discontinued Windows Live Writer.

    It could probably take advantage of the WP-Rest API and it would be a tool specifically for Editors and authors who don’t (want to) know how to change the site’s settings – all they need it to create and publish their content fast and hassle-free (no logins, work offline, manage multiple sites etc).

    In fact, if it were open source, developers could modify it to include their custom posts, meta and taxonomies, extend it with plugins (e.g. multilingual or SEO extensions) etc.

    • That already exists. It’s called LyX. Pair it with LyXBlogger, and you have the best way I know of writing posts for WordPress. (It uses xml-rpc but, since it’s all open-source, there’s nothing to stop anyone making it work with the REST API as well.)

      You even get the added bonus that LyX produces the best PDFs around (and can export to ePub, Markdown, etc) so you can just write in the one program irrespective of the type of output you want.

  15. Looks great but also seems that it’s a one size fits all editing experience and a couple of questions come to mind from a quick look…

    Can TinyMCE be customised for users?: I usually customise the editor matching the fonts and styles to the site’s frontend and giving them custom styles they can apply to element, also use the TinyMCE Advanced plugin to give them extra tools like table editing as well. Doesn’t appear that any of this will flow through to the app.

    Custom post types: Am I right that only ‘standard’ posts and pages are editable via the app right now and that custom post types will jump out of the app to browser?

  16. I think Calypso is not just about and a Front-End Desktop App, but a larger picture of the future direction the WordPress system is also taking. Seeing Calypso for .com and the REST API coming out in 4.4 is not giving mixed signals, but a unification in a single direction.

    Our CTO has actually tried to dig deeper and understand the architecture of Calypso and the possible future possibilities and direction WordPress is taking. Cannot add all the points here, but the blog here This is definitely the biggest thing being talked about in the WordPress community right now Emily.

    In fact, our CTO has analysed this and provided a architectural breakdown of Calypso and provide his thoughts on the future direction WordPress is taking. Could not add all points here but the blog post should be a complementary for readers here. could be helpful.

  17. I don’t see, or even, moving away from PHP. With PHP 7 just around the corner, most of the glaring performance issues are no longer issues. I do, however, think that we will see more client-focused work, such as themes and the admin UI, moving to REST-based implementations and abstracting away more of the PHP core code.

    I was disappointed to see that this wasn’t built to use WP REST API right away, but rather uses the API, though I understand why – WP REST API isn’t in core yet. The Calypso team has publicly stated, though, that they expect to see parity between the two APIs in the future, which could make the Jetpack requirement go away completely. Either way, this is an exciting development and a very forward-thinking modern architecture glimpse at the future of WordPress!


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: