IBM, the button-down revolutionary

Lest we take them for granted...

replacing the iTunes app with a web app

9to5mac reports rumors that Apple plans to replace the iTunes app with a Safari-only web app.

Before commenting on how credible this might be, let me suggest a little experiment. Fire up iTunes and point it to the iPhone/iPod/iPad app store, also fire up the Mac app store application, then do a few parallel searches for apps that exist on both platforms. Note how the performance of the iTunes app compares with that of the Mac app store application.

Apple has been building out a web version of iTunes for some time. Take the Twitter app, for instance. If you search for Twitter, in the iOS app store using the iTunes app, and click on the bird, nothing will happen because you're already there, but if you right-click (control-click) on the bird and choose copy link, then paste that link into Safari and activate it, instead of being taken back to the iTunes app you're instead taken to a look-alike web page.

Given that Apple has a contractual obligation to constrain the installation of non-free apps to devices owned by people who've paid for those apps, it makes sense that they would limit access to a web version of the iTunes store to Safari, which they can control, possibly using a plug-in for this purpose. They might also use Safari only to conduct transactions with the store and use a separate program to manage the configuration of various devices.

Whatever the details, there's probably some truth to this rumor.

what I'm talking about

After years of anticipation, here it is, the brush you can use to paint on a screen!

Now, imagine using one of these on a screen that has touch sensitivity in each and every pixel, instead of the currently lower-resolution grid!

iRobot's AVA uses iPad for controller and telepresence interface

If you can program an iPad (or Android tablet) you can program iRobot's AVA.

Engadget originally characterized AVA as a telepresence machine, using an iPad sitting on a mount that incorporates a camera as the interface, but the AVA will be a general purpose platform complete with SDK, which, for the iPad, will be compatible with Xcode and the iOS SDK.

Great move, iRobot!

if you've already paid for Pixelmator, buy it again now!

If you have Pixelmator 1.6.3 installed on your Mac, don't be fooled if running "Check Now" in Preferences => Updates tells you that you are running the latest version. 1.6.4 is waiting for you on the Mac App Store!

What? Pay for it again? Well, as an email sent to licensed users says "You can download Pixelmator on the Mac App Store for just $29, for a limited time. By transitioning to the Mac App Store, you will get the totally awesome Pixelmator 2.0 (and, of course, still lots of 1.X updates) for free once it is out in the Mac App Store later this year."

So think of it as a prepaid upgrade. True, those who hadn't yet paid for the program will get the same deal, but at least they'll be joining you in helping to underwrite one of the finer pieces of software in existence.

If you wait, the price will go up, so act now.

24 hours and a million downloads later

One of the most interesting aspects of the Mac App Store is how smoothly the application used to access it works. My guess is that it's based on WebKit and that the store itself uses SproutCore or something like it. In any event, it's a considerably more pleasant experience than using the iTunes app to access the iOS app store.

Should help sales!

what I'm talking about

In a previous post I discussed the possibility of using an iPad as a Mac peripheral, and stated that I believed there were already iPad apps which made this possible, speculating that they probably paired with specific Mac apps.

Now, Macworld has found one that augments the Mac's Finder. Remote Conductor comes in two parts, the iPad app and a free Mac server application with which the iPad app cooperates, communicating via wifi. With this setup established, Remote Conductor offers three modes, one which turns the iPad into a large, multitouch trackpad, another which turns it into something resembling a grid display of your Applications folder from the Dock, and the third allows you to navigate through open windows by application (scrolling left/right) and by open windows belonging to an application (scrolling up/down).

I didn't see a price listed anywhere on the company's website, but a quick trip to the App Store shows that it sells for $9.99, which is a little steep, unless you'll be using it a lot, which, if it works as advertised, I'm sure many will. (Oh, and they're working on a Windows version of the server software.)

Very interesting, but not quite what I was talking about. What I'd really like to see would be a more general iPad app (or mode) that works with either a server or, preferably, with any app that includes and makes use of a framework for remotely controlling the iPad's display and directing input received from it. This is the easier option from a developer's standpoint, since making use of a separate server program would involve making use of services it presented by sending script-level messages to it, much as Automator does, something fewer developers know how to do.

Even better would be to do both. Since at least a minimal server process would be necessary, it might as well be owned by the operating system, and present applications with a choice of either passing low level data, generated by and targeted to code compiled using a framework designed for this purpose, or else interacting with the iPad via scripting. Those scripting hooks could actually be included in Automator, making them accessible to a much larger audience.

For security reasons, the part of this combo running on the iPad should be sandboxed at least to the same extent as other iPad apps, so that it had no more access than they do to data stored on the iPad. Because Mac apps aren't necessarily subjected to review, it might be better if it were even more isolated, as a service provided by iOS running in a special, locked-down mode. It could be enabled via a second button, like the one on the lock screen that puts the iPad into slideshow mode, and interrupted at any time by pressing the Home button (or as determined in Settings).

However the implementation were to be handled, the end result should be to make it possible for a Mac app to run part of itself on an iPad, taking advantage of not only the iPad's touchscreen but also the lion's share of its cpu/gpu time and RAM, as as much nonvolatile memory as any app is allowed, with Mac UI elements compiled using AppKit and iPad UI elements compiled using UIKit.

Unless and until Apple decides to make such a framework (and/or script server) available, it's still possible, right now, to create iOS apps which communicate and cooperate with Mac (Windows, etc.) applications, providing those applications with what amounts to a smart touchscreen peripheral.

If you're having trouble imagining how this might be useful, imagine an emergency call center with a highly integrated computing environment, with operators sitting at workstations and the shift supervisor walking around behind them carrying an iPad that's displaying an overview of all the traffic passing through the call center, with additional information (the history of calls from a particular number) just a quick tap away.

here comes the Mac App Store

Opening January 6th.

I might have added "finally" or "at long last" to the title.

Sure, it's an idea that would have been very difficult to implement well just a few short years ago, before the iOS app store illuminated the territory, and in that sense its arrival is timely, but it fills a niche which has lain empty, potential yet gnawingly empty, at least since the ascendancy of the Internet. (There have been attempts to create a common marketplace for Mac apps, but all have fallen far short of what only Apple was ever in a position to do right, by integrating it into the system software.)

For the independent software developer, it's a godsend! Suddenly they'll have the means to make their wares widely available with little effort beyond that involved in crafting them well in the first place, and with little friction to prevent customers from making the decision to buy.

For users it's an answer to prayer! As the vendors of the third-party programs they use move (or expand) their distribution into the Mac App Store, users will gain a one-stop shop for updates. They'll also gain a simple, trustworthy process for buying new apps, and no more need to assume whatever risk there might be in using PayPal or other, similar services, and Apple's review process will help protect them from malware and poorly written programs.

Most likely, the stated price of apps (not what you can get in bargain basement combo deals) will come down on average, and, between the convenience and safety of the store itself and the better prices, the market will respond with an abrupt increase in sales volume. With a larger market, more effort will be devoted to developing Mac apps, and those apps will, for the most part, be gathered together in one place where the customer can browse through them looking for a best fit for their circumstances. Everbody wins!

What a heartening development!

Apple in 2011 and beyond

Jonny Evans, writing in his Computerworld blog, has already issued his speculations for what might be forthcoming from Apple during 2011. I won't be going through that list, just pointing you to it.

The way I see it, there's several major trends to be tracked in news from Apple: the development of iOS, Mac OS X, and the cross-fertilization between them; the parallel development of iDevice and Mac hardware; the movement towards cloud computing; and any indication that Apple is transitioning towards increased self-reliance with regard to essential components. There's also the collection of secondary devices and peripherals, which may take on greater importance in the future as it becomes possible to shoehorn a complete system into smaller and smaller boxes.

Of these, I only intend to address Apple's movement towards self-reliance in essential components, branching out some from that starting point.

First, I don't mean to suggest that Apple is about to build or acquire an IC foundry, except perhaps a small-scale one sufficient to allow them to keep their IC designs in-house until ready for mass production. As the scale of circuit features has diminished, the cost of the equipment needed to fabricate chips has gone through the roof, and only very large scale operations are economically viable. This means a handful of foundry operators selling production line time, and that situation isn't likely to change soon. If Apple were to build or acquire a foundry, they would have to farm out production time when their own needs were slack, and buy additional production time from others when demand for their products grew faster than expected, meaning that it would be at best a marginal advantage and probably not enough of an advantage to justify the investment.

The tools for chip design, on the other hand, have become more affordable, and a cottage industry of small design houses has blossomed as a result. Many of these companies are involved in producing application-specific integrated circuits (ASICs), frequently combining only a small amount of custom circuitry with cores and subsystems licensed from others.

Apple has long been in the ASIC design business, incorporating custom chips into their product designs, but they have recently been bolstering this capability, in part through the acquisitions of Palo Alto Semiconductor and Intrinsity, and, at least for iOS devices, they have moved to custom CPU designs incorporating ARM cores. We can expect more of this, and it wouldn't be terribly surprising if the MacBook Air were to be switched to an ARM-based design.

Apple already has the technology to cross-compile software between CPU instruction sets, having done this first for MC68000 code running on PPC machines, and then for PPC code on Intel machines. Moreover, in the transition from PPC to Intel, they did some work on using an intermediate instruction set for an abstract virtual machine as part of process of translating code from one platform to another, and they have continued as an active participant in the LLVM project, incorporating that technology into Xcode.

That doesn't necessarily means they could deploy an ARM-based machine running Mac OS X tomorrow, but chances are they've been working quietly on exactly that; the writing having been on the wall since they determined that the Intel Atom wasn't competitive for use in portable devices. And, while they could use an off-the-shelf CPU in such a machine, it's nearly certain they'll instead opt for an in-house custom design. This would allow them to, for example, incorporate a graphics core that's optimized for both OpenGL and OpenCL. (They might even bring back the Velocity Engine, in a fresh, multicore implementation.)

But an ARM-based MacBook Air shouldn't be taken as an indication that Apple was about to abandon Intel's processors. While the low-end (plastic) MacBook might also make the switch, it's unlikely that the MacBook Pro line would follow, at least not immediately, and even less likely that the desktop line would drop Intel. Apple has long upheld the principle that software should be hardware-independent, both allowing maximum flexibility in the selection of hardware and helping to insure that changes in the hardware don't break the software. Simultaneously shipping ARM-based light-weight portables and Intel-based desktop and professional machines - that run the same software without the need for fat binaries, because it's all compiled for the LLVM virtual machine - would drive that point home.

So, three predictions: first, expect Mac OS X 10.7 (Lion) to have a legacy environment, for software that assumes the Intel CPU architecture, and a native mode for software that's been (re)compiled with the LLVM virtual machine as the target architecture; second, expect the Mac App store to cease accepting new Intel binaries within a year of the release of Lion, perhaps as little as six months; and third, expect an LLVM-binary compatibility environment in Snow Leopard before they cease revising it (analogous to the inclusion of Carbon in Mac OS 8 and 9).

Back to you, Jonny.