Solipsism Gradient

Forgot to link to Macworld’s iPhone FAQ, which also tries to answer many questions about the business aspect.

To sum up, anyone can register as a developer and run applications on the included “Aspen” simulator. However, to run your app on an actual iPhone or iPod Touch, you need to invest $99. This gives you a code signing certificate that will be attached to your applications. I’ll post more about code signing later, but in essence this certificate is a code that uniquely identifies you (the developer) and is tied to Apple’s master certificate. It’s not counterfeitable by current technology. Whenever some software is executed by the iPhone, the system first checks its signature. If it’s not signed, it won’t run at all. If it is signed, the certificate will be either Apple’s own – in which case the software presumably will have full access to all system functions – or it will be a “normal” developer certificate. In that case, the application will be allowed to run with restrictions inside a sandbox – a separate folder contain the application and its data.

Once your application is tested, you must send it to Apple to be considered for inclusion into the App Store. This is a central marketplace that will be accessible directly from the iPhone or from iTunes. Apple may not approve your application; some broad guidelines were mentioned, and hopefully will be clarified before the store goes online by the end of June (after WWDC). In any event, approved or not, you’ll have no alternative way of distributing; both iTunes and the iPhone OS will only load new applications from the App Store. Presumably approved applications will have a stronger certificate which is checked at installation time, and which can be remotely revoked by Apple if your application is latter deemed to be “untrusted”.

One particular “forbidden” application type is one that downloads and runs plugins, interpretable or executable code from elsewhere. Of course that can’t be taken too literally, or it would exclude (for instance) JavaScript on a web page. Still, it would at first glance forbid Java; even so, Sun has announced intentions to produce a free Java virtual machine for the iPhone. No word yet from Apple about that, but you can presume that all those rules will have exceptions whenever Apple considers it convenient to make them.

For “indie” developers like myself, the App Store seems to be a good idea. You get 70% of the sales price. Free apps are allowed, too. In comparison, I get 85 to 90% of the sales price in my current arrangements for Mac software – but I spend some of that difference on bandwidth, site maintenance, and customer support. I personally spend almost nothing on marketing and advertising, but some developers do spend more. The App Store idea is that Apple takes care of all the business details for you, and it’s not an unreasonable deal.

Many people are discussing the implications of consenting to Apple’s rules in order to being allowed to publish iPhone applications. Personally, I’m not too bothered. Like any finite game, you can consent to play or not, but once you do, you have to play within the rules.

Speaking of rules, some of them are none too clear yet. It seems that publishing a free version that is unlocked by a serial number, as we’re used to, is not allowed as such; I suppose you’ll have to do a free version and a paid update. How would I send my app to another user for beta-testing? Unless that user also has the SDK and a certificate, and if I’m willing to send over my source, that seems to be impossible. For now, I suppose you can compile a simulator version and send the object code to some other SDK user; good for checking out the user interface maybe, but not a real-world test.

Support is also tricky. Will Apple do support for all the apps? I doubt it. If someone emails you with a support request, how can you, since there are no serial numbers, check that the request comes from a legitimate user? And you can’t send out a special version for testing, either. Hopefully Apple will explain this soon.

Next: code signing.

Update: forgot to explain the $99. This appears to be an annual fee, much like the $500 I pay now every year for the “ADC Select” program. Does this mean that the developer certificates expire after a year? Well possible, but will that also affect applications already on the App Store? More questions…

Well, there’s little actual information to add to Gruber‘s and TidBITS usual comprehensive write-up, but maybe I can explain some parts in more detail, or provide an opinion on how this will impact developers in the future.

Regarding SDK details as such, most of it is under NDA, which I signed yesterday; but some details have been published already. It’s common knowledge that it includes Xcode 3.1, which will very soon be available as an independent (and free) download, and of course included on installation DVDs with any Mac as soon as it gets out of beta. It also includes Interface Builder 3.1 but not the special objects to directly build iPhone windows; this will no doubt follow in the next release.

I was looking forward to getting my hands on the iPhone UI – to date, I haven’t seen one in the flesh (same for the iPod Touch). But fortunately the simulator includes Safari, so at least I can check how this site looks; some pages come in too wide, and I’ll tweak them as soon as I find time. Still, the UI for the few included apps looks great and it’s useful to get a feel for all the animations. Speaking of the simulator, it’s not a hardware-level simulator; it seems to run x86 code, no doubt an easy way to make it even harder for hackers to glean information about the actual iPhone OS implementation.

I suppose this would also explain why the current SDK is Intel-only; the PowerPC version might not have made it in time, or may be too slow, or whatever. Still, it’s a bad precedent. Intel Macs seem to be about 50% of the installed base by now, a year before I thought that would happen, but it’s still too soon for people to stop doing Universal applications. For what it’s worth, I had to install everything on the only Intel Mac I have – a Core Solo mini with 512MB RAM – but it seems to run quite well despite the cramped hardware.

