inessential by Brent Simmons

June 2012

Twitter and Anti-User Behavior

Matthew Ingram on GigaOm:

Ultimately, the company could ruin the experience that made Twitter so compelling in the first place, in the same way that MySpace and Digg did.

How long before Twitter isn’t fun to use anymore?

More Details

I left out a bunch of stuff when writing about replacing Twitter yesterday.

A big piece is this: a client developer would probably have to write and run their own web services. (And would probably have to have subscription pricing so they have recurring revenue so they can afford it.)

The services would provide a few things at a minimum:

  1. Hosting for published statuses.

  2. A content service that reads the feeds, so that you don’t have a zillion clients all polling. (Not rocket science. As done by NewsGator, Google Reader, Bloglines, Fever, etc.)

  3. Push notifications for new statuses.

  4. An API for the clients to talk efficiently to the content service (to be able to get just what’s new, for instance).

It’s work, and it takes money and time.

At any rate — even if I’m wrong in every single way about how to replace Twitter, I would still be very nervous as a Twitter client developer, and I would absolutely start talking with other developers about how to move on.

Matthew on Twitter Restrictions

Matthew Panzarino:

I polled a few high-profile developers who use the Twitter platform and APIs and the general consensus was that the wording of the post was “ominous.”

I’m glad I don’t have a stake in this. But it does nudge me ever closer to quitting Twitter. (I’ve already quit Facebook, LinkedIn, and Instagram.)

What I’d Do

Were I a Twitter client developer, I would get in touch with other client developers and start talking about a way to do what Twitter does but that doesn’t require Twitter itself (or any specific company or service).

Once we came to a consensus, then we’d add support for whatever-it-is to our apps. We wouldn’t drop Twitter support — we’d just add the new thing. Do both.

And then we’d promote the new thing, encourage people to use it, help it grow. Then drop Twitter some day — or wait till Twitter cuts off our apps. Whatever. And not care, because we’ve got the new thing.

Technical Details

The interesting (to geeks like us) part is this: what system that works like Twitter could exist without a company behind it?

Think about it this way:

Under the hood, following somebody is really just subscribing to a feed of their statuses. Posting is really just updating a feed of your own statuses.

So you standardize on a feed format. RSS would work great, of course, and there’s a ton of RSS reading and writing code out there already — and it’s not like it’s dead. (For instance, just this week Apple released a major iPhone app that uses RSS.)

Any given feed could live anywhere on the web.

It’s one feed per “account” — with “account” in quotes because there are no actual accounts anywhere.

Each feed would need an associated file that lists the people that that person follows. Under the hood this is just like an RSS subscription list — and OPML makes sense for this file.

Do this much, and you’ve got the basics down: following, reading, and posting.

For searching and mentions, a client could just look at the feeds it’s already reading — but for system-wide searching and mentions some special services would need to be built (is my guess). But there could be many competing services instead of just one indispensable service. (For instance, years ago there used to be services that specialized in blog-searching. This would be similar.)

(Same for direct messages, though I think that might be one Twitter feature that you don’t really need. People already have ways of contacting each other privately — email, SMS, chat — so time spent on this might be a waste of time.)

Side Effect: Stuff to Read Is Already Available

If you did the above, and chose RSS as your format, you’d also have the ability to “follow” Daring Fireball, Macworld, The Next Web, Apple — every site that has a feed. Your UI might truncate the posts to make them more tweet-like, of course — but it means you’ve already got a ton of content for people to follow.

Think of how there’s an @daringfireball Twitter account — in this system you’d just use its RSS feed instead.

Nobody Could Shut You Down

Some people are committed to using the open web versus APIs from other companies. Some people don’t care.

But there’s a practical reason to use the open web: your app can’t be shut down. And Twitter is looking more and more like a company that’s thinking about shutting apps down.

Jake Moves On

My friend Jake Savin is leaving Microsoft.

It’s hard to imagine today, but when I started my tech career as a test engineer, a really big hard disk held 4GB of data and cost around $1000, and the Web was still booting up. The entire company I worked for then had less storage capacity than some of us now carry with them in their laptops. When I started at Microsoft, Vista hadn’t shipped yet, Nokia, Palm and RIM were the mobile computing kings, there was no iPhone, no Android, and no Kindle, and tablet computing required a stylus.


