Home

Hello, I'm Matthew Johnson: a digital product designer, iOS developer and lover of music.

Hello, I'm Matthew Johnson: a digital product designer, iOS developer and lover of music.  I also enjoy yoga, swimming, and occasionally running.  Anandabits is my professional identity.  The word ananda means bliss in many eastern languages.  I believe well designed digital products can and should produce a feeling of joyfulness in the user.  Joy creates happy users and happy users create successful businesses.


Blog

The cnet interview that was published following Apple's Mac event yesterday quotes Jony Ive as saying Apple decided against touchscreens for the Mac “many, many” years ago.  I hope this is just Jobsian rhetoric and not a sign of true stubornness.  It completely misses the big picture: In 2016 I do not want to charge, carry, and maintain two devices just because there are two important interaction models, each of which is better suited to some tasks and circumstnaces than the other.  

The situation on the patent front is becoming increasingly uncomfortable for Google, Samsung, and the Android ecosystem at large. More and more strategic Apple patents are confirmed by the patent office and the appeals court, and it appears inevitable that Android device makers pay Apple royalties and agree to "anti-cloning" provisions of the kind HTC accepted. For some time the Android camp thought that standard-essential patents were the answer, but it turns out that they are not. Patent enforcement takes time, especially in the U.S., but Apple has already made enormous headway, particularly in recent months. Let there be no doubt: Apple is on the winning track against Samsung and Google (at least in the U.S.).

 

I recently fixed a rather pernicious and pervasive crashing bug in an app I’ve been contributing to.  The bug appears to have resulted from a misunderstanding of some relatively subtle behavior in Objective-C.  This post explores the problem as well as a solution.

 

Mercury News has published a series of photos of a model of Apple’s new campus.  It looks beautiful.

 

 John Gruber has written a really good takedown of some common bear cases against Apple

Apple bear argument 1: Superior design doesn’t matter in the long run, the mobile market will be commoditized by “good enough” competitors.
Apple bear argument 2: Quality matters but iOS devices have already lost their edge, and are no longer superior to competing devices from Samsung, Google, or Amazon. iOS devices just cost more.
Apple bear argument 3: Design doesn’t matter, app developers and peripheral makers will flock to Android simply because of raw market share, even if that market share is almost entirely at the low end of the market.
Whats interesting is that arguments 1 and 3 are both refuted by the position the Mac holds in the mature PC industry.

It is a really great piece as his usually are.  I do disagree with one bit however:

Put another way, this third strain of Apple bear subscribes to the theory that iOS is the new Mac, Android is the new Windows, and Apple is about to see the 1990s all over again.
I agree with Blodget in one regard: the Mac, and its decades-long competition against Windows and the commodity PC industry, serves as a useful example. But I disagree what the Mac proves.

I do not believe the history of the PC is a very useful example to use in looking for insight into the dynamics of how the mobile market will play out.  The post “Platform Wars: Why This Time Is Different” from a couple weeks ago outlines my perspective on this in some detail.  Interestingly, Gruber does appear to agree that one of the fundamental differences between then and now:

modern computers — PCs, phones, tablets, all of them — are effectively just clients on one universal platform: the Internet. In the ’90s, as the Mac and Apple waned, *compatibility* meant connecting to Exchange servers, and reading and writing Microsoft Word, Excel, and PowerPoint files. Today, compatibility is a rarely uttered word. Twitter, Facebook, email, and at a lower level, HTTP are available to all platforms.

What I find most interesting, however, is that Gruber is able to make a compelling case that even if the PC industry is a useful example, it does not necessarily imply anything bad for Apple.

 

DRM is ineffective and bad enough on its own.  Including it as part of an "open" international standard is even worse.  Hopefully web community will push back hard on this decision.

Simon St. Laurent comments on the unanswered question Tim Berners-Lee himself has asked about the issue:

Yes. What should we ask in return? And what should we expect to get? The W3C appears to have surrendered (or given?) its imprimatur to this work without asking for, well, anything in return. “Considerations to be discussed later” is rarely a powerful diplomatic pose.

The Electronic Frontier Foundation has argued strenuously against including DRM in the standard and makes some incredibly potent points that do not appear to have been considered adequately:

In our conversations with the W3C, we argued that the W3C needed to develop a clearly defined line against the wave of DRM systems it will now be encouraged to adopt.
Many W3C participants held their nose to accept even the EME draft, which was carefully drafted to position itself as far away from the taint of DRM as was possible for a standard solely intended to be used for DRM systems.
 But the W3C has now accepted "content protection". By discarding the principle that users should be in charge of user agents, as well as the principle that all the information needed to interoperate with a standard should be open to all prospective implementers, they've opened the door for the many rightsholders who would like the same control for themselves.
The W3C is now in an unenviable position. It can either limit its "content protection" efforts to the aims of a privileged few, like Hollywood. Or it can let a thousand "content protection systems" bloom, and allow any rightsholder group to chip away at software interoperability and users' control.

 

 This looks like some very interesting technology.

 

 A video demonstrating haptic touch screen technology was published by Disney Research on YouTube.  It has been receiving quite a bit of attention this week.  

Haptic technology is something I have been interested in since Apple started filing for patents on the technology several years ago.  Earlier this year some of these patent applications have begun to be granted.  

We may not have much longer to wait to see this technology make its way into the Apple products.  There may even be an outside chance that a haptic touch screeen will be the surprise feature of the new iPad when it is announced later this month.  I hope there is.

 

Dave Rahardja posted a very insightful response to Ben Thompson’s post on obsolecence.  The essence of his insight is that tools and platforms are subject to different forces:

  • Platforms Get Obsoleted
  • Tools Get Low-End Disrupted
  • Treating platform obsolescence the same way as tool obsolescence is a mistake. Platforms are *not* susceptible to low-end disruption in the way that tools are. Platforms reach a low-end limit to pricing, because it has to maintain performance, while tools are more likely to continue its descent into commodity pricing, and finally, to becoming a mere component on a platform.

     

    TechCrunch reports on incentives ranging from featured placement in Amazon’s App Store to discounts on Amazon Web Services offered by Amazon to Android developers.

    To qualify for program benefits, developers’ apps have to render in high definition (meaning using the entire screen without distortion or pixelation on Kindle Fire), and they must be available on both Kindle Fire and the Amazon Appstore, where they’re able to run on Amazon and non-Amazon Android devices alike.
    Most importantly, the apps have to use Amazon’s APIs where relevant. That means games will have to implement the GameCircle API; those with in-app purchases need to use Amazon’s In-App Purchasing API; and those running ads will need to include the Amazon Mobile Ad SDK. And no, developers cannot pick and choose which API they’ll throw in there to meet the qualifications – it has to use the whole lot of them, depending on what makes sense given the application’s features and functions.

    In other words, Android developers who wish to receive important marketing advantages must use Amazon specific APIs for a variety of features in their apps.  This should not be surprising to anybody and is a sign of further fragmentation yet to come to the Android family of platforms.