Ken Case on OmniPresence, which ships tomorrow:

"OmniPresence is designed to work well with any Mac app which supports OS X’s Auto Save and Versions. Using the same underlying document coordination as Versions, OmniPresence lets your app know when a document has been changed on another device, and double-checks to make sure it always syncs a current and complete copy of any documents currently being edited."

…

"We believe in building solutions that will stand the test of time, and we believe that your data should be yours to control—whether you’re syncing your personal files or your company’s confidential information. So rather than use a proprietary syncing service which might not be available in five or ten years, OmniPresence is built on top of open web server technologies."

OmniPresence is a new syncing tech from the Omni Group, and it ships tomorrow. You know it's going to be solid because … well, it's written by the F'n OmniGroup and that's what they do.

WWDC 2013 is fast approaching, and chances are good that we'll get some sort of preview and song and dance about how iCloud sync is even better than ever for developers. Honestly, would you expect Apple to say anything else?

But how are we going to know Apple has finally fixed iCloud syncing for developers and is really serious this time? And I'm not just talking about Core Data syncing, I'm also talking about the APIs developers are given to push document data back and forth. The broken stuff, the things developers laugh at Apple about and have given up on.

Here's my short and inconclusive list of things that will let us know iCloud might be ready for real world developer use.

1: iCloud APIs are no longer tied to monolithic OS updates.

This was the very first thing that set off alarms in my head when Apple introduced the iCloud APIs. It's baked into Foundation. Not "at the foundation of the OS" marketing talk, but the APIs are exposed to us via Foundation.h. This is a very, very bad code smell. Things on the web and in sync land move fast, and if we have to wait 12-18 months for something to be fixed or updated, why in the world would a developer adopt it?

Oh, you say it's all fixed on 10.9? That's great. How about all those users who aren't updating to that OS for whatever reason? Oh, they are screwed? Great. That's what I wanted to hear.

.Mac syncing sucked- but it had a downloadable SDK and it was the sane way to do things. You could download an update which fixed bugs and it was possible for Apple to add new APIs without having to do it in sync with the OS. Just because an idea had a bad implementation doesn't mean the idea is wrong.

2: iCloud sync uses sane APIs.

Dropbox is popular because it's a folder. And you put stuff in that folder. And it syncs that folder. And it just works.

Apple needs to make iCloud document syncing that simple. No need for file coordinators, no blocking when saving, no crazy continueThisBlockWhyIsTheStack40FramesDeep: methods, simple notifications when a file is updated.

There's an old AppKit/NeXT saying: "Make it work. Then make it work right. Then make it work fast."

For iCloud syncing I propose: "Make it easy. Make it simply work. Get crazy after that."

We obviously need atomic operations at the package level- but don't make it required for the developer to adopt. Or at least make it work without exposing how it's happening. I want a folder that I can write to, that'll just sync. Make it happen and make it dead simple to adopt.

3: Apple uses the iCloud APIs for their own apps.

When iCloud was introduced, Pages on iOS certainly wasn't using the same APIs Apple gave us for syncing. Why not? I guess because it was broken and/or unreliable. Something third party developers had to find out on their own.

When Apple's consumer apps use the exact same APIs we are given, it might be time to seriously look into using iCloud for doc syncing.

4: Apple gives us some server side tools to kick things.

Why are there no developer tools that let us see the status of syncing data? Why is there no website for developers to log into to watch data transfer from one machine to another, or to know which bit of data came from where? Does Apple understand how hard it is to debug things when we have no access to "The Truth"?

I think Apple's answer as to why we don't have this is because "it should just work". Well, it doesn't. And to pretend otherwise is to sow distrust among your developers. Start with an assumption that it's going to break, and break hard. Give developers tools to analyze and clean things up. Apple gives us pretty great tools for debugging and improving code running on our local machines. We need the server side equivalent of that.

…

I've got more ideas, but I think these four things would be a great start.

I really want to use iCloud. But I just don't trust it and I don't want to waste my time implementing and debugging things when there's other syncing solutions out there that just work.

This has been a pretty awesome week for Acorn 4. Tons of great press, 4.5 mice, App Store Editor's Pick, amazing sales, and just great excitement around the newest pixel nut.

Here's how the past week unfolded.

Getting the Server Ready