Jake and I worked together at UserLand Software in the late ’90s and early ’00s. A few years ago he moved to the Seattle area — which means we hang out a lot more than when we were co-workers, which is cool.

Facebook goes native on iOS?

The New York Times reports that Facebook’s iPhone app will go more Objective-C and less HTML5 in an upcoming release.

I had the opportunity to see the as-yet unreleased iPhone application, and it is fast. Blazing fast.

Any one of us could have told them to start with Objective-C in the first place.

(I like HTML5 — but it’s not the right tool for every job.)

“I decided to uncancel my small part of the project”

The Graphic Calculator Story is a part of the culture of people who write software for Apple products.

Required reading.

We were saved by the layoffs that began that month. Twenty percent of Apple’s fifteen thousand workers lost their jobs, but Greg and I were safe because we weren’t on the books in the first place and didn’t officially exist. Afterwards, there were plenty of empty offices.

(Greg Robbins, by the way, now works for Google just outside Seattle. And he’s on the advisory board for the University of Washington’s Certificate in iOS and Mac Application Development course, which you can apply for now.)

Core Intuition on Glassboard

Manton Reece’s and Daniel Jalkut’s very cool Core Intuition podcast now has a Glassboard board. The invitation code is COREINT.

Note that it has a custom invitation code. We set those up manually. If you have a podcast and would like a board (for listener questions, feedback, DVD extras, whatever) with a custom invitation code, get in touch with me.

One-Star Reviews

John Scalzi quotes a few one-star reviews of Redshirts, his latest bestseller. (Which I haven’t read yet, but is on my list.) And he says:

I think as a creator you owe your audience your best efforts, but if at the end of your best effort some of them are still not happy, the best response is, oh, well, maybe next time. You will never make everyone happy. If you try, you’ll likely create something mediocre, and then nobody will be happy. Least of all you.

Applies to app developers too.

If God Himself made The Greatest and Most Wonderful App Ever, it would still get a bunch of one-star reviews. And if it was $0.99 there would be people bitching about the price.

n+1 on Twitter

Please RT:

Few things could appear much worse, to the lurker, glimpser, or guesser, than this scrolling suicide note of Western civilization.

(Via Buzz, who may be my favorite finder-of-links.)

Closeby Lessons

Collin Donnell:

…when I first released the app I got so many great suggestions from other developers and designers that I wanted to implement that I spent way too long trying to fit all of them into one release. This was a mistake…

UIGestureRecognizer and nil-targeted Actions

I like the Cocoa responder chain — I like being able to specify nil as target and have the action message follow the responder chain until it’s handled (or not).

I like this so much I almost never specify a target — I (just about) always use nil.

But this doesn’t work with UIGestureRecognizer. The documentation states that “nil is not a valid value” for the target in addTarget:action:.

If I forget and use nil anyway, nothing happens. (Which is frustrating, because I don’t know why until I remember or look it up. Which just happened.)

How I work around it:

I specify the target in the same file where the gesture recognizer is created. I have it call a method something like this:

rs_performSelectorViaResponderChain looks like this:

I don’t like having to do this, but it works.

Why oh why

But my question is: why does UIGestureRecognizer not take nil as a target and work like everything else works?

I don’t have a theory.

Update 10:30 pm: Chris Parker writes on Twitter:

“They’re intended for specific gestures on views, rather than a hierarchy of actions. More of a virtual control.”

Update June 23, 2012 12:00 pm: Ben Lings asked on Twitter why I didn’t use -[UIApplication sendAction:to:from:forEvent:] instead of rs_performSelectorViaResponderChain.

Excellent question. I think I should be using sendAction:to:from:forEvent:. So I changed my code.

Après moi le déluge?

Manton Reece notes a growing list of apps leaving MAS:

TextExpander 4 shipped this week, and with the update it breaks from the Mac App Store and instead requires customers to buy directly. TextExpander is the first popular app I’ve seen to do it.

