Much ado has been made about the idea of App Store apps getting discounted upgrades, where you buy an app once, and then pay a discounted amount for an upgrade. This idea is not new; for many years, developers sold apps under a model known as shareware. In an era when software was harder to use and people feared viruses, this model thrived among technically-savvy people who tended to spend more money on technology. The generally-accepted model in the Apple world has a fair bit of complexity, involving trials (some time-based, some feature-restricted), serial numbers or license files, and periodic requests for more money. Then the App Store came and replaced it outright with a new, simpler model that favors a traditional retail-style system of cheap software that you pay for once. It’s far more straightforward and easier to understand; if you want the app, you buy it, and then you own it.

Developers who have thrived under the old model have complained for a long time that they want discounted upgrades to make a return to iOS. Along with it comes the added complexity of managing different tiers of ownership, both technically and mentally. Apple has not offered this, instead opting to make major updates available as a separate, standalone app that existing users pay for in full, as was done recently with Logic Pro X. To me, this is far and away a better and simpler approach to handling upgrades in an era when non-technical people buy software.

As I’ve stated before, your app needs to sync. This has not gone unnoticed by the startup world, who are offering more and more options for developers to build sync into their apps. Today, Dropbox announced a new datastore API, a system for syncing application data (that isn’t file-based) into and out of Dropbox.

At first glance, this looks like a wonderful solution. You get a drop-in component on iOS, Android, or the web to put your app’s data into the cloud, with very little thought by you. Data gets stored offline automatically. It even handles merging and conflicts quietly in the background. Pretty great, right?

I hope that the Dropbox Datastore API can deliver on these promises. I don’t think they’re necessarily impossible problems to solve. But these are the exact same problems that Core Data + iCloud claims to solve, and between iOS 5 and iOS 6, iCloud hasn’t been able to deliver on that promise. This certainly doesn’t mean Dropbox can’t, or that the Datastore API has problems. Dropbox is certainly well versed in the concept of syncing blobs of data between multiple systems, silently and effectively, as that’s what they’ve been doing for the last five years. But this solution should be approached skeptically and carefully.

Before you ship your app built with the Dropbox Datastore, these claims should be tested thoroughly. Test data sync across 1, 2, 3, 8 different devices. Test it offline. Introduce conflicts. Save data offline. Try multiple conflicts. Create conflicts on one machine while offline, etc. There’s a lot of ways a magic sync solution can fail.

Of course, the benefits to a drop-in solution are immense. You don’t have to write sync logic. You don’t have to wake up at 4 AM because your MongoDB process randomly died, taking your server API out with it. You don’t need to handle the differences in online and offline state. You know there’s a company whose goal it is to solve this problem for you; that’s their job.

Just be careful. When it comes to any tool that claims to be a cure-all, make sure it does the job.

In the last few years, an interesting alternative to paper currency has risen in the form of Bitcoin. I started paying attention to Bitcoin two years ago, and have owned some ever since. I’ve purchased physical and digital goods with it, as well as traded it for cash. It’s particularly intriguing to me because it maintains the core properties of economic models while creating a system of inflation guided by encryption algorithms rather than humans. And it’s grown in huge popularity over that time, with a net worldwide worth of over $750 million USD at the time of this writing.

Many people have asked me about Bitcoin, so here’s a basic introduction to what Bitcoin is and how it works.

Note: I am neither a lawyer nor an accountant. This should not be construed as legal or financial advice. If you use the information in this post, you agree that it is at your own risk.