Before the launch I had to get the server ready for the massive number of hits I was hoping it would get.  When we released Acorn 3 I was caught completely off guard by the amount of people visiting the site.  I've been linked to by major publications before including Daring Fireball on a number of occasions, and my server always held up admirably.  But with the release of Acorn 3 so many folks were hitting my server that there were a couple of minutes where it was unresponsive. I had to quickly reconfigure things to make it load faster.

But this time I was ready.  When folks visited Acorn 4's site on launch day, the only piece of data loaded from my server was the HTML for the page. Everything else was hosted on Amazon S3.  Images, CSS, JavaScript files - everything.  And it worked beautifully.  The page loaded super fast at all times and the server didn't even break a sweat.

Timing the Release

Acorn was set to be released on Thursday, May 2nd.  Releasing an app on my own site is a very simple process. I move some files around and it's launched.  But when you want to release an application in Apple's App Store, you set an availability date and then it starts rolling out at 12:01 AM on that date.  Easy enough, right? There's one little problem.  It releases at 12:01 AM… but in what time zone?  Well, it turns out all of them. People in New Zealand would be getting Acorn 4 about 19 hours before folks on the west coast.

There are a number of reasons why this isn't great.  The first is that if Acorn shows up for folks in NZ, they would then be tempted to start singing its praises on Twitter. People in different time zones would then look for Acorn 4 and not find it. We would start getting hit with questions like "where the hell is it, why can't I buy it, why are you excluding us, you suck!”, etc.  A rolling release like that would make for a whole lot of work when we're already too busy trying to tie up loose ends.

Another big problem was that a number of news sites had embargoed press releases that were set to expire on Wednesday night.  I really didn't want news sites that didn't already know about Acorn 4 to get a jump on the publications that couldn't publish because of our agreement.

I was chatting about this problem with a friend when all of a sudden a solution hit me. I could set the release to May 3rd, and then when I was ready I could just push the release date back to May 1st!  Since May 1st was already here (and gone in some time zones) Acorn 4 would roll out everywhere at the same time, which was exactly what I wanted.

So that's what I did.  At 7:30 PM on Wednesday I set the release date for Acorn 4 to May 1st and Apple's servers started doing their thing.  I actually gave the App Store a 30 minute head start on the release because I wanted to make sure it was there and ready immediately when the Acorn 4 site went live.  Then at 8:00 PM on Wednesday I pushed the Acorn 4 site, updated the Flying Meat store, and the embargoes were lifted.

Holy Crap Everyone Loves Acorn 4!

Macworld had a great review of Acorn and gave it 4.5 stars! Acorn 4 adds impressive features and a smart new look

Jeff Blagdon from The Verge interviewed me a few days before and had a great review of Acorn 4 as well: Acorn 4 flies through image editing with new filter UI, improved speed, and curves.  I even have my own tag on The Verge now!

MacStories wins the trigger finger award for publishing 4.7 seconds after the announcement: Acorn 4.0 Brings Non-Destructive Filters, Updated Interface, And More

Daring Fireball had great things to say about Acorn 4 as well: "An almost unbelievably great update to Flying Meat’s already-great image editor for the Mac".  And holy crap, when John Gruber links to your site, you better be ready for a ton of hits.

Ars Technica had a great announcement as well: OS X image editor Acorn hits version 4 with 150 new features.

Mac Rumors had a write-up too!  I believe this is the first time Flying Meat has been mentioned there, which was nice to see since I visit that site quite often.  Acorn 4 Image Editor Adds Improved Speed, Enhanced User Interface and More

Even non-tech sites were picking up on it, such as the Houston Chronicle! Acorn image editor worth scooping up.

I could keep on listing the reviews and posts about it- but you get the idea.  I was pretty floored at the attention Acorn was receiving.

App Store Editor's Choice

And then at about 1:00 PM PST time on Thursday May 2nd, Acorn 4 was front and center on the Mac App Store with the coveted "Editor's Choice" award for the week. Sweeeeeeeeeet.  Needless to say, Acorn's App Store ranking shot through the roof.

Adobe Creative Cloud

A couple of days later on Monday May 6th, Adobe announced that Photoshop and their other CS products were to become subscription only. With Acorn in the news and Adobe announcing this giant change, people who hadn't looked at Acorn before certainly were now.  We received a ton of questions, the requests for Photoshop specific features shot up, and the focus of attention on Acorn grew a bit more.