This worries me. I like the Mac App Store, and I definitely prefer to buy my software there. While I don’t have a Mac app at the moment, I’m sure I will again in the future. (I love writing Mac apps too much to stay away.)

If the Mac App Store is known as the home of the hobbled versions of Mac apps — or, worse, is known as the place where good and useful Mac apps just aren’t permitted — then it’s not going to work, and developers and users lose out on the benefits of the Mac App Store.

I have no problem with Gatekeeper, even for non-Mac-App-Store apps. The problem is sandboxing. Maybe it’s fixable — but I won’t consider it fixed until apps like TextExpander can get back on the app store.


Mike Ash writes about Objective-C Literals in the latest Friday Q&A.

I already look back on pre-ARC days as another world. This isn’t quite as big a change, but it’s big.

The more Objective-C is like a scripting language, the better.

Gus on Retina

Retina or Bust:

Acorn is being “Retinafied” (@2xed? HiDPied?) for version 3.3, and this involves a bit more work because I’m just not going to update the graphics for it (that’s the easy part!). Oh no — there’s something a bit more awesome that’s being worked on…

How Glassboard Got Its Name

I’ve written before the real story about how MarsEdit got its name. (Hint: the story involves beer.)

The story we tell about Glassboard is that “glass” refers to the glass covering your phone, and “board” is like board-of-directors, with hints of bulletin board.

That’s fine, and that fits. It works. (Though I realize that “glass” doesn’t really suggest privacy. Well, the app’s private anyway.)

Of course we looked at a bunch of names, not just for the app but for the company. (For a while I thought we’d be called Hepcat Software. We ended up as Sepia Labs. I’ve learned that almost nobody pronounces Sepia correctly — it’s like the C in C3PO, not like the “se” in “severed heads.”)

Raise High the Roof Beams, Geeks

The name “Glass” comes straight outta Salinger. I was a huge fan when I was a teenager, and I remain fond (though I’ve read Mary McCarthy’s excellent, scorching takedown — and, well, she’s right).

I’d wanted to name a product Glass-something, or just Glass, since I first started naming products in the mid-’90s — because of the Salinger stories and because glass itself is cool. Because I love the name.

NetNewsWire could have been GlassNews. MarsEdit could have been GlassEdit. TapLynx could have been GlassAppMaker.

Texts from the ’60s

I can’t help but imagine Franny and Zooey as a modern mobile conversation.

Franny: Dude Im having a nervous breakdown.

Zooey: Whats wrong??!?

Franny: Ive gone all spiritual OCD.

Zooey: Remember the little people okey?

Franny: Thanks. Ill feel better soon. Don’t smoke so many cigars.

Zooey: Cigars are just balls.

Franny: ???? wtf Zoey

Zooey: Ballast not balls. Damn you autocorrect!

How We Use Glassboard for Work

Last week was WWDC, which I missed this year — which meant that I was home working on Glassboard while my friends at the conference were using the app to figure out where to eat lunch and which parties to attend.

I had fun watching. I could live vicariously while I was otherwise just working. (Shields! No, Chieftain!)

While Glassboard is useful for conferences — huge thanks to everyone who gave it a go at WWDC! — it’s even more useful for day-to-day work. We’ve been using it inside Sepia Labs for over a year now, since the very first moment it was usable at all. We use Glassboard to make Glassboard.

We’ve found that the social-networking-like model — messages, comments, pictures, videos, likes, shared files, locations — works great for work, for getting things done as a team.

We hardly use email at all any more. (Especially now that there’s a web app. It may still be in beta, but it works.)

Jenny posted a thing to the Glassboard blog (that I had written on a Glassboard board) with some more details about how we use it for work. If you have any questions, please feel free to ask me on Twitter or on the inessential board in Glassboard. (Invitation code: rovhy.)

How It’s Going with Glassboard

The Glassboard 2.0 launch counts as one of the best days in my career — we had way more downloads than I expected, and people liked the app.

I had setup an “inessential” board and posted the invitation code, so we were able to talk with people as they were checking out the app. Having that immediate contact with new users was energizing and loads of fun.

