Xcode 3.2
The fact that the version number has gone from 3.1 to 3.2 is deceptive to the huge amount of improvements that have been added.
The fact that the version number has gone from 3.1 to 3.2 is deceptive to the huge amount of improvements that have been added.
Film playback is a bit weird as the new-style window will hide its title bar after a while. The idea sounds all nice, clean and efficient but I find all the additional appearing / disappearing animation triggered by it worse than the waste of space a persistent title bar would have caused. The playback controls now appear on top of the film and fade out as well (making the width of the controls the minimum width a film can be played back at). Unfortunately the controls and the ‘scrubber’ have a fixed width and don’t grow width-wise with the window to allow easier jumping inside films. Although the playback controls can be moved to a position of your choice in the movie, QuickTime Player immediately forgets about your preferred position for them and displays them in the standard position for the next film you open.
I wish I could get the controller out of the way instantly.
Update (2009-08-30): Lee Bennett writes:
As for the new QuickTime Player, I have numerous observations of behavior and gotchas. As much as Apple might have you believe that the new version folds in all the features that were available in QuickTime Pro, I most heartily assure you it’s only a half-baked effort.
I wish I’d known about those keyboard shortcuts earlier. Perhaps this is a third-party opportunity for a basic QuickTime editor that isn’t iMovie.
As one of the few feature changes in Snow Leopard, you’ve probably seen how Expose now works from the Dock, arranges windows in an easier-to-read layout, and enables you to move content between applications. Here are a few shortcuts that will make Expose even more useful…
Tim Wood has a good roundup of the new developer features in Snow Leopard.
Rosetta only takes up a few megabytes of drive space, and without it older programs simply won’t run, so if you have such programs, that option is worth checking.…I can only assume that making Rosetta optional is an attempt by Apple to goad users to upgrade their apps and to shame developers who still haven’t recompiled their apps to run on Intel chips. But given that most everyday users have no idea which of their apps are Intel-native and which are PowerPC, this seems unnecessarily harsh.
Seth Dillingham is selling bundles of Mac and iPhone applications to raise money for fighting cancer. Go build your own.
Thanks to xkcd, the secret is out. As a developer, I would hope that “experts” also look in the manual/FAQ for the software in question. Sometimes you just don’t know the right words to type into Google.
Mike Ash has some good examples of how blocks can be used. I think they’re probably the best new feature in Objective-C since Apple has been working on it.
Jon Whipple has written a massive comparison of DTP applications (via John Gruber).
Allan Odgaard on finger trees:
The only nodes which need updating are those on the path from the root down to the inserted node, i.e. we never update more nodes than the height of the tree which is log(n) (assuming our binary search tree is self-balancing)…
For whatever reason, I was more comfortable making an unsubscribe decision than a mark-all-as-read decision, possibly because it was easier to make a permanent judgment on a single site, relegating them to the dustbin, rather than tossing out perfectly good news items simply because their date of publishing fell on the wrong week.
A virtual keyboard lives and dies by the details. It’s not that there’s a single feature which makes the iPhone’s virtual keyboard better than Android’s; it’s death by a thousand cuts. A number of small differences end up making a huge difference.
Now, I want to be clear, a sufficiently clever GC on a drive that has enough reserved space might be able to do very well on its own, but ultimately what TRIM does is give a drive GC algorithm better information to work with, which of course makes the GC more effective.
In other words, not only must the dictionary be censored — a dictionary — but even after being purged of “objectionable” words it would only be considered with a 17+ rating. Even after agreeing to these terms, it took another two weeks for Ninjawords to appear in the App Store. According to Crosby, “We gave in and said fine, hoping that we could get on the App Store immediately since the solution to their rejection was a simple metadata change. However, the App Store reviewer would have none of that. We would have to resubmit an entirely new binary and get to the back of the queue before they would look at it again.”
Ninjawords seems to be a great app. Interestingly, if you search for a related word it will often offer links to the “objectionable” words, and the definitions for them are still there. I think it’s silly to censor a dictionary, but at least this rejection has some basis in the letter of the iPhone SDK Agreement.
Update (2015-12-18): John Gruber:
Matchstick Software initially submitted the app on May 13. The response from the App Store was that Apple wouldn’t publish it with those words without a 17+ parental control rating. But parental controls — the preferences that specify the age rating limits for apps — debuted in iPhone OS 3.0, which was not released until June 17. And, it’s worth noting, the June 17 release date wasn’t announced until the WWDC keynote address on June 8. Back in May, Matchstick Software knew only that OS 3.0 was coming in the near future.
[…]
I believe Phil Schiller that Apple’s policy is not to reject App Store dictionaries for containing swear words. However, it’s clear this policy has not been consistently enforced by the App Store review team. The problem, as I see it, is not that one or more App Store reviewers were unaware that it is acceptable for dictionaries to contain words that are not acceptable in other contexts. Mistakes are inevitable. The problem is that there’s no good recourse for developers to appeal such a mistake. It should have been enough for Matchstick Software to point out that the words flagged as objectionable in their initial rejection are in fact present in several other dictionaries already in the store.
I discovered yesterday that there is a way to make the Xcode source list suck a hell of a lot less. I’ve known for a while that you can split the source list vertically, but what I didn’t realise is that each split view can have different items in it. This opens up the source list to be a much more flexible tool.
Why would you want to use DTrace instead of the other developer tools that Apple provides? Many of those who work with DTrace are fond of saying that it lets you ask specific questions about your system or applications and easily arrive at answers. Simple scripts, such as the examples I provide here, can be quickly written to resolve slowdowns or bugs related to a particular aspect of your application.
DTrace is amazing.
I believe that it truly is beneficial for Apple to maintain secrecy regarding future products. The problem is that Apple is secretive about everything — not only does Apple not talk about what they’re going to do, they don’t talk about what they’ve already done. The relationship between the App Store and iPhone developers is emblematic of the problem.
The August issue of ATPM is out: