Marco.org

I’m : a programmer, writer, podcaster, geek, and coffee enthusiast.

Blindly speculating on Twitter’s future

Mike Isaac, The Future of Twitter’s Platform Is All in the Cards:

But amid the confusion of the past month, nearly all have overlooked the section of Sippey’s post which holds the key to Twitter’s future: Cards. Twitter’s new Cards technology allows third-party developers to create richer, more compelling — and, above all, visually consistent — content inside of Twitter itself.

Therein lies Twitter’s goal: A rich, consistent Twitter experience for every user. When the hammer drops and Twitter changes its guidelines, those apps that can’t deliver this consistency will no longer be able to integrate with Twitter.

A big question is whether Twitter will even give third-party apps the chance to display their “consistent experience” before cutting them off. I’m guessing they won’t.

Maybe the reason promoted tweets still don’t show up in the API, and therefore still aren’t displayed by third-party clients, is that Twitter never had any intention of monetizing the timeline outside of their official clients, because there won’t be any more third-party clients soon.

MG Siegler, Twitter’s Landscaping Problem:

I see the current Twitter Card offerings and I’m extremely underwhelmed. I don’t get the point of the news excerpts. Inline pictures are fine, but I don’t think I want to play micro-games inside of Twitter. I certainly don’t want to watch long-form video content there. And so I’m worried once again that all of these “extras” are going to overwhelm and distract from what Twitter has always really been about: information.

Over the last few years, Facebook has tried in a number of big ways to be more like Twitter because too much social activity was happening on Twitter and Facebook was threatened.

Now, Twitter may be about to turn their community upside down and make a lot of enemies to be more like Facebook because Facebook’s type of platform has more monetization potential and more platform lock-in effects.

The mutual envy is palpable. No wonder the two companies don’t like each other. They’re fighting for the same ground.

Facebook was already mostly there. For Facebook to add major Twitter-like features, it didn’t need to change very much, as far as users could tell. But for Twitter to add major Facebook-like features, they need to upend much of their service, causing a lot of destruction in their wake and breaking a lot of what people loved about Twitter.

Or, to use Twitter’s language, they’re about to break a lot of “the features that make Twitter Twitter.”

But I don’t think Twitter’s current leadership knows what makes Twitter Twitter anymore, if they ever did.

The Kaffeologie S-Filter

Most coffee nerds will tell you that paper filters block flavorful oils from getting into the brewed cup, while the superior metal-mesh and perforated filters will let these oils through for a superior taste.

The AeroPress is designed to use its paper filters, which the extreme coffee nerds have always held against it. A few years ago, Coava (now Able Brewing Equipment) made a stainless-steel perforated “Disk” replacement filter, which I really didn’t like, mostly because its holes were too large for the fine AeroPress grind and it complicated cleanup.

Now, Kaffeologie has launched the S Filter on Kickstarter, and they were kind enough to send me a preproduction prototype:

Kaffeologie says that the final version should be nearly identical, but with more precise welds attaching the outer ring to the mesh.


S Filter in front of Disk.

Note how much more fine the S Filter’s holes are compared to the Disk filter behind it. Here’s a closeup, with circles to indicate where the Disk filter’s holes are because they’re hard to see at this scale:

From the Kickstarter page, Kaffeologie claims:

It’s the finest reusable filter in the world. The S Filter is designed with smaller openings than any other reusable filter. By far. With tens of thousands of holes per square inch and hole openings smaller than a human hair, the S Filter will brew a much cleaner cup than other reusable filters.

I can’t verify their finest-in-the-world claim, but based on what I’ve seen, it’s certainly plausible.

Brewing

The S Filter lets water through noticeably more quickly than the paper filters. Therefore, when brewing with the S Filter, you should use the AeroPress inverted (upside-down) method if you’re not already using it.

Like the Disk, the S Filter’s thickness prevents the AeroPress’ cap from fully closing into its retaining teeth:

I was afraid that this might lead to grounds leaking around the filter, like they sometimes do when using paper filters without a tight fit, but this didn’t happen in practice.

Results

The S Filter produced very good coffee. Like the paper filters, and unlike the Disk, it left no sediment in the cup.

Unlike the Disk, it also didn’t clog on my fine grind (“6” on a Virtuoso 586). Because it didn’t clog, it was much easier to clean: the grinds fell right off of it with a quick rinse, just as Kaffeologie promised.

Of course, cleanup is even easier with the paper filters: just pop the puck of grounds, filter and all, into the trash and get another filter next time. The S Filter really isn’t a hassle, though: it’s still far easier than cleaning a French press or an auto-drip coffeemaker.


Paper-filtered cup on left, S-Filtered cup on right. Click for larger version.

I couldn’t detect any difference in taste or oils. As far as I know, the tiny, shiny dots on the surface of a fresh cup are the oils, and both of my test cups — one made with paper, one made with the S Filter — had approximately the same amount of visible oil. I also couldn’t taste any meaningful differences in overall flavor.

I cannot, therefore, recommend the S Filter for taste alone — I suspect the common paper-blocks-flavor-oils wisdom is a myth,1 or the difference is just too small to notice beyond the placebo effect.2

But the S Filter is a well-designed, very effective reusable AeroPress filter. I’m glad I have it in case I run out of filters or need to minimize paper waste in certain situations.

If you’d like one, too, they’re $10 on Kickstarter for the next 25 days, and they ship in September.


  1. I also can’t taste the difference between a rinsed and unrinsed AeroPress filter, so I don’t rinse them. Rinsing a paper filter might have a larger effect when there’s much more (and much thicker) paper being used, such as a thick pour-over or Chemex filter. ↩︎

  2. French presses, often lauded for their superior oil-filled coffee, have a lot of other reasons why their coffee could be so good. ↩︎

Don’t blame the link blog

Marcelo Somers, The Linkblog Cancer:

The problem is, we can’t all be Daring Fireball - we can’t get away with posting a witty headline and a blockquote 5-10 times a day. We’ve adopted John’s concept of linking, but not the idea that we need to tell a bigger story on our sites.

Kyle Baxter responds:

There’s no reason to link to something unless it’s something readers probably haven’t come across already or you can provide a unique perspective on it. Only link to something when you’re adding some value.

We do have a surplus of bad copies of Daring Fireball, but the link-blog format isn’t the reason. I think the real reasons are environmental:

Blaming the format itself for link-blog overload is like blaming Canon for the deluge of mediocre SLR photography over the last decade. The tools are now available to everyone, which is great. Most people won’t become world-class users of these tools, but the surplus of mediocre output doesn’t mean that there isn’t room for more people who can be truly great at it — it just means that most people’s link blogs aren’t worth following.

We don’t need more Daring Fireballs. We have Daring Fireball already. People who read it have little reason to read anyone else’s minimally differentiated clone.

Rather than letting my links tell a story arc with minimal commentary, I use link posts as a formatting convenience when I have a paragraph or three in response, but not enough material or time for an article. If I don’t have anything meaningful to say about a link, or if Gruber already did a better job of commenting on it, I’ll usually pass on it.

I’ve taken the link-blog format Gruber popularized and found my own way with it, and hopefully, that provides value and differentiation for readers.

And I highly suggest to other writers that they find their own way.

My next text editor

TextMate is over.

Suspecting this was going to happen last fall, I tried a few alternatives: BBEdit, Sublime Text 1, and an alpha of Chocolat. At the time, none of them won me over. Once the TextMate 2 alpha was released, I switched to it full-time.

But a few weeks ago, after concluding that TextMate 2 was probably going to be abandoned, I started trying the alternatives again with their significant updates: Sublime Text 2, and Chocolat 1.2.