(The “inessential” board is still there. If you’d like to check out the app, get the iPhone or Android version and enter the invitation code rovhy. And post a picture or say hello.)

We also had some nice press and mentions. Jenny (one-sixth of Sepia Labs) spent a couple days at WWDC after-hours and people were eager to show her that they were already using Glassboard. Friends have said that they like it and use it, which means a lot to me.

The app was featured in Google Play for the last week, so we’ve been getting a ton of Android users lately. I’m proud of Nick Bradbury (Glassboard for Android author) and of our team.

Next Steps

While I can’t go into details, we’re working on a few things. The list is probably obvious.

  1. We’re working on making money. We have a plan — we know what to do — and now it’s a matter of making it so. I don’t expect any part of it to be surprising. The main things: we’re not going to start showing ads, and we’re not going to start trying to make money by selling or analyzing your private data.

  2. We’re working on the web app. It’s still in beta. There’s a cat silhouette in the upper-left corner of the app. Because it’s beta.

  3. We’re working on the mobile apps. There are bugs to fix and features to add — and we continue to polish.

For me personally this mostly means a return to coding. I spent most of the Glassboard 2.0 development time outside of Xcode, working on mockups and graphics. I wrote a little code just before the launch, but now I’m coding full time.

Which feels great. I love coding. (But I also loved doing the graphics. I think I love being able to switch between the two.)

In fact, the whole thing feels great. Every startup is a risk — and this one is riskier than many, since privacy is a fundamental part of the app and the outside world can’t see in, not in the way you can with Twitter and Instagram and similar apps. (And it’s not like an RSS reader where there’s a never-ending supply of content. Other people have to use the app to make it useful.)

But it looks like it’s working despite the risk — the app is doing very well.

The basic interaction — posting statuses, comments, pictures, videos, locations, files — has been proven to work on Twitter and Facebook and similar places, and I believe it’s the future of working together. (It sure beats email!) I can’t say for sure that Glassboard itself will be the app that everybody uses, but we’re on the right road.

And I’m excited.

Correcting the Dots

One of the cool things about Objective-C is all the common conventions. My code should look like your code.

But there seems to be one area where we’ve decided that anarchy is okay.

I’m a wild fan of chaos and things-on-fire — everywhere except for code. So here are my two pleas:

  1. Use dot notation for properties.

  2. Do not use dot notation for non-properties.

Yes, I know it doesn’t matter to the compiled code, but I like having the conceptual difference, and the syntax reinforces that difference.

And while you might not like dot notation — or you might love it and want to use it for things like count that are not properties — I ask you to remember that cool thing about Cocoa where we care about readability and common conventions.


In case the appeal to principle didn’t do the trick for you, here’s a practical case.

Say I’m searching a .m file to find out where a UIImageView gets its image set. Knowing that image is a property, I search on .image = to find out where it gets set.

If I find nothing I start to freak out because it doesn’t make any sense. I check the xib file to re-confirm that there’s no image specified there. I make sure the image view isn’t a public property — it isn’t referenced somewhere else. I even search the project for valueForKey:@"imageView" to see if some other class has cheated to get a reference to the image view. But no.

I know that image view displays an image, and I know the image is set somewhere in that file — and I can’t figure out where.

And then, after wasting time and brain cells, I remember to search on setImage:. There it is.

The above has happened to me. So has the problem of searching for count] in order to find when an array was counted — and not finding it, and getting frustrated, until I remember to search for .count.

What’s the obvious thing to do, the easiest way to agree? Just do what the headers say. If it’s a property, treat it as such. If it’s not, don’t.

And when in doubt, look it up. (If you’re not willing to take a little extra time to do things correctly, then you should probably find another career.)

On Buying Direct or Via Mac App Store


Apple now only accepts sandboxed Mac apps, clarifying the situation: customers should buy Mac apps directly unless there’s a good reason not to.

Wolf argues that sandboxing tips the scales in favor of buying direct.

I have to admit that I remain worried about sandboxing. I find myself discarding good ideas for apps just because of sandboxing rules. That can’t be a good thing for the platform.

And so I take a wait-and-see approach — don’t start any new Mac apps. Which also can’t be good.