This “iPhone OS” name now seems to be the new “OS X” and it’s… clumsy. Not a good way to indicate a new platform that already includes the Touch and before the end of this year (or so I think) will get new members. Indeed, there are hints that both “mobile” and “touch” were at one time or another the platform name du jour, and hopefully this will prove to be just a beta name.

Certainly nobody in the Mac developer community was surprised that the SDK is based on Xcode, Cocoa and Objective-C; doing otherwise would mean a complete rewrite of the current 1.1.x firmware, and Apple hasn’t enough manpower to pull such a thing off. Besides, it’s certainly a good way to get Macs into the hands of new developers. Still, no doubt some people are miffed or surprised that the SDK doesn’t run in Visual Studio, or that there’s no Java or .NET support; I can imagine them complaining to Microsoft about this (hey, Microsoft owns a good chunk of Apple, or so they probably believe).

Next: the business part. That’s where it gets interesting.

I pushed Quay 1.1b3 out a few days ago and immediately had to quick-fix and slip in a new build (same version number) because of an endian issue on Intel Macs.

Yes, I should have tested this; for some reason, all people I asked to run preliminary builds also were on PowerPC Macs – including two I’d have sworn were on Intel. Murphy never sleeps. My own solitary Intel machine – a rock-bottom mini (Core Solo, 512MB) – had been down for almost a month, having had some indigestion with one of the last Leopard betas, and I finally spent an afternoon wiping it and reinstalling 10.5.1 on it (also seizing the opportunity to confirm that Qay still runs well, and with almost all features, on that version).

Curiously enough, this made me notice that two steps in my build chain (utilities that generate intermediary files) are still PowerPC-only and break when I build the project on an Intel machine. Must fix that because pretty soon I’ll have an Intel laptop available, and it must be able to do full builds.

I hope to have the next version out in the middle of next week. I’ve already fixed one issue – an oversight in the last rewrite made it stop working for folder aliases dragged directly into the Dock. There are a smaller bugs outstanding, but nothing too serious. Unless something turns up that requires serious testing in the field, the next release will (I hope) be 1.1 final.

Quay is the first software I wrote from the outset to be localized. Once you take some precautions this is relatively easy to do in a Cocoa application, and I’m talking to Ronald Leroux, a well-known localizer for French, to see whether we can get a pilot French version in time for 1.1. There are a few obstacles; I’m used to fiddling around with text right until the last minute; current localization software isn’t quite working yet for the new-fangles nib files used by Leopard/Xcode3; and code signing proves to be an unexpected puzzle.

Well, of course I can put all the current localization into the application bundle and sign it, and everything will “just work”. However, 99.9% of users will use only one of the included languages and some of those would be happy if no others were present. Code signing (at least the standard way which I’m using) doesn’t like files or folders removed from the application, nor does it like added items. It would indeed be nice if the various languages were present on the installation disk image but the user should be able to opt only for the currently enabled language, for instance. And it would also be nice be able to download additional or new languages as they become available.

I do have some ideas for workarounds to that issue, but I’m not sure they’ll work in time for next week’s release – be it 1.1b4 or 1.1 final. In any event I’m very anxious to finish off 1.1, as I’ve got serious plans for 1.2; a new GUI is only one aspect of that. Stay tuned.

Update: regarding localizations and signing, Mike Ash just reminded me that you can remove localizations without messing up the signature, but you can’t add new ones. I found out, however, that you can put a new localization somewhere outside the application bundle and then add a symlink from the resources folder from there. Interesting.

uliwitness wrote:

Oh, BTW, also found your review of the FireWire power specs interesting. I was hoping someone with better electrical skills than me would eventually post the fundamental maths involved to prove/disprove the “No FireWire cuz it needs too much juice” theory that’s been bandied about.

The post was already too long, so I didn’t mention the possibility of using the Sony 4-pin FireWire connector, which doesn’t supply any power; it’s also much smaller, getting around some of the space argument too.

Still, it’d be a hassle needing an external power supply for those small portable FW drives; most of them don’t come with one. Also I’m not sure whether Apple would have to pay Sony for that.

As I also said previously, each extra USB connector would also need more space and power, though less (2.5W) than FireWire.

Posted by uliwitness:

“When it comes to Japanese PC manufacturers, their manufacturing plants will complain or add their own technical efforts to lower cost, if a proposed structural design was insufficient,” one of the engineers said. “The MacBook Air gives me an impression that its manufacturing plant packaged the computer exactly as ordered by Apple.”

Rainer,

thanks for posting this — it mirrors exactly the thoughts I had when I read this news bit, and now I don’t have to coherently blog about it anymore.

