The App.net social network, which I wrote about in “New App.net Social Network Aspires Beyond Chat and Ads” (28 August 2012), is still under development, but interest hasn’t ebbed after an initial flurry of attention. The service keeps adding features for parity with Twitter (such as the capability to “favorite” a message) and offering unique options (like posts that link to a non-App.net source, whether another social-network service or a Web page). One could argue that only a service that doesn’t care if users leave to look at something else can afford to allow off-service links.

App.net has snagged nearly 20,000 paid subscribers, including those who participated in its crowd-funded startup phase. Last week, the service dropped its price from $50 per year to $36 per year (when paid in advance) and pushed existing members’ expiration dates back several months. It also added a $5 month-by-month rate to allow people to try without the same financial commitment.

The service also announced its first approach to rewarding developers. Starting in October 2012, App.net will set aside at least $20,000 each month to disburse to software makers that have App.net programs or services in active use. Each month, members will receive a survey about the utility of each app or service they have used with the option to ignore or to move sliders to adjust how “valuable” they have been. That will be combined with usage patterns and other data. Developers opt into this program, and it doesn’t preclude software or sites charging fees or making money in other ways.

The number of increasingly mature applications that work with App.net continues to grow. Several iOS apps are now available; I’ve tried (and paid for) three of them. Notably, Tapbots released Netbot, an App.net version of its popular Tweetbot client. It offers separate $4.99 versions for the iPhone/iPod touch and iPad. One of its included tools lets you compare your App.net following list against those you follow on Twitter accounts that have been registered in iOS. I found that 15 percent of the people I
follow on Twitter also have App.net accounts — about 150 out of 1000 accounts. (Many accounts I follow are RSS-like, notifications, or other infrequently updated auto-bots.)

Netbot allows cross-posting to Twitter using iOS’s built-in functionality. Twitter doesn’t (yet) prevent such cross-posting, although its API wouldn’t allow Tweetbot to access Twitter messages and then post to App.net via Netbot or another method. I’m not going to cross-post; I’m trying to keep the two services separate as I watch App.net develop.

When I started reading James Stewart’s New York Times “Common Sense” column titled “Apple’s Maps and Jobs’s Shadow,” I thought in the first two paragraphs that he had captured the nuance of Apple in transition from Steve Jobs to Tim Cook, and correctly offered the context of its last 12 months of financial success and the challenges ahead that the firm faces. Then I hit the third paragraph and it all goes downhill from there.

Stewart confuses the Maps app, a software application, with the mapping data that underlies it and the algorithms for driving directions that Apple put in place. He apparently doesn’t fully understand that competitive mapping and navigation programs have been available since 2009. He also wedges in a years-old decision on electronic book pricing that Jobs was instrumental in putting into place, and makes that something for which Cook bears responsibility — or doesn’t bear responsibility. It’s not clear. (After its original appearance, Stewart’s article was updated in several places, only one of which is noted in a correction that’s appended. The updates make many arguments even muddier, and I’ve attempted to note
them.)

To start with, Stewart writes, “Apple hasn’t fully explained its decision to replace Google’s maps with its proprietary mapping application…” Apple has always written the Maps app, from its first appearance, and Google provided the data. Apple changed its data and directions provider from Google to its own set of licensed sources, which includes firms like TomTom and Waze according to information in the app itself. He also seems to be saying that the replacement happened in the iPhone 5, not other iPhone models that can run iOS 6, although owners of earlier models may opt to stay put in iOS 5 and continue to use the older Maps app with Google data (for now). [Update: Stewart’s article was later changed to eliminate “its
proprietary mapping application” and to add a reference to iOS 6.]

He continues, “Apple’s use of its own mapping technology in the iPhone appears to be a textbook case of what’s known as a tying arrangement, sometimes referred to as ‘bundling,’” and goes on to make the case that buying an iPhone 5 requires the use of the Maps app. If that were the case, it would have been a problem from the first day the iPhone were offered, when it didn’t allow any third-party apps at all. Buying a new iPhone 4 or 4S today would also include iOS 6 and the new Maps app, although those models could theoretically be downgraded to iOS 5. [Updates: The article was later modified to remove the specificity of the iPhone 5. A reader informs us in the comments that downgrading an iPhone 4 or 4S is nearly
impossible.]

Stewart tries to tie this to the battle between Microsoft and Netscape (and other firms) from the late 1990s into the 2000s. Microsoft bundled its own Web browser “to the exclusion of Netscape,” he writes, but that statement and those that follow miss many nuanced points that counter his analogy from that many-year legal and public-relations fight.

First, Internet Explorer was designed to be integral to Windows (and became more so over time), and it used proprietary technologies like ActiveX that made it impossible for a third-party Web browser to provide the same experience. While the Maps app can’t be deleted from iOS, and is integrated with Siri and works from the lock screen, those aren’t giant advantages over other available apps.

Second, it was alleged that Microsoft modified Windows to make it harder for third parties to write Web browsers that could work as well as Internet Explorer, and denied technical resources and support to boot. Since the release of third-party developer tools for iOS, that hasn’t been the case for Apple. In general, Apple has worked with each release to give developers more access to previously Apple-only features, such as adding limited background tasks. (True, some apps have privileged positions in iOS, and Apple has at times rejected competitive apps from the App Store.)

Third, Stewart claims that the situation was resolved in a way that “Microsoft eventually agreed that Windows users could designate their own Web browsers,” which is completely incorrect. Solely in Europe, Microsoft had to provide a kind of “ballot” that allowed users to pick among many browsers to use. It was never forced to unbundle in the United States nor most of the world. [Update: The article was revised to remove this whole reference for the reason I cite, and a new specious argument was put in its place.]

What happened, in fact, is that third-party Web browsers improved to a point at which they competed on performance and quality, especially for rendering sites that were designed to conform with Web standards. Along the way, Microsoft did an enormous about-face, and has spent years bragging about (and proving) how standards-compliant Internet Explorer’s releases have become with each new version.

Since the introduction of third-party apps to iOS, Apple has never to my knowledge restricted the distribution of mapping software. There are a few dozen programs available, many from major standalone GPS makers, some free, some for a fee. The MapQuest app, from a division of AOL that competes with Google Maps, has been in the App Store for years, and is both free and a delight to use. I’ve reviewed over 15 of these navigation apps over the last three years, and several are better than both the current Maps and Google’s mapping program in the Android operating system. (Google also supports alternative maps apps in Android.)

Stewart points out that Maps has its problems, which it does. He wonders if Jobs would have apologized as quickly and profusely as Cook did for the quality of data behind the Maps app (not the app itself, which is lovely and works quite well). He apparently forgets Jobs’s behavior around MobileMe, as even veteran tech reporters have done, in which Jobs apologized in public and via email to users who emailed him, fired the head of the division, and took months to get everything back in order.

Stewart says of Jobs, “He was famously resistant to the idea [of apologizing] after complaints about the iPhone 4’s antenna.” That was a more complex situation. Jobs clearly felt that a marginal situation was blown up beyond all proportion, especially since most cell phones had similar problems, often documented in their manuals. While Jobs never said “sorry,” the company redesigned the antenna as early as the Verizon model of iPhone 4, gave away free bumpers and cases for a few months, and sold many millions of that model. The problem went away because it simply wasn’t a consistent problem for the vast majority of users, who would otherwise have returned the phone or avoided it because of word of mouth.

At this juncture in the column Stewart confuses who wrote the Maps app before the iPhone 5 release, is unaware that it is available to all iOS 6 users, and seemingly doesn’t incorporate the fact that other mapping apps have long been available. He notes that worldwide, iOS has a minority share of the smartphone market, and then finally points out that Cook suggested users try “alternatives,” without also mentioning that these are free and paid map programs that work just as well or better in iOS than the built-in offering. That was true before iOS 6, too.

Stewart next throws in the red herring of the iBookstore and pricing arrangements, quoting from Walter Isaacson’s biography of Steve Jobs. But isn’t this an article about Tim Cook’s problems in guiding Apple forward after the masterful hand of Jobs? Regardless, Stewart also disregards the opinions of those that oppose the Department of Justice’s lawsuits and settlements against publishers, which includes booksellers. The opponents believe it will establish Amazon as the monopoly player in the ebook market, presumably setting up a new antitrust situation that the DOJ would later have to address.

An expert that Stewart quotes says, “Historically, Apple hasn’t been very sensitive to antitrust issues.” Historically, Apple hasn’t been confronted with monopoly situations, so it’s hard to know what these issues might be.

Stewart closes by praising Tim Cook for his Maps apology (but didn’t he critique that as anti-Jobs earlier?), and suggests the antitrust suit should be settled quickly. He veers again — is he using Maps data for writing? — and appears to demonstrate his ignorance of the ecosystem once more, suggesting Cook should make “Google’s and other map applications readily available to iPhone users” as a break from the past, when that’s the current state of the market (Google reportedly isn’t yet developing its own Maps app for iOS), and Apple has been highlighting alternatives in the App Store since Cook’s letter appeared.

This muddle of a column comes from a normally sober and sensible financial reporter whose work I admire. Conflating the Maps app and its data along with a lack of knowledge (or, say, even asking the New York Times’s technology reporters) of the history of competing apps and the current availability of the same spreads misinformation. There’s plenty to critique about Apple’s premature release of the Maps app. This column has nothing worthwhile to contribute.

You could be forgiven for feeling a little confused if you’ve been trying to keep up lately with the various regulations and requirements surrounding electronic devices on airplanes, something I try to do even though I spend more time teaching physics than flying these days.

For a number of years, the rule has been quite simple: no personal electronic devices may be used below 10,000 feet, the altitude at which the captain will, typically, turn off the “fasten seat belts” warning, and, generally, a point in the flight by which the aircraft has left the busy airspace around a major airport.

But recent news from American Airlines would appear to undermine this regulation. Last month, American announced that paper flight manuals and navigation charts were to be phased out on their Boeing 777 flights, with iPads taking their place. In late 2011, American’s pilots began using iPads as electronic flight bags during some phases of flight; this new development sees iPads being used in the cockpit during the entire flight, from pushback to parking.

However, American Airlines passengers must still turn their electronic devices off before takeoff and leave them off until 10,000 feet; the requirement remains for passengers to power down all electronic devices — cellphones and laptops, Kindles and iPods, even the very iPads that the captains of American Airlines’ triple-sevens are using while they are telling their passengers not to use theirs — during departure or arrival.

So why does the U.S. Federal Aviation Administration (FAA) continue to apply this rule? If, as American Airlines has demonstrated, iPads in the cockpit — inches away from the very avionics they could theoretically interfere with, if they were in the hands of passengers — represent no hazard to flight safety, why, then, can they not be used in the cabin? The answer simply seems to be that the FAA’s regulations regarding personal electronics are a holdover from the Dark Ages of Tech — Part 91 of the Federal Aviation Regulations (FARs) bans all personal
electronics, with a handful of specific exceptions: portable voice recorders, hearing aids, heart pacemakers (jolly decent of them there) and electric shavers. An eclectic list, to be sure, but one that’s entirely antiquated (portable voice recorders? really?) and long overdue for an overhaul. And, once the overhaul is complete, given that the rest of the world tends to follow the FAA’s lead in this area, perhaps the de facto international standards will also relax.

The FARs do allow the operator of a flight — in the case of commercial flight, the airline — to allow the use of any devices they have determined to be safe, but the FAA has issued guidelines that ban electronics under 10,000 feet. And so the FAA’s request for comments on the matter, issued on 28 August 2012, is long overdue.

Clearly these regulations are in need of review. Modern portable electronics are designed to conform to U.S. Federal Communications Commission (FCC) rules on electromagnetic emissions, and should be able to handle interference from other nearby devices — if my iPhone can handle some stray radio waves, then surely a hundred-million-dollar Boeing jet should be equal to the challenge.

