This is an insightful 2005 article by John Siracusa on the lessons from Copland, Apple’s attempt to turn Classic Mac OS into something modern, and predictions/advice for Mac OS X on future-proofing:

Avoiding Copland 2010

This is a follow-up article where the author re-visited his predictions:

Copland 2010 revisited: Apple’s language and API future

And now we have Apple introducing a new language: Swift

https://developer.apple.com/swift/

Introducing a new language is interesting. We have Dylan (failed), Dart (maybe), Go (doing quite well), and Rust as “modern” mainstream languages aimed at replacing some previous language. Objective-C is only successful because the iPhone and iPad are successful.

From the xcode-users mailing list:

> My app built with Xcode on 10.9 won’t launch on 10.7, but I don’t use any new OS features.

The most likely cause of your problem is base internationalization. Newly created Xcode projects have base internationalization turned on, but base internationalization works only on OS X 10.8 and later.

To support 10.7, turn off base internationalization. Select your project from the project navigator to open the project editor. Select your project from the left side of the project editor. Deselect the Use Base Internationalization checkbox.

http://harlanhaskins.com/2014/03/02/laying-out-ios-uis-in-code.html

https://github.com/alexbw/novocaine

This is the code used by the author (Alex Wiltschko) in several cool iOS apps that he released last year. I don’t know anything about the code yet, it’s on my list of things to look at, but the apps are cool.

Oh, and there’s also

http://theamazingaudioengine.com/

which I haven’t looked at either, yet.

http://garylarizza.com/blog/2013/01/20/using-veewee-to-build-os-x-vms/

http://grahamgilbert.com/blog/2013/08/23/creating-an-os-x-base-box-for-vagrant-with-packer/

http://www.vagrantup.com/

http://www.vagrantup.com/vmware

http://blogs.vmware.com/teamfusion/2013/04/using-vmware-fusion-with-vagrant-to-speed-software-development.html

http://puppetlabs.com/blog/new-vmware-provider-gives-vagrant-a-boost

http://dyli.sh/2013/08/23/OSX-Vagrant-Docker-Sinatra.html

I always forget how to do this, and fortunately Google and Stack Exchange have my back

defaults write com.apple.Finder AppleShowAllFiles YES; killall -HUP Finder

If by some reason you want the default behavior back, set AppleshowAllFiles back to NO (or False, either works).

http://apple.stackexchange.com/questions/58709/how-can-i-view-hidden-files-in-the-finder

Caroline Rose created some of the best technical documentation ever with the Inside Macintosh volumes. The Macintosh, like the Lisa, had a radically different programming architecture – it was event-driven rather than structured or procedural. And so, the documentation had to not just describe the Macintosh APIs, but also to put them in context so that people could make the shift. It didn’t try to teach event-driven programming, but it did constantly talk about how various parts of the system should be used.

PDFs of the original three volumes are online here:

http://www.weihenstephan.org/~michaste/pagetable/mac/Inside_Macintosh.pdf

It’s worth looking at if you are writing technical documentation of your own. You could go far worse than to try to emulate this style.

And to put the size of the documentation in context – there was 64KB of ROM, and 128KB of RAM, in the first Mac that shipped, and this was covered with about 1200 pages of documentation. For a modern system that encompasses millions of lines of code – either we write code much less tightly than Apple did back in 1984, or we don’t document it nearly well enough.

Oh, and I say Caroline Rose, because my understanding is that she wrote a lot of the first three volumes of Inside Macintosh, and even had an impact on the software by trying to document it (“Her systematic approach to clarity also helped internal Apple developers who, thanks to Caroline remarks, sometimes rewrote their software improving it substantially”). Here are some links:

• http://www.folklore.org/ProjectView.py?name=Macintosh&characters=Caroline%20Rose
• http://www-sul.stanford.edu/mac/primary/interviews/rose/trans.html
• http://www.storiesofapple.net/interview-with-caroline-rose.html

Uninstalling Xcode

Xcode 1 through Xcode 4.2

