Automattic Acquires Simplenote Creator Simperium

Automattic Acquires Simplenote Creator Simperium

As reported by AllThingsD, Automattic, the company behind WordPress.com and other products, has acquired Simperium, creators of popular note-taking app Simplenote.

This isn’t one of those talent acquisitions where the products aren’t part of the equation; Automattic expects to continue and extend work on both Simperium and Simplenote. “Simperium seems like a genuiune utility for our own apps and for other people as a service,” said Automattic founder Matt Mullenweg yesterday. “And Simplenote as a product I love and it’s just darn handy.”

According to Simperium, they will keep expanding their platform as a “tool for building apps”. They have already open-sourced the iOS and JavaScript components of their code, but it doesn’t look like the existing Simplenote apps will be going away any time soon. In a different blog post, the Simplenote developers explain how Automattic will help them “supercharge” Simplenote and bring it to more platforms:

You know how sometimes, the services you love just disappear when they’re bought by someone else? Or they wither and die a slow and painful death? Not the case here. We made sure of that.

Simplenote is one of the most popular third-party note-taking apps for iOS, with native clients for the iPhone and iPad that sync to a variety of desktop and web clients. On the other hand, Automattic has been criticized on several occasions for features lacking in its WordPress client for iOS, and it appears the Simperium acquisition will enable them to bring more intelligent and reliable sync to the app, though it’s unclear how and when.

You can read the details of the acquisition and transition to Automattic in the blog posts linked above. If you’re looking for Simplenote alternatives, Shawn Blanc recently shared his thoughts on the best note-taking apps for iOS and OS X. You can find our past coverage of Simplenote (including reviews of the apps) here.

Permalink

The Untapped Potential Of Dual Screen AirPlay Games & Apps

What do you know about Dual Screen AirPlay games? Chances are, you don’t know much about it and might not even know what on earth I’m talking about. It’s a feature of AirPlay - the protocol that allows iOS devices to stream audio and video to an Apple TV. More specifically, Dual Screen AirPlay is the ability for app developers to use a connected Apple TV as a secondary screen, displaying different content on the TV as to what is on the iOS device. In theory it’s an awesome feature that has significant potential. In reality there haven’t been many examples of its implementation, let alone many that did so in a unique and exciting way.

So today I look at where Dual Screen AirPlay has been used, focusing on games in particular and then look to why it hasn’t been as widely deployed. I’ll also touch upon the problems with its implementation, where it could be improved and lastly a brief discussion on its potential in video apps as well.

Read more


Apple Q1 2013 Results: $54.5 Billion Revenue, 47.8 Million iPhones, 22.9 Million iPads, 4.1 Million Macs Sold

Apple has just posted their Q1 2013 financial results for the quarter that ended in December 2012. The company posted revenue of $54.5 billion ($13.81 per diluted share), with 22.9 million iPads, 47.8 million iPhones and million 4.1 Macs sold. Apple sold 12.7 million iPods. The company reported quarterly net profit of $13.1 billion.

We’re thrilled with record revenue of over $54 billion and sales of over 75 million iOS devices in a single quarter,” said Tim Cook, Apple’s CEO. “We’re very confident in our product pipeline as we continue to focus on innovation and making the best products in the world.”

“We’re pleased to have generated over $23 billion in cash flow from operations during the quarter,” said Peter Oppenheimer, Apple’s CFO. “We established new all-time quarterly records for iPhone and iPad sales, significantly broadened our ecosystem, and generated Apple’s highest quarterly revenue ever.

Compared to last year’s Q1 – which had an extra week – Apple made $8.2 billion more revenue, but the same profit. Read more



Watermarker 1.1 with Batch Processing

Watermarker 1.1 with Batch Processing

When my dear friend and MacStories writer Don Southard released the first version of Watermarker, I didn’t know whether posting about it here on MacStories would be appropriate. However, after I’ve come to use the app and know how much Don is committed to making it great, I now think not mentioning it would be a disservice to my readers.

Watermarker provides a simple and automated way to add watermarks to images. You can choose between various options including text, your own logo, or even a customizable strikethrough. The app has a clean interface with the “canvas” (the area where you can drop an image) displayed on the left, and watermarking settings on the right. I like how you can save presets (so I can have one for my “large” MacStories watermark, another one for the smaller version), and the fact that an image’s size is reported right below its preview. Don’t take my word for it – I’m not the only one who thinks Watermark is a fine app.

Today’s update is particularly interesting for my workflow because it adds batch processing. You can drop multiple images at once into the canvas or dock icon (you can also drop an entire folder), and Watermarker will display a red badge in the canvas on top of your “stack” of photos (I wish I could click on the photos in the stack to select them). Once imported, you can set your watermark, and the app will apply it to all images at once; I like how Don also created a slider to set opacity for an image. To export, you can simply drag the images out of the canvas or save them. In both cases, a copy will be created.