It's flattering that people consider Acorn a worthy competitor to Photoshop now.  And certainly for some things Acorn is up to the task. But as I've written in the past, it isn't Acorn's goal to be a Photoshop clone.  There are obviously a number of features that both products are going to share since both are image editors, but I really don't want to ape what PS does.  What's the point of that other than being a cheaper imitation?

Acorn is fundamentally different and I want it to find its own way forward.  I believe this will make Acorn better suited than Photoshop for some things, but not everything.

As an aside- John Nack was in Seattle last night and came out to the local Cocoa programmer's meet up and I got to chat with him for a bit.  John works for Adobe and was at one time the senior product manager for Photoshop, so it's always fun to talk to him about what's going on in the industry.  But it's weird. I just can't manage to put it in my head that I'm competing with Photoshop or Adobe or this guy who was sitting across the table from me in any way.  People just seem to want this story to happen, which I guess I understand. Industry drama can be fun sometimes.

So What's Next?

Updates of course!  There are a bunch of features that I wanted to get into Acorn 4 that just didn't happen in time, and there are bug fixes that need to be done as well.

Be sure to stay tuned because Acorn is just going to get better.  If you haven't purchased Acorn 4 yet, you better jump on it soon. The temporary discount is only going to last till the end of May.

Acorn 4 is out, and I'm slightly proud of this bit of code.

A brand new UI, non destructive filters and layer styles merged together in one great bag of awesome, curves, much improved vector tools, and speed. And that's just some of the big stuff. There's a ton of little things which when added all together make Acorn feel and work better than it ever has.

Do me a favor- if you've written Acorn off in the past, give version 4.0 a try. You just might be pleasantly surprised. And if you've been using Acorn for years, I think you're really going to love what we've done with it.

For the month of May, we're offering upgrade pricing on Acorn 4 to everyone- $29.99. If you'd like to move from the Mac App Store to the direct version of Acorn, or the other way around - you can do so without having to repurchase Acorn all over again. At the end of May, we'll be raising the price back to normal levels.

And finally, for fun, here's a little video I whipped up of the new filter UI in action:

Last summer, Adobe killed their image exchange format "FXG". The idea was to have a publicly defined XML based image format which could handle vectors, bitmaps, and layers, and could be read and written by any app that wanted to support it (as Acorn did for a while).

I can't say I'm sorry to see it go. It was a horrible format. The goal is worthy, but the implementation of it was an incredibly bad idea. When you want to send someone an image you want to pass them a single file, not an XML file with a folder of assets. While there are technical benefits to this, it's an incredible burden on the customer.

There is of course PSD which is the native format for Photoshop, and over the years it has become the de facto standard for layered images. PSD is a crazy format and implementing a reader and writer for PSD files is non-trivial and nobody but Adobe actually supports it correctly. It's crazy hard (and I'm not blaming Adobe or PS engineers for this- extending a file format for 25 years isn't exactly an easy thing to do).

So what would be better?

Quote from Appropriate Uses For SQLite.

There's my vote. Acorn has been using SQLite as its native file format since version 2.0, and it has been wonderful. When writing out and reading in an image I don't have to think about byte offsets, I mix bitmap and vector layers together in the same file, and debugging a troubled file is as simple as opening it up in Base or your preferred SQLite tool. This sure beats opening a PSD file in a hex editor to figure out what's going on.

Using SQLite for an image format has a ton of advantages:

• SQLite is easy to use and easy to embed. It's also public domain so there's no licensing to worry about.
• Just about every scripting language worth its salt already has binding for SQLite, or even ships with it installed. Anyone can write a simple Python script to look inside a sqlite file and dump out or update the contents.
• Scalability. A SQLite database can grow in size to 2 terabytes.
• It's Atomic. With transaction support you aren't going to be writing to an image and have partial saves when the power goes out.
• Updates. Changing a single layer of a 2000 layer image doesn't need to update the whole file. You simply update the row associated with the layer, and go on your merry way.

A simple schema for the database will also go a long way. Here's the three tables Acorn uses:

create table layers (id text, parent_id text, sequence integer, uti text, name text, data blob);

This is where your layers are stored. The id of the layer is a unique identifier (UUID). The parent_id is the layer's group UUID; if this value is null, then it's a top level layer. The sequence is the order of the layers in the group, the UTI is the type of the data the layer holds, and the name field is UTF8 that is shown to the user in the layers list. The final field is data for the layer.

Acorn uses 'public.png' for its bitmap layers, 'com.flyingmeat.acorn.shapelayer' for its vector layers, and 'com.acorn.group' for the group layers. Acorn can also load other bitmap types and in a future release will use tiff for bitmap layer data.