The U.S. Transportation Security Administration (TSA) clearly does not regard portable electronics as a significant threat to flight safety. Even though passengers in U.S. airspace are prohibited from carrying more than a thimbleful of liquid through airport security gates, portable electronic devices — which, the FAA fears, could send a plane plummeting from the skies just because a passenger has started playing Angry Birds — are waved through. If these devices actually represented a safety hazard, would we be allowed to carry them on board?

Similarly, ask yourself this — if your iPhone really had the potential to down your plane, would your flight attendant be happy simply to ask you to turn it off, and then trust that you have complied? In reality, many passengers don’t — a simple search on YouTube for takeoff and landing videos such as this arrival into Auckland suggests that plenty of aircraft are landed on a daily basis with all manner of electronic devices running in the back.

We travelers assume that there is no evidence to suggest that portable electronic devices actually can cause accidents. If there were, then we would be prohibited from using our electronics at any phase of the flight, not merely during takeoff and landing. The FAA’s own fact sheet on the matter suggests that I have to turn my iPad off to avoid distracting the flight crew because they will be concentrating especially hard:

“At a lower altitude, any potential interference could be more of a safety hazard as the cockpit crew focuses on critical arrival and departure duties.”

The same fact sheet also points out that the FCC bans use of 800 MHz cellphones because of potential interference with ground facilities — not confirmed interference, and not with inflight electronics. But most modern electronic devices have some form of “flight mode” or, in the case of the iPhone, “airplane mode,” that disables all wireless transmissions while allowing use of all other functions.

Again, we should remember that this rule is, clearly, being flouted on a daily basis to no ill effect. The argument goes that a cellphone several miles up has direct line-of-sight access to a large number of cellphone towers, many more than it can directly communicate with while on the ground, and it can thus confuse the cell networks. By this logic, we should also, presumably, ban the use of cellphones in tall buildings, atop hills, or anywhere else where such a situation might occur. But we don’t, for the same reason that the in-flight rule is so weakly enforced — clearly there is little actual impact, and no evidence of a safety-of-flight hazard. Besides, if this were an issue, wouldn’t the FAA point the finger at the cell
carriers, rather than claim it’s a safety issue?

It’s also worth bearing in mind that the requirement that iPods and iPhones and the like are turned off until 10,000 feet has an interesting unintended consequence. When a plane passes this altitude, as many as a few hundred devices could all be turned on at the same time — hundreds of devices being powered up simultaneously will, presumably, result in a major surge of electromagnetic radiation, but electromagnetic interference has yet to be implicated in a single crash. Indeed, the FAA itself has, albeit grudgingly, admitted that there is no evidence to suggest that inflight electronics have been responsible for accidents: the New York Times quotes an FAA spokesman as saying “There have never been any reported accidents from these kinds of devices on planes.”

So maybe the issue is not specifically electronic, but more broadly mechanical. When the “fasten seat belts” sign goes on during heavy turbulence, an iPad could, in theory, be thrown from a passenger’s hand and become a lethal projectile. The laws of physics don’t entirely agree with this argument, though — the kind of turbulence that is invoked in discussions such as this tends to be vertical, rather than horizontal, rendering iPads rather harmless. And if we’re banning electronic devices on this basis, what about other heavy objects, such as books? I have little doubt that the banning of books on flights would lead to major passenger resentment — there would be riots in the aisles. And again, it’s not like the FAA
states this as a problem — the claim is always that the regulations exist to prevent electronic interference with avionics.

When I talked about this on Radio New Zealand’s Nine To Noon program in December 2011, the topic generated more email from listeners than any other subject I have discussed on the show, with many comments coming from pilots who are concerned that, if there is currently a ban and there are no crashes, then best to leave well enough alone. But, speaking as a commercial pilot and a physics teacher, as well as an avid user of innumerable electronic devices over the years, I am strongly of the opinion that this is a rule that has outlived its usefulness (if it ever had any). I’m hopeful that the FAA’s invitation of input from the public will result in a modernisation of rules that are so out-of-date that they suggest that “portable voice recorders” are cutting-edge technology.