FWIW, from what I heard, this is a common thing with Asian manufacturers. They like to improve products, but since they usually don’t have the whole list of why something should be done this way and not another, the customer of these manufacturing plants isn’t always happy with that.

Some western companies have “solved” this by putting QA guys in place that will babysit the manufacturers and make sure stuff gets produced the way they requested it, for exactly that reason.

I guess this is a cultural issue that will have to be resolved by understanding each other…

Oh, BTW, also found your review of the FireWire power specs interesting. I was hoping someone with better electrical skills than me would eventually post the fundamental maths involved to prove/disprove the “No FireWire cuz it needs too much juice” theory that’s been bandied about.

The snowball effect I was writing about is also very evident in the design of the MacBook Air. I’ve posted before about some aspects of this (I was wrong about it having fewer internal screws, though).

Just saw this: Japanese engineers trash MacBook Air. Here’s the original article in somewhat clumsy English. Some choice quotes:

“Can we say that the MacBook Air has a perfect, sophisticated external appearance, but its insides are full of waste?”

…

What astonished all those engineers was the fact that the computer had a very costly structure. For example, it used an extremely large number of screws to attach components. About 30 screws were used to attach the keyboard alone.

…

“When it comes to Japanese PC manufacturers, their manufacturing plants will complain or add their own technical efforts to lower cost, if a proposed structural design was insufficient,” one of the engineers said. “The MacBook Air gives me an impression that its manufacturing plant packaged the computer exactly as ordered by Apple.”

…

Based on the results of our teardown project, we guess Apple is not paying much attention to both workmanship of the hardware design and comprehensive cost reduction…The MacBook Air’s mysterious internal design might be a violent antithesis against Japanese manufacturing, which allows no compromise even in detailed parts of the hardware.

This is a very interesting insight into manufacturing. Can you imagine Steve Jobs’ reaction to somebody at the Air factory deciding to take out 25 of the 30 screws that hold the keyboard? Heads would roll!

No doubt all those screws (and the other things they considered “waste”) contribute to the Air’s extremely solid feel that’s remarked upon by everybody who has handled one. Contrast this to all the “this thing must be soo fragile” comments, just after the launch, by people who had not handled one. Obviously people are used to small electronic devices following the (apparent) Japanese practice of shaving off internal “waste” to save a little space and money and ignore the consequence of a flimsy feel… something that would be especially accentuated in such a thin device as the Air.

So, this article betrays a fundamental misunderstanding of Apple’s design strengths and intentions. Their definition of “workmanship and… cost reduction” is very different. From what I can tell, the Air was designed from the outset to be extremely thin and rugged, while maintaining adequate battery life and performance. These considerations snowball to the extent that the battery uses up 2/3 of the space, and seems to be (along with the keyboard) itself a structural element.

Everything else flows logically from that. To put in a FireWire connector means reserving resources for a 7W additional power drain – that’s 1A extra current at the 7.2V battery. It also means an extra power supply to jack this up to the 9 to 12V required at the connector, extra PCB traces, and so forth. The battery has a capacity of 37 watt-hours, meaning that at the rated duration of 5 hours, the average power draw is slightly over 7W; this would double when a FireWire drive is connected, meaning battery life would be only half, 2.5 hours. Also, the extra connector would mean widening the flip-down door and shaving off maybe 2cm off the battery on that side… more capacity reduction. The 45W external power supply would also have to be beefed up, and the internal charging circuitry as well… this means more heat dissipation. It would probably have been necessary to make the battery itself thicker, maybe 5mm or more.

Now look at a typical Ethernet connector; it’s thicker than the Air’s door, so some millimeters would have had to be added to the Air’s thickness, too; as well as taking the extra chunk out of the battery as well.

Same applies to an internal DVD drive. If it doesn’t work as a burner too, they’d have complained – but imagine the power requirements, or read the Lenovo x300 review; Lenovo engineers are very capable too, but they decided on different trade-offs. I have handled some other brands of small laptops from Toshiba and I must say I was unimpressed by the feel and finish.

Finally, imagine the Air with a removable battery. This means extra connectors, a case opening, of course with either a full-width extra wall (meaning at least 4mm extra thickness) or some heavy-duty latches (considering the battery is 2/3 of the size and a similar proportion of the weight of the Air). Consider the loss of rigidity that would imply, and the extra size and weight that would have to be “wasted” to counteract that.

So that’s my point. Any change in the Air’s design immediately snowballs into a larger, heavier, hotter and (probably) less solid-feeling machine. Jobs obviously thought it was worthwhile to concentrate on those aspects, and it’s rather shortsighted to conclude that “Apple is not paying much attention to … workmanship”.

Interesting how some design choices you make early on cause a “snowball effect” – many product details end up depending on these choices. Sometimes you have to go back and change the initial direction of the snowball, so to speak, because some of those end effects turns out to be unacceptable.

