AAPL Stops On A Dime

Two months ago, Joe Springer of Seeking Alpha called out January 18, today, as a point of interest in the trajectory of Apple’s stock price. He suggested that because of a particularly large number of open AAPL options expiring today, this would be a turning point: the stock price would remain artificially deflated through today, and then rise more organically starting next week.

Earlier this week, John Gruber of Daring Fireball linked to the post and gave his own summary of the situation:

Billions of dollars at stake if AAPL stays near or under $500 a share until January 19 and then makes a run after that. No tinfoil hat required to see the motivation here.

I’m not sure where the $500 number comes from, because it wasn’t cited in the original article. I suspect that Gruber did some more research and determined that in the months since Springer’s article, $500 had become the most popular option price among investors, and thus carried the heaviest weight among the variously-priced options set to expire today.

Today, Apple’s stock price closed at exactly $500. Sometimes the way things unfold seem too precise to be merely coincidence, and Gruber’s reaction to the news says as much:

I still have that bridge to sell you if you don’t think the fix was in on this.

But was it a fix, or merely an “honest” market doing what markets do? I don’t claim to know too much about the perplexing ebbs and flows of the stock market, particularly when it comes to options, but this article by Rocco Pendola offers a counterpoint to the conspiracy angle, taken verbatim from his interview in 2011 with Neil Pearson:

Neil Pearson: Let’s use AAPL as an example. Friday, AAPL’s closing price was near $340. Further, let’s suppose that there is a large trader or group of traders who follow a hedging strategy that requires them to sell aggressively if AAPL rises above $340, and buy aggressively if AAPL falls below $340. If this is the case, their trading will have a tendency to “pin” AAPL at or near $340. It is only a tendency, because during the week there might be some event, either a news announcement or trading by some other investors, that dwarfs the effect of the hedging strategy and moves AAPL away from $340.

In other words, Pendola agrees that the large number of open options had a part in pushing the stock price to $500, but insists that the fact that it closed precisely on that number was hardly guaranteed or “fixed” as Gruber suggests.

Because Pendola and Pearson are experts in stock analysis, who have covered precisely this topic before, even to the extent that Apple was previously the subject, I tend to respect their conclusion. I also noticed that in after-hours trading, AAPL hasn’t begun rocketing upwards. If there were some conspiratorial manipulation of the stock to keep it at $500 only through close of trading today, one would imagine it would have traded higher than $500.31 after-hours.

I was as quick as anybody to jump on the conspiracy wagon when the stock closed exactly at $500, but sometimes truth really is stranger than fiction.

Dell’s Downfall

I wrote seven years ago that Dell was on the way out. Apple had just announced they would be moving to Intel-based CPUs for the Mac, and I extrapolated, somewhat wildly it turns out, that this would lead to Dell’s downfall.

I was wrong.

A huge, erroneous assumption in my condemnation of Dell was that Apple’s ability to boot Windows on Mac hardware would make the buying decision easy for folks who cared about Windows but wanted a high-quality machine. In retrospect, I don’t think the ability to run Windows on Mac has done nearly as much to help Apple as I predicted. Why? Windows became irrelevant. In late 2005 I saw the future of personal computing as a battle between Macs, PCs, and Linux. With the debut of Intel Macs, I saw Apple coming to the table with a trump card: “if you like our hardware, we can run your OS!” For a moment, the Mac could run every relevant, mainstream personal-computing OS. That didn’t last long.

The debut of iOS, Android, and to a lesser extent, Windows 8, changed the landscape. Nobody cares that the Mac can run Windows anymore, because nobody cares about Windows. And as much as it pains me to say it, outside of the relatively small group of enthusiasts to which I belong, nobody cares about the Mac. The mass market turned to mobile, and it was Apple, Google, and Samsung who ended up seizing on that opportunity.