At the last App.net hackathon, I unveiled Apparchy, a proxy server that converts your App.net timelines into data that looks like the Twitter API, which you could then connect to via Twitter’s official iOS apps to post and view to and from App.net. This was a really cool hack, but it suffered from many problems. It relied on a proxy server, which had issues relating to security and privacy, as well as being a single point of failure. If the proxy server went down, everyone’s app broke. Apparchy itself was built to work with Twitter’s official apps, which use a LOT of private methods on Twitter’s server API, and those private APIs changed often from release to release, meaning the app would break if you updated it. It was a big pain to set up, taking many steps that were easy to get wrong. But perhaps the most important and the most philosophical problem that plagued Apparchy was that the early adopter audience of App.net were not the kind of people who embraced Twitter’s official apps. They used Tweetbot or Twitterrific or some other app because it was better suited for their needs or looked better or some other reason.

Even with all these problems, it was fun and fascinating to make. Going into this weekend’s App.net hackathon, I wanted to top it. How? By building something that was just as mindblowingly cool, that also fixed all of those problems.

Since the last hackathon four or five months ago, App.net has been hustling on getting new APIs out, having added the Messaging API and the Files API, among other things. I’ve been dreaming for years of a better chat app with first-class, bulletproof file transfer support, and App.net has all the ingredients for a killer implementation. Similarly, for over a year, I’ve been sitting on the knowledge of the existence of the IMServicePlugIn framework, waiting for an opportunity to use it for something.

And thus, #ProjectAmy was born. App.net messaging integrated natively into Messages for the Mac.

Rene Ritchie on iCloud vs. Dropbox:

For all Dropbox’s automagical-ness, it’s a relic of the past. It’s a file system. It’s a hierarchy. It’s a folder sync. It’s a bunch of encrypted data stored on Amazon’s S3 network.

As much as iCloud is the right idea still not realized, Dropbox is the wrong thing done brilliantly well. And at the end of the day, that still amounts to the wrong thing.

There’s an important distinction here, and that’s separating files as UI from files as API. iOS (and, to a lesser but growing extent, Mac OS) has proven the value that users should not have to manage their own file system, that files as UI is a poorer user experience. You shouldn’t have to worry about where photos are stored in your photo library; iPhoto will manage collections of photos for you and they get stored on your disk somewhere. Apps can present organizational context that files cannot, letting one photo be in your library, your photo stream, an event, multiple albums, and with multiple people, all without having to exist in folders representing each of these collections. This is a good thing, it’s a significant advancement forward in human/computer interaction design, and it’s the model that computing on all platforms will be following going forward.

Files as API, however, are as important as ever. Besides being organizational chaos for a user to manage, a file system can be thought of as a structured way of mapping lots of pieces of separate data to a physical disk. Apps can store whatever data they want into a file, and the OS figures out how to actually store it. It’s a system that works very well. Using the iPhoto example, those photos may be interacted with in one or many collections with a smarter and more appropriate UI, but that photo is still being stored as a file somewhere on disk.

So while the UI has transcended the need for users to use the Finder for organization, the underlying data still relies on files, which is still the best way to save large amounts of disparate data. Just about every abstraction on files (e.g. databases or object stores) ultimately ends up writing files to the file system. Developers are still heavily reliant on files as API, even if we’ve moved beyond needing or wanting them in UI.

Besides the key/value store (which I believe uses a different syncing mechanism), iCloud advertises three mechanisms for syncing data – the file store, the document store, and the Core Data store. All of these are actually based on the same syncing mechanism for syncing files (a “document” refers to something like a Pages document, which is stored on disk as a folder with multiple files for separate images, text, and metadata; Core Data store refers to database-style apps that have lots of little pieces of data and maybe some files that go along with them). With iCloud, developers get a folder that the user never ever sees called a “container” to move files to and from the cloud. And it’s this basic file/folder synching mechanism that is apparently flawed, as there have been many reports of iCloud-based apps that have had problems, whether they’re based on Core Data, on documents, or on other storage with files.

Dropbox, on the other hand, was designed around files, both from a UI point of view and an API point of view. This means their file syncing is very, very good. If a file gets put into a Dropbox somewhere, it ends up everywhere quickly, basically with absolute reliability (short of network errors). If you’re building an app that needs to sync, that kind of reliability is exactly what you’re looking for. And you’re already using files to store stuff. The Dropbox file UI side of things is optional for users; they have to seek it out, either on the website or by having one of the Dropbox apps – there’s nothing stopping you from having a Dropbox account purely for syncing data, without ever installing the Mac app or viewing a directory on the web site. But their syncing of files works. Apps can build better UI on those files whether they’re stored locally, stored in Dropbox, or stored in iCloud. But Dropbox has proven it’s reliability, and iCloud hasn’t.

So while there is an argument to be made that Dropbox’s UI is a relic, its value as a syncing engine is still huge, precisely because it’s built around the paradigm of files, a paradigm we have decades of experience working with.

Every few weeks, some tech company is in the fire over changes to their rules. This week it’s Instagram, but who knows who it’ll be next week. They put out some change to their terms of service that claims new or changed rights over what they can do, someone notices, bloggers and headline-hungry tech reporters find it, and suddenly we have us a news cycle. In 2012, the truth is not the actual truth, but that which is tweetable. People circulate headlines speculating on what the new terms mean, a few rounds of telephone go by at the speed of light, and pretty soon the company in question is the most evil entity on earth for the next two or three days.

This nuclear chain reaction cascades, and eventually people get mad; so mad, they decide to pull off a move that could never have existed in the pre-Internet era: the ragequit. A ragequit consists of three parts – backing up your account data (usually), deleting your account, and then talking very loudly about it on social media. Usually this decision is made within hours of the change going viral public. Its intent is to send a message that says that these changes are not OK, and if you’re going to make them, I’ll just take my ball and go home, so you should fix them.

In a way, the ragequit is fascinating to observe in human nature. In just a few hours, someone can go from ignorance to apathy to fear to anger, and let this rush of emotions dictate a permanent decision. We’ve now moved to a point where software is so disposable that we will spend months and years putting our life into it and throw it away at the first sign of perceived injustice against ourselves. It’s equally curious how people think a few scattered deleted accounts will end up persuading the company to see the error in their ways, as opposed to all the monstrous bad press being simultaneously thrown at them.

One of the most infamous incidents of the ragequit happened in 2010 when Facebook announced a number of changes to their privacy options and policies. As with all things Facebook and privacy (hence Instagram and privacy), people got mad and deleted their accounts en masse. Did it work? Well, no. Facebook didn’t even bother to dignify the effort with a response. They likely picked up more new users that day than they lost from ragequitters. That was two and a half years ago, and it’s not like Facebook’s privacy controls have gotten any better. The whole thing was a futile effort that made some people feel good, and effected no change.

Nobody has ever been called noble or admirable for knee-jerk removing part of their online presence. Those who do it are never celebrated for it beyond the moment, and many times end up crawling back, tail between the legs, and resuming their use of the service. So remember, if you’re thinking of pulling off the ragequit, it probably won’t do anything but make you feel better in the moment. The company might end up backpedaling, the story ends, and suddenly you’re looking for a new photo-sharing app.

And yes, I am entirely guilty of the ragequit in the past.

When I got my first-gen iPad, I stopped using it regularly within a few weeks. It was just too heavy, too big, too thick to really consider using as a replacement for a laptop, or to bring with me places. It’s too heavy to hold for a sustained period of time. In many ways, the iPad mini is what I really wanted the iPad itself to be, and how I want to use it. Smaller, thinner, and lighter than a laptop. Easy to carry everywhere. More immersive than an iPhone. It’s much better suited for the couch, bed, hammock, bus, or car. It’s the size of a book but the weight of a pad of paper.

Today, most iPhone apps are meant to be used in portrait (if not exclusively, then at least primarily). The OS goes out of its way to enforce this; the home screen is in portrait, and locking the orientation restricts you to portrait (even in cases like video and the camera where it makes no sense). On iPad, you can orient the device any way you like, including for the homescreen and orientation lock, but I’d wager that most people use it primarily in landscape. The narrower edge design of the iPad mini seems to encourage more portrait use, which means there may be an awkward early adopter period of apps that aren’t as useful on the mini because they are optimized for landscape over portrait. One possible benefit of the smaller size and the portrait emphasis is that maybe, just maybe, scaled-up iPhone apps won’t look as comically bad on the mini (and don’t scoff, as there are hundreds of thousands of apps that aren’t optimized for iPad). Who knows.

Last week I said I wasn’t going to buy one until I tried it out and felt the size. Oops. I guess we’ll see how it feels when I get mine on Friday.

Dealing with dependencies in Objective-C has always been a tedious process. You typically do some git submodule stuff, import their Xcode project into yours, add a dependency, add a linker target, set some compiler flags, etc., or you include the project’s .h and .m files manually. Then you end up running into problems because the header paths are wrong, or you forgot to add some linker flags that include categories, or some other problem. If that project requires ARC or iOS 6, you have to figure that out and set it up to be consistent with your project. Then, when you need to upgrade the library, you need to make sure all these steps still work, and hope nothing new got added that might break. It’s a very error prone process. Now, being a stubborn developer that’s always done it this way, I’ve been wary of any tools to automate this process, as I usually think I can handle it myself, and I’m usually wrong. Other languages have had package managers to solve this problem, so why not Objective-C?

CocoaPods tries to solve this problem by automating the process of fetching dependencies (and recursively fetching their subdependencies), adding them to an Xcode project, managing paths for everything, adding any extra compiler or linker flags, copying in any resources (images, nibs, sounds, or whatever else), and building it into your project. The end result is a very simple process of defining your dependencies in a file (called a Podfile), running a command line process, and then just building your app and referencing those dependencies. If you need to update dependencies or add new ones, just add them to the Podfile and run the command line process again. It’s very simple, and a far cry from managing all this stuff yourself. And, as of this writing, there are over 600 projects you can include in your app.

Under the hood, CocoaPods is creating an Xcode project which builds a static library, libPods.a, consisting of all your dependencies. It adds this project to an Xcode workspace and makes your project dependent on libPods.a using an Xcode config file. It then rewrites your Xcode project to link libPods.a and copy resources, and set some paths to variables included from the config file. It even detects if your project uses ARC, and sets flags appropriately. The result is that the majority of changes to your project are minimal, but instead reference a project that is under the control of CocoaPods, and as such it can be changed while rarely affecting your project. It’s a well thought out system.

To get started, you need to install the CocoaPods gem with a gem install cocoapods at the command line. Then, in the root of your Xcode project, add a Podfile that lists your dependencies and your deployment target. For this example, we’ll target an iOS 6 app that depends on the AFNetworking and FormatterKit projects. You can search for more projects on CocoaPods.org.

platform :ios, '6.0'
pod 'AFNetworking', '~> 1.0'
pod 'FormatterKit', '1.0.1'

Note: CocoaPods uses semantic versioning to determine how to handle version numbers. The version string can either be a specific version, or can include an operator that tells CocoaPods to pick a version for you. The ~> operator says, for version X.Y.Z, “use any version matching X.Y.*”, but you can also use >, >=, <, or <= which do what you expect.

Once you have this in place, run pod install. This command will:

• download the podspec (a manifest listing instructions on the project’s requirements and build instructions) for each dependency you list, and those for any subdependencies
• check the requirements for each podspec to ensure that your project meets the minimum requirements (so a Mac project won’t be added to an iOS app, or a project that only works on iOS 6 will not work on iOS 5)
• set up a new xcodeproj with a static library target for all the source files in the dependency tree
• set up an xcworkspace if you don’t already have one
• add the Pods xcodeproj to this new xcworkspace
• create an xcconfigfile that includes header paths for all dependencies
• change your xcodeproj to use the xcconfig file for header and linker paths
• add the libPods.a library to the Link Bundle With Libraries phase of your ‘xcodeproj’
• add a new Copy Pods Resources script phase to copy any resources to your bundle

