In “More on Apple’s Removal of Airfoil Speakers Touch From the App Store”, John Gruber of Daring Fireball has a detailed “back-and-forth with a few informed sources” about why Apple rejected the app.
The trouble? Per a tweet from Jeff Johnson, who works at Rogue Amoeba on Airfoil:
If Apple is talking to the press, it’s extremely underhanded and unethical, because they aren’t talking to us.
I don’t get a good feeling from this.
Update 5/23/2012: Mystery solved! See the end of this post below.
Until recently, for as long as I’ve been using Xcode, this code has never compiled successfully without warning:
#import <Foundation/Foundation.h>
@interface Foo : NSObject
@end
@implementation Foo
– (void)myMethod {
[self myPrivateMethod];
}
– (void)myPrivateMethod {}
@end
Can you see why? The method myPrivateMethod is never declared, and it isn’t defined until after its first usage in myMethod. Since C compilers are, as far as I’m aware, by standard implementation if not formal definition single-pass compilers, that first usage should have been flagged as something the compiler didn’t know about.
In Xcode 4.3.2, the current version of Xcode, the compiler doesn’t make a peep.
This is big.
Many of all the ancient, crufty things we hate about C and C-derived languages are due to that single-pass compilation — predeclarations and declarations of methods and classes (and everything), #import and #include statements, .h files at all. Java, for example, has none of these things.
What if clang got rid of all of that for Objective-C?1
John Siracusa in his 2011 episode of Hypercritical “A Dark Age of Objective-C” bemoaned how Apple was dragging its feet about moving on from its current legacy language and runtime to something more modern and competitive.
What if they’ve already started, without telling anyone?2
Update 5/23/2012: Turns out, it’s not a conspiracy, it’s a bugfix.3 Discussed in this March 6, 2012 thread in the Xcode-users mailing list. The thread points to this llvm commit on August 31, 2011 and mentions that the behavior is new to Xcode 4.3. It also mentions this post on the Apple DevForums, but I get an error when I try to go to it. (I really wish Apple made its non-NDAed DevForums posts freely available on the web.)
Thanks to Andy Lee for the information.
So I guess clang isn’t taking over the world, just yet? It’s too bad…
Xcode’s new Core Data model file format, introduced with Xcode 4.1 in 2011, never made any waves in Cocoa development blogs that I saw.1 Which is a shame, because it’s a pretty kick-ass improvement. Instead of a binary plist format (more specifically, Cocoa objects serialized directly to disk in a binary plist format), it’s eminently readable and diffable XML.
It reminds me, for two reasons, of Mark Pilgrim’s complaint about Apple’s switch from the standard .mbox format to the (Spotlight-friendly, but undocumented) .emlx format in Mail.app in Mac OS X 10.4, which was part of his rationale (last straw?) for leaving the Mac ecosystem and moving to Linux. (See this Daring Fireball article about it, since Pilgrim’s blog posts are now only available via the Wayback Machine.)
For one, it’s because my experience with the new format involved what I remember to be an involuntary switch. The details are a little fuzzy for me now (a good reason to write these blog posts in a more timely manner), but I recall my edits being saved in the new format without my having done anything to warrant it, and without any prompting on Xcode’s part. Just like Mark’s experience in Mail. If Xcode did make a habit of that, I would be rather annoyed, and for the same reason. (As an aside, I go on about this at some length in my first podcast (link forthcoming2 due to this mistaken remembrance. See the second podcast for followup, or just read the rest of this post.) I’m a sophisticated enough user that I care about format switches, mostly for the sake of backwards compatibility. For non-technical users, losing that compatibility might be fine. Developers, however, are by their nature not non-technical users.
It turns out, I can’t reproduce that experience now with fresh reinstalls of Xcode 4.0.2, 4.1, and the latest Xcode 4.3.2. Instead, the only thing that changes the format is for you to explicitly change it in the model’s inspector pane. Which is great. Exposing that level of control over a file’s format is exactly what a developer tool should do. And they do it for other important file types too, like xibs. So, kudos.
For two, it’s because this is kind of Mark’s experience in reverse. Going from a less standard format to a more standard format. (I did say “kind of”.) While it isn’t documented, it is uncluttered, as far as I can tell, by the kind of unreadable binary garbage that pollutes other XML file formats. Entities are referred to solely by name, not UUID. Attribute titles are simple and understandable. From a practical perspective, this will make the SCM diffs you do every day far more useful and enjoyable. But I could also see someone using a script to mechanically put together a Core Data model file, much more easily than you would put together an Xcode project file. And going further, I could see someone writing a third-party Core Data modeling tool that spits out one of these. I’m almost surprised someone hasn’t done it already, though the Xcode 4 Core Data modeling tool is good enough (and free) that there probably isn’t much demand for it.
On recent Build and Analyze and Hypercritical podcasts, Marco Arment and John Siracusa, respectively, talked about the rumors of a bigger iPhone screen.
John predicted that Apple would only make the screen a little taller, but Marco observed that any resolution change would mean significantly more work for developers.
My take is the latter rules out the former: Apple won’t and can’t make a little change. Anything that requires new developer work opens the possibility that many/most developers won’t do it promptly or at all, making Apple look bad. The Cudgel of Rejection only works for new apps; for old apps, there has to be a carrot that motivates developers to rush out new versions with support for the new resolution.
And while I don’t know what it will be (I can’t even hazard a guess), I believe it won’t be a minor hardware upgrade.
Weaponized Fluff 