I’ve now chosen my TextMate replacement, but before I reveal it, let me give a huge disclaimer: You will have your own opinion. It’s probably safer to talk about Jesus, gun control, Israel, global warming, parenting techniques, regional pizza styles, Linux distributions, why I don’t like cats, or my favorite PHP features.

Yet here I am, comparing text editors and giving my subjective and arbitrary opinions on them. What could possibly go wrong?

The big three

Like most software, text editors are best when they’re under active development and have large user communities. These usually ensure the fewest bugs and the strongest ecosystems of plugins and themes. In the world of general-purpose Mac text editors, that leaves three choices, in decreasing order of popularity:

BBEdit: Very long history, very active development, and top-notch developers. Unfortunately, it’s not my style in many big and small ways. I think its long history will continue to endear it to its userbase and long-time Mac users, but it doesn’t feel like the younger apps at all. It also has a much simpler syntax-parsing engine, which I think keeps it very fast but reduces the usefulness of syntax highlighting and scope-related editing features relative to the other editors. But I’m also pretty sure it will outlive them all. I wish I liked it more. (Used full-time for 2 weeks.)

Sublime Text 2: Cross-platform, fairly young, active development. In many ways, it’s “not Mac-like”, possibly because of the cross-platform implementation. It’s a bit ugly in places, and some common operations are unintuitive. But it has a huge fanbase and tons of plugins, and the engine seems solid: it’s extremely fast, seems stable, and supports every modern feature I tried. (Used full-time for 2 weeks.)

Chocolat: Very young, active development. It has the most modern Mac interface, but it also bears a creepy, uncomfortable, Samsung-like resemblance to TextMate: it’s effectively a TextMate clone with a few new features added. It’s very pleasant to use, but its youth is obvious: it’s still noticeably incomplete, and it suffers from serious performance problems frequently. The performance issues scare me, and I’m not sure it will be able to mature into a fast, full-featured, rock-solid editor. (Used full-time for 2 weeks.)

Alternative lifestyles

Vim and Emacs: Not native, very hard to learn, ugly, lack many modern features (flame suit: on). But they’re very powerful, they’re available on all modern OSes, and they work in remote terminals. Bonus feature: you can throw away your mouse. These apps are good for many things, but not the type of app I’m looking for. (Used Vim full-time for 2 years, and still use it on remote servers. Cursed at Emacs a few times in college.)

MacVim: Slightly native, but otherwise the same drawbacks as Vim.

Coda 2: A great web-development IDE by Panic. You couldn’t ask for better developers. But it’s a complete IDE, not a general-purpose text editor, so I can’t really include it here: if you want the type of app that Coda is, you should definitely try Coda, but if you’re looking for a text editor, it probably isn’t a good fit.

SubEthaEdit: A very good editor, but it was dramatically outclassed by TextMate 1. Coda 1’s editor was based on SubEthaEdit’s engine. Recent development seems minimal. I bet that if you’re reading this and you have SubEthaEdit, the last time you launched it was at WWDC, where its collaborative-editing feature is still very popular for publicly shared, collaborative notes. And before that, the last time you launched it was probably WWDC 2011. (Used full-time for a few months in 2006.)

TextMate 1: You could just use TextMate 1 until it stops working. But it has many small flaws, a few big ones, and some performance issues, and it lacks many modern features. It will probably never get another significant update, and it might not even get any future bugfix or compatibility updates. (Used full-time for 5 years.)

TextMate 2 alpha: Development has just been open-sourced after 7 months of going almost nowhere, so it’s probably safe to assume that it’s effectively abandoned. It supports many modern features and is quite good in many ways, but there are huge bugs, shortcomings, and performance issues that will probably never be fixed. If someone else took this over and worked on it full-time for a year or two, it might become a great editor, but today, it isn’t, and there’s nobody at the wheel. (Used full-time for 7 months.)

So what’s next?

I almost picked Chocolat, but its performance problems gave me pause.

So I picked Sublime Text. So far, I don’t love it, but I like it. The more I used Chocolat, the less I liked it, but as I continue to use Sublime Text 2, I like it more.

And I think it has a more promising future of stable, high-quality, long-term development than anything else on this list except BBEdit, which I still wish was more my style, but it still isn’t.

I’ll see how Sublime Text grows on me.

Interpreting some of Twitter’s API changes

Twitter has posted some of their upcoming API-policy lockdowns and restrictions in this post from Michael Sippey, euphemistically titled “Changes coming in Version 1.1 of the Twitter API”.

First, from Twitter’s Display Guidelines, which will become requirements for all apps:

“Individual Tweet” section

Embedding tweets in a blog post in any way other than their dynamic embed code is effectively prohibited:

[3a] Reply, Retweet, and Favorite action icons must always be visible for the user to interact with the Tweet.

[5b] “The Twitter logo or Follow button for the Tweet author must always be displayed in the top right corner.

I’m pretty sure this means that I can’t just display a tweet as a link and blockquote when I want to quote it here.

Sending links to Instapaper or its clones, viewing a tweet on Favstar, and certainly sharing links to tweets on other social services is probably prohibited:

[3b] No other social or 3rd party actions may be attached to a Tweet.

Whether email clients (“Email link”) and web browsers (“Open in Safari”) count as third-party actions is yet to be determined.

Zooming full-sized pic.twitter.com images in their own windows or screens is probably prohibited:

[6b] pic.twitter.com images may not be detached and displayed separately from the Tweet.

That also seems to prohibit apps that render only photos, such as gallery or photo-browsing apps. And it might create a Twitpic-ownership-like issue.

“Timelines” section

Rule groups 1–4 dictate tweet layout with very little flexibility. Timelines in all conforming clients will look extremely similar.

Rule 5a is far-reaching:

[5a] Tweets that are grouped together into a timeline should not be rendered with non-Twitter content. e.g. comments, updates from other networks.

In other words, apps cannot interleave chronological groups of Twitter posts with anything else.

This is very broad and will bite more services and apps than you may expect. It’s probably the clause that caused the dispute with LinkedIn, and why Flipboard CEO Mike McCue just left Twitter’s board.

Closer to home for me, it affects Instapaper’s “Liked By Friends” browsing feature, which will need to be significantly rewritten if I want it to comply. (If.)

Naturally, this also prohibits any client from interleaving posts from Twitter and App.net, or any other similar service, into a unified timeline.

“Requiring developers to work with us directly”

The rest of the “Changes” post is full of bad news for developers:

One of the key things we’ve learned over the past few years is that when developers begin to demand an increasingly high volume of API calls, we can guide them toward areas of value for users and their businesses. To that end, and similar to some other companies, we will require you to work with us directly if you believe your application will need more than one million individual user tokens.

How, exactly, will Twitter “guide” developers who are required to “work with them directly”? What exactly are “areas of value for users and [our] businesses”?

Translation: “Once you get big enough for us to notice, we’re going to require you to adhere to more strict, unpublished rules to make sure you don’t compete with us or take too much value from our network.”

And “big enough” might not be as big as you think:

Additionally, if you are building a Twitter client application that is accessing the home timeline, account settings or direct messages API endpoints (typically used by traditional client applications) or are using our User Streams product, you will need our permission if your application will require more than 100,000 individual user tokens.

Instapaper’s “Liked By Friends” feature reads timelines and will need more than 100,000 tokens. And that’s a relatively minor feature in a small web service run by one guy.

We will not be shutting down client applications that use those endpoints and are currently over those token limits. If your application already has more than 100,000 individual user tokens, you’ll be able to maintain and add new users to your application until you reach 200% of your current user token count (as of today) — as long as you comply with our Rules of the Road. Once you reach 200% of your current user token count, you’ll be able to maintain your application to serve your users, but you will not be able to add additional users without our permission.