I haven’t kept close tabs on Dell over the past several years. Heck, I thought they were on the way out of business, so why should I bother? But taking another look I find their marketing emphasis is almost identical to what it was before. You can buy a laptop, you can buy a tower, you can buy a monitor. That’s the Dell way, and although I’ve been wrong before, I am doubling down: the Dell way will be Dell’s downfall.

Aaron Swartz

I woke to the sad news that Aaron Swartz has died by suicide.

I have been inspired by Aaron’s work and philosophy since 2004, when I started reading his thought-provoking blog. I checked in with him after a few of his more down-spirited posts, and this led to a very loose, occasional friendship by email. Our paths nearly crossed in the Boston area a few times but owing separately to his or my own social anxieties, we never met in person.

Like many successful people, Aaron never seemed to appreciate his own achievements the way others did. After Reddit was acquired by Wired, presumably making him rich, he wrote about his inability to celebrate like his co-founders did, and all but wished it undone.

A piece that will probably get a lot of attention in the wake of his death is his own dramatic post about suicide from 2007, which was originally written auto-biographically. The post elicited responses from many people, including me. I wrote to reassure him, lightly, that many folks would miss him if he left us. He thanked me, and said he was “just having a really bad week.”

Given the combination of challenges Aaron faced, from the inner voices that talked down his successes or criticized his appearance, to the fear of imprisonment for trumped up charges of wire fraud, these “really bad weeks” may have been frequent.

It’s hard to find an appropriate perspective for commemorating somebody who has died so suddenly and so tragically. When suicide is involved, our society tends to look for someone or something to blame, often the victim himself. After witnessing a small extent of the struggles Aaron fought, I choose to commemorate him with gratitude for the many bad weeks when he resisted drastic action, and gave us all more time to appreciate and share his contributions.

Screenshot Lightning

Apple recently changed their policy regarding screenshots for iOS applications in the App Store: you must supply any changes to your screenshots by the time of approval, or the existing screenshots will be locked down until the next time you submit and are approved.

Long story short: you better have those screenshots ready at submission time or very shortly after. And the screenshots had better be something you are willing to live with for a good long while.

This is a dramatic change from the old policy, under which developers could update screenshots at their leisure. This afforded a workflow where a developer might put all of their effort into the actual development of the app, submit it, and then get to work fine-tuning their screenshots for the marketing aspect of selling in the App Store.

One reason for putting off the job of creating screenshots is that creating them is time-consuming and tedious, even with a relatively simple app. For a more complex app, or one that is localized into many languages, the challenge is that much greater.

Last night, at our local Boston CocoaHeads meeting, I learned about a well-timed solution for this problem. Kent Sutherland, the programmer for Flexibits, showed off how he uses an automated screenshot-capture procedure to tame the task of generating Fantastical’s many screenshots, in many languages.

His approach uses a novel technique in which the target app itself is built with customized screen-capturing code compiled right in. Then the app can be driven through the iOS Simulator with WaxSim, a command-line tool for launching the simulator with various options. He was kind enough to share a sample project in which he applies the same technique to Apple’s UICatalog sample app:

Click to download Kent’s UICatalog sample.

After downloading the sample, navigate to the “Screenshots” folder to find the real goodies. The Readme.txt in that folder has simple instructions for kicking off the process. In a nutshell: just open the Screenshots folder in the Terminal, and type “python make_screenshots.py output”. Then watch as the iOS simulator cranks through the process of generating 12 screenshots for UICatalog before you’ve had a chance to wipe that tear of joy from the corner of your eye.

I plan to build more iOS software in the future, and something like this will undoubtedly be a lifesaver when I have significant screenshots to generate. My only existing iOS app, Shush, only has 4 screenshots in one language, and I still found it tedious enough to re-generate screenshots that I hesitated to improve the UI because of the work of another round of, ahem, bitsplitting.

The same approach is also applicable to Mac apps. Currently I go through a similarly tedious procedure of manually navigating and cajoling the app into a specific state before taking a screenshot by hand. This could all be driven by automated capture code built into a custom version of the app, where I could also imagine other niceness such as adding annotations to illustrative screenshots, being added to the process.

If you’re selling apps on the iOS App Store, Apple’s policy change makes it imperative that you come up with a workflow for effortlessly and quickly generating screenshots. Thanks to Kent’s generous sharing of his approach, your work is mostly done for you.

Shame Projection

Marco Arment addresses the common defense among media pirates that lack of a legal alternative has “forced” them into pirating it:

Admit it: you’re ripping it off, it’s morally questionable at best (and illegal), but you don’t care.

A few years ago my wife opened my eyes to the phenomenon of shame projection. In short: assigning blame for your own shortcomings to external circumstances. Now it’s like that thing where you learn a new word and suddenly start noticing it everywhere: our society is swimming in shame projection.

I am no psychologist, nor have I ever taken a psychology class, nor have I even finished the “Psychological Projection” Wikipedia article cited above. So I’m probably completely misguided and wrong about this, but an example that springs to mind is when a motorist almost runs me down, and then screams at me for being in the way.

What happened in the blink of an eye is:

  1. Motorist is cruising along, distracted, late for work, whatever.
  2. I step into the crosswalk, over-confident of my right of way.
  3. Motorist proceeds to within inches of striking me before braking abruptly.
  4. Motorist feels terrified, ashamed, regretful, and then grateful I’m not hurt.
  5. I, nearly killed, glare my visceral outrage at motorist.
  6. Motorist feels offended by my lack of graciousness upon not being killed.
  7. Motorist’s brain seeks unconsciously for directions to project blame.
  8. Upon not finding any reasonable outlet, brain settles on me. Watch where you’re going, you idiot!
  9. Motorist carries on, content that he or she was the victim, not me.

Most folks who pirate media are feeling some of those same terrified, ashamed, regretful, and grateful feelings that the motorist felt upon almost killing me. In the case Marco cites, the projection outlet is on the companies for not making the media available.

This kind of projection seems to have a delightful efficiency. When the media companies do make the media available, the blame will be on their pricing it too high. When the price is right, it’s the media format that’s wrong. If the media format is right, then the DRM is too odious. If DRM is absent, then the authors are making too much money, anyway. If the authors aren’t making much, you’re only pirating to try it out. Once you’ve tried it and like it, you’ll pay for it when you get your next paycheck. You wouldn’t have to pirate at all if your boss wasn’t such a cheapskate and paid you better…

Hacking My AOL Account

When I read Mat Honan’s article today about the relative uselessness of passwords in protecting the security of our various online accounts, I was attracted by his assertion that it’s particularly easy to hack into an AOL account:

Let’s say you’re on AOL. All I need to do is go to the website and supply your name plus maybe the city you were born in, info that’s easy to find in the age of Google. With that, AOL gives me a password reset, and I can log in as you.

Although I have never been an avid AOL user, I do have an AOL Instant Messenger (AIM) account. I figured, and was correct, that for the purposes of this assertion, the accounts are one and the same. I quickly set about hacking my own account, just to see if it was as easy as Honan had described.

After navigating to AOL, I clicked the Login link and then clicked the “Forgot password” link to get to a very friendly, step-by-step process for resetting the password on an account. As Honan predicted, it offered to let me reset my password if I could supply my home town and another piece of personal information such as my birthday. But try as I might, I couldn’t get the right answers, and therefore I couldn’t break into my own account.

You see, I have had a habit for a long time of supplying bogus information when prompted for personal information. Obviously I break this habit when dealing with an institution that legitimately requires it, but I guessed that when I signed up for AIM, I had supplied false information. The nice side-effect of this appeared to be that my account was now less hackable than a typical account.