I don’t like watermarking images, but Watermarker makes it extremely easy and fast. If I had to nitpick, I’d say that it’d be nice to navigate images in the canvas using the arrow keys (so you could still get a preview of the images you’re watermarking) and have AppleScript support for deeper automation workflows. Even without AppleScript, however, version 1.1 is a great improvement over Watermarker 1.0, which required you to import images one-by-one.

Go check out Watermarker here. The app is available at $7.99 on the Mac App Store.

Permalink

Due Clipper For Google Chrome

When there are no actual news or notable app releases, I prefer investing my time in creating something for other people.

Continuing my ongoing series of tips on iOS URL schemes, here’s an adaptation of my existing Due bookmarklet to work better with Google Chrome for iOS (which, as I’ve pointed out several times, has a very nice URL scheme). The following code (to install it, simply copy it and paste the entire string into a bookmark) grabs a webpage’s title and URL and sends them to Due (also powered by a great URL scheme). Read more


Create New Byword Notes From Mr. Reader

Create New Byword Notes From Mr. Reader

I’m a big fan of Mr. Reader’s new services menu. Through URL schemes (documented here), it allows the app – a Google Reader client – to send selected text, URLs, or article titles to other apps. One of the custom actions posted by the developer allows you to create a new note in Byword, possibly formatted as a linked post for your blog.

The action (which you can download here) uses by Byword URL scheme to create a new note. In the note, you can have the article’s original title, some selected text, and a source link formatted as Markdown. As shown in the image above, you can modify the template with any characters you want. For instance, I added a > character before [TEXT-SELECTED] to format the selection as a quote block in Markdown.

I personally use Nebulous Notes and Poster to create articles for MacStories on the iPad, but a lot of folks like Byword. Check out the Mr. Reader action if you’ve been looking for a way to send text and links from Google Reader to Byword.

(Bonus: here’s a quick video showing the action)

Permalink

Chrome for iOS: Send A Webpage Back To Safari Via Bookmarklet

Sort of. Here’s a fun experiment.

Today, I wanted to quickly send a URL from Chrome for iOS – my default browser – back to Safari. I know there are ways to do Safari-to-Chrome, but I wanted the opposite: from Chrome back to Safari. I needed to install some custom Mr. Reader actions, and Chrome was giving an error when tapping on the downloadable files. I figured I could make a bookmarklet to take the current webpage in Chrome and send it to Safari.

Not so fast. There’s no documented URL scheme on iOS for opening web links in Safari, except, well, the http:// scheme itself. In testing various bookmarklet ideas, I thought that replacing googlechrome with http in Jon Abrams’ bookmarklet would force Chrome to send a link to Safari. But as It Turns Out™, doing this sort of trick in Chrome for iOS:

javascript:window.open('http'+location.href.substring(4));

…simply opens a new tab in Chrome.

What I ended up using is a hack – and a very curious one – to leverage Chrome’s support for x-callback-url to open a link back into Safari. I was inspired by Cormac Relf’s script, which I discovered yesterday when he showed me another script he made for Pythonista.

javascript:window.location='googlechrome-x-callback://x-callback-url/open/?url='+encodeURIComponent(location.href)+'&x-source=Safari&x-success='+encodeURIComponent(location.href);

As you can see above, we’re telling Chrome to open a new tab using…itself. The trick, at least theoretically, is to use an encoded location.href string to call back Safari, which is registered for the http:// scheme that Chrome, in this case, opens “externally”. Displaying x-source is needed per Google’s URL scheme specification; the name you give to x-source will be displayed as a “back” button in Chrome (as shown in the image above).

This is a profoundly inelegant and ultimately flawed solution. To make this “work” you have to:

  • Type the bookmarklet’s name, because Chrome has no bookmarks bar;
  • Nothing will happen.
  • Close Chrome;
  • Re-open it;
  • A wild new tab appears!
  • Tap the Safari button. It’s super-effective.
  • Safari will launch the link, closing the additional tab Chrome decided to open.

What is going on, exactly? Via JavaScript, we’ve forced Chrome to open a tab in itself, but doing so with x-callback-url inside a bookmarklet creates, for some reason, quite a strange behavior: the tab isn’t opened unless you close and re-open Chrome, therefore partially defeating the whole purpose of this bookmarklet, which is to quickly open a webpage in Safari. But, in spite of the clunky process, a new tab with a “Safari button” is created nevertheless, allowing you to tap it to launch Safari and close Chrome’s extra tab.

My conclusion is that we have three solutions: a) it’s not possible to create a straightforward Chrome-to-Safari bookmarklet; b) it’s possible in another way that I haven’t explored; or c) it’s possible with the x-callback-url hack, but in a different way.

If you have ideas, ping me on Twitter.