TL;DR: I made an Objective-C wrapper for LevelDB, called APLevelDB.

I’ve been enjoying tinkering with Redis lately, which has left me wanting something similar for Mac and iOS projects. Tokyo Cabinet seems to be the big name in speedy key-value stores, but its LGPL license leaves much to be desired. I finally settled on LevelDB, a similar offering from Google with a much friendlier license (New BSD).

LevelDB’s C++ API is pretty reasonable, but since I don’t like naming all of my files .mm, and stylish Objective-C APIs are part of what make developing in Cocoa/iOS so much fun, I decided to write my own. I hope you’ll agree that it’s quite pleasant to use; it’s called APLevelDB. It has a few opinions, but leaves the big decisions to you. You can find usage examples in the readme.

CloudApp is one of my favorite tools for sharing images quickly, and I also use Acorn quite a bit for quick image editing tasks. I’ve been wanting a quick way to upload a snapshot of what I’ve got in Acorn using CloudApp, so tonight I wrote AcornRaindrop.

AcornRaindrop exports the active document in Acorn as a PNG and uploads it using CloudApp. It’s a Raindrop, which is a plugin for CloudApp. You can download it, or peruse the source on GitHub. It is made available under the MIT License.

Note that testing at this point has been ridiculously limited. It works for me; hopefully it will work for you too!

The implementation is rather simplistic: it uses osascript to instruct Acorn to export the active document, then passes the result along to CloudApp. My first attempt was using NSAppleScript, but for reasons I don’t fully understand it blocked for about 30 seconds while running the script, but only under CloudApp. Something to do with loading frameworks, perhaps? At any rate it runs quite quickly with osascript.

Happy CloudApp+Acorning!

v1.0.1, 1/18/2012: Gus Mueller was kind enough to contribute some changes demonstrating how to connect directly to Acorn using NSConnection, so the osascript call is now history. This allows AcornRaindrop to base the filename uploaded to CloudApp on the filename of the exported document.

There was a post on The Guardian’s Technology Blog by Matthew Baxter-Reynolds last week. The piece couches itself as an overview of mobile platforms for the developer looking to get his or her feet wet.

Turning its attention to iOS, The Guardian cuts with broad strokes on Objective-C and Xcode (“horrendously, absolutely awful”), and then opines:

The fact is that if your day job involves sitting in Visual Studio writing C# applications, or building Java applications in Eclipse (which will be most of you — albeit not necessarily in Eclipse), when you fire up Apple’s Xcode and start building CocoaTouch applications in Objective-C you’re going to come face-to-face with a toolset that has not had the sort of love put into it that the open source community has put into the Java toolset and associate platforms, or that Microsoft has put into VS and .NET over the past 10 years.

Today, John Gruber replied:

Objective-C is different than C++ or Java. Xcode is different than Visual Studio or Eclipse, and Xcode 4 is very different from previous versions of Xcode. Baxter-Reynolds certainly wouldn’t be alone in saying that he doesn’t like these differences. But it’s curious to argue Apple developer tools and frameworks are deficient due to a lack of time put into them. In numerous ways, both linguistically and tools-wise, Xcode, Objective-C, and Cocoa/Cocoa Touch are the evolutionary descendants of the NeXT developer platform from 1989.

Both of them are right, and both of them are wrong. Baxter-Reynolds’ “horrendously, absolutely awful” comment is ordinary internet grandstanding (aka trolling). The iOS platform would not be where it is today if Objective-C and Xcode were horrendously awful. Part of the success of iOS is that it is the first great mobile development platform. I’d wager that Gruber is partially correct in thinking that Baxter-Reynolds’ viewpoint here is rooted in fear/dismissal of the unfamiliar.

Where Gruber is wrong, however, is in his own dismissal of Baxter-Reynolds’ argument as simple, again, fear of the unfamiliar. Before I landed my dream job writing Mac and iOS apps (at last!), I spent many years with Visual Studio writing C++ and later C#. And while Xcode has been improving by leaps and bounds, let me tell you: Microsoft has set the bar very high with Visual Studio.

Visual Studio excels in two areas: debugging and autocomplete. The Visual Studio debugger is blazing fast. Stepping through statements is super speedy, and the variables view would keep up without breaking a sweat. Xcode’s debugger has a tendency to take its time when stepping, and the variables view can be ridiculously finicky.

My perception is that part of this sluggishness has to do with gdb, and maybe lldb will help to improve this over time. If you’re thinking that debugger stepping speed is a petty thing, think again: just like responsiveness in iOS is clearly a big deal – something Apple has put a lot of energy into – so is responsiveness in a developer’s tools.

Xcode’s autocomplete has come a long, long way in the last couple years. However, it’s just not a fair fight against autocomplete with a strong typed language like C# or Java. Strong typing allows the IDE to provide fast, accurate autocomplete. With Objective-C’s dynamic typing, autocomplete becomes more of an art than a science. Additionally, the dot notation syntax of C# and Java give the IDE another leg up: the dot is the perfect cue to bring up autocomplete. Objective-C does not lend itself to this quite so easily.

As to the question of the amount of time put into Xcode versus Visual Studio, it’s worth pointing out that Apple’s Developer Tools team is almost certainly significantly smaller than Visual Studio team.

Xcode has come a long way, and it has one really amazing component – Instruments – that, as far as I know, Visual Studio doesn’t have anything close to (that isn’t a commercial add-on product). But Xcode is lacking in some key areas that can make a big difference in a developer’s perception of tool quality. I think it’s important that we, as proud Apple platform developers, are honest about that.

I’m pleased to announce the release of SwiftText, a text scratchpad app for Mac that makes itself available with a keyboard shortcut – and disappears just as quickly. It’s available now on the Mac App Store; you can see more screenshots on the SwiftText page.

Several months ago I needed an app just like this, but all of the possible solutions I found did too much. I simply wanted a lightweight app to pop up with a keystroke, let me type immediately, and get out of my way again with an escape when I was done. So I wrote SwiftText and found it useful enough that I figured there are probably other people out there with similar needs.

SwiftText is priced at US$1.99, but it’s available through April 8th at a special price of US$0.99. If you decide to give it a go, I hope you find it to be as useful as I have, and don’t be shy about sending your feedback (use the feedback tool in the app, or the address here). I have several ideas cooking for 1.1; I’d love to hear yours.

Say you have a lot of transparent images that you need to add a white background to. Flying Meat’s Acorn has some nice scripting bindings that are up to the task.

Not being a huge fan of AppleScript, I started out writing JSTalk inside an Automator task, but frankly I couldn’t figure out how to fill the new layer. Filling is, however, documented for AppleScript. I got an AppleScript version working, but quickly found that (at least on my system) running AppleScript inside Automator is very slow.

So I abandoned Automator and adapted that code to an AppleScript droplet. After saving it as an application from AppleScript Editor, I had a speedy app bundle that I could drop images on. Here’s the code:

on open input
	repeat with anImage in the input
		tell application "Acorn"
			open anImage as alias
			tell document 1
				duplicate layer 1
				fill with color (65535 & 65535 & 65535)
				merge visible layers
			end tell
			activate
		end tell
	end repeat
end open