Once this is in place, you can build and run. Unless there are any problems with the dependencies, Xcode will compile all the dependencies and link them into your app. It’s very important that you use the xcworkspace, so Xcode knows how to build the Pods project correctly. You can then #include <afnetworking/AFNetworking.h> to begin using the code. That’s it!

I’ve started using CocoaPods on a project and have been enjoying using it over managing dependencies myself. I haven’t seen any reason to believe this would be more problematic than doing it all myself, but there are plenty of benefits. Dependencies can be kept up to date much more easily, and their inclusion process is much more strictly defined (and automated). For many projects, it’s far more likely to get the setup process right than I am, and it’s faster to get set up. I recommend checking it out for your projects.

The iPad mini is basically a small iPad 2. It has an upgraded camera, improved wireless, and a 15% higher density screen. But the screen is only as good as the original iPhone, and it’s running the same 19-month-old A5 processor (which is no slouch, but is hardly state-of-the-art). This is the same chip used in the latest iPod touch, but has more pixels to drive. I wouldn’t be surprised if, even with the non-Retina display, this device feels a little sluggish compared to an iPhone 5, or even a 4S.

The mini certainly fills a need; the current iPad is too large to be truly portable, but is smaller than every notebook you can buy. The iPad has definitely been the dominant player in the 10-inch tablet market, but the 7-inch tablet market has been growing. The leading competition in the 7-inch tablet space is the Nexus 7 (which is a very capable tablet), which will probably end up in a respectable #2 place by the end of 2012 in the area of several million units. It makes sense that Apple would want to try to hold on to the top seat.

The $329 base price point, however, is a strange and awkward place to start the lineup. Not only is this $130 more expensive than the Nexus 7, it misses the psychological barrier of getting under $300. This propagates through the upgraded models as well, and causing a weird staggering effect. In fact, adding in the iPad 2’s and the iPad 4’s price points, we get this pricing chart of 13 prices spread out over 14 models:

While there are some overarching rules (e.g. if you want more space, or you want 4G data, you’re paying more), there’s no consistency when you move up or down by one price point. If you were thinking of spending an extra $30, you suddenly have a lot more variables to consider. Perhaps Apple did this to maybe get a few extra dollars out of the customer, but my hunch is that it’ll have the opposite effect. Say you walk into the Apple Store to buy a base model iPad 4 at $499. If you wanted to spend a little more, you could get a slower iPad with 3G, or a smaller iPad with a lot of space you don’t know if you need. On the other hand you could get the iPad mini with the exact same storage, a smaller screen, and 4G data, all while walking out of the store with $40 in your pocket. It’s not a hard conclusion to draw.

In the end, Apple will sell a zillion of them, and they’ll work fine. In a year, Apple will announce the next iPad mini, which will probably include a Retina display, a more modern chipset, and probably a price drop to $299 as well. It just feels like they’re holding some of that stuff back from this version, and it doesn’t seem like price is the motivating factor.

Personally I’m waiting to get one until I actually hold it and try to fit it into my large-but-not-iPad-large jacket pocket. The true test of a device like the iPad mini is its portability. The Nexus 7 fits my jacket, but barely. Hopefully the iPad mini fits as well.

The Wii U includes an unusual controller, the GamePad, that looks and acts like a small tablet with physical controls (or a large PlayStation Vita). Besides the conventional array of game controls like two analog sticks and a bunch of hardware buttons, the controller includes a microphone, speakers, a headphone port, a screen, and a front-facing camera. There is also a more conventional, Xbox-like controller called the Pro controller which has none of those inputs.