Before Xcode 4.3, uninstalling means running a script. Assuming you installed Xcode to /Developer, you would do this

brian-mac-pro:bfitz$ sudo /Developer/Library/uninstall-devtools --mode=all

This actually runs a handful of other scripts to uninstall the various pieces that the Xcode installer put on your system, and in looking at the scripts, they are really wrappers for pkgutil invocations to remove files and package receipts.

Xcode 4.3 and up

As of Xcode 4.3, it is self-contained – uninstalling Xcode is a matter of throwing away Xcode.app. Mostly; if you install separate command-line tools, those need to be uninstalled by hand – or by script, and you can find a script here that will uninstall them: http://www.cocoanetics.com/2012/07/you-dont-need-the-xcode-command-line-tools/; said script uses the package receipts and lsbom to find and remove all the files in the package. Note that this isn’t really the “right” way to do this, instead you’re supposed to be discovering and iterating through pkgutil.

Note that you don’t actually need to install the separate command-line tools, if you’re willing to use the ones located inside the Xcode.app bundle; you use xcrun to find and run one, for example, xcrun git would find and run /Applications/Xcode.app/Contents/Developer/usr/bin/git, assuming that your Xcode is in /Applications.

Xcode is mostly free, but it’s large – it occupies multiple gigabytes on your hard disk. If you just want to build code and just want compilers and SDKs, it’s a lot of overhead.

Several years ago, Kenneth Reitz put together a cut-down version that was Xcode minus Xcode – basically GCC and all the headers and libraries that weren’t Apple-licensed. He called this OSX-GCC-Installer, hosted it on GitHub, and it became fairly popular. It became popular enough that people from Apple became interested in it, and eventually Apple released Command Line Tools for Xcode. It’s free, although it does require an Apple ID to download it.

Links

• http://kennethreitz.org/experiments/xcode-gcc-and-homebrew
• https://github.com/kennethreitz/osx-gcc-installer/
• http://stackoverflow.com/questions/9329243/xcode-4-4-command-line-tools

With Mac OS X, Apple started out in the GUI world, but over time has transitioned to a more traditional Unix world with command-line tools, but without forcing this on most users. For example, you can perform and access install information via the command-line as well as through the GUI programs Apple supplies.

The standard on Mac OS X is “the package”, and this is for atomic entities, such as applications, libraries and frameworks. Installers add packages to the system; users run them (a .app is a folder that is a package that masquerades as a file).

The pkgutil command-line program gives you access to information about installed packages. man pkgutil tells us a little bit:

pkgutil(1)		  BSD General Commands Manual		    pkgutil(1)

NAME
     pkgutil -- Query and manipulate Mac OS X Installer packages and receipts.

SYNOPSIS
     pkgutil [options] [commands]

DESCRIPTION
     pkgutil reads and manipulates Mac OS X Installer flat packages, and pro-
     vides access to the ``receipt'' database used by the Installer. Options
     are processed first, and affect the operation of all commands. Multiple
     commands are performed sequentially in the given order.
...

First off, you can just get a list of all the packages installed to a specific volume. For the most part, packages are installed to the root volume /, and if you don’t pass in a –volumes option, pkgutil will default to /.

brian-mac-pro:~ bfitz$ pkgutil --packages
com.apple.MacOSX.lang.ar
com.apple.MacOSX.lang.cs
...
com.apple.MacOSX.lang.zh_CN
com.apple.MacOSX.lang.zh_TW
...
com.apple.pkg.BSD
com.apple.pkg.clangLeo
com.apple.pkg.CoreAudioSDKLeo
com.apple.pkg.CoreFP
com.apple.pkg.CoreFP1
com.apple.pkg.DeveloperToolsCLILeo
com.apple.pkg.DeveloperToolsSystemSupportLeo
...
com.apple.pkg.XcodeEssentialsSystemSupportLeo
com.apple.pkg.XcodeUserSystemSupportLeo
com.apple.pkg.xcrunLeo
GitOSX.Installer.git182.etc.pkg
GitOSX.Installer.git182.git.pkg
brian-mac-pro:~ bfitz$ pkgutil --packages | wc
      87      87    2549