When I started rewriting Quay for the first 1.1 public beta, I decided to change the way the background application (QuayMenu) was run. In 1.0, a Quay icon in the Dock was a file hidden away inside the Quay database package. When the user clicked on the icon, QuayMenu started up (if it wasn’t running already), and presented the menu. This simple scheme interfered not at all with the Dock itself but depended on several tricks to find out, approximately, the on-screen location of the clicked icon – something that a normal application doesn’t need to know. (It also didn’t work at all if you accessed the Dock over keyboard navigation.)

For 1.1, I decided to convert QuayMenu into a LaunchAgent: a per-user background application that runs constantly and is restarted by the system if it fails. I also worked out a way to have QuayMenu monitor click and keyboard events for the Dock, and use the Accessibility APIs to work out exact locations and details of a clicked Dock icon. So when the user clicks on a Dock icon, QuayMenu checks out if it ought to handle that click and pass it on if not.

This design decision had immediate consequences. It’s much easier to control (and update) a LaunchAgent if it’s in a fixed, known place. I decided to store the main Quay application inside the Quay database itself (which is in ~/Library/Application Support), both to prevent the user from moving it and to have a single known location for updating. The idea of having everything inside ~/Library stems from complaints I had about XRay storing stuff inside /Library, years before. So there was an a priori concern to make Quay a simple, no-hassle, per-user application; nothing stored outside the user’s home folder, no administrator password needed, no security concerns.

However, this immediately conflicted with the need of using the Accessibility API. Basically, if you use this API to ask other applications about their user interface, you have two options. You can wimp out and ask the user to turn on “Enable access for assistive devices” in the Universal Access preference panel, or you can run a “trusted” accessibility client. The first option means that you depend on the user having this turned on all the time; if it gets turned off, things stop working and you have to show a dialog asking for it to be turned on again; clumsy. Also, some people (including myself) don’t like turning this on because it changes the way tabbing between text fields behaves – it then tabs over buttons too.

The second option – running as a trusted client – was the better one, then. However, it too comes with a trade-off. A trusted accessibility client runs “setgid 90”, meaning the executable is forced to run from the special “accessibility” group. This is a tamer version of the tricky, all-powerful and potentially unsafe “setuid root” executable; its only advantage over a plain vanilla executable is that it can see (and affect) other applications’ user interface elements. However, there’s one common aspect; to turn the setgid bit on, you need to ask for an administrator password. As a side-effect, copying the executable to another place turns the bit off again, and it’s ignored altogether if run from an external volume or a disk image.

All this meant that I would have to write an installer to move the applications into their place, ask for an administrator password and turn on the setgid bit. Apple’s guidelines say that in such a case you should do a standard Apple Installer package and have all this accomplished by scripts inside the package. I decided against that for several reasons.

One, it’s harder to check an installer package against unauthorized modifications, while an installer application can use code signing to prevent those. Personally, after some bad experiences with badly-written install scripts, I distrust installer packages a bit more than separate installers – although I know people who distrust installers even more. The third option, of writing a self-checking, self-repairing application that could be drop-installed anywhere – as Quay 1.0x was – I reluctantly discarded. Some people prefer to have multiple copies of applications available, some use weird separate application folders (as was usual in the Classic days), and if you back up your applications with Time Machine, you’d have copies right there which shouldn’t be accessed except when restoring from the backup volume.

So the decision of writing a suitably self-explanatory and “just works”-type installer appears to be the right one. It’s actually working pretty well in the current (1.1b2) beta… except that I’d forgotten one important thing. FileVault (on the list of system features I don’t use myself) is based on a special “sparse” disk image that is mounted in place of your home folder. Meaning that, if you use FileVault, you can’t have setuid or setgid executables inside your home folder – and certainly not inside ~/Library.

OK, so I’m dutifully rewriting my installer to move everything into /Library which has no such limitations. An added advantage is that now there’s a single copy of Quay installed for all users; but should the serial number, then, also be valid for all users? That means the added hassle of separating the preferences into yet another file, installed into /Library/Preferences; one more thing to uninstall. An added disadvantage is that, now, the uninstaller – which I’m building into the Quay application itself – will need to ask for an administrator password, too. Or maybe I should have a setuid root uninstaller tool inside the application; I don’t like that either, but having such a tool would also mean an easy way of adding extra functionality to the Quay popups.

Well, all these are trade-offs, and I hope that when 1.1 (final) comes out, that the net effect will be positive. If all goes well, 1.1b3 should be out sometime next week, and you’ll have the chance to comment. Stay tuned.

My ADSL line has been down for almost 24 hours now – and it’s promised to be up in a few hours. But then, they already said that yesterday, to no effect . First time it’s been down in over a year, so I can’t complain much.

I’m posting this from my neighbor’s poky connection; if you’ve e-mailed me in the last 24 hours, my apologies. It may still take some time before I can reply.