Got a successful Twitter app or Twitter-integrated service already? Either “work with” Twitter quickly and make whatever changes they require before you get too many more users, or shut down.

Finally, there may also be additional changes to the Rules of the Road to reflect the functional changes in version 1.1 of the Twitter API that we’ve outlined here.

There will definitely be more rules that we’re not ready to discuss yet, possibly because we haven’t decided what they are yet, or possibly because we know you’re not going to like them.

For instance, I bet this is finally how clients will be required to display tweet ads. That requirement, probably worded roughly as “you must display every tweet in a timeline, and display them all consistently”, will also kill any clients’ filter and mute features.

Twitter for Mac and iPad

Twitter for iPhone has been thoroughly gutted of any traces of its Tweetie origins, and it’s clearly Twitter’s premiere client. (It probably gets more usage than their website.)

But Twitter’s own Mac and iPad apps, both also acquired as versions of Tweetie, haven’t been meaningfully updated in many months. Both lack significant features and have glaring bugs, and neither of them comply with the Display “Guidelines”.

Twitter’s inaction on these apps suggests that they’re probably going to be either discontinued entirely (most likely for Mac) or gutted and replaced with an interface more like their iPhone app (most likely for iPad).

Subjectivity and uncertainty

Twitter has left themselves a lot of wiggle-room with the rules. Effectively, Twitter can decide your app is breaking a (potentially vague) rule at any time, or they can add a new rule that your app inadvertently breaks, and revoke your API access at any time.

Of course, they’ve always had this power. But now we know that they’ll use it in ways that we really don’t agree with.

Anil Dash wants us to compare this to Apple’s App Store review process (while not using App.net if we’re white geeks, or something like that). The amount of power Twitter has over developers is similar to the App Store setup, but the incentives are completely different.

Many uses of Twitter’s platform compete with Twitter on some level. Twitter doesn’t need a lot of its nontrivial apps, and in fact, they’d be happier if most of them disappeared. Twitter’s rules continue to tighten to permit developers to add value to Twitter (mostly “Share on Twitter” features) but not get nearly as much out of it (e.g. piggyback on the social graph, display timelines, analyze aggregate data).

By comparison, Apple needs its apps much more than Twitter does, and Apple’s interests conflict much less with its developers’. Even its famous anticompetitive rules, such as the prohibition against “duplicating existing functionality”, have been minimally enforced and have actually diminished over time.

Furthermore, we know pretty well how Apple will behave and what sort of rules we’ll need to follow in the future. They’ve been consistent since the App Store’s launch. But Twitter has proven to be unstable and unpredictable, and any assurances they give about whether something will be permitted in the future have zero credibility.

I sure as hell wouldn’t build a business on Twitter, and I don’t think I’ll even build any nontrivial features on it anymore.

And if I were in the Twitter-client business, I’d start working on another product.

Pass the costs along

Andy Ihnatko’s reaction to the Apple-Samsung lawsuit struck a nerve:

The biggest losers here are consumers. If the verdict stands, then the costs of the judgment will be reflected in the cost of mobile devices. Furthermore, other manufacturers will feel the need to buy Apple’s official permission to build useful phones, passing down the possible $20-per-handset fee.

I disagree that “useful” phones need to be so close to the iPhone that they run into Apple’s patents and trade-dress claims in the Samsung case.

I also don’t buy the “we’ll have to pass the costs along” argument. Businesses always say that to scare people, usually government regulators via their voters, into maintaining the status quo and avoiding additional regulatory, safety, or environmental costs that are usually better for consumers.

Smartphone and “tablet” manufacturers will keep doing what they always do: sell us their products at the highest prices they can possibly charge for them to maximize total revenue.

Maybe we’ll pay this theoretical “extra $20” in patent-license fees for our smartphone up front, a surcharge less than any carrier in the U.S. will charge to “activate” it, because it’s a drop in the bucket relative to the $2,000-over-two-years contract. In that case, this discussion is moot.

