X.5 Developing¶
3384 words on Mac OS X , Mac OS X 10.5 Leopard , Software
While it may be hard to argue in favour of Mac OS X.5 when speaking to normal people, developers will surely love it. Not only is the new OS version full of updated frameworks and other behind-the-scenes magic that makes programming easier, the Developer Tools have also been improved significantly. I am not a hard-core developer, so I surely missed many great aspects in this list of my experiences so far.
You are invited to add your pet loves and hates at the end.
XCode
XCode has become faster and more powerful in its third incarnation. The slowness of Cocoa’s text engine is pretty much forgotten and XCode can now open and syntax-colour large source files quickly enough that an onlooking Linux person doesn’t have enough time to recite the benefits of emacs along with a full list of key bindings. That is an extremely welcome improvement.
Just like code folding is. Having it invalidates excuses for not having lengthy comments, say, and it can simplify understanding structures and problems on a global level. Unfortunately XCode 3 seems to have shipped so immaturely that code folding is wildly incomplete and buggy. A rather obvious problem is that red or black markers in the editor’s scroll bar, which indicate compilation problems, appear in the wrong position when lines have been folded above the error. Another is that the foldings aren’t reliably persistent which they certainly should be if they are to be useful.
A neat new feature of XCode’s editor is its ability to ‘refactor’. In a way I am a bit disappointed by this because I used to think that ‘refactoring’ is a big computer sciency thing where you re-think your application and re-design its data structures for a new version to make things better, more efficient and fantastically future-proof. In XCode’s terminology (and quite possibly in reality - my respect for all programmers who spent a hard night ‘refactoring’ just dropped!) refactoring means that you re-name some variables. Probably all for the sake of consistency, beauty and future-proofing as well - but somewhat less spectacular than what I had in mind.
That said, it is a wonderful feature. You click a variable in your code, it will become underlined and an arrow button appears to its right (most of the times, anyway). That button will contain a menu which activates ‘refactoring’ and after selecting it, any change you make to the variable’s name will be copied to all other occurrences of that variable name as well. In effect this means that you are much more likely to end up with good variable names simply because replacing the bad ones you initially put there is easy.
Just be warned that XCode’s interpretation of the Edit all in scope
command is a bit - ahem - idiosyncratic: When I define a variable inside an if branch, I (and my debugger) consider the scope of that variable to be that branch only, XCode’s refactoring, however, will happily rename all other variables with the same name inside your method but outside that branch as well. I rate this somewhere between ‘not helpful’ and ‘dangerous’.
The new XCode version also cleaned up a few other things to make your work more streamlined. Compilation errors will now show up amidst your code, the Run and Debug modes work more similarly and the debug mode has generally been improved. Most notably you just need to hover over variables in your code while debugging to see their value and inspect them. Thousands of clicks and sighs will be saved this way.
XCode’s breakpoints gained a GUI for things like playing a sound or logging some string or backtrace as well as the ability to have Global
, that is cross-project, breakpoints. That’s great for those of us who program occasionally and forget whatever little they know about the gritty gdb commands in between. That said, the GUI implemented here is far from perfect once again:
After just a few uses I noticed that: (a) you cannot use the scroll wheel in the breakpoint list when there are expanded items with text fields in them, (b) switching between the different actions like Log
, [Play] Sound
&c deletes the settings you made in your previous choice; that’s very inconvenient and bad for experimentation, (c) no Undo (but at least Copy and Paste work, so it’s still better than an iPhone…), (d) no Duplicate command, (e) after expanding a breakpoint by clicking the triangle at the left of the breakpoint you always have to click the ⊕ button at its far right side; that’s annoying; relocating the buttons or simply letting a double click in the area have the same effect would be handy.
XCode’s help now seemingly gained the ability to automatically subscribe to documentation updates, download and install them (in what seems to be universally considered the most resource hogging background process Apple gave us so far) and thus save you the hassle of that login, download and install process.
Another addition - which may well end up being a star of XCode - is the Research Assistant, an inspector window that displays information and documentation about the method, variable type or function your cursor is currently on. It’s a wonderful idea which could be tremendously useful if it were well implemented. But it’s still quite far from that.
Even in my shallow experience the Research Assistant is one of the main factors making XCode 3 terribly sluggish - waiting a full second before seeing what you typed appear on screen sluggish, that is. This needs major improvement. Allegedly there are cutting edge technologies like multi-tasking or multi-threading which let applications look up one thing without stalling your typing while doing that. Let’s hope Apple catch up with those technologies at some stage. The Research Assistant also isn’t terribly good at displaying information for many things it should know about. Specifically it doesn’t display information when you click into a child part of a struct or Objective-C 2 property statement or when you click into one of the methods of your own classes. - Nice idea, but not really there yet.
XCode’s autocompletion improved as well. But it remains ridiculously bad. I don’t think I ever used an autocompletion feature which so consistently managed to suggest the most useless autocompletion when several possible completions are available. Making this perfect should be hard but a bit of work might lead to considerable improvements already: XCode has a lot of information at hand, it knows about Apple’s data types and the functions/methods belonging to them, it knows about your classes and it knows the code you use close to where you are typing. Humans and even dull logic will probably manage to complete [bezierPath moveToPoint: NSMak in a useful way - a task which is already too hard for XCode’s autocompletion. And this is just a random example I had on screen at the moment. There are many many others you will come across.
I am lazy, so I really want to use autocompletion, but with XCode’s - as it is today - I frequently think that it would have been quicker to type things myself than to wait for the autocompletion suggestion to appear or to fight XCode to provide me the correct autocompletion. This is even harder and frustrating because even after using it for a while I am unable to predict what hitting the tab key will do. You cannot develop ‘muscle memory’ for the autocompletion for (at least) two reasons: The first is that you cannot simply type a few letters and hit tab. You have to wait for a moment before hitting tab until XCode has caught up with you. That costs time and ‘flow’. And then, XCode seems to try to be ‘clever’ about the default completion it suggests. Which could be a good thing. But somehow I found that in most cases it’s just not clever enough and hands me the wrong completion.
Objective C 2
Objective-C - the best programming language since Basic or Pascal - got a version bump as well. And it surely resolves the single thing Objective-C lacked in comparison with RealBasic: Garbage collection. While, personally, I think that Objective-C’s retain-release concept really isn’t so bad once you got the idea, leaving out all those explicit retain, release or autorelease calls will certainly make programming more fun and less of a hassle.
I’m sure there will also be situations where having proper garbage collection will solve real memory management problems. Just as there will be situations where it will hurt performance. In fact, I am fairly sure that I already observed such a situation in a fun little project where I ended up using 60MB of extra RAM while displaying an animation. Probably just being able to release the images in question as soon as you don’t need them anymore rather than waiting for the garbage collector to feel like doing the job could avoid this generous waste of precious RAM.
Properties look great as well because - as big as my love for brackets may be - it’s quicker to type than accessor or Key-Value-Coding methods. I’m lazy in that way. XCode’s autocompletion still mostly sucks when you are using properties and I am not sure whether I fully grasped the concept and its consequences yet. (What’s the cost of using a property? Does it really make sense to access a class’ instance variable via self.myInteger? I keep thinking that it may be the ‘cleaner’ version of doing things but that in many cases it’s probably just an absurd waste of CPU cycles - i.e. global warming. So what’s the responsible thing to do?) My lazy self is also a bit disappointed that setting up a property requires three lines of code in three different locations. I was thinking more about a single magic statement in a single place. As XCode’s ‘refactoring’ also fails to make renaming properties easy by offering to change both the source and header file and listing all other places where the property is used by files (code and nibs) in the project, this isn’t entirely convenient.
Objective-C 2’s new looping techniques are very welcome as well. I doubt that anybody will miss having to type NSEnumerator all over the place. I certainly won’t.
Interface Builder
One of the more problematic parts of X.5’s developer tools is the completely reworked Interface Builder. While re-engineering and re-writing the ancient Interface Builder application to better match today’s Cocoa environment with things like Bindings and the iPhone runtime environment around is most likely a good idea, the application itself seems terribly under-engineered and prematurely released to me.
Somehow the new Interface Builder seems to require a lot more screen real estate than its predecessors with its huge, overly animated and split viewed Library palette being the most obvious problem. Just try creating a medium sized window on a MacBook screen. It will end up being frustrating because you’ll either have the Library palette covering your window or you’ll have to fight the battle between the Library and Inspector palettes about who is on top. That’s not very convincing.
Interface Builder’s - just like XCode’s - New File window is a matter of bad design as well. Rather than carefully using the space in that huge window to make all relevant items that can be created clearly visible, you’ll easily find yourself in a situation where you see scrolling views and many subitems which makes things look much more complicated than they really are.
Other things that regularly drive my nuts in the new Interface Builder are that it seems even worse at dealing with localisations than its predecessors (easy switching between different language versions of the same UI element would seem like an obvious thing to do), that it makes it ridiculously non-obvious how to instantiate one of your own classes in a nib file and that its bindings editor still sucks full time (no good preservation of what you enter, no help autocompleting key paths and no friggin’ way to make the Inspector window wide enough to even see your full key path, FAIL, FAIL, FAIL) which makes other points like the new icons for nib and xib files that simply don’t stand out in your XCode file list and thus needlessly hard to find seem minor in comparison.
Uh, and Interface Builder’s pseudo HUD, small, overly auto-scrolling action method selection window is probably something for which you want a copy of the HIG engraved in some hard material just so you can slap the people who implemented this with it.
Documentation
Apple have a proud history of shipping all that nice Cocoa stuff and giving us sub-standard documentation and examples along with it. My impression is that this situation has improved a little but hasn’t changed fundamentally yet.
The problem with this is that it can waste a lot of time or create sufficient frustration to simply discourage people - particularly those of us who’re only in this for the fun - from trying things. In many places of Cocoa the behaviour of the framework is un(der)-defined by the documentation. Be it because Apple are too stingy to have more exhausting documentation written as they don’t care about their developers or because they don’t know themselves. Giving Apple the benefit of the doubt one could hope that the people working there and making the frameworks actually know those details and can explain them. Then please make them share that knowledge, it will save time over and over again around the world!
Then there are small things in XCode’s documentation browser which could be smoother. Say, when I’m entering NSMenuItem into the search field I keep getting the legacy NSMenuItem protocol as the first result. I am even warned about this being a deprecated way of doing things and (after scrolling) I’ll get a link to the new class, but wouldn’t things be, um, useful if the Help gave me the thing I’m looking for right away?
Another aspect of documentation - which is quite ‘in character’ for Apple, though - is that it’s not very candid about what doesn’t work. This kind of information can be tremendously helpful as it keeps people from wasting time trying things that are hopeless. What about a comprehensive guide to all Cocoa controls indicating which of them can realistically be used with Bindings, say?
The final point are examples. Many people, including myself, find examples a very valuable form of documentation as they don’t just theorise about the frameworks but show you how things are done. With a bit of luck you can even nick some code from them. In some areas (Quartz Composer, Audio?) the examples seem to be quite comprehensive and give you a good starting point for not just using those technologies in a simple way but really digging into them. In other areas, however (CoreData and Bindings come to mind), the examples are far from covering the whole problem space. I think that having more of them could make learning the underlying technologies much easier (particularly for ‘magic’ technologies like CoreData which you are not going to understand fully).
Code Signing
MacOS X.5 is full of technology for code signing. It has good and bad sides. Let me discuss what it does first.
The essential idea for code signing is to authenticate an application. A developer can create a certificate and sign his application. While - just as with encryption certificates - it takes quite a bit of extra effort to make sure such a signature really authenticates the developer, this at least gives you a way to determine whether two different versions of an application originated from the same developer (modulo the developer’s incompetence at handling his certificate, that is).
Mac OS X.5 already uses this in a number of ways. The best one of them is the keychain. If an application has been signed by the developer and you allow that application to access your keychain, the keychain will now remember not just the application and its version but the developer’s certificate. If you download an update for the application, the keychain will recognise that it has been signed by the same developer and the application will be granted access to the keys without further ado. This means there is one less annoying dialogue asking the user for permission to access the keychain. Which makes it more likely that users will take those requests seriously when they do appear. It’s a good thing.
Other areas where Mac OS X.5 uses code signing is for its firewall and its nanny mode. In the latter, code signing is used more destructively: Rather than letting people execute any code, only certain ‘trusted’ applications which are pinned down by the signatures of their developers (or the signatures OS X.5 adds if there is none) are allowed to accept network connections or to be used by the kids.
Obviously things easily become a bit creepy once we venture in this direction. For example because of the automated code signing by the OS, applications can be modified without you really knowing about it. And obviously once you have these technologies in place for the good intentions they are also easily available for bad ones.
I suppose the iPhone is a prominent example for this. Essentially it’s Apple’s decision whose code can run on the iPhone. That toy is not a computer at all but a highly controlled environment. Apple dictates its rules and it will be interesting to see when the first applications are found to be against Apple’s arbitrary terms and conditions and will be banned from iPhones. Would instant messaging be fine? Would route planning be OK for third party software on the iPhone or did Apple make an ‘exclusive’ contract with some software company for that already? Is porn in or out? And if it’s out, who gets to decide what porn is? Is VoIP OK? Or an application displaying The Guardian? Or one displaying Fox News for that matter? Do we really want someone else deciding which software may run and which doesn’t?
Well, the iPhone and Mac OS X.5 have the technology to censor away. Currently it’s a mere possibility but what will happen in X.6, .7, .8? We don’t know. The code signing doesn’t seem to be fully documented yet (another aspect which makes this a bit creepy) so the full power isn’t entirely clear at the moment. But it appears that using the codesign utility you can sign pretty much everything from a Unix command line tool to a OS X bundle. And the detailed settings appear to give finely levelled control about which parts of a bundle are covered by the signature. When will applications start trying to refuse running when their signature isn’t matched? When will frameworks which Apple ship but don’t want other applications to use simply fail to initialise when the application using them hasn’t been signed by Apple?
We’ll have to see how this plays out. If I am not mistaken they have done a similar thing on Windows for ages with drivers. Whenever a hardware company doesn’t cough up the money for Microsoft’s certification and a driver is installed some dialogue box comes up asking people whether they really want to continue installing an unsigned driver. I haven’t watched many Windows users but none of those I saw seemed to even register that warning, they just dismissed it because that’s the natural thing to do. Which to me means that if signing technology is to have any practical effect it has to be drastic. Things need to not work when they are not signed. And that’s a bit of a scary prospect as it makes a completely walled in computing experience - one that one wouldn’t consider a computing experience at all in some classical sense - seem quite realistic.
Interesting question: Does XCode support convenient code signing yet? There is a field for entering the key to use for singing in the build target inspectors. But entering something there never did much for me. When compiling the project with the xcodebuild command, however, it looked like a signature was created.