Kyle Orland of Ars Technica wrote this piece on Nintendo’s “solution” for in-game voice chat in their upcoming Wii U console. Nintendo decided to add in-game chat to the Wii U, which is something you’ve been able to do for almost a decade on other gaming platforms. But here’s the catch: those ports on the GamePad won’t work with it. You have to buy a standalone headset and plug it in to your GamePad to get it to work. Even stranger, the Pro controller doesn’t have the port you need to even use it. Furthermore, unlike Xbox and PlayStation, this support is not baked into the system as a whole, but will be opt-in for whatever games choose to spend the time, money, and energy to support it.

When you design a feature into anything, some percentage of people will use it, some won’t. The more barriers you place between the person and what they try to do, the more of them will give up. Design involves removing the barriers between the person and the solution to their problem. I reach for my iPhone over my Vita because my iPhone is usually closer. I reach for my Vita over my Xbox because the Vita is self-contained and doesn’t make me change my TV’s inputs. I reach for my Xbox controller over my Mac laptop with Windows on it because my Xbox doesn’t make me log out of everything I’m doing and restart. These barriers may be small and subtle, but people choose the path of least resistance to solve their problems, and barriers act as resistance.

Frankly, this kind of half-assed solution for a voice chat feature – voice chat, mind you, being an integral part of mutliplayer gaming for many – just increases our concern that Nintendo is still struggling to get online functionality right this time around.

Inexplicably, Nintendo chose to add all kinds of barriers to this one solution – how to talk to your friends while playing games. I can’t tell if this was done intentionally or as just a gaffe in design. Either way, what does it say of the rest of the Wii U? And what other features are going to suffer as a result of focusing on something they don’t care so much about?

This afternoon, Matthew Panzarino and Ken Yeung of The Next Web posted about a potential acquisition of the poster childs of startup excess, Color. A gut reaction of stunned disbelief is not unreasonable here, after a string of flopped products and tales of the CEO splitting for Maui. But after the shock comes intrigue. The Next Web rarely posts rumors of acquisitions unless they’ve triple checked everything. So if we assume it’s true, the question remains, why?

$41 million means you can make extremely compelling offers to the best engineers. Daniel Jalkut found that some of that cash went to paying for a number of tech patents as well. These patents relate to their technologies in grouping people together by their location and sharing content between them. These engineers spent the last year and a half tuning these algorithms, even if they weren’t used by people very much. Part of the reason Color was such a flop was because everyone had to use it for you to want to use it. That’s not an easy sell, especially in an environment like iOS where a person has to actively be using your app in order for it to provide value to others.

But let’s imagine a world where this stuff is built into the heart of iOS. There may not have been a lot of people who used Color, but there are a lot of people who use iOS devices, and suddenly Apple has solved the chicken-and-egg problem of availability. The solution Color offered can become much more useful if offered by Apple, who can break any of the rules they impose on 3rdparty developers. If you go to a barbeque or a concert, and everyone’s taking pictures and video, your iPhone will know that all these photos relate to the same event, and can group things together. It can tie in data from your address book to determine who the people around you are, and if you know them. You can create Photo Streams of events with everyone’s (or just your friends’) photos. Maybe this would integrate with the calendar, or even Facebook, to automatically associate photos and videos with events. (It’s worth noting that Google recently introduced a very similar feature to Google+ and Android.) And who knows, maybe in some weird way, this could become an aid to Apple’s troubled Maps, providing some kind of functionality like Street View or Microsoft’s Photosynth.

So maybe it makes sense that Apple might acquire this company for their expertise. Sure, they could do it all themselves, but Apple tends to buy companies with expertise in areas Apple wants to do better in. And buying the company outright gets you the engineers and saves you from the patent lawsuits. But if Color managed to “succeed”, it’s for many of the wrong reasons. Making it via a ton of money, a few unused apps, a pile of patents built on stale prior art, and a pool of developers to focus on a niche set of knowledge is a role of research departments within companies like Apple. If this were a model for the industry, we’d be looking at apps that have no real utility to people built by companies that focus on compartmentalizing knowledge and locking it off for others to use, all in the hopes that a cell phone maker has a bunch of cash to throw at you for the next new feature. That’s not a bright future. So while this may make sense for Apple, Color, and for iOS users, it sets an uncomfortable precedent. Hopefully it won’t change the idea of the overfunded startup into a model to be emulated.

