Peak Facebook

I don’t use an iPad. I own one, but my son uses it now, mostly for games. Between iPhone, Desktop, Laptop, and Kindle I could never find a place for it in my life. So I’ve started quizzing my tablet-using-friends about theirs. I ask friends, “When do you use your tablet and what for?” Almost unanimously the answer is: around the house for web, Facebook, email, and books. Basically a living room couch web browser and e-book reader.

What I noticed though, is that all of these tasks are largely platform agnostic: It’s tough to tell Facebook running on an Android device from Facebook running on an iOS device. There are some great platform specific apps of course, but they seem to be more niche use cases, at least in my anecdotal polling.

This made me wonder if the iPad’s platform agnostic nature will have a long term impact on the the platform. Without app lock-in will less expensive tablets become more popular?

The new iPads are now both very light and both have amazing screens. Just refinements, perhaps, but amazing ones. However both features seem to be nearing the point of diminishing return. Further weight reductions and screen improvements are unlikely to make for a better Facebook experience in the living room, we’ve reached “peak Facebook” already.

And here’s the crux of this post: what else is there? How does Apple make the living room web browsing experience better than this? Or how do they change what users are doing with their iPads? When Samsung catches up in a few months what will keep people from choosing the least expensive device? Or will there be any reason at all?

I don’t doubt that Apple has something planned, maybe even a few things, but I do feel that they’ve painted themselves into a corner more than I would have expected.

How to compete with Facebook: A guide for independent developers.

At WWDC this year I attended a fund raiser to support the Cartoon Art Museum thrown by Pixar tech god Dr. Wave. This year Andrew Stone gave a demo of some of his early NeXT graphics software collaborations with Pixar and told stories about the early days of the OS we now keep in our pockets. Andrew said it was a magical time because suddenly, with the help of a NeXT cube and its free development tools, a lone developer could build software that rivaled what large companies were selling for hundreds of dollars.

We all know that new tools bring about radical changes. When a single developer can build and sell software that competes with companies that are staffed by dozens or hundreds, the game is no longer on a level playing field. A single developer invests only their own time so there’s little risk and even a comparatively tiny revenue is a success. It’s just a matter of noticing the tools when they arrive.

In the software industry, new tools are invented all the time. Word processors used to take a large team to build, a publishing company to distribute, and a retail chain to deliver. Now we can write a basic Markdown text editor over a free weekend and send it to the App Store to reach millions of people.

The past ten years has seen an explosion of social services, but for an independent developer there are not many ways to participate. We can only build clients beholden to services and their advertisers which is no fun. The reason, of course, is that servers, storage, and bandwidth are expensive. Business models that require large capital investment are pretty much out of the question for independent developers. What we need is new tools.

App.net is a service that provides developers with the tools a social service needs: a social graph, file storage, and a robust API to group them together. As icing on the cake, it has a lively installed base of over 100K users that are hungry for more apps (which handily solves another social problem — the “there’s no there, there” problem — but that’s for another blog entry). But some services have become developer-hostile when they start to sell their product (your users) to their customers (advertisers). In constrast App.net’s business model sells premium service to users directly (like Dropbox and Flickr), so your customers and their customers are one and the same. Aligned goals make for better business partners.

10 years ago, to build Delicious probably took a room full of servers, and another room full of nerds to keep the servers alive. 3 years ago Pintrest probably got a leg up by avoiding the servers and buying bandwidth from the likes of Amazon AWS. Today, you can build a link sharing service by yourself, on your laptop, while sipping on a latte in Starbucks. Other guys are doing it, what’s stopping you?

Xcode, build numbers, and git. A simple solution in three steps.

Step 1: Add a Build phase Pre-action script.

Open up the scheme editor, expand the Build phase, and select the Pre-actions step. Add the following shell script. You’ll want to copy and paste this part to get all the quotes correct.


cd "${PROJECT_DIR}"
rm -f "${BUILT_PRODUCTS_DIR}/build_number"
echo "#define __GITBUILDNUMBER__ `git log --pretty=format:'' | wc -l | sed -e 's/ *//g'`" > "${BUILT_PRODUCTS_DIR}/build_number"

This will add a file to your built products folder whenever a build is about to run and it will have a simple C Preprocessor define with a build number extracted from the git log.

Step 2: Enable the Preprocessor

In your target build settings, enable the preprocessor for the Info.plist file. Enable preprocessor

Then set the preprocessor prefix file to build_number file. Build settings details

Step 3: Add it to your Info.Plist file

In the Info.plist add the build number to the Bundle version line. Info.plist details