Or that extra $20 is significant, we won’t pay it, and the manufacturers will find a way to save $20 somewhere else to remain competitive and continue selling us their products that are so close to the iPhone that they run into these patents.

Ihnatko continued:

And it’s possible that the next great phone, the one that shames the iPhone the same way that the iPhone buried the Blackberry, will never make it to market. Designing and selling an advanced smartphone just became a dangerous business.

Apple’s claims from this case aren’t very far-reaching. What they won, effectively, is a weapon to use against anyone who copies a narrow set of behaviors, appearances, and packaging designs.

If Samsung wasn’t so blatantly idiotic about copying so much from the iPhone, Apple wouldn’t have won so many of their claims. In fact, Apple lost most of their more generic, less-blatantly-copied iPad claims.

Google has already sidestepped most of Apple’s interface-behavior patents with the newest versions of Android, which might eventually be used by more than a handful of customers. And Android is much more of an iPhone-ripoff “iOS-inspired platform” than Windows 8, which has avoided almost all relevant Apple patents.

What’s really going to disrupt the iPhone is going to be something completely different, not something that tries so hard to clone the iPhone that it hits Apple’s patents.

Unoriginal manufacturers will need to pay for their unoriginality. The most reasonable course of action, therefore, is to truly innovate and design products that aren’t such close copies.

I fail to see how consumers lose.

Retina MacBook Pro review as a Mac Pro owner

I just returned from a five-day trip in which I worked a lot, doing significant amounts of writing, web development, and especially iOS development. And I did it all on my base-model Retina MacBook Pro: the $2199, 2.3 GHz model with “only” 8 GB of RAM and a 256 GB SSD.

This is the best computer I’ve ever used. And I can say that with no hesitation, qualification, or equivocation.

It still can’t be my primary computer, and in that sense, I can’t say it’s the best computer for me, necessarily. But that’s mostly only because I’m a picky asshole who doesn’t like a cable-covered desk, clamshell mode, dual-monitor annoyances, or external hard drives, yet I don’t mind the cost and inconvenience of having both a desktop and a laptop.

For most reasonable people’s needs, this can easily be their only computer. And if some crackpot legislators passed a law tomorrow that everyone could only have one computer, I’d definitely pick the Retina.

The only performance issue I regularly hit is the jerky scrolling, which is covered well in the excellent AnandTech review:

To be quite honest, the hardware in the rMBP isn’t enough to deliver a consistently smooth experience across all applications. At 2880 × 1800 most interactions are smooth but things like zooming windows or scrolling on certain web pages is clearly sub-30fps. At the higher scaled resolutions, since the GPU has to render as much as 9.2MP, even UI performance can be sluggish. There’s simply nothing that can be done at this point - Apple is pushing the limits of the hardware we have available today, far beyond what any other OEM has done.

I used it at the scaled “1680 × 1050” resolution the entire time, since the native “1440 × 900” resolution isn’t enough space for me to comfortably do iPad development in Xcode. I definitely felt the sluggish UI performance.

But that’s the only negative point I can make, and it’s really not that bad.

With mostly CPU-bound tasks, the Retina is not technically as fast as my “new” 2010 3.33 GHz 6-core Mac Pro, but in real-world use, it’s close enough to not notice the difference most of the time. And I have the base model. (The three available CPUs are all within about 10% of each other’s real-world performance, so I opted for the lowest-end one to keep the cost reasonable, minimize heat, and maximize battery life.) The long-standing performance gap between the Mac Pro and the MacBook Pro is now effectively moot, except for that UI performance issue.

In addition to the value of the high performance and potentially available screen space, iOS development is especially great on the Retina because the Simulator runs natively at Retina density. So you see your app in the Simulator exactly as it will appear on any modern iOS device. (Except maybe that rumored non-Retina iPad Mini in October.)

