Very Web. Such Blog. Wow.

I was recently banging my head against a problem trying to add a SwiftUI view into my existing AppKit using NSHostingView. The basic problem was that it seemed no matter what I did, I couldn’t get my SwiftUI view to expand to fill up the entire superview that the NSHostingView was being added to. The basic layout of the SwiftUI view looks like this.

struct IPReportDetailView: View { var body: some View { VStack(spacing: 20.0) {   Text(selectedReport.title) .font(.headline)   IPReportView(reportDocument: selectedReport)   Spacer()   } } }

And the setup of the NSHostingView looked like this:

class IPReportListViewController: BWViewController { lazy var reportListViewModel: IPReportListViewModel = IPReportListViewModel(reports: IPReportDocument.allStoredReports()) override func loadView() { let reportListMainView = IPReportListSplitView(reportListViewModel: self.reportListViewModel, selectedReport: self.reportListViewModel.reports.first) let hostingView = NSHostingView(rootView: reportListMainView)

hostingView.translatesAutoresizingMaskIntoConstraints = false //Green border so we can see the bounds of the hosting view hostingView.layer?.borderWidth = 1.0 hostingView.layer?.borderColor = NSColor.green.cgColor self.view = hostingView } }

Both the Text and IPReportView views have fixed heights, and the usual trick if you want a VStack to expand to fill the rest of its parent is to add a Spacer view to the end, which will gobble up any remaining space. However, this was not working at all, and ended up looking like this.

Despite the presence of the Spacer, the NSHostingView insists on shrinking down to fit the fixed size of the rest of the VStack. In the process of trying to figure out what’s going on, I came across this blog post from objc.io with a technique for printing out the size being proposed to your view by SwiftUI. You can read the blog post if you want to see the details of how it works, but the short version is that each time SwiftUI proposes a size to your view, this code will print out both the proposed size, then also the size that ends up being returned by SwiftUI that the view should actually use. I added their view modifier to my VStack and got output that looked like this (the first size is the proposed size, the second one is the size returned by SwiftUI).

Detail VStack: 0.00⨉0.00 656.00⨉48.00

Detail VStack: inf⨉inf 656.00⨉inf

Detail VStack: nil⨉nil 656.00⨉454.00

Detail VStack: 656.00⨉454.00 656.00⨉454.00

Detail VStack: 656.00⨉454.00 656.00⨉454.00

To be honest, I couldn’t really make heads or tails of this, since it seemed to be doing multiple size proposals every time my view refreshed. I took that as a dead end and started investigating other options.

The next thing I came across was a property on NSHostingView called ‘sizingOptions’, which is described in the documentation as "The options for how the hosting view creates and updates constraints based on the size of its SwiftUI content.” Well that sounds promising! The default setting is all three options, [.minSize, .intrinsicContentSize, .maxSize], so I tried setting it to just [.minSize] and lo and behold, it worked! The Spacer was now growing to take up the whole height of the superview! (setting [.minSize, .maxSize] also worked)

But, there’s just one problem… this property was introduced in macOS 13 and I’m still targeting macOS 12. 😭 But, after seeing this property and how it works, I think I now understand what was going on with the size proposals earlier. I believe what NSHostingView does is to probe its rootView once each so it can set up constraints for a minimum size, intrinsic content size, and maximum size. Proposing a size of 0x0 lets it determine the view’s minimum size, proposing infinity x infinity lets it determine a maximum size, and proposing nil x nil determines the intrinsic content size.

So what I need to do is basically reimplement what the sizingOptions property is doing, which is to ignore the intrinsic content size of the SwiftUI view. To do that, I created a subclass of NSHostingView and overrode the intrinsicContentSize property like so:

class IPReportHostingView<Content: View>: NSHostingView<Content> { override var intrinsicContentSize: NSSize { var size = super.intrinsicContentSize   size.height = NSView.noIntrinsicMetric   return size } }

As outlined in WWDC ’23’s “What’s New In Privacy” session and the sandbox documentation:

In macOS 14 and later, the operating system uses your app’s code signature to associate it with its sandbox container. If your app tries to access the sandbox container owned by another app, the system asks the person using your app whether to grant access. If the person denies access and your app is already running, then it can’t read or write the files in the other app’s sandbox container. If the person denies access while your app is launching and trying to enter the other app’s sandbox container, your app fails to launch.

The motivation behind this change is very understandable, to make sure the user has control over what apps on their system access other apps data, as well as ensuring that one app doesn’t try to pose as another one. However, in my opinion there are a couple major issues with the way this is implemented in the macOS Sonoma beta seeds thus far. When you launch an app that tries to read another app’s sandbox container, this is the message that is presented:

Note that the second message shown there can be defined by the running app’s developer (PowerPhotos in this case) by adding a “NSAppDataUsageDescription” key to your Info.plist file. (this key is not yet documented yet, but was confirmed by an Apple employee on their developer forums).

There are two main issues here:

The top message in the prompt doesn’t tell the user which app’s data is being read. In this case, my NSAppDataUsageDescription string explains what PowerPhotos is reading, but there’s no actual relation between that message and what files are actually being read. In other words, a malicious app can easily lie to the user here.

Unlike most of macOS’ security prompts, this one is displayed every single time the user launches your app, regardless of whether they’ve granted permission in the past. Not only is this just annoying, but this will quickly train the user to dismiss these prompts without reading them, which undercuts the whole purpose of the feature in the first place.

I’ve filed a Feedback (FB12473837) with Apple that basically suggests that these prompts should work more along the line of the existing “Automation” prompts, which are triggered when one app sends an Apple event to another app. The way it would work is:

The system should only ask once per combination of running app/sandboxed app (prompting again if either app's code signature changes).

The sandboxed app should be named in the message that’s displayed to the user. 

The results of these choices should be controllable via the Privacy & Security section of the System Settings app.

That way, the user doesn’t need to click through prompts every single they time they open a particular app, and it gives them additional control over which sandboxed apps data they want to allow or deny access to.

I was a happy user of both Twitteriffic and Tweetbot on both Mac and iOS for many years, until of course Elon burned everything to the ground and kicked out all the third party Twitter clients. 

I’ve moved over to Mastodon now, and while there are several decent Mastodon apps on the Mac, most of them are designed for iOS first and lack one of my favorite features from both Twitteriffic and Tweetbot: a global keyboard shortcut that will bring your timeline window forward to read, then hide it again when you’re done.

Until my favorite feature gets implemented by the apps, in the meantime I’ve come up with a solution using AppleScript to get the same effect. I thought others might find it useful, so here’s how to do it if you want.

1. First you’ll need something to handle the global keyboard shortcut. My tool of choice is FastScripts, but any app that lets you trigger an AppleScript with a global keyboard shortcut will suffice.

2. Open Script Editor, paste in the following script, and save it in ~/Library/Scripts so FastScripts will include it in its script menu. The following script is using the app Ivory, but you can replace the “Ivory” name with whatever Mastodon app you’re using.

tell application "System Events"   if exists process "Ivory" then     tell process "Ivory"       if visible then         set visible to false       else         tell application "Ivory" to activate       end if     end tell   end if end tell

3. Use the FastScripts preferences window to assign your preferred keyboard shortcut to run this script.

I’ve recently been dipping my toes into SwiftUI for the first time, with my first project being a document based app using the SwiftUI lifecycle. This post assumes you’re already familiar with the basics of writing a document based SwiftUI app.

My app lets you drag multiple photos into a document and has a basic photo browser for viewing the photos and various control for doing stuff with them. It has its own document type which is saved as JSON data, and that JSON contains URLs that reference the photo files that you dragged into the document. That all is relatively straightforward, and here is the basic code for my document.

struct MyDocument: FileDocument { var documentData: DocumentData static var readableContentTypes: [UTType] { [.myDocumentType] } init(configuration: ReadConfiguration) throws { guard let data = configuration.file.regularFileContents else { throw CocoaError(.fileReadCorruptFile) } let jsonDecoder = JSONDecoder() self.documentData = try jsonDecoder.decode(DocumentData.self, from: data) } func fileWrapper(configuration: WriteConfiguration) throws -> FileWrapper { let encoder = JSONEncoder() let data = try encoder.encode(self.documentData) return .init(regularFileWithContents: data) } }

And the relevant part of the data model:

struct DocumentData: Codable { var photos: [Photo] } struct Photo: Codable { let url: URL }

Where I hit a road bump was that I wanted the user to be able to drag multiple photo files from the Finder and drop them onto my dock icon, and have that open a new, untitled document that’s already populated with those photos. SwiftUI isn’t really set up for that scenario, so I had to try a few things before finding one that worked.

First, to get the dock icon to accept dropped image files, I added a new document type in the Info pane for my app target in Xcode, specifying “public.image” so it will accept any image formats, and a role of “Viewer”, since I’m not actually editing the photos themselves. Then, if I added .image to the list of readableContentTypes in my document, that would result in SwiftUI trying to open a separate document for each photo that was dragged to the app icon. That’s not what I want though, I want all the photos to go into a single document.

My next attempt was to see if I could handle the dropped files in my app delegate that I have set using SwiftUI’s @NSApplicationDelegateAdaptor property wrapper on my App instance. I tried implementing the application(_:openURLs:) method, and after removing the .image type from my document (so that SwiftUI would no longer route the dropped images there), it did call my app delegate. Yay!

Now I needed to actually create the new document. You can’t do this by directly calling SwiftUI, but all the SwiftUI stuff is handled using the underlying NSDocument architecture in AppKit, so this was my first stab at it:

func application(_ application: NSApplication, openURLs: [URL]) { do { let photos = urls.map { Photo(url: $0) } let documentData = DocumentData(photos: photos) let encoder = JSONEncoder() let encodedData = try encoder.encode(documentData) let fileWrapper = FileWrapper(regularFileWithContents: encodedData) let newDocument = try NSDocumentController.shared.openUntitledDocumentAndDisplay(true) try newDocument.read(from: fileWrapper, ofType: UTType.myDocumentType.identifier) } catch let error as NSError { NSApplication.shared.presentError(error) }

I ran this, but soon discovered that even though the delegate method accepts multiple URLs as input, and in a normal AppKit app a single drop of multiple files would all be passed at once, SwiftUI was still doing its thing behind the scenes and calling the delegate method multiple times with one URL passed each time. This resulted in multiple documents opening up, each with a single photo.

So, like so many things in SwiftUI, we need to do a dirty little hack to collect all the URLs we want before opening the document, like so.

var urlsBeingOpened: [URL]? = nil func application(_ application: NSApplication, open urls: [URL]) { //We start collecting URLs and set up a timer to fire the next time through the run //loop after we stop receiving URLs. if urlsBeingOpened == nil { self.urlsBeingOpened = [] Timer.scheduledTimer(withTimeInterval: 0.1, repeats: false) {_ in self.createDocumentFromOpenedURLs() } } self.urlsBeingOpened?.append(contentsOf: urls) } func createDocumentFromOpenedURLs() { do { guard let urls = self.urlsBeingOpened else { return } self.urlsBeingOpened = nil //reset the collection for the next drop let photos = urls.map { Photo(url: $0) } let documentData = DocumentData(photos: photos) let encoder = JSONEncoder() let encodedData = try encoder.encode(documentData) let fileWrapper = FileWrapper(regularFileWithContents: encodedData) let newDocument = try NSDocumentController.shared.openUntitledDocumentAndDisplay(true) try newDocument.read(from: fileWrapper, ofType: UTType.myDocumentType.identifier) } catch let error as NSError { NSApplication.shared.presentError(error) }}

Since SwiftUI calls our delegate method multiple times in a tight loop, we use an instance variable to collect all the URLs into an array, and fire off a one-shot timer that triggers the next time through the run loop after SwiftUI is done giving us all the URLs. That lets us take all the URLs and create a single document from them there. Note the use of a FileWrapper to pass the encoded document contents to the document for reading. I initially tried just passing a plain Data object to NSDocument to read, but apparently SwiftUI doesn’t implement that reading method, but putting it in a FileWrapper did the trick.

I just figured out how to solve a problem in Xcode that’s vexed me for a number of years, and thought I’d share. The problem is that I usually have Xcode’s built-in “All Exceptions” breakpoint enabled when debugging my application, but when I run unit tests in Xcode, I have certain unit tests that will throw exceptions and trigger the breakpoint, halting the test until I tell it to continue. So far my only solutions have been to babysit the unit test while it runs and click “Continue” when it halts, or disable the “All Exceptions” breakpoint, which I inevitably forget to turn back on when I go back to debugging my app normally. (This is a test bundle that runs with a host application, so the whole app gets launched when running the unit tests)

The solution I’ve found goes like this. First, I wrote a function in my app that will tell me whether I’m in a unit testing environment. The best method I’ve found for this from Stack Overflow looks like this:

func BWIsUnitTesting() -> Bool { return NSProcessInfo.processInfo().environment["XCTestConfigurationFilePath"] != nil }

Then, open up the breakpoints navigator in Xcode, right-click on the exceptions breakpoint, and add !BWIsUnitTesting() to the “Condition” field, like this:

When reading Gus Mueller’s post about how the presence of Marzipan might interact with Apple potentially transitioning to ARM processors, he mentioned that moving to a new architecture is a nice time to drop legacy frameworks and make a clean break with backward compatibility. This got me curious: how many frameworks currently on macOS could actually be dropped altogether?

So I dove into the Frameworks folder in the latest macOS SDK and found a total of 147 frameworks listed there. Yikes! I went down the list and wrote down which ones I think could reasonably be jettisoned on an architecture switch (note that there would also be many APIs within various frameworks that could be tossed too, even if the framework as a whole sticks around). Here’s the full list of all the frameworks:

Accelerate.framework Accounts.framework AddressBook.framework AdSupport.framework AGL.framework AppKit.framework AppKitScripting.framework AppleScriptKit.framework AppleScriptObjC.framework ApplicationServices.framework AudioToolbox.framework AudioUnit.framework AudioVideoBridging.framework Automator.framework AVFoundation.framework AVKit.framework BusinessChat.framework CalendarStore.framework Carbon.framework CFNetwork.framework CloudKit.framework Cocoa.framework Collaboration.framework ColorSync.framework Contacts.framework ContactsUI.framework CoreAudio.framework CoreAudioKit.framework CoreBluetooth.framework CoreData.framework CoreDisplay.framework CoreFoundation.framework CoreGraphics.framework CoreImage.framework CoreLocation.framework CoreMedia.framework CoreMediaIO.framework CoreMIDI.framework CoreMIDIServer.framework CoreML.framework CoreServices.framework CoreSpotlight.framework CoreTelephony.framework CoreText.framework CoreVideo.framework CoreWLAN.framework CryptoTokenKit.framework DirectoryService.framework DiscRecording.framework DiscRecordingUI.framework DiskArbitration.framework DrawSprocket.framework DVComponentGlue.framework DVDPlayback.framework EventKit.framework ExceptionHandling.framework ExternalAccessory.framework FinderSync.framework ForceFeedback.framework Foundation.framework FWAUserLib.framework GameController.framework GameKit.framework GameplayKit.framework GLKit.framework GLUT.framework GSS.framework Hypervisor.framework ICADevices.framework ImageCaptureCore.framework ImageIO.framework IMServicePlugIn.framework InputMethodKit.framework InstallerPlugins.framework InstantMessage.framework Intents.framework IOBluetooth.framework IOBluetoothUI.framework IOKit.framework IOSurface.framework iTunesLibrary.framework JavaFrameEmbedding.framework JavaScriptCore.framework JavaVM.framework Kerberos.framework Kernel.framework LatentSemanticMapping.framework LDAP.framework LocalAuthentication.framework MapKit.framework MediaAccessibility.framework MediaLibrary.framework MediaPlayer.framework MediaToolbox.framework Message.framework Metal.framework MetalKit.framework MetalPerformanceShaders.framework ModelIO.framework module.map MultipeerConnectivity.framework NaturalLanguage.framework NetFS.framework Network.framework NetworkExtension.framework NotificationCenter.framework OpenAL.framework OpenCL.framework OpenDirectory.framework OpenGL.framework OSAKit.framework PCSC.framework Photos.framework PhotosUI.framework PreferencePanes.framework Python.framework QTKit.framework Quartz.framework QuartzCore.framework QuickLook.framework QuickTime.framework Ruby.framework SafariServices.framework SceneKit.framework ScreenSaver.framework Scripting.framework ScriptingBridge.framework Security.framework SecurityFoundation.framework SecurityInterface.framework ServiceManagement.framework Social.framework SpriteKit.framework StoreKit.framework SyncServices.framework System.framework SystemConfiguration.framework Tcl.framework Tk.framework TWAIN.framework UserNotifications.framework VideoDecodeAcceleration.framework VideoSubscriberAccount.framework VideoToolbox.framework Vision.framework vmnet.framework WebKit.framework

Out of those, I figure the following 27 can probably be chucked:

AddressBook (replaced by Contacts)

AGL (OpenGL deprecated)

AppleScriptKit (Part of AppleScript Studio, which let you write Cocoa apps in AppleScript. No, really.)

CalendarStore (replaced by EventKit)

CoreTelephony (replaced by CallKit)

DirectoryService (replaced by OpenDirectory)

DiscRecording (LOL disc burning)

DiscRecordingUI

DVDPlayback (they’re gonna add Blu-ray support any day now)

FWAUserLib

GLKit (OpenGL deprecated)

GLUT (OpenGL deprecated)

ICADevices (replaced by ImageCaptureCore)

IMServicePlugin

InstallerPlugins

InstantMessage

iTunesLibrary (hopefully they’d bring AssetLibrary.framework over from iOS)

JavaFrameEmbedding

JavaVM

MediaLibrary (hopefully replaced by AssetLibrary + PhotoKit)

OpenCL (OpenCL deprecated)

OpenGL (OpenGL deprecated)

QTKit

QuickTime (so long little buddy 😢)

SafariServices

Social

SyncServices (and you thought iCloud Core Data was bad! 🐝🐝🐝)

  That’s actually not that many, all things considered! But then, looking through this rather long list of frameworks, I started wondering: how many frameworks were present in the initial release of Mac OS X 10.0? I couldn’t dig up a list for 10.0, but some enterprising individual created a repository on Github with all the macOS SDKs back to version 10.1.5. There were 41 frameworks in that SDK:

  AGL.framework AppKit.framework AppKitScripting.framework AppleScriptKit.framework AppleShareClient.framework (no longer present, probably dumped during the PPC->Intel) AppleShareClientCore.framework (no longer present) AppleTalk.framework (no longer present) ApplicationServices.framework AudioToolbox.framework AudioUnit.framework Carbon.framework Cocoa.framework CoreAudio.framework CoreFoundation.framework CoreMIDI.framework CoreMIDIServer.framework CoreServices.framework DVComponentGlue.framework DirectoryService.framework DrawSprocket.framework ExceptionHandling.framework Foundation.framework GLUT.framework IOKit.framework InterfaceBuilder.framework JavaEmbedding.framework JavaVM.framework Kerberos.framework Kernel.framework LDAP.framework Message.framework OpenGL.framework PCSC.framework PreferencePanes.framework QuickTime.framework ScreenSaver.framework Scripting.framework Security.framework System.framework SystemConfiguration.framework vecLib.framework (got moved into Accelerate.framework)

A new story was published on Bloomberg this morning outlining rumored Apple plans to further unify the Mac and iOS platforms to make it easier for developers to offer apps for both. In their words:

Starting as early as next year, software developers will be able to design a single application that works with a touchscreen or mouse and trackpad depending on whether it’s running on the iPhone and iPad operating system or on Mac hardware, according to people familiar with the matter.

This leaves open a lot of questions about how exactly this would work, though, that aren’t covered by the story. Coming from the Mac side of things, I’ve been skeptical for years about continued speculation that Apple would eventually unify the two operating systems. I still don’t think a complete merger will ever happen, but there are a number of places on the spectrum between the current state of things and a full merge that could be viable. There are few levels of integration that I could think of here.

1. The simplest thing that Apple could do would be to allow users to purchase an app once and receive both the Mac and iOS version, rather than having to make separate purchases for each. This would basically mean a developer could link one of their Mac apps to the corresponding iOS app, and they would share receipts/credentials on the App Store (this could even include in-app purchases). The Bloomberg story points at something greater than this, but I think this step would make some sense even if the development side of things didn’t get unified right away.

2. On the opposite end of the spectrum, you basically have the “port UIKit to the Mac” crowd, which would basically let you take your existing iOS app and run it on the Mac with few or no changes. I don’t think this will be what happens, mostly due to the terrible user experience that would result. Have you ever tried actually using an iOS app in the Xcode simulator for any extended period of time? Yeah, it’s not good. So I think (hope!) Apple will do something more sophisticated than this.

3. An in between approach would involve taking some, but not all, elements of UIKit and related iOS frameworks and making them available on the Mac. The two platforms are different enough that taking the really high level stuff from UIKit (e.g. UIApplication) would not make any sense at all. After all, there are many things in iOS app development that just don’t apply on the Mac (e.g. handling rotation, backgrounding tasks… shake to undo?) and vice versa. Most of the pain points are usually in the UIView and UIViewController layers, since these basically have to be rewritten for their AppKit equivalents (e.g. NSView instead of UIView).

I could imagine a system that might work somewhat like the Carbon/Cocoa integration that Apple provided in the early OS X days, where you could do things like embed a Carbon view in a Cocoa view, mix Carbon and Cocoa windows in the same app, and so forth. There would still be some work to do for iOS devs to make their apps work well on the Mac, but I think this might be a good middle ground similar to Carbon, where 80% of the work is already done for you, and you’d just need to handle the extra hooks in order to have your iOS components behave inside a Mac environment.

One easy example of where this would be applicable is in extensions. To Apple’s credit, when they introduced extensions in iOS 8, they also brought the same technology to the Mac, with many (but not all) of the same extension points. However, anywhere you have to put up a user interface, such as when implementing a share extension, you still need to write both a UIKit and an AppKit version of that at the very least. For example, none of the sticker and special effect extensions that are on the iOS version of Messages are present on the Mac, and having some basic UIKit stuff available on the Mac might make this sort of thing more tenable to support cross platform.

As for x86 vs. ARM, while it’s possible that Apple could rig something so the UIKit bits would run on some sort of ARM coprocessor on the Mac (at this point I highly doubt it’s worth the time and effort for Apple to port all of macOS to ARM), I don’t think having to compile a separate Intel binary for the Mac version of an app would be too burdensome for developers. So, I would predict whatever happens it will probably still be Intel based.

4. And just for giggles, the pipe dream version of this would be an entirely new UI framework that supplants both UIKit and AppKit, acting as the new Cocoa to their Carbon. Of course it would be written from the ground up in Swift, and would produce rainbows and unicorns in addition to cross platform UI components. Given that Swift isn’t even ABI stable yet, I give this a snowball’s chance in hell of happening anytime soon, but it could be something to keep in mind down the road another 5-10 years.

With Apple's move of WWDC to San Jose, a lot of folks are wondering what all San Jose has to offer during the week they're in town. Being a local to the area, and spending a lot of time in downtown specifically, I thought I'd offer some recommendations for restaurants and attractions. These are just the places I know about myself, so it's not meant to be an exhaustive list, but hopefully this will give a good starting point for anyone looking to explore San Jose a bit. Note: now updated for 2018!

General advice

San Jose has different weather from San Francisco! It's quite a bit warmer down in the valley, and will typically be in the 70s or 80s in early June during the day. You might want a light jacket if you'll be out at night, but you almost certainly won't need one during the day. And if you plan on spending significant time outdoors, you'll probably want sunblock and/or a nice hat.

Like any city, San Jose has its share of "local color", shall we say, but is pretty darn safe overall. There's no section analogous to SF's Tenderloin area that is really a "do not go here!" zone.

Getting around

San Jose is not as dense as San Francisco, but the downtown core itself is fairly compact. You can do just fine walking around within a mile or two of the convention center and find most anything you need.

The VTA bus and light rail can get you around outside the downtown area, and of course Uber/Lyft is always an option. If you have a Clipper card from using the BART or Caltrain, you can use that to pay on VTA as well.

If you want to pop up to San Francisco before/after the conference, the easiest way to is to take the free DASH shuttle (weekdays only) or light rail to Diridon station, and then hop on the Caltrain up to SF.

The nearest Apple Store is at the Valley Fair mall, about 5 miles west of downtown. You can hop on either the 23 or 323 bus right outside the convention center and it will take you straight to the mall.

Ford GoBike provides a number of stations downtown with bikes you can rent and travel to other places around San Jose. Both LimeBike and Bird have plentiful dockless scooters and bikes you can tool around on as well.

Coworking

If you didn't get a golden ticket to WWDC but are coming to town for the week, and would like somewhere a bit less chaotic than a coffee shop to get some work done, check out Nextspace (full disclosure: I work out of Nextspace myself). You can get a free day pass to try it out, and buy further passes if you want to come back. There is also a WeWork location downtown, so if you have an existing membership at another location, you can easily set up camp there.

Running/biking

For those looking for somewhere to get in a run/bike ride, I recommend the nearby Guadalupe River Trail. From the convention center, just jog a block west on San Carlos and the trail entrance is on the north side of the street. The trail goes both directions, but I recommend heading north from there. The trail goes for many miles, and does have a couple places where it splits and rejoins, so do keep an eye out on your way back, as you may end up coming back on a different fork that you went out on. If you go far enough (about 6-7 miles) you can visit Lupe the Mammoth!

Groceries

If you have need to pick up any food or other grocery items, the Safeway at San Fernando and 2nd is your best bet. There used to be a Walgreens on 1st street which unfortunately closed a few weeks ago, so if you're in need of a pharmacy/drug store currently the CVS on The Alameda is probably your best bet.

Coffee

Straight to the important stuff! San Jose has several good coffee options, including:

Philz, a very popular pour-over coffee Bay Area chain

Social Policy is an excellent hang out spot with good coffee and eats.

The Forager (serving Devout coffee from Fremont)

B2 Coffee in San Pedro Market

Beers

Original Gravity House has a wide selection of beers on tap, along with a variety of homemade sausages and other foodstuffs.

ISO Beers has good variety at the tap, as well as several fridge cases of bottled beers and other yummy beverages. Also has a nice outdoor patio seating area.

Cocktails

Paper Plane is my favorite place for a good cocktail. They have a constantly changing menu, or the bartender will be glad to whip up something based on what your likes are. Their small plates are also very good, also a rotating menu, and I don't think I've ever had anything bad here.

Haberdasher is a fun downstairs cocktail bar with a 40s speakeasy feel going on. I've only been here once, but had a lovely custom cocktail and enjoyed it quite a bit.

Cafe Stritch also has a nice cocktail menu, good food, and features live jazz music Thursday through Sunday nights.

Pizza

Pizza My Heart is a popular South Bay chain, originating in Santa Cruz, featuring large slices with a wide variety of toppings. Make sure to try the Shark Repellent hot sauce!

Pizza Bocca Lupo makes a nice simple wood-fired pizza, and have a good lunch special with half a pizza and a salad.

Pizzetta 408 is another, newer wood fired pizza place that I haven't yet had a chance to try myself, but looks quite good, and is super close to the convention center.

Burritos

San Jose burritos are a bit different from SF mission burritos, and are all about their garlicky orange sauce. I can't get enough of the stuff. La Victoria is my go-to place for a burrito, and Iguanas (home of the Burritozilla!) is good too.

Vegetarian

There aren't a ton of strictly vegetarian places in downtown, but Good Karma is definitely a good option. Everything I've had from their menu has been good, and they offer a number of craft beers as well.

Breakfast/diner

Peggy Sue's and Johnny Rockets are the two popular diners downtown. Neither is particularly special, but has your typical diner fare.

There's no 24-hour diner right in the downtown core, the nearest such option being an IHOP about a mile up 1st St.

Bagels - nope 😭 

Other good food options

San Pedro Market is an open market with a variety of different eateries to choose from (crepes, Vietnamese, tacos, pizza, seafood, mediterranean, poke bowl, and so on), and a generous amount of both indoor and outdoor seating. This is a great place to go with a group, as everyone can split up and get food wherever they want, then meet up in the central seating area.

Taurinus Brazilian Steakhouse is a solid choice for those looking to recreate past years' WWDC Night Of Meat™. Remember to bring your hollow leg.

Nemea Greek Taverna is a nice, higher-end Greek restaurant. I've been here several times with good quality food and service.

Smokin Pig BBQ is a bit outside the downtown core, a couple miles north, but has some seriously tasty BBQ. They are unopinionated when it comes to region, so you can get pulled pork, brisket, or a number of other meats, as well as four different sauces. Also make sure to try the Wolf Turds and the peanut butter pie.

Back A Yard is one of my favorites, and serves Jamaican fare. I recommend the jerk pork with dirty rice.

IPOH Garden serves good Malaysian cuisine, I love their lamb curry.

I'm working on a rather large Objective-C codebase, so I haven't been able to do a ton of Swift yet, but I have been starting to try to take advantage of the new nullability and generics capabilities that have been added to Objective-C. Even though my code doesn't interact with much Swift code yet, you do get some benefits even in a pure ObjC codebase.

One of the downsides to Objective-C generics though is that your type declarations get really big and hard to read. For example, in the code I was just working on, I wanted to have a dictionary that mapped from one set of NSURLs onto another set of NSURLs. In Swift, the type would simply be declared [NSURL:NSURL]  but in Objective-C, you get the much less clean NSDictionary<NSURL*, NSURL*>*  Once you start declaring this in multiple places, passing parameters, etc. it can make your code very hard to read. One brief example:

- (NSDictionary<NSURL*, NSURL*>*)mapSourceURLs:(NSArray<NSURL*>*)sourceURLs toContentsOfDirectory:(NSURL*)directoryURL { NSDictionary<NSURL*, NSURL*>* urlMap; //code code code... return urlMap; }

After briefly contemplating rewriting the whole class I was working on in Swift just so I could minimize the offense to my delicate eyes, I remembered that C has a tool to help with this kind of thing, trusty old typedef! I started by declaring the following at the top of my source file:

typedef NSDictionary<NSURL*, NSURL*>* IPURLMap;

Then, I changed my variable declaration in my method to the following:

IPURLMap* urlMap;

However, this brought up a compiler error stating: pointer to non-const type 'IPURLMap' (aka 'NSDictionary *') with no explicit ownership. This was because I had declared the IPURLMap type as a pointer to a dictionary, but then the variable declaration was also declared as a pointer, which threw off the compiler. I could remove the asterisk from the variable declaration, but that looked weird to me, since it doesn't look like I'm declaring an Objective-C object there. So instead, I removed the asterisk from the typedef, so it ended up like so:

typedef NSDictionary<NSURL*, NSURL*> IPURLMap;

With that, the method declaration now becomes:

- (IPURLMap*)mapSourceURLs:(NSArray<NSURL*>*)sourceURLs toContentsOfDirectory:(NSURL*)directoryURL { IPURLMap* urlMap; //code code code... return urlMap; }

I started using Beats Music a few months ago, and have really been enjoying the custom playlists that it's been suggesting for me. I think Apple has done a good job overall moving the functionality of Beats over to Apple Music, but there were a couple things I used to do in Beats that it took a little figuring out on how to do the same thing under the new regime.

The "Introduction to" playlists

Almost every artist on Beats Music had a playlist called "Introduction to <artist name>", which would typically contain a good number of the "greatest hits" from that artist, along with a few other less well known, but good tracks mixed in. I found these playlists to be a fantastic way to get acquainted with the work of an artist I had not listened to much before.

When I found such an artist (typically when playing some mixed playlist that they were in), I could simply tap on that artist, then there was a "Playlists" section on the artist page where I could go find the "introduction" playlist and subscribe to it. This approach doesn't work in Apple Music though, as the artist page seems to only show their tracks and albums, but not playlists they're in.

I did find a new approach though, which is to simply search for that artist's name instead. In the search results, there is a "Playlists" section that will contain any playlists that contain songs from that artist, including the "introduction" playlist.

"Loved" songs

Apple Music brings over the ability from Beats Music to "love" a song by tapping the little heart icon next to it. This gives Apple Music feedback on what you like, and lets it make better suggestions for you. One thing that I always wished Beats Music had (or if it did, I could never manage to find it) was the ability to see a complete list of songs that I had already "loved".

This is now possible under Apple Music, by creating a smart playlist with a rule reading "Loved is true". That will list all the songs that you've marked as loved in a single convenient playlist. Note that there doesn't appear to be any way to create smart playlists on iOS, so you'll need to create the playlist using iTunes on your Mac or PC, but that playlist will then automatically sync over to your iOS device (assuming you have iCloud Music Library enabled, of course).

On a related note, Beats also had a "don't love" button (heart with an X through it) that you could press if you didn't like a particular song very much. There doesn't appear to be an equivalent button in Apple Music though. I don't know how much effect that button had on your suggestions, but I did find it satisfying to press for particularly egregious choices that would come up now and then.

Beats playlists vs. my playlists

I recently read a short post over at Glenn Reid’s blog describing a situation he ran across with Apple’s new document model (as of OS X 10.7). The new model frequently autosaves the current state of an open document to disk rather than waiting for an explicit save command. It’s when another program (in his example, Dropbox) overwrites the file on disk while the document is still open that hilarity ensues. However, while this situation does have a plethora of confusing language and UI, there is not in fact any data loss in the process. Let’s walk through a similar example, step by step.

1. Create a new document in TextEdit, type some text into it, and save the document.

2. Add some more text to the document, but do not use the save command yet. You can see that the document is labelled as “Edited” in the title bar. 

3. Instead of setting up a Dropbox sync, I’m just going to open the file in a terminal window using nano, but the behavior here will be the same as if Dropbox had been the one to write over the file. You can see when we open the file that the new text has already been saved to disk, even though we never hit Save in TextEdit.

4. Now let’s replace the existing content with some new text, then tell nano to save its changes to the file.

5. When we switch back to TextEdit, we still see the previous content, and not the new changes we just applied using nano. However, when we hit Save, that’s when we see the same dialog that Glenn came across.

This is the point where the aforementioned confusing language and UI comes in. If we take a closer look at this message, there is a key phrase that’s easy to miss:

Click Save Anyway to keep your changes and save the changes made by the other application as a version, or click Revert to keep the changes from the other application and save your changes as a version.

This is the “Versions” part of Versions & Autosave kicking in. No matter which button we choose, both versions of the document will be saved: our version from TextEdit, and the version written behind our backs by Dropbox/nano. The only difference between the two choices is which version we will see in the TextEdit window immediately afterwards.

After clicking “Save Anyway”, if we go to File > Revert > Browse All Versions…, we can see that both versions of the document are still available.

I recently fixed a crash I was seeing reported in one of my applications, and thought the steps I ended up going through to figure out what was going on might be worth sharing. This may not end up actually being useful to anyone, but hopefully it will at least serve as some programming nerd entertainment!

The crash

The top of the crashed thread’s stack trace looked like this, while trying to filter a set using an NSPredicate:

Thread 4 Crashed: 0 libobjc.A.dylib 0x00007fff8501fe90 objc_msgSend + 16 1 Foundation 0x00007fff87af1701 -[NSPredicateOperator performOperationUsingObject:andObject:] + 109 2 Foundation 0x00007fff87af0fe8 -[NSComparisonPredicate evaluateWithObject:substitutionVariables:] + 290 3 Foundation 0x00007fff87af0a9a -[NSPredicate evaluateWithObject:] + 18 4 Foundation 0x00007fff87af0a1f _filterObjectsUsingPredicate + 332 5 Foundation 0x00007fff87b9a60a -[NSSet(NSPredicateSupport) filteredSetUsingPredicate:] + 337

OK, crashing in objc_msgSend usually means you’ve got a bad object pointer gumming up the works. My first guess was to think there was some sort of memory management issue going on, where an object was being messaged after having been deallocated. Looking at the code surrounding the crash though, I didn’t see anything obviously wrong that might cause that sort of problem though. Next, I looked at the top of the crash report for details on what was actually causing the crash:

Date/Time: 2014-11-03 09:26:05 +0000 OS Version: Mac OS X 10.7.5 (11G63b) Report Version: 104 Exception Type: SIGSEGV Exception Codes: SEGV_MAPERR at 0x10 Crashed Thread: 4

OK, so it seems to be trying to access the address 0x10. That is definitely not going to be a real pointer to an object - but how is that getting there? Fortunately, one of my users actually filled out that little box in the crash reporter that asks what you were doing when the app crashed! (PSA: always put something into that box if you possibly can - sometimes even the most innocuous looking clue will get the developer looking in the right place)

The culprit

That clue got me looking at a particular predicate in my code, the format string for which is “FUNCTION(self, ‘isAlbumMemberWithMask:’, $VALUE) == YES”. This is a somewhat esoteric feature of NSPredicate that lets you define a custom function that is evaluated as part of the predicate. For the gory details on how this works, I refer you to Dave DeLong’s extensive explanation here.

The code for my -isAlbumMemberWithMask: method is below. Now that you’ve read that article and know how custom functions are supposed to be written, you’ll immediately see what I did wrong here:

- (BOOL)isAlbumMemberWithMask:(NSNumber*)inMask { return (self.albumMembershipMask & [inMask unsignedIntegerValue]) != 0; }

The problem here is that the return value from this method needs to be an object, but I’m returning a BOOL. That certainly explains why there’s a problem when trying to send it an Objective-C message! So, the fix here is to change this method to return an NSNumber instead of a BOOL. Easy peasy.

But wait a minute…

I had run this code through its paces before releasing it, and written several unit tests to exercise it, and everything worked fine. So… how on earth did this ever work in the first place?! I must know!

Looking through the crash reports again, I noticed that all the crashes I received were either on 10.7.x or 10.8.x. I had not received any crashes on 10.9 or later, and I had done most of my development/testing on 10.9, so it seems that somehow, my broken code worked on 10.9, but not on earlier versions of the OS. Huh?

Thinking through things, my method would always return one of two values: NO or YES, or in numeric terms, 0 or 1. The 0 value would be treated as a nil object pointer, and sending a message to a nil object will always return 0/nil. NSPredicate would presumably send a -boolValue message to the returned object to determine whether things evaluated to true or false. An NSNumber wrapping NO would return 0, but a nil object would also return 0, so it makes sense why the NO case would work. But what about YES?

Enter tagged pointers

On newer architectures such as 64-bit Intel, Apple has implemented something called tagged pointers. For the gory details on how these work, I refer you to Mike Ash’s extensive explanation here. The basic idea is that due to the way memory is aligned on newer architectures, the bottom several bits of an object pointer are always going to be 0. Apple takes advantage of this for certain classes by storing the value for the object in the pointer rather than allocating separate memory to hold the value. Since in a normal object pointer, the bottom several bits will always be 0, a tagged pointer instead has its bottom bit set to 1. When the Objective-C runtime sees that bottom bit is not 0, it knows that it’s dealing with a tagged pointer and not a “real” object pointer, and can use a different code path to handle sending messages to the object.

In our case, if our method is returning a YES value, that will end up with a full value of 0x0000000000000001. If you try interpreting this value as an object, the runtime will think it is a tagged pointer, since the bottom bit is 1. OK then, so what kind of object is this exactly?

Well, the class of the tagged pointer object is determined by looking at the next 3 bits of the value, which allows for 8 different classes to be represented by tagged pointers. After some searching, I found the list of these classes defined in the Objective-C runtime, which is open source. The list looks like this:

{ OBJC_TAG_NSAtom = 0, OBJC_TAG_1 = 1, OBJC_TAG_NSString = 2, OBJC_TAG_NSNumber = 3, OBJC_TAG_NSIndexPath = 4, OBJC_TAG_NSManagedObjectID = 5, OBJC_TAG_NSDate = 6, OBJC_TAG_7 = 7 };

For our object, those three bits are all going to be 0, meaning that this tagged pointer will be interpreted as an NSAtom, whatever the heck that is. It’s not a publicly defined class, to be sure, so I fired up LLDB in Xcode to see if I can track this thing down.

NSAtom

OK, let’s just try printing one of these things out and see what happens.

(lldb) po (id)0x1 <object returned empty description> (lldb) po [(id)0x1 class] <object returned empty description>

Hmm, well that’s not terribly helpful. Let’s try something a little lower level.

(lldb) print (char*)object_getClassName((id)0x1) (char *) $3 = 0x00007fff8808b334 "__NSAtom"

OK, now we’re getting somewhere. Where is this class defined?

(lldb) po [NSBundle bundleForClass:(Class)NSClassFromString(@"__NSAtom")] NSBundle </System/Library/Frameworks/CoreFoundation.framework> (loaded)

Aha, it’s in CoreFoundation. Let’s do a little class-dump on CoreFoundation and see what this class looks like

@interface __NSAtom { Class isa; } + (void)initialize; @end

Ummmm, OK. That doesn’t tell us much. Let’s try poking at it some more in LLDB. Printing out the class didn’t give us anything useful, but I wonder what that -class method is actually returning…

(lldb) print (int)[(id)0x1 class] (int) $6 = 1

The class is 1? That’s… weird. Let’s try something else.

(lldb) print (int)[(id)0x1 description] (int) $7 = 1

Hmmmm. Is there a pattern here?

(lldb) print (int)[(id)0x1 copy] (int) $8 = 1 (lldb) print (int)[(id)0x1 hash] (int) $9 = 1 (lldb) print (int)[(id)0x1 wat] (int) $10 = 1

Ah, so it looks like, whether by design or by accident, no matter what message you send to NSAtom, it returns a value of 1. Hang on a second…

(lldb) print (int)[(id)0x1 boolValue] (int) $11 = 1

Aha! This explains why NSPredicate didn’t crash with my crappy-ass code.

If our method returns NO, that’s treated as a nil object, and sending -boolValue to nil returns NO.

If our method returns YES, that’s treated as one of these NSAtom objects, and sending -boolValue (or any message) to NSAtom returns 1, a.k.a. YES.

As I mentioned in my last post, I'm currently learning about how a view based NSTableView differs from an old style NSCell based table view (or technically in my case, an NSOutlineView). I'm taking notes on what all is different, and figured I'd post it here too, in case it helps anyone else

Like before, you can use either bindings or a data source to provide data to your table view.

However, with cell based views, you would bind each individual column, or provide different object values for each row+column in -tableView:objectValueForTableColumn:row: With view-based tables, it's just a single 'content' binding that binds each row to an object value, and that same object value is set as the objectValue for each of your cell views. Each view can show different data by binding to different properties of the objectValue, e.g. the name column would bind to "objectValue.name", etc.

With a data source, you don't actually need to implement -tableView:objectValueForTableColumn:row:, as you can just configure your view yourself before returning it from -tableView:viewForTableColumn:row:. However, you can implement the object value data source method if you want, and NSTableView will do just like bindings, and use that as the objectValue for the cell view.

Editing cells is no longer handled by the table view itself, and doesn't call a setObject data source method to pass on the value. Instead, you're supposed to use bindings or hook up target/action from the subviews in your cell's view to modify the model object as needed. NSTableCellView handles this mostly automatically for you though. This does make it much easier to have a single cell handle editing multiple bits of data though, if needed, since you no longer have to work under the assumption that one cell displays just one value.

This also means that starting an edit programatically works a bit differently too, since NSTableView is no longer doing the work of setting up the field editor for your NSTextFieldCell like it did before. According to the docs, it tries to make the view in that row/column the first responder, and then it's up to the view to start editing? Or something? I need to play with this one to figure out how it really works.

With cell-based tables, each table column just had a single NSCell instances, stored in its dataCell property. You could give it custom cells using the -tableView:dataCellForTableColumn:row: method, to have different types of cells in different rows. For view-based tables, you can just drag multiple views into a single table column, and give each one a unique identifier string. Then you can just call -makeViewWithIdentifier:owner: to have it make a new instance of that view each time you need it. This makes it really easy to have heterogenous cells in your table.

So, I’m finally getting around to learning about view based NSTableViews, which were introduced in OS X Lion, with the intention of converting my app PlistEdit Pro to use the new type of table/outline view.

I started by reading through the docs, and looking at the TableViewPlayground sample code. Everything mostly made sense, but there was one part I couldn’t quite understand, which was the usage of the -makeViewWithIdentifier:owner: method. More specifically, I understood how you were supposed to use it, but I couldn’t figure out how it worked. I guess I’ve become less tolerant for letting things remain “magic”, so I decided to do some digging and see if I could figure out how this thing was implemented.

To start with, here’s how this method is typically used:

(NSView *)tableView:(NSTableView *)tableView viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row { // Retrieve to get the @"MyView" from the pool or, // if no version is available in the pool, load the Interface Builder version NSTableCellView *result = [tableView makeViewWithIdentifier:@"MyView" owner:self]; // Set the stringValue of the cell's text field to the nameArray value at row result.textField.stringValue = [self.nameArray objectAtIndex:row]; // Return the result return result; }

And here’s what the docs say about the method:

Typically, identifier is associated with a cell view that’s contained in a table’s nib file. When this method is called, the table view automatically instantiates the cell view with the specified owner, which is usually the table view’s delegate. (The owner is useful in setting up outlets and target/actions from the view.) Note that a cell view’s identifier must be the same as its table column’s identifier for bindings to work. If you’re using bindings, it’s recommended that you use the Automatic identifier setting in Interface Builder.

This method may also return a reused view with the same identifier that is no longer available on screen. If a view with the specified identifier can’t be instantiated from the nib file or found in the reuse queue, this method returns nil.

This method is usually called by the delegate in tableView:viewForTableColumn:row:, but it can also be overridden to provide custom views for the identifier. Note that awakeFromNib is called each time this method is called, which means that awakeFromNib is also called on owner, even though the owner is already awake.

When you set up a view based table view in Interface Builder, you can drop a view onto one of your table’s columns, and give it an identifier using the inspector. This is the identifier that you pass into -makeViewWithIdentifier:owner:. Easy peasy.

However, each time you’re calling this method, “the table view automatically instantiates the cell view with the specified owner”. Instantiates how exactly? This certainly seems to imply it does so by the normal nib loading mechanism, which is further supported by the owner: argument, and the warning in the docs about awakeFromNib being called multiple times when using this pattern. But this view is embedded inside a table column inside your table view, which itself is archived along with whatever other objects are in the same nib file. Is it really going to instantiate this entire nib file again, just so it can go in and pluck out this one cell view, then discard the rest? Or is it using some other mechanism entirely, like calling -copy on an existing view? Neither explanation seemed right, so I started digging a bit further.

I started by taking the .xib file from the TableViewPlayground project and looking at the raw XML, so I could try to figure out how and where those cell views are stored. Opening it up in BBEdit, I found the section containing the information for the table column, which looks like so:

OK, so it looks like NSTableColumn has this “prototypeCellViews” key where those views that you drop onto the table column get stored. This obviously isn’t exposed in the public API, but it does explain where those views are stored, and how you can manage to put multiple cells with different identifiers inside a single table column (unlike a cell based table view, where each table column only has one data cell of its own). But they’re still buried deep inside the nib file - how do you instantiate these things without loading everything else as well?

The next step was to take a look at the compiled .nib file, which is created by Xcode when building your application, by running the ibtool command line tool, which translates the SCM friendly XML into the fast loading binary .nib format. If you look at this in HexFiend, it looks like this:

I’ve dealt with these some before, and they are actually blobs of archived data created by NSKeyedArchiver, which in turn ends up storing its data as a binary plist (thus the “bplist” value at the very beginning). If only I had some sort of property list editor that would let me view it…

Making your way through a raw keyed archive isn’t difficult, but it is a bit cumbersome. It basically ends up being a giant list of objects, all indexed by object ID numbers in that "$objects" dictionary. Whenever any object has a reference to another object, it uses the object ID to refer to the other object. So, to follow the graph down, you start with one ID number, find what it’s referencing, find that ID number in the big $objects dictionary, and repeat the process ad nauseum. Or, if you know what you’re looking for, you skip all that and just do a search! I did a find on “NSTableView”, and here’s what popped up:

Well that does look like a bunch of information an NSTableView would need, things like NSBackgroundColor, NSDelegate, NSEnabled, NSTableViewArchivedReusableViewsKey, NS- wait, reusable who in the what now? Let’s go further down that rabbit hole and see what ID 60 is all about…

Here’s how we can interpret object #60:

It’s $class points to object ID 70. If we look down at object 70, it looks like that’s telling us that this object is an NSMutableDictionary.

The dictionary has keys (NS.keys) and values (NS.objects). Looking at the first entry in each list, we have a key value pair with the key pointing the object 61 and the value pointing to object 63.

Following those links, we see that the key is “SampleWindowCell”, which corresponds to the identifier this nib file has for a custom cell in its table view.

The value is object 63, which appears to have… a bunch of NSNib related info. Wait, what?

The class for object 63 is object 67, which we follow and see is in fact the NSNib class.

Looking at that NSNibFileData key, that points us to object 64, which is a big old data blob.

OK, so what the heck is that data blob then? Let’s copy all that hex data and paste into HexFiend:

Oooh, this looks familiar, doesn’t it? Looks like another keyed archive, doesn’t it? OK, let’s save this to a file and open it in PlistEdit Pro:

Looks just like when we opened MainMenu.nib! And if we dig around in the various objects here, it looks like it does contain the components for our SimpleWindowCell view object. That’s right, we’ve solved the mystery of how these cell views are loaded, and the answer is:

Nibception!!!

Yup, we’ve got ourselves a nib inside a nib here. That's why it doesn't have to reload the entire thing, it just reloads the smaller nib embedded as a data blob inside the main nib. The complete sequence of steps is:

When you do your setup in Interface Builder, it saves the data for those cells in the prototypeCellViews section that we saw in the XML for the .xib file.

When ibtool compiles the .xib file, rather than just embedding those views inside the table view like is normally done for subviews, it instead sucks each cell view into its own separate NSNib, uses NSKeyedArchived to encode the NSNib object to a data blob, then stores that data blob inside the parent .nib file that’s being created.

When your program runs and loads the outer nib file, those cell views don’t get instantiated immediately. Instead, those archived NSNib objects get instantiated from the data blobs and stored internally by the NSTableView.

Finally, when you call -makeViewWithIdentifier:owner:, that finds the appropriate NSNib object for that identifier, then calls -[NSNib instantiateWithOwner:topLevelObjects:], passing along the owner argument that you gave it.

Now of course you don’t actually need to know this to use this API, but knowing how it works does put my mind at ease that there’s no funky magic going on, just some clever engineering from the folks at Apple.

OR IS IT!?

Using the App Store to download and install Xcode updates is very convenient, especially since it can often download delta updates which are much smaller than redownloading the entire installer from Apple's developer site. I've seen many people run into an issue when doing this though, where after you update Xcode, the App Store continues to insist that Xcode needs to be updated again, to the same version, and will happily let you download and install Xcode a second time.

The most common reason for this is that developers will often want to keep old versions of Xcode around, e.g. if you are not ready to move to the new version of Xcode full time for doing production builds, and need to keep the old version around for a while. However, the App Store app is rather aggressive when it comes to finding apps that need updating, so if you have another version of Xcode laying around, it will find that old version and say "Hey, this needs updating!" even if the main copy in your Applications folder has already been updated. Needless to say, this is rather annoying, especially if you only discover it after it's blown away an old version of Xcode that you wanted to keep.

The mechanism it uses to do this is our old friend, Spotlight. If Spotlight can find an old version of Xcode, the App Store will happily update it. So, the trick you can use to prevent the App Store from doing so is to hide your old version(s) of Xcode from Spotlight.

The way I do that is to create a new folder where I put any old versions of Xcode that I want to have around. Then, open System Preferences and go to the Spotlight pane. In the Privacy section, you can then add that folder to the list of folders Spotlight should ignore. For me at least, that does the trick, and keeps the App Store from mucking around with my old Xcodes.

Shortly after Apple released their OS X 10.8.2 update last week, I started receiving e-mails from iPhoto Library Manager users who were getting timeout errors when trying to use iPLM to transfer photos between iPhoto libraries. iPLM uses Apple events to communicate with iPhoto, and sends the events using the AESendMessage() API in the CoreServices framework. (it doesn't use AppleScript for reasons of control and efficiency) After some investigation, I believe there is a bug in 10.8.2 that causes this problem, and thought I'd post my findings here in case any other developers were running into similar issues. The bug is filed as number 12424662 and can be found on Open Radar at http://www.openradar.me/12424662

The basic outline of the problem is that sometimes a particular application will get into a state where any events sent to it using AESendMessage (or AESend, for that matter) would not be delivered to the target application, and AESendMessage would simply block until the timeout value was reached, then return an errAETimeout error code. Quitting and relaunching the target application doesn't change anything, but logging out and logging back in usually seems to fix the problem, at least temporarily. It also appears to only affect one application at a time, e.g. if iPhoto breaks in this way, other apps on the system will continue to function just fine.

After much experimenting with different things, I found a way I was able to get events to flow again, even with the target application in this state. When you set up an Apple event, one of the parameters you need to give is an "address" of the application to which you want to send the event. The Apple event system has several ways of specifying this address, the most common of which are by bundle identifier or by the application's four character creator code. My code was using the bundle identifier, which looks something like this:

NSAppleEventDescriptor* addressDescriptor = [[NSAppleEventDescriptor alloc] initWithDescriptorType:typeApplicationBundleID data:[self.bundleIdentifier dataUsingEncoding:NSUTF8StringEncoding]]; NSAppleEventDescriptor* newEvent = [[NSAppleEventDescriptor alloc] initWithEventClass:kAECoreSuite eventID:kAEGetData targetDescriptor:addressDescriptor returnID:kAutoGenerateReturnID transactionID:kAnyTransactionID];

What I eventually discovered was, that if I instead used an address descriptor that specified the process ID of the target application rather than just its bundle identifier, then the event would be delivered normally instead of timing out. This of course requires that the application already be running, and requires a bit of additional code to fetch the process ID for the application. This sample code does just that:

NSRunningApplication* runningApplication = [[NSRunningApplication runningApplicationsWithBundleIdentifier:self.bundleIdentifier] lastObject]; pid_t pid = [runningApplication processIdentifier]; NSAppleEventDescriptor* addressDescriptor = [[NSAppleEventDescriptor alloc] initWithDescriptorType:typeKernelProcessID bytes:&pid length:sizeof(pid)];

I wrote up a sample project to demonstrate the problem for the bug report. Anyone interested can download the project here. Note that I have still not come up with a way to reliably get an application into this weird state, so running the sample app might not be particularly useful for most people, but you're welcome to take a look at the code in any case. The "Use pid address" checkbox in the main window is the relevant one - the other checkboxes there were for a bunch of other variations I was trying out, none of which turned out to be the issue. You're all welcome to play around with it though. :)

My speculative theory is that somewhere in the bowels of the Apple event system, there's some sort of mapping that it keeps to translate bundle identifiers into process IDs so that events can be delivered to the right app, and it keeps this updated as processes get launched/quit. Somehow on 10.8.2, this can get messed up for a particular application, and any events sent to that bundle ID get swallowed up never to be seen again. Sending directly to the process ID still works though, because it doesn't need to rely on the messed up internal mapping. Update: It looks like there is a background daemon called appleeventsd which seems to be responsible for this. Killing that process resets things, so you can do that rather than doing a full logout. 

I also saw one other developer, Michael Tsai, mention that he was getting similar reports from another program trying to target his app, SpamSieve, with Apple events. In his case, the events were being sent using typeSignature (the four char code for the app) instead of typeApplicationBundleID, but the symptoms were all the same, so it does appear that this problem can potentially affect any application on OS X once the internal state for it gets messed up.

One additional tidbit, for those who don't want to use NSRunningApplication (e.g. targeting 10.5 or earlier), this code can also be used to translate from a bundle identifier to a process ID (courtesy of Michael).

ProcessSerialNumber psn; psn.highLongOfPSN = 0; psn.lowLongOfPSN = kNoProcess; while (GetNextProcess(&psn) == noErr) { CFDictionaryRef infoCF = ProcessInformationCopyDictionary(&psn, kProcessDictionaryIncludeAllInformationMask); if (infoCF) { NSDictionary *info = [(id)infoCF autorelease]; NSString *identifier = [info objectForKey:(id)kCFBundleIdentifierKey]; if ([identifier isEqual:@"com.c-command.SpamSieve"]) return [info objectForKey:@"pid"]; } }

During long Time Machine backups, I often find myself checking the console for messages from backupd indicating how progress is going, especially when it has to delete a bunch of old backups to make room for the new one, which can take quite a bit of time. I found myself wishing I could just be notified via Growl whenever a new messages popped up in the console, rather than having to check it myself. So, being a programmer, I naturally wrote a script to do it for me.

The script relies on the growlnotify command line tool, one of the extra downloads that you can get with Growl, so you'll need to download and install that tool first. It's written in Ruby, and uses the syslog tool to read the messages and then pipe them into calls to growlnotify, so they appear on the screen as Growl notifications. You can find the script as a gist on Github at the link below.