Dr. Drang has a post (now fireballed) bemoaning the large difference in resolution between desktop, notebook, and ultraportable Macs. There is indeed a wide range, from 102 ppi on the 21.5” iMac to 135 ppi on the new 11” MacBook Air. Apple has been working on resolution independence for awhile, but thus far it’s been too buggy to unleash on the general public. Lately those efforts seem to have stalled, at least as far as public announcements go. There are a couple of reasons why this might not be such a bad thing.
First, the different displays mentioned above are typically used at different distances. I’m typing on a 27” iMac, with the display at a distance where I can very nearly (but not quite) reach out and touch it. It wouldn’t be physically possible for me to type on a laptop at this distance, at least with the built-in keyboard.
Controls really ought to occupy a fixed number of arc-seconds of one’s visual field based on typical usage. That way, regardless of screen size and working distance, they occupy the minimum amount of screen real-estate necessary to be readable. The WYSIWYGness of what’s displayed on the screen only becomes an issue when you want to gauge what a document will look like printed. So the important parts of this sort of resolution independence can be (and mostly are) implemented in individual print-media creation apps.
The second reason is that resolution independence might soon become moot. Displays are rapidly becoming too high-res for a person to distinguish individual pixels: the iPhone 4 already achieves this at typical smart-phone viewing distances, and I would argue that my iMac and the new 11” Air are, if not already there, really close (at their typical viewing distances). If and when desktop and notebook displays reach Retina Display resolution, Apple could simply declare that 320 is the new 72 and be done with the whole resolution independence quagmire for good.
A caveat is that some people (particularly those my age and older) are going to want larger controls on an arc-seconds-of-visual-field basis. That in itself might make resolution independence worth fighting for.
I spent about an hour yesterday carefully stepping through some code that was setting the text of a UILabel in an iPhone app I’m working on. It worked perfectly on my 3.0 development box and my 3.0 device, but for some inexpicable reason, the text wasn’t showing up on my client’s 2.0 machine or device.
(more…)
Apple released the beta version of their iPhone SDK yesterday, and the response from the developer community was an unintentional DDoS of the entire developer.apple.com domain. But there are a few caveats to the otherwise Christmas-morning-like announcement.
Among them is that to get an app into the hands of users, a developer must sign up for a $99 app-signing license, and then sell the app through Apple’s iTunes-esque store, with Apple taking a 30% cut. This is really convenient (if a bit expensive) for the developers, but runs up against the established business model of the vast majority of indie Mac OS X developers: try-before-you-buy shareware. In this model, the software is distributed free-of-charge, often with limitations or nagging that can be turned off (or extra features that can be turned on) only by entering a license code purchased from the developer. It’s not completely clear how this would work under Apple’s model.
But another thing Apple released yesterday was a Mac-OS-based iPhone simulator. Right now it’s Mac-only, and it may or may not be a major PITA for Apple to port this functionality to run under Windows, but it represents an ideal solution to most instances of the try-before-you-buy conundrum: Apple would merely need to allow developers to link their app against the simulator and to distribute the resulting bundle as a trial version of their app. If by playing around with it on your (non- or less-mobile) desktop or laptop you decide that you like it, you would pay to download it from Apple’s store.
Now it’s true that a linked-against-the-simulator app could lead to piracy, but realistically the App Store will do little more than to keep honest people honest; dishonest people will most likely just copy the app from a hacked iPhone. It’s also true that people might use the simulator-widgets on their computer in lieu of paying to use it on their iPhone. But typically anything that can be done on an iPhone can be done better on a PC, albeit in a less pocket-sized fashion.
So I believe that represents another category of people who wouldn’t have purchased the app anyway.
The previously mentioned teach-myself-to-program-Cocoa-apps app is now available in a more-or-less feature-complete beta version.
The program is called Checkpoint, and is used to calculate scores for a certain style of time-speed-distance road rally. It’s something I had first tried to put together as a pure JavaScript+HTML app à la TiddlyWiki (but without the ability to save), and then as a (buggy) Ruby on Rails app I ran on my laptop. Then I realized that it’s probably one of the few apps that really makes sense to run as a pure desktop application.
Anyway, on the off chance that you think you might find this sort of thing useful, follow the link above. It’s free as in beer and runs on Mac OS X 10.4 and later.
I’ve been putting together a “Learn how to program Cocoa” program, and one of the things I’ve recently struggled with is how to link up an NSComboBox with a Core Data entity so that a heretofore unseen entry in the text box part of the combo box adds an instance of the entity and sets the value of the combo box to the new entity instance.
(more…)