[Steve McCabe is a British-born Mac consultant, tech writer, and teacher who now, for reasons that have but the most tangential connection to technology, lives in New Zealand. He writes about his adventures in New Zealand and blogs about tech. Steve’s first novel, “Crash Landing,” based loosely on his experiences learning to fly — when he’s not teaching or computing, Steve is also a multi-engine instrument-rated commercial pilot — is now available in paperback.]

If you’ve been vacationing on the far side of the moon, you may be unaware that Apple released a mess of hardware and software two weeks ago, including iOS 6. If you’re back on Earth and you haven’t installed iOS 6 by now, you’ve doubtless noticed your iOS device (assuming that it’s of fairly recent vintage) trying to gain your attention by badging various icons and generally nagging you to upgrade your system software. At the same time, numerous apps have already been revised for compatibility with iOS 6, and this process can be expected to continue for a while. The excitement is palpable.

For me, though, the exciting part of a new iOS release isn’t the visible system-level changes and built-in apps. iPad finally gets a clock? It’s about time. (Ha ha.) Customizable photo streams? Whatever. Facebook integration? Gag me with a spoon. Siri can launch apps? Should have done this all along. And if Apple feels like jumping the shark by throwing the Google Mobile Maps service out the window in favor of its own maps, that’s fine.

To me, the fun of iOS is programming it. iOS is a wonderful platform to program; that’s why I wrote a book about it (“Programming iOS 5”). What interests me about a new iOS release is what it lets developers do. And you should care about this too, because what developers can do affects what they’ll build into apps when writing or rewriting them to adopt iOS 6 features. And that, in turn, affects what you will see and what you’ll be able to do.

Almost a year ago (see “How iOS 5 Will Affect Developers — and You,” 17 October 2011), I described certain aspects of the then newly released iOS 5 from a developer’s point of view, and made some predictions (which turned out to be extraordinarily accurate and prescient) about how these would affect what users would see on the screens of their iOS devices. This article attempts to do the same for iOS 6. As in my earlier article, I stress that there’s nothing here you couldn’t deduce for yourself; my sources are mostly Apple’s own release notes.

Pay No Attention to That Man Behind the Curtain — Some of the most far-reaching changes are those that occur far upstream from end users, in the realm of the tools developers use.

For instance, Objective-C, the native programming language of iOS’s Cocoa touch world, has gained a few elegant shortcuts. None of these are earth-shattering — certainly nothing as fundamentally revolutionary as Automatic Reference Counting, on which I reported in my earlier article — and none of them will mean anything to you if you’re not an Objective-C programmer, so I’ll spare you the technical details of such things as autosynthesis. But trust me when I say that these changes, while small, are part of an Apple agenda of rationalizing Objective-C (to the extent that it can be rationalized, given the age and complexity of its underpinnings), and will mean a lot to developers, in this simple sense: they won’t have
to write as much code, so they’ll be able to put more time and effort into what matters to end-users, namely the actual functionality of the app.

Xcode, the milieu in which iOS programmers work, has evolved to version 4.5, and again this will generally mean less work for developers to achieve goals they were previously accomplishing in a more frustrating, time-consuming way, even though you won’t know that’s happening. Take, for example, storyboards, introduced in Xcode 4.2 as a way of letting developers describe graphically the relationship and transitions between the “scenes” of an app (where a “scene” means, roughly, the interface that currently occupies the screen as a whole). It sounds convenient, but in fact storyboards were originally implemented in a half-baked way. In my book about
programming iOS 5, for example, I pointed out that to use a storyboard to design a simple animation-free “modal view” transition was much more work than doing the same thing without the storyboard, because the storyboard interface provided no way to specify “no animation”, and no way to get back from the modal view to the view that triggered the animation. In Xcode 4.5, that and other storyboard limitations are removed, making storyboards more inviting to work with.

Another interface design feature of Xcode 4.5 and iOS 6 is the introduction of “constraints”, a new way of describing how interface elements should automatically move and resize themselves when the surrounding interface changes its size. Interface rearrangement has always been a challenge for iOS developers, as the interface must reconfigure itself any time the user rotates the device and the interface rotates to compensate. The early API for describing automatic interface rearrangement worked well for simple interfaces, but complex layout rearrangements among multiple interface elements had to be coded by hand, or (more probably) avoided entirely by keeping the interface fairly simple.

Constraints were already available to desktop developers starting with Mac OS X 10.7 Lion, and you may already have seen their effects without realizing it. For example, look at how, in 10.7 Lion and 10.8 Mountain Lion, in Apple Mail, when you make the mailbox list on the left wider or narrower, the Delete button in the toolbar slides along to match. Before constraints, such an effect was virtually impossible; the layout of a toolbar was a separate world from that of the main window interface, and followed its own rules. With constraints, that behavior requires effectively no code at all; it can be designed directly in Xcode. Now that iOS 6 implements constraints, iPhone and iPad users may expect to see some similar increase in the
sophistication of interface layout.

All the Lonely Frameworks, Where Do They All Belong? — iOS 6 has piled on some additions and changes to various specialized frameworks, and developers of certain kinds of app will want to take advantage of them.

The new maps architecture allows apps to interact more easily with the Maps app: instead of displaying its own map, an app can tell the Maps app to display a point of interest. Moreover, there’s a new API for letting apps provide turn-by-turn directions, and such an app can share its knowledge with other apps, such as the Maps app, so that they can display those directions as well.

The new Passbook app (see “Passbook’s Best Is (Probably) Yet to Come,” 20 September 2012) functions as a library for passes (a pass, in general, is any sort of redeemable ticket or token). Vendors can provide passes through email or the browser; apps can also communicate with Passbook to create, delete, and manage passes. The Twitter framework of iOS 5, allowing any app to offer the opportunity to send a tweet, has been expanded to include Facebook and Weibo. Apps can now communicate with the Reminders app. You can expect to see apps taking advantage of these expanded powers, along with improvements in the Game Center and in-app purchase delivery.

You’ll also notice that your iOS device running iOS 6 evinces a new wariness about letting apps access your various libraries of information. I have always found it sadly ironic that in the supposedly “sandboxed” world of iOS, an app must obtain the user’s explicit permission in order to display an image from the Photos library — on the dubious grounds that such an image might contain GPS coordinates, and GPS coordinates constitute oh-so-sacred location data — while any app, without the user’s knowledge, is perfectly free to manipulate your Contacts library however it likes, including relaying all the email addresses to a server in the Ukraine, changing all the phone numbers to ring up a pizza delivery service, or just
wantonly deleting all the data. In iOS 6, the user is notified the first time an app tries to access a library, and is free to grant or deny such access, just as with Location Services.

A Box of Toys — This is the stuff that makes me feel like a greedy, selfish kid ripping the wrapping off presents: the shiny new changes in the toolbox, the repertoire of interface widgets that Apple gives its developers to play with. What did you bring me this year, Apple???

The major new widget that will have the biggest impact on app interfaces is the collection view. A collection view is like a table view on steroids. A table view is the scrolling column of cells commonly seen in any master–detail app where a list must be displayed; Settings, Mail, and Music are familiar examples. A collection view breaks the bonds of the single vertically scrolling column, so you can expect, in short order, to see horizontally scrollable rows of data, multicolumn tables, and grids of information.

Such things were not impossible in the past, but they could be quite tricky for programmers to construct, especially if you had many rows or columns of information to display. You can’t simply form the whole grid display in advance to make a vast user-scrollable view; that would cause the device to run out of memory, and your app would be summarily killed. Instead, you have to work one screenful at time, loading the data and forming its visual representation as needed — that is, as the user is about to scroll that representation onto the screen — and freeing up memory when the user can no longer see a representation.

A table view does this dynamic memory management automatically for the programmer, which is why a table can be very long; but it’s limited to a single vertically scrolling column. Programmers who wanted a horizontally scrolling table, or a scrolling grid, as in the Photos app, could perhaps create it as a one-off with some serious effort and ingenuity; but it wasn’t easy, and such interfaces are not common, especially when the data is of any size, and are sometimes rather sluggish. The collection view generalizes the entire notion and makes it easy, and implements it efficiently.