Even if you app doesn't know how to read certain layer types, you can open up and preserve the existing data while being able to modify the layers that you do understand.

The second table is defined like this:

create table layer_attributes (id text, name text, value blob);

The id is the UUID of the layer, the name field is a key for the attribute, and the value is … the value. This is where things like the frame of the layer are stored, blend mode, opacity, whether it is visible or not, etc. You get the idea- it's a key value store for the layer.

And finally, the third and last table is defined as:

create table image_attributes (name text, value blob);

This is the key value store for the whole document. The image's color space, rulers, is the grid showing or are the guides locked? Etc. There's even a composite of the image in here so if an application just wants to show a preview of the image it's a single query to pull it out (this idea is stolen from PS, which puts a composite of the image at the end of a PSD file for the same reasons).

This format is flexible, it's easy to implement, and Adobe, if you are listening you should really give SQLite a serious look. And if there are any other companies out there wanting to work on this- please get in touch with me (gus@flyingmeat.com). I'm not married to Acorn's format or table names, but I think it would be a great start.

It's 2013. Wouldn't it be awesome if you could hand off a single layered file format to multiple image editors, and it would just work?

I've been busy for a while on working on the next big version of Acorn, and I could use some more testers to help me squash the final bugs. The requirements are pretty simple: 10.8+ and you've got to be able to keep secrets.

Interested? Send an email to acornfyea@flyingmeat.com and I'll get you on the list.

I'll be speaking at NSNorth in about three weeks on Core Image, and there are still tickets available if you're wanting to go! The schedule is up, and the blitz talks are all set. Should be a great time.

About 6 months ago I started making a real effort at drawing a little bit every day. There are a number of reasons I came up for doing this, but mostly it's because I like looking at well done sketches and I just thought it'd be neat if I could make some myself.

Sketching is a great hobby. It's cheap, you can take it anywhere with you, and it's pretty fulfilling. I sit in front of a monitor and peck at a keyboard all day long, so it's nice to sit down with a little coffee at Cafe Amore and lose myself in making something analog.

What I didn't know at the time is how sketching every day would change the way I looked at everything in subtle ways.

I started out with gesture drawings which I was reasonably happy with, but I always struggled with faces. There was something wrong with my lines and I couldn't quite see what. So I just started drawing mostly faces for a while, until I didn't cringe anymore when looking at what I drew out.

And then something slowly started to happen. I began noticing every single little detail in everyone's faces. How high someone's cheekbones were, their brow and hairline, reflections on lips, the cut of their jaw, noses, noses, noses. Everyone's nose is completely unique in wildly varying ways. And you never notice just how important getting the nostrils right are until you start focusing on it. Nostrils! Who ever talks about nostril?! If you get the angle of a nostril wrong it will completely screw up a face and even if you have no idea how to hold a pencil, you'll see a nostril at the wrong angle and it will subconsciously drive you mad.

Of course once you start noticing the details in everyone's faces, it begins to leak out into other areas. You'll notice the width of people's shoulders relative to their face, postures, just how big some woman's hips can be and how some men have no necks at all. I've always seen these things of course, but I now look with a level of detail that I never did before and wonder how I would represent it on paper. And I've gotten faster at noticing things as well, which sometimes feels like a superpower.

So why sketch every day? Because over time it'll open up your eyes and you will be able to see everything.

Hypercritical: The Case for a True Mac Pro Successor.

"On paper, the Mac Pro may no longer be a viable product, but it would be a mistake for Apple to abandon the concept that it embodies. Like the Power Mac before it, the Mac Pro was designed to be the most powerful personal computer Apple knows how to make. That goal should be maintained, even as the individual products that aim to achieve it evolve."

John Siracusa writes what I've been feeling about the Mac Pro, but didn't know how to express.

Rafe Colburn: Don’t get stuck:

"Thinking in terms of what code you can write that you can push immediately is one way to help keep from getting stuck. In fact, a mental exercise I use frequently when I’m blocked on solving a problem is to try to come up with the smallest thing I can do that represents progress. Thinking in terms of what can be written and deployed immediately helps with staying in that mindset."

Rafe's post is mostly about continuous deployment at Etsy- but I wanted to call out this last paragraph to help my fellow coders who get stuck. If something's too big or overwhelming, break it up into smaller and smaller pieces. Then before you know it, you've finished your project.