Dustin Curtis found that Twitter has a patent on Twitter/Tweetie’s pull-to-refresh gesture.
Update (2012-03-29): Buzz Andersen:
Ultimately, I decided to nix the pull-to-refresh idea and go with a straightforward button because I felt the whole thing was a bit too self-consciously clever and not discoverable enough (the above iteration of the design was actually an attempt to solve the discoverability problem, but I still never really warmed up to it). This, of course, seems silly now since we all know how well received the idea was, but it’s very easy to forget that at the time Loren and I were racing to build the perfect Twitter client, nobody really knew what an iOS Twitter client should look like.
Neven Mrgan:
Simple ideas like this will naturally occur to many people. A small percentage of those will have the ability to execute on them. A small percentage of those will then actually do so. And an even smaller group will combine it with an otherwise interesting product, thus making it into something.
Also, it’s been noted that this is a patent application; it’s not necessarily been granted yet.
Update (2012-04-17): Twitter:
The IPA is a new way to do patent assignment that keeps control in the hands of engineers and designers. It is a commitment from Twitter to our employees that patents can only be used for defensive purposes. We will not use the patents from employees’ inventions in offensive litigation without their permission. What’s more, this control flows with the patents, so if we sold them to others, they could only use them as the inventor intended.
Mark Dalrymple:
The conclusion I draw at this point is that your choice of isEqual: and isEqualToString: is purely stylistic. If you have a lot of isEqual: calls in a method comparing other objects, go ahead and use isEqual:. If you want to tell the reader that you’re only expecting strings to be involved, use isEqualToString:. I believe that the demonstrated corner case makes any safety benefits moot in choosing which method to use.
The main point I would emphasize is the need to check for nil before using compare:, because if the receiver is nil you’ll always get NSOrderedSame. I like to use category methods such as mjtCaseInsensitiveIsEqual: where the result from a nil receiver will be what you expect.
Update (2012-03-30): Dalrymple has a follow-up post.
Chris Adamson:
In both of these cases, we see Apple breaking with their own documentation or with long-established practice with no warning, and instead using app rejections as a tool to communicate and carry out new policies. This is wretched for developers, who get caught scrambling to fix problems they didn’t know they had (or didn’t expect just yet).
App Review App Store Rejection Mac Mac App Store
Matt Neuburg:
As I’ve said, books can arrive on the device in ways that songs can’t. Suppose a book arrives via Dropbox or Safari on the device, and I transfer it to iBooks. Unless I take measures independently to make a separate backup, that may well be my only copy of the book. And such measures may not be easy to take, because the device, with respect to this strange music-and-movies-and-books category, is like a diode: current passes only one way. Just as you can copy music onto the device but you can’t copy it off again, so too you can get books onto the device but you can’t copy them off again. Meanwhile, the book isn’t being backed up to my computer — and it won’t survive migration to the next-generation device.
I mostly use GoodReader and the Kindle app, but I guess I should be careful with ePubs in iBooks.