Blocks in Objective-C are super useful for making your object-oriented code a bit more functional. But as blocks are an extension to the C language, they have to play by the rules of C, so the syntax is a little obscure, and the documentation can be a little hard to find. So here’s a guide on how to declare blocks so you can use them in various scenarios.

Update: It didn’t work out, but all the content from that blog has been merged back here.

Starting over is often a difficult, but necessary, way to revitalize yourself. When I was in middle school, I wrote a column in my school’s student newspaper talking about video games. I’ve been writing since before I was coding, but lately the coding has superceded the importance of writing in my life. I haven’t been content with this for a long time, and have been trying a variety of strategies to make myself write more. My personal blog, SteveStreza.com, has acted somewhat as the outlet for this, and it has succeeded in getting me to write long-form articles, but it has largely failed at producing shorter and more frequent content. But the opposite side of that is a lack of focus and a burden of further long-form content. I love writing, but the hole in what I have been writing has been bothering me for awhile.

So today, I’m beginning a new experiment, Informal Protocol. This new blog is focused around the topics of development, design, tech, and culture. The goal is to keep most articles at 5 paragraphs or fewer, and to have at least one new post a day. But as the name implies, this is an informal protocol, and won’t always be followed. Quantity and quality will have peaks and valleys, and the focus may skew one way or another. It’s wholly possible the direction may drift and this becomes something else entirely. But hey, sometimes you just have to give it a shot.

Informal Protocol is an experiment. Like all experiments, it may fail. But sometimes you have to just jump face first into a new adventure and start over. If you would like to join me on this adventure, you can follow new posts at Informal Protocol via RSS, App.net, or Twitter.

One of JavaScript’s greatest strengths is its extremely powerful function syntax. You can use it to encapsulate portions of code, large or small, and pass these invocations around as any other object. node.js takes this and builds an entire API on top of it. This power is great, but unchecked, it can lead to convoluted and complex code, the “callback spaghetti” problem. Here’s a sample JavaScript function which chains together some asynchronous APIs.

function run() {
	doSomething(function(error, foo) {
		if (error) {
			// handle the error
		} else {
			doAnotherThing(function(error, bar) {
				if (error) {
					// handle the error
				} else {
					doAThirdThing(function(error, baz) {
						if (error) {
							// handle the error
						} else {
							// finish
						}
					});
				}
			});
		}
	});
}

async.js tries to fix this by providing APIs for structuring these steps in a more logical fashion while keeping the asynchronous design pattern that works so well. It offers a number of control flow management tools for running asynchronous operations serially, in parallel, or in a “waterfall” (where if any step has an error, the operation doesn’t continue). It also works with arrays, and can iterate over items, run map/reduce/filter operations, and sort arrays. It does all of this asynchronously, and returns the data in a structured manner. So the above code looks like this:

function run() {
	async.waterfall(
		[
			function(callback) {
				doSomething(function(error, foo) {
					callback(error, foo);
				});
			},
			function(foo, callback) {
				doAnotherThing(function(error, bar) {
					callback(error, foo, bar);
				});
			},
			function(foo, bar, callback) {
				doAThirdThing(function(error, baz) {
					callback(error, foo, bar, baz);
				});
			}
		],
		function(error, foo, bar, baz) {
			if (error) {
				// one of the steps had an error and failed early
			} else {
				// finish
			}
		}
	);
}

While the resulting code may be a little longer in terms of lines, it has a much more clearly defined structure, and the error cases are handled in one place, not three. This makes the code much more readable and maintainable. I love this pattern so much, I’ve begun porting it to Objective-C as IIIAsync. If you’re a JavaScript developer, and you use function for its more advanced use cases, you want to use async.js.