Of course Honan has had a little more practice than me with this, and when he saw my tweet he was inspired to ask if he could give it a shot. He and I are friends, and I trusted him to do nothing more than test the security of my account, so I agreed. He said it might take a day or two. A few hours later he sent me a screenshot of the AOL page where it was helpfully offering to let him enter a new password for my account.

I simply hadn’t tried diligently enough to get through the ridiculous “security” wizard. In the end it was as simple as knowing that I grew up in Santa Cruz (a value that I had evidently chosen to enter accurately), and that my email address was my last name at “red-sweater.com.” Totally, outstandingly, ridiculously poor security.

I made a video of myself “hacking” my own account, to show just how awful it is. The worst part is AOL will offer a laughably guessable hint about the alternate email address (j****t@red-sweater.com) down one security path, which can then be used to satisfy the secret question answer down another path.

As I said in the video, my best advice for anybody who has an AOL/AIM account is to change every personal detail on the account to something bogus, and to write those values down in an encrypted note somewhere for future reference if it’s needed. An idea I had is to choose as the email address something like “jalkut+fdj29f292935″@red-sweater.com. This way the confirmation email will still get to you if it’s ever needed, but the address will be much harder to guess.

Shame on you, AOL.

The Anti-Apple Market

John Gruber points to Amazon’s willingness to use its valuable home page to antagonize Apple and its fans by deriding the iPad mini in comparison to the Kindle Fire HD:

I’m sure some people will love it; they’re going for the anti-Apple market.

I first learned about Amazon while working at Apple in the mid-1990’s. There was a series of mail-sorting cubby holes in a hall at work, and I remember noticing the Amazon-branded boxes multiply as my colleagues turned on to the dead-simple innovation: a huge selection of books and music delivered to your door for a reasonable price.

Although I was an early, occasional patron of internet commerce, I looked at Amazon with some derision because of a character flaw. For as much as I appreciate and yearn for innovation, I tend to overvalue the status quo. These folks were buying nearly all their books and music online. My internal dialogue judged them as entitled and too lazy to support a local shop. They may well have been, but a few years later, I was shopping at Amazon too.

From the beginning Amazon has shared Apple’s focus on simplification and iterative improvement. Their catalog evolved into the internet’s de facto product review authority. It’s as easy today to buy all your toilet paper from Amazon as it was to buy all your books from them 15 years ago. Amazon CEO Jeff Bezos’s reputation for customer-focused innovation is often compared with Steve Jobs’s mastery of that art.

The company has grown consistently from within but also through judicious acquisition. The companies they buy typically share that quality of providing customers with some product at a level of service that was previously thought infeasible. Zappos sold upscale shoes with an unfathomably generous return policy. The IMDB collected an unprecedented database of information for film buffs. Audible cracked open the market for digital audio books. I made my first CD Now purchase through a terminal connection over telnet! “Amazon companies” are always innovative, and focused primarily on the service of premium customers.

As with Apple, Amazon’s pursuit of premium customers has resulted in a strong appeal to the mass market. I believe that companies like Amazon and Apple have expanded the expectations of the mass market, such that it’s getting easier to market a company based on its unique, premium innovations. The “anti-Apple” market historically pooh-poohs these advantages, reducing the product landscape to a crude, high-level comparison of features and prices. This is what Amazon has done on their home page, comparing the $199 Kindle Fire HD to the $329 iPad mini, while audaciously claiming they offer “Much More for Much Less.”

Since when does Amazon target the anti-Apple market? The companies compete in a growing number of areas including digital music, movies, and eBooks. But Amazon has thrived with this competition largely because it targets the same market that Apple does, while doing some things better than Apple. From the early days when my colleagues were tearing open shipping boxes at Infinite Loop, to the present time when many Mac and iPhone aficionados cling tenaciously to their authentic Amazon Kindles, the pro-Apple market is the pro-Amazon market. Why would a company that has historically aimed so high change its focus to the lower end?

I see this as a rare example of concession on Amazon’s part. Traditionally when the company discovers they are not the best in a market they wish to dominate, they acquire the stunning leader and integrate the advantages. Here they are going up against Apple, which happens to be both the largest company in the world and also the most inimitable hardware designer. Amazon can’t buy it, and Amazon can’t copy it. They must compete on price, and they must confuse on features. They must go anti-Apple, which is a shame for Amazon and a shame for customers, but it’s the only reasonable choice they have.

Fairly Priced

Tapbots released a Mac version of Tweetbot, their popular Twitter client.

I have been beta testing the application for months and have found it to be a suitable replacement for Twitter.app, the once neglected, now abandoned official application.

But folks are talking less about Tweetbot’s features and more about its price: $20. In today’s culture of low-priced apps, anything costing more than a Starbucks latte raises a eyebrows of the suddenly cash-poor masses who shelled out for expensive iPhones and Macs.

A healthy opposition to the price-whiners has risen to the task of preaching the merits of “fairly priced” software: $20 is a relatively small investment for something you use all the time, quality software takes a ton of time and effort, and unless your beloved software can sustain its creators comfortably, you’ll be disappointed when they abandon it or sell it to a multi-national corporation.

I agree with all this “fair pricing” rhetoric, but I can’t help but notice a key point missing within it: Tapbots doesn’t want to charge $20. From their announcement:

Because of Twitter’s recent enforcement of token limits, we only have a limited number of tokens available for Tweetbot for Mac … This limit and our desire to continue to support the app once we sell out is why we’ve priced Tweetbot for Mac a little higher than we’d like.

The culture of low-priced software is artificially pulling the prices of many apps downward, while in this case Twitter, with its API token-limitation policy, is artificially pulling the price upward.

Is $20 a reasonable amount to pay for Tweetbot? I think so. But if Tapbots would have preferred to charge even less, has it been fairly priced? Many folks are seizing on the coincidence of Tapbots needing to charge more as an opportunity to exalt “fair pricing,” when this was a result of coercion in two directions.

With price pulled downward by the expectation of free or ultra-cheap software, and upward by Twitter’s inconsiderate API policies, Tapbots have settled on a stasis point. It’s not as low as they wish it could be, and at the same time not as high as it’s “worth.” If Twitter’s API policies were not a factor, then staking out a bold $20 price would merit applause. But as the developers have settled on the price grudgingly, this is no victory for fair pricing. It’s an opportunity to acknowledge the discomfort of being pulled in two directions and to congratulate Tapbots on making a pragmatic choice. Well done.

Color Inside The Lines

Twitter is buzzing with rumors that Apple is on the verge of acquiring Color Labs, the company that famously raised $40 Million in venture capital before failing to produce anything that resonated with a large number of customers.

The article on The Next Web alludes to the possibility of there being some patent value in Color’s holdings. Interestingly enough, Color has apparently only recently published several patent applications related to sharing of information among “device groups.” The applications listed are all published within the past month and a half, and all feature iPhone-like art in the supporting illustrations.

I haven’t taken the time to dig through the content of these patent filings but the the fact that they are based specifically in sharing of content among iPhone-like devices, and that they were filed within the past few weeks, lends credibility to the separate speculation by The Next Web that Color’s founder Bill Nguyen has been specifically angling for an acquisition by Apple. “See these pretty iPhone patents? They could be yours!”

OpenSSL On Mac OS X

Wolf Rentzsch learned about the various gotchas of linking directly with Mac OS X’s OpenSSL security libraries, and shared his wisdom in a cheeky Apple-style technote format:

Long story short: we screwed up when we included OpenSSL (libcrypto) in OS X in the first place.

(We learned our lesson and didn’t repeat the mistake with iOS.)

Now there’s some transitionin’ to do.

Linking directly to OpenSSL on Mac OS X is a time bomb. This is probably a more pervasive bug than it would otherwise be, since Apple prescribed using OpenSSL in their Mac App Store documentation demonstrating how to analyze Mac App Store receipts. The vast majority of developers probably followed Apple’s example, and are thus using OpenSSL and linking directly to libcrypto.

Twitter’s Token Rush

One of the developer-hostile aspects to Twitter’s announcement of upcoming changes in the 1.1 release of their API, is the imposition of new “user token limits.” Developers of traditional client applications will be limited to 100K tokens, or twice the number currently issued, for apps that already have more than 100K. What’s a user token? It gives a person like you or who downloads the app the ability to actually connect to and work with your Twitter account data. No token? No service.

Suddenly the total number of users any Twitter client developer can expect to support has a hard limit. Limited resources tend to rise in value, and we’re already seeing that play out in the client market. On a recent episode of Core Intuition, we welcomed Twitterrific developer Craig Hockenberry, who spoke candidly about the changes. During the episode, he pointed out that the ad-supported, “freemium” model adopted by Iconfactory and many other developers, may not survive this transition.

Tapbots, the developers of the popular Tweetbot client, announced today that they have pulled their Tweetbot alpha release for Mac, citing the new user token limitations. While exposure to a large number of users is undoubtedly good for testing and promotional purposes, they don’t anticipate it being worth the potential cost in “lost tokens.”

Matthew Panzarino of The Next Web reported on the Tweetbot news, taking care to emphasize that because user tokens don’t expire on any regular schedule, they can be used up even by users who download a client once, connect, and never launch the app again. The total number of oustanding user tokens doesn’t go down unless users log in to Twitter and explicitly revoke access to the client application.

During our conversation on Core Intuition, I pointed out that Twitter’s new policy runs the risk of invoking Apple’s ire, as well. Apple’s App Stores for Mac and iOS are host to dozens if not hundreds of Twitter API clients, many of which meet Twitter’s criteria for “traditional clients.” When a particular app reaches its 100K token limit, what happens to the user who purchases the app from Apple’s App Store a second later? I suppose it will be up to developers to anticipate their proximity to 100K, and start winding down the operation (and their business) by removing the app from the store, etc. But if they don’t? Apple’s just sold an app that, through no fault of theirs or the developers, is useless for connecting to the service it’s meant to support.

A Token Degree Of Control

It’s bad enough that clients will have to contend with a hard limit of 100K active users per application, but what must be particularly infuriating to developers is the knowledge that some of those 100K tokens may not have been used for years, and may never be used again.

The Tapbots announcement included an overt request that users of any Twitter clients should “help 3rd party developers out” and revoke any tokens that you’re not using. This underscores the doubly subservient position developers have been put in by this move: Twitter imposes a hard limit on the number of user tokens, only end-users can free up previously used tokens, and developers, helpless to address any of this on a meaningful level, are left to suffer the worst of the consequences.

At a minimum, Twitter should support developer-driven token expiration. Google, for example, supports an API endpoint for revoking OAuth 1.0 or 2.0 tokens. This gives developers the ability to improve the user’s experience when revoking a token makes most sense: e.g. if a user has opted to “Uninstall” an application. But it also provides some discretion and flexibility for the developer to revoke in other scenarios where it makes sense. A scenario such as the one Twitter is imposing, for example.

With the ability to programmatically revoke tokens, the particulars of doing so would be up to developers. For example, if I were the developer of a 3rd party client such as Twitterrific or Tweetbot, I might arrange for the client application to communicate token usage data to a centralized server. This would theoretically give me the ability to say “expire any user tokens that haven’t been used within the past year” and rest assured that I’ve freed up a bunch of tokens without inadvertenly inconveniencing an active user.

There are security issues at play here, and the unfortunate potential to seriously inconvenience an active user if a user token is revoked prematurely. But given the hard limits being imposed by Twitter, some hard coping mechanisms are due to developers. Tokens are precious, limited resource, and neither users nor developers can take them for granted any longer.