Technology – Page 14

The Much-Discussed Apple iPhone 4.0 beta TOS

As I write this in April 2010, Apple has just released a beta iPhone 4.0 SDK with the following rather alarming addition to the legal terms (at least according to many web sites; I haven’t seen it directly from Apple yet):

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

The is an avalanche of commentary out there on this, most of it negative, centered around the word “originally”. John Gruber, in his second comment about section 3.3.1, gives some reasons why this is sensible from Apple’s point of view. The essence is that it will lead to higher quality app, on average.

I will try to add a bit of insight from my experience. I am of two minds on this.

Why It Makes No Sense

From the point of view of using / creating the best tools, it strikes me as ridiculous. Great developers, or developers creating great things, generally use layered software designs to do so; and indeed layering, the increase in abstraction over time, is absolutely crucial to the software industry’s ability to make good use of ever-growing hardware capabilities. One obvious and vital kind of layering/abstraction is the use of higher level languages. Apple’s new insistence that only its provided languages/runtimes be used, ignores this fundamental insight.

More ominously, if this notion of “originally written” turns out to be enforceable. Imagine if earlier platforms had required that all software be written “originally” in the provided languages, with any attempt to build a higher level on top, banned; we could never have gotten to the amazing variety of technology available today, under such a regime. If such restrictions grow popular beyond Apple, that could lead our industry in to a kind of dark age.

I don’t think that’s likely though, and for that matter I think it is most likely that Apple won’t be able to make this new term stick. There are many successful apps already using a variety of languages, frameworks, and layered designs. Enforcing it as written, universally, would impact too many of those. Yet if Apple enforces it selectively (just to squash Flash, as many commentators suggest), they invite a long and painful legal mess. Speaking of that, such a legal mess would be an enormous windfall for Android.

Why It Makes a Bit of Sense

Setting aside the questions of whether it can possibly work, Apple’s notion does make a some sense, at least for the immediate future for this specific (iPhone etc.) platform. Most iPhone users/customers are probably better served by a market consisting mostly of native apps.

The difference between native and non-native apps for iPhone OS, is mostly analogous to the same difference a decade ago in PalmOS software. The native (and tedious to use) C toolset was the most popular, but there were many other (higher level) tools to choose from, and with frank honesty I can say that the results were generally poor, and almost always worse that write the same app with the native tools.

In fact, my firm Oasis Digital worked for at least two different customers on projects to replace applications written using such tools, with code we wrote in C or C++. Yes, it took longer; yes, it was more lines of code. Yes, it took more testing and was more prone to the kinds of problems low level code has, with memory leaks and the like.

But most critically, from the point of view of the users, our results with low level tedious implementation were obviously better. The high level tools available today for iPhone are much better than the Palm stuff a decade ago; but still, I suspect the same applies to a lesser extent on the iPhone-OS platform today.

Apple, Cut That Cord

As I think back to opening up my new iPad, two things stand out. First, the product packaging is delightfully minimal. It does not even contain media with the iTunes software, instead explaining that the first step is to download iTunes.

Second, a new iPad does not work at all until syncing it with a PC (Mac or Windows) via the included USB cable. I find this surprising because, in so many other ways, the iPad is a great device for someone who wants access to basic computing capabilities (web, email, casual games) without caring about the complexity of a PC. Yet such a user must already have a computer, with all its (potentially very-un-Apple) complexity, to use an iPad. The polished experience is potentially debased by being plugged in to a $200 closeout PC, just to get it running.

The need for iTunes seems quite justifiable in smaller Apple iDevices; but for the iPad, I can’t help but notice its specs are ample to be self-contained.

Even for those of us who will sync to a PC, why the cord? The iPad has WiFi and Bluetooth, as do most PCs nowadays. Plugging in that wire to sync seems utterly antiquated. Apple could could scrap that many-pinned proprietary port, and replace with a much simpler power plug, which would also free it from the pitiful rate of charge provided by USB. An iPad could have a MagSafe charger, and charge up more safely and in 1/2 the time.

Apple, cut that cord!

My iPad is (unfortunately, mostly) a toy

Some pundits have declared the iPad a “toy”, or suited only for content consumption. I disagreed with the latter a few days ago, and I think it will have some very interesting business uses. If I come up with a sufficiently novel one, Oasis Digital might implement it.

But sadly I must mostly agree, for at least my personal use of iPad v1, with the “toy” assessment. Here’s why.

I like to hand this iPad (I wrote the first draft of this post on it) to other people to try out, to my kids to play with, to sit it out as a novelty for guests, etc. But if I set it up as a personal tool, with my email, calendar, Twitter, Facebook, other accounts, work related files, etc., then I’d be handing access to all that personal and business information to everyone I offer the iPad to. Clearing out and re-entering my accounts from a whole pile of apps (and Safari, and Mail, and ???) is tedious and error-prone. My personal accounts include occasional bits of my (and our customers’) proprietary information, so leaving them present for guests is clearly unacceptable. Thus, for now this iPad can be only a toy to me. I occasionally set up email, then remove it; set up Twitter, then remove it, etc. I type some notes, then email them to myself, and remove them.

The key missing feature of the iPad, for me, isn’t a camera, a USB port, or an SD slot – it is the lack of a user account/profile capability. My Ubuntu netbook, at half the cost, has this capability in the box.

This isn’t much of an issue with an iPhone, which by nature of being a phone, is inherently almost always a personal (not shared / guest) device.

This isn’t much of an issue with an iPod Touch, at least for me, because I already use it as a guest/toy only anyway.

I suspect that Apple won’t add an account/profile mechanism anytime soon; it is easier to therefore ignore a mixed personal / guest use case like mine. If Oasis Digital ends up with a line of iPad software, we’ll work around the problem by buying more iPads.

But in the meantime, I like the share the one I have – so I must configure it primarily as a toy.

iPad: Not Only for Content Consumption

Like 300,000 other people, I have a shiny new iPad in hand. Here is my very short review:

Apple is going to sell a huge pile of these things.

Expanding on that…

Lots of other companies are going to sell an enormous pile of apps for the iPad. From the point of view of a maker of software, this is a very appealing market. As with the iPhone before it though, my main concern is that it is such an appealing market, that is might actually have an unfavorable ratio of developers to customers.

Other hardware and software makers are either in panic mode, or they should be and will suffer if they aren’t.

The device and its software are remarkably polished and ready for wide use, primarily for content consumption. There are many commentaries out there about the iPad as a device only for consumption, citing the lack of a keyboard and camera among other factors. While the lack of a camera in iPad v1 is a bit annoying, I expect that to be fixed in the next version (2011?). Regarding the keyboard, I am also a fan of physical keyboards, but I was able to write the first draft of this post on an iPad without much difficulty. It is clearly unsuitable for writing many pages of text or extensive editing, but quite sufficient for blog posts, tweets, organizing and naming photographs, short emails, and many other minor-data-entry tasks done every day.

On the other hand, I generally agree with the many comments out there about open vs. closed systems, and I am a fan mostly of the former. We are in a situation right now where is one particular closed system has a great lead on the open alternatives, a situation I expect to continue for a few years but not much longer. The hardware design needed to make the iPad work is currently an area where Apple is well ahead of its competition; but they will catch up. Android devices with a similar form factor, battery life, and somewhat-as-polished user experience will appear.

The biggest surprise so far is Pages – it works much better than I expected (which was admittedly a low bar). A related annoyance is that Pages documents don’t automatically sync in iTunes; rather iTunes provides a GUI by which I can manually copy Pages files back and forth.

The second biggest surprise is my impression of the size of the iPad. I had expected it to feel a bit too small; instead, I think it’s actually a bit too large. I wouldn’t be surprised to see v2 feature a screen 1/2 inch smaller, and overall size 1 inch smaller.

As I expected, for me an iPad is an adjunct to my real computers. My work involves extensive use of multitasking, keyboard, pixel-accurate mouse positioning, large hierarchical collections of files, and all the other things that modern “real” computers are well suited for. I don’t see this as problem for the iPad though; for it to succeed, it is not necessary for grown-up computers to fail. It doesn’t even need netbooks to fail.

Lastly, it has been observed that iPad use requires a knees-up sitting position, and I can confirm this is true. There isn’t a good way to rest an iPad and have both hands free to use it, while tilting it to a reasonable viewing angle, other than with one’s knees up.

My First Emacs (plus Slime, Swank, Clojure) on Mac OSX

Emboldened a talk that Ryan Senior gave at the St. Louis Lambda Lounge (now available as a video), I grabbed the most popular two Emacs versions for Mac OSX:

and set up each on my Macbook Pro (10.6.2). For each Emacs, I also set up SLIME, Swank, and Clojure.

If that sounds like a bunch of garbled nonsense, don’t worry, it is simply a sign that you are a normal, well adjusted person, rather than a Lisp person.

It was a bit irritating to get these tools up and running the first time; there are countless web pages with the details (I won’t make that worse by adding my own here). The challenge is figuring out which instructions to follow, while ignoring the rest. The most tractable approach for me, for a quickly-installed, easily-updating, fewest-steps process, was to install the needed packages from ELPA, without any manual downloading/configuration of SLIME, Swank, etc. at all. I have no command line operations to share with you, because in the process I recommend, there aren’t any.

I used Emacs in school, but not at all in the last 10 years. Since then, my expectations for developer tools have grown – I think it is reasonable for a modern development environment to simultaneously:

be easily discoverable, for a fast start
cooperate with its environment well
make good use of the large high-res display on most PCs, to expose expected status and control surfaces
be deeply configurable and highly powerful

My experience, coming in from that point of view, differs from what Ryan and a couple other people suggested: I suggest Aquamacs. It is much more of a good citizen on the Mac platform. Its menus are much more approachable. Printing works in a Mac way. You get tabs showing your buffers, by default. You get menu options to gather them up in to one window(frame) or split them apart, all by default.

It may indeed by worth switching to the non-Aqua version later, if/when you get so deeply in the toolset that the pure emacs experience is preferable… but I estimate you’d need to be pretty far down the path (much further than I).

Something I should try out eventually is the Emacs Starter Kit. Perhaps it would have given a sufficiently “saner set of defaults” to make the non-Aqua version a more reasonable choice. Emacs gurus seem to lean that direction, overall.

Books, shirt, free to whoever wants them at STL JUG tonight

The world is my warehouse. Here are a few items I’m storing in the warehouse (giving away) tonight at the St. Louis Java User Group:

The Hawken book is a classic, a wise read for anyone serious about growing a business. I’ve read it at least three times in full.

The Walsh book is a great introduction to the many hundreds of things a person needs to know, to start a web startup. I’m not starting a web startup; but if you’ve thought about doing so, come get this book free.

The T-shirt is from the EFF, a great cause that I support every year… but I have too many T-shirts already, and I prefer to wear plain (text free) clothing.

Update: Given away successfully.