Moreover, the collection view generalizes the notion of layout. Thus the lines of represented data don’t have to be regular; they don’t even have to be straight lines! Apple’s WWDC 2012 videos demonstrate a collection view being used to implement Cover Flow View, as seen in Mac OS X’s Finder or iTunes, where items appear to twist and change size as they scroll across the screen; the videos even show a collection view displaying photos in a circle. So you can expect the collection view to form the basis of some very interesting interface in iOS 6 apps.

Most of the other widget changes in iOS 6 rationalize and tighten up what iOS was already doing; they fall less into the category of “new” and more into the category of “totally obvious and why didn’t you do this long ago?” For example, iOS knows how to draw text in multiple styles, as Mail and iBooks prove, but developers couldn’t use such text in the labels, button titles, and editable text fields that permeate the interface; now they can. More drawing effects available on the desktop are now possible in iOS; for example, we can now easily invert an image’s colors, make interesting tiling patterns, and perform new image transitions. Page view controllers now allow pages simply to slide, without the telltale “page
turn” animation. The march of color and customizability begun in iOS 5 (and noted in my earlier article) now encompasses additional basic widgets; watch for switches that say something other than “ON” and “OFF” (at long last!), along with wild-looking steppers and more.

Many other changes will have no obvious visible manifestation, but will mean a lot to developers. For example, Apple has changed how developers signify whether a certain view rotates to compensate when the user rotates the device; you were probably unaware that the old architecture for doing this was challenging and inflexible, but developers weren’t, and will rejoice. Similarly, table views now let the developer control easily whether the user can tap to highlight a cell, and section headers and footers are more efficiently managed. Still deeper under the hood, iOS now acquires from OS X some cool collection classes, such as NSMapTable, that only a programmer could love — and does.

Evolutionary Magic — It’s easy for end users of an iOS device to let the magic of the interface lull them into a sense of acceptance and entitlement: it just works, and most users don’t care how. When I look at an iOS app’s interface and behavior, however, my first impulse is always to try to guess how the app works under the hood and how it accomplishes its magic. Knowing more about how iOS works from the developer point of view makes the magic more impressive, not less.

The iOS SDK — the developer toolbox for programming apps — was revolutionary when it first appeared (as the iPhone SDK), an ingenious rethinking of Mac OS X’s Cocoa aimed at a device with a small screen, a slow processor, limited memory, and only the user’s fingers to tell it what to do. Since then, the changes have been mostly evolutionary. iOS has grown, to be sure — there’s a reason why the second edition of my book is 200 pages longer than the first edition — but mostly it has become cleaner, clearer, more flexible, and more sensibly architected on every release. Linguistic features like blocks and ARC have made Objective-C more elegant and less tedious. Interface widget management tools such as custom view controller
containment and view appearance proxies have provided clean, reliable, efficient ways to obtain effects that visionary programmers and designers previously had to accomplish with fragile hacks.

iOS 6 is no exception. It has grown from iOS 5 like a tree: it’s taller and has a few more branches, but what’s really important is that its roots are deeper and more solid. Many sentences in my book where I complain of a missing feature, an inconsistency, a hole in Apple’s logical thinking, can now be deleted. What’s new in iOS 6? It makes developers happier. And in the long run, as their apps come down the pipeline, that’s going to make you happier.

Things 2.1 — Cultured Code has released Things 2.1, an update to its task management app with improved integration for OS X reminders, providing more control over which types of reminders are displayed. The maintenance release also fixes an issue where interacting with an item in the Daily Review list could cause keyboard shortcuts to stop working, resolves a problem where dragging a Today item assigned to a project to the top of the Today list would remove the project association, includes items from repeating projects in search results, and returns links to Entourage 2008 email messages to displaying the email subject (as
previously handled in Things 1.5 for the Mac). ($49.99 new from Cultured Code and the Mac App Store, free update, 17.2 MB, release notes)

Read/post comments about Things 2.1.