My Mac currently has 87 packages installed on it (I don’t install a lot of things, sorry).

You can list packages that match a pattern – for example, to find all packages with the string Xcode:

brian-mac-pro:~ bfitz$ pkgutil --pkgs=.\+Xcode.\+
com.apple.pkg.InstallXcodeLion
com.apple.pkg.XcodeEssentialsSystemSupportLeo
com.apple.pkg.XcodeUserSystemSupportLeo

The trick with the regular expression is that it must cover the entire name, there’s an implied start and end anchor applied to the regex, and you need to escape characters that the shell might interpret (like <, +, \ and so on). For example, if your regex needs a backslash, then you need a backslash for that backslash.

One of the most useful commands is “I have a file on my hard disk, what installed it”. For example, something installed git to /usr/bin/git – what was it?

brian-mac-pro:~ bfitz$ pkgutil --file-info /usr/bin/git
volume: /
path: /usr/bin/git

pkgid: com.apple.pkg.DeveloperToolsCLILeo
pkg-version: 1.0.0.9000000000.1.1249367152
install-time: 1316396966
uid: 0
gid: 0
mode: 755
brian-mac-pro:~ bfitz$

Evidently, when I said “install command-line versions of tools” in Xcode, it installed git to the global system folder. So, what else did it install? The –files option lists all the files installed by a package, and –only-files makes it list just the files, not the directories that were created to hold those files.

brian-mac-pro:~ bfitz$ pkgutil --only-files  --files com.apple.pkg.DeveloperToolsCLILeo
Library/Developer/4.0/distcc/distcclaunchdconfig
usr/bin/BuildStrings
usr/bin/CpMac
usr/bin/DeRez
usr/bin/GetFileInfo
...
usr/etc/distcc/hosts
usr/lib/libgmalloc.B.dylib
usr/lib/libltdl.a
usr/libexec/gcc/darwin/i386/as
usr/libexec/gcc/darwin/x86_64/as
usr/libexec/gdb/gdb-i386-apple-darwin
usr/libexec/git-core/git
..
usr/share/aclocal/argz.m4
usr/share/aclocal/bison-i18n.m4
usr/share/aclocal/libtool.m4
...
brian-mac-pro:~ bfitz$ pkgutil --only-files  --files com.apple.pkg.DeveloperToolsCLILeo | wc
    1852    1856  102002

It installed 1852 files, and the files are as expected, command line programs and man pages and even a suite of test code.

You can get more information about a package with –pkg-info.

brian-mac-pro:~ bfitz$ pkgutil --pkg-info com.apple.pkg.DeveloperToolsCLILeo
package-id: com.apple.pkg.DeveloperToolsCLILeo
version: 1.0.0.9000000000.1.1249367152
volume: /
location: /
install-time: 1316396966
groups: com.apple.FindSystemFiles.pkg-group com.apple.DevToolsBoth.pkg-group com.apple.DevToolsNonRelocatableShared.pkg-group
brian-mac-pro:~ bfitz$ date -r 1316396966
Sun Sep 18 18:49:26 PDT 2011

The install-time flag is in Unix seconds (seconds since 1970), which I turned into a human-readable date with the date command-line tool, so you can see that I installed this package (which came from an install of Xcode) on September 18, 2011.

Here we see that com.apple.pkg.DeveloperToolsCLILeo is part of several groups, and we can discover what other packages are in a group by using –group-pkgs:

brian-mac-pro:~ bfitz$ pkgutil --group-pkgs com.apple.DevToolsBoth.pkg-group
com.apple.pkg.clangLeo
com.apple.pkg.DeveloperToolsCLILeo
com.apple.pkg.gcc4.2Leo
com.apple.pkg.llvm-gcc4.2Leo
com.apple.pkg.X11DocumentationLeo

Of course, at this point you’re reverse-engineering what some developer has as their plan for how to organize software, and you’re not likely to find this documented anywhere.