While people accustomed to MacBook Airs probably think the 4.5-pound Retina is big and heavy, I’ve found it to be noticeably thinner and lighter compared to the previous 15” MacBook Pro. It no longer feels like a “big” laptop — few would argue if Apple just called it the 15” MacBook Air. Given this size reduction and the huge increase in power and usefulness over the MacBook Airs, I no longer wish that I was carrying a 13” Air instead: the Retina is small and light enough to alleviate that desire, especially knowing what I’m getting for the additional mass.

And the screen.

That screen.

I thought, having previously used Retina screens on my iPhone and iPad, that I had a pretty good idea of how good a Retina screen would be on a laptop.

I was wrong. It’s far nicer than I expected. And after five days of only seeing Retina screens, the 30” HP ZR30w on my desk really looks like garbage. Huge, spacious garbage.

My only regret about the Retina Display is that I can’t buy a standalone one for my desk, and this one’s not big enough to just prop up the laptop on a stand and use it as the only monitor in a desktop setup.

We’re obviously in the middle of two awkward transitions: toward all-Retina screens, and toward all-SSD storage. The difficult computer choices that many power users will struggle with will probably be much easier in 2–3 years, when even the most die-hard desktop users can probably get a MacBook Something with a priced-within-reach 2 TB SSD and an external 27” Retina Display for desktop use.

Today, that’s just a fantasy. So while this Retina MacBook Pro is the best computer I’ve ever used, I’m also impatiently waiting for the day when I can comfortably make one of these my only computer, and it’s not there yet.

In the meantime, I can definitely see why so many people are migrating from Mac Pros to the Retina MacBook Pro. When the next Mac Pro comes out, I might not want it.

27” Retina math

Reader Adam Lacy sent this via email, reprinted here with permission:

I was reading an article about the new 84” Toshiba 4K TV and it got me thinking about how 4K relates to Retina Display PPIs.
I wanted to speculate on the possibilities for the future iMac/Cinema Displays. In doing so I came across some interesting math.

4K = 3840 × 2160

If you work out the PPI for 4K at 27 inches it conveniently comes out to 163 PPI.

That’s pretty close to the 165 PPI for the iPhone 3GS and the speculated iPad Mini.

Apple’s been having this display PPI manufactured for a long time now and I bet they’ve been testing cuts at 26.7 inches (almost 27).

This would be exactly 4K (3840 × 2160), it would be 165 PPI, same as iPhone 3GS/iPad mini, and would also be exactly 1.5 times the size of the current iMac’s resolution of 2560 × 1440. Not doubled, but I think that matters less for OS X.

This would easily meet some of the Retina Display requirement charts. And would probably work nicely with pixel doubling 1080p video content for display.

Not bad. Not bad at all.

I did some measurements myself: I sit about 24” away from my 30” desktop monitor. If I sat approximately as close to a 26.7” Retina Display, the effective pixel size is similar to the iPad 3 at my viewing distance from it, too. It would barely qualify as “Retina”, but if it had a scaling mode to give me the same space as 2560 × 1440 (much like the Retina MacBook Pro’s simulated 1680 × 1050 and 1920 × 1200 modes), I’d take it.

By the time Thunderbolt is fast enough to send 4K video (some have speculated that this will come with Thunderbolt 1.2 in 2014) and GPUs are fast enough to render the interpolated modes without significant lag, I bet it’ll be surprisingly affordable to manufacture such a panel.

Predicting the “iPad Mini” internals

I saw two curious entries in Instapaper’s device stats today: one iPad2,5 and one iPad2,6.

(There were also a few iPhone5,1 devices, but that’s not a surprise — that’s almost certainly next month’s new GSM iPhone.1)

These device models, as reported by the OS, could be faked by a jailbreaker with enough free time.2 But I’ve never had a device show up there that didn’t end up being a real, about-to-be-released Apple device.

iPad2,1 through iPad2,3 are the iPad 2’s original Wi-Fi, GSM, and CDMA models, respectively.

iPad2,4 is the 32nm die-shrunk update that quietly replaced the 16 GB Wi-Fi iPad 2 when the iPad 3 was released, yielding better battery life and lower cost, and probably partly responsible for the iPad 2’s price drop to $399. From AnandTech’s detailed review, this remark now seems prescient:

It’s rare these days that we actually see a pure die shrink anymore. With Intel’s tick-tock model we almost always see increases in functionality to accompany each process node shift. … With Apple’s 32nm A5 however, we truly end up with a die shrunk version of the 45nm A5 SoC. About the only part of the computing world where we see these pure shrinks is in the console space where performance doesn’t have to go up within a generation, but cost must go down.

As far as I know, this was the first time Apple invested in a die shrink mid-cycle for any of the iOS devices. They haven’t even done it for the still-sold iPhone 3GS or iPhone 4. The decision to revise the iPad 2 internals, therefore, seemed a bit odd at the time, but makes a lot more sense now.

The iPad2,5 and iPad2,6 could be boring: GSM and CDMA versions of the die-shrunk iPad 2 so the shrink isn’t only available on the Wi-Fi model, bringing lower costs to the other iPad 2 configurations that are still for sale. But now, even later in its lifecycle, that would be a pretty strange move.3

The much more likely explanation is that iPad2,5 and iPad2,6 are the new “iPad Mini” in Wi-Fi and GSM, and I haven’t recorded the likely iPad2,7 CDMA version yet.4

If so, this suggests that the iPad Mini is, effectively, an iPad 2: an A5 with 512 MB of RAM and enough GPU power to drive the Gruber Display, but not a Retina Display.

It’s a textbook Tim Cook supply-chain move: selling the last generation’s hardware at a lower price point to expand marketshare.

But this time, it’s more dramatic. Rather than just sell the original iPad 2 with a price cut, they’ve made a new product designed to be far less expensive from day one by combining old and new parts: the 32nm iPad 2’s guts, larger-cut iPhone 3GS screens, a smaller case and battery, and the new iPhone’s low-power LTE chip for $100 more.

This is all speculation, of course, but I’m convinced: like the leaked Dock connector, this move is so ingenious that it’s most likely to be what Apple has really done.

I bet they could sell that for $249, and that would be a steal. The iPad 2 is still great by today’s standards, and in some ways,5 it’s actually better than the iPad 3.

This is going to be an interesting two months.


  1. The sixth iPhone bearing an iPhone5,1 model identifier isn’t going to help the “it’s not the iPhone 5” cause. (The numbering is off because the iPhone 3G was model iPhone1,2.) ↩︎

  2. But who would fake an oddly numbered iPad 2? A faker would almost certainly choose iPad4,1. ↩︎

  3. Update: Some readers have suggested that these iPad2,5 and iPad2,6 model identifiers could just be another standard iPad 2 revision with the new Dock connector. That’s also possible, but I think it would be just as strange and unlikely: that’s a major revision for a product that might only be sold for another 6 months. And I’d probably also see an iPad3,4, iPad3,5, and iPad3,6 representing the similarly revised iPad 3 models.

    I think the more likely explanation is that the iPad 2 and iPad 3 won’t be updated to the new Dock connector — the next 10” iPad will get it, and the iPad 2 never will. The iPad 2 might even be quietly discontinued after the Mini is released and existing stock is depleted. ↩︎

  4. Update: As many have pointed out, the iPhone 4S has a universal radio and doesn’t have separate model identifiers for GSM and CDMA. But the iPad 3 does. If the iPad Mini has a universal radio, there may not be an iPad2,7. ↩︎

  5. It’s thinner, lighter, cooler-running, faster at some graphics operations, and much faster to recharge. And with the 32nm shrink, it has a noticeably longer battery life. ↩︎