Sandvox 2.6.7 — Karelia has released Sandvox 2.6.7, a maintenance release that squashes a number of bugs in the Web publishing tool. Highlights include a fix for a crash that was occurring during publishing, resolution to several issues with link handling, a correction for a problem where files would be repeatedly re-uploaded for some host configurations, and a fix for an issue where typing would slow down over time. Additionally, the release now enables you to place multiple Twitter objects on a page. ($79.99 new from Karelia or the Mac App Store, free
update, 29.6 MB, release notes)

Read/post comments about Sandvox 2.6.7.

Hazel 3.0.13 — Noodlesoft has updated its Hazel file cleanup utility to version 3.0.13, which adds “IgnoreGrowl” as a hidden default that can be entered at the command line to shift notifications to Notification Center. The release also resolves a problem with custom tokens getting renamed over and over after dragging one within the same pattern, ensures that the “Run rules on folder contents” command crosses over into attached disks, and fixes a crash when using the “other” attribute in the Sort into Subfolder pattern. ($25 new, free update, 6.2 MB, release notes)

Read/post comments about Hazel 3.0.13.

Airfoil 4.7.4 — Rogue Amoeba has released Airfoil 4.7.4, which now provides support for Airfoil Speakers for Android (which was recently released as a public beta). The network audio streaming app also improves support for audio sent from an Apple TV (running iOS 5.1 or later) to Airfoil Speakers and fixes a crash that occurred when selecting “Show Airfoil Only in the Menu Bar” in Preferences. ($25 new with a 15-percent discount for TidBITS members, free update,
9.1 MB, release notes)

Read/post comments about Airfoil 4.7.4.

Adobe Lightroom 4.2 — Adobe has released Lightroom 4.2 with a number of fixes applied to the professional photo cataloging and editing application. The update includes a fix for stacked photos that were hidden in both the Grid view and Filmstrip, resolves a problem with publishing videos to Facebook, ensures that Lightroom photo can be edited as JPEGs in Photoshop Elements, and fixes an issue with carriage returns in either the Title or Caption field that invalidated a Flickr upload. The release also adds support for 22 new cameras (though offering just preliminary support for the Nikon D600) and 43 new
lenses. ($149 new, free update, 407 MB, release notes)

Read/post comments about Adobe Lightroom 4.2.

OS X Mountain Lion 10.8.2 Supplemental Update — Apple has released OS X Mountain Lion 10.8.2 Supplemental Update, a small update that addresses a few specific issues that weren’t large enough in scope to require a new version number. In particular, it fixes a problem that caused certain Japanese characters to appear incorrectly in Mail, fixes a crash with DVD Player, enables access to secure Web sites in Safari when parental controls are enabled, and fixes an issue that could prevent systems with more than 64 GB of RAM from starting up. (Free, 26.65 MB, available through the Mac App Store or direct download)

Read/post comments about OS X Mountain Lion 10.8.2 Supplemental Update.

Mac OS X Lion 10.7.5 Supplemental Update — Apple has released Mac OS X Lion 10.7.5 Supplemental Update, an addition to the recently released Mac OS X 10.7.5 Lion that’s tiny enough not to merit its own version number. The update resolves only two issues: one that could cause Time Machine backups to take a long time to complete and another that prevented certain applications with a signed Developer ID from launching. If you hadn’t previously installed 10.7.5, you won’t need to worry about this supplemental update — the latest build of Lion 10.7.5 (11G63) includes these
two fixes. (Free, 2 MB)

Read/post comments about Mac OS X Lion 10.7.5 Supplemental Update.

iPhoto 9.4.1 — Apple has released iPhoto 9.4.1 to improve synchronization of photos with iOS devices via iTunes and fix a problem with downloading and viewing photos synced from Facebook albums. The update also fixes two specific crashes: one when using the Export command and another when upgrading multiple books, cards, and calendars. Note that iPhoto 9.4.1 now requires OS X Mountain Lion 10.8.2 or Lion 10.7.5. ($14.99 new from the Mac App Store, free update through Software Update or the Mac App Store, 757.62 MB direct download via Apple’s support
page)

Read/post comments about iPhoto 9.4.1.