Delete Program Preferences in OS X (Including Cache)

Often while debugging an app it’s handy to delete its preferences so it will “start over” like a fresh install. You used to be able to find the .plist file in the Preferences folder and delete it. Simple.

Starting with OS X 10.9, preferences are cached. So even after deleting them, they’re still around. Here’s the magic shell command that deletes them:

defaults delete com.company.programName

Why I Don’t Care About Swift

Swift is a new programming language created by Apple for use on OS X and iOS devices. The programming world is agog. Apple’s fantastic new language apparently solves all their problems, as evidenced, they say, by the fact that some programmer ported Flappy Birds to it in a few hours.

I’ve been around long enough to see languages come and go. Each claimed to solve all the problems introduced by its predecessors, yet each was replaced by a language that solved all its problems. In some cases, the new language surpassed the success of the language it replaced (C++ and Java); in other cases, the new language faded into obscurity (Modula-2 and Ada).

Lately the motivations for new languages have been dubious. There is a big emphasis on making a language easy to learn and having it hide nasty issues related to memory management and type safety. One review of Swift I read stated, “Apple hopes to make the language more approachable, and hence encourage a new group of self-taught programmers”. While that sounds great, it means that those of us who have mastered our craft after 30 years or more of practice are saddled with the training wheels and water wings that are written into these languages for the noobs.

A classic example is the lack of unsigned integers in Java. The motivation for this was to simplify the language for “new and self-taught programmers” by avoiding errors caused by a lack of understanding of sign-extension. However, for those of us who showed up for class the day that sign extension was taught (that would be day two), we’re left with a language that unnecessarily limits the range of positive integers and requires us to actually have mastered sign extension in order to understand what is happening when we directly manipulate the bits in our integer variables.

Explicit vs. Implicit Typing

One of the simplifications Swift makes is that it infers the types of variables from the values assigned to them rather than requiring the programmer to explicitly type variables. If this was true “weak typing” like I’m familiar with in VBScript, it would be great (though it would come with its own set of problems). But all Swift does is infer the type of the variable from the first value you assign to it.

This actually introduces problems, because it’s not always possible to unequivocally determine the type of a literal value. So Swift gives you ways to force it to interpret a literal value as a given type. Rather than removing the necessity of the programmer understanding types, Swift thus requires “new and self-taught” programmers to have a mastery of types so that they can understand how Swift is working behind the scenes and make sure that their variables have the desired type.

Strings

Swift is said to improve string-handling over Objective-C (the current language used on OS X and iOS). There is certainly room for improvement there. When I first started programming in Objective-C, one of the first things I did was bring over my own C++ string class, as I found NSString to be overly complicated and muddled. Over the years I’ve gotten better with NSString.

I would argue, however, that some of the so-called “improvements” in Swift with respect to strings are differences without a distinction. So instead of this in Objective-C:

[NSString stringWithFormat:@"The value of num is %d", num]

you say this in Swift:

"The value of num is \(num)"

The Swift version is obviously more concise, but it is also less powerful. To add more complex format specifications to Swift you actually have to invoke the functionality of the underlying NSString class, which means the “new and self-taught” programmer, again, needs to understand the details of the implementation in order to do anything beyond the simplest strings.

One of the stated benefits of string handling in Swift is that “all strings are mutable”. One need not worry about whether the string is declared as an NSString (immutable) or NSMutableString (mutable). Well, you don’t have to worry unless you do have to worry — strings assigned to constants are immutable in Swift. So:

var myString1 = "Mutable string"
let myString2 = "Immutable string"
myString1 += myString2    // perfectly legal
myString2 += myString1    // compile-time error

Switch Statements

Swift eliminates the “fall-through” behavior of switch statements, which is said to eliminate bugs caused by omitting the break at the end of each case block. But, oops, sometimes the fall-through behavior is exactly what you want. So Swift adds the fallthrough keyword. It could be argued that Swift eliminates a line of code (the break) while giving the behavior one normally desires. But at the same time, it adds a keyword (fallthrough) that does the opposite. This requires “new and self-taught” programmers to have the same thorough understanding of switch behavior that Objective-C and C++ programmers do.

Single-line Blocks

The Swift compiler will warn you if you omit the braces in any block (such as after an if) and does not allow single-line blocks, thus avoiding this error:

if (x < 0)
    goto fail;
    goto fail;

The code above will always execute one or the other of the goto statements in Objective-C or C++. Even though the second goto is indented, it is not part of the if-block and will be executed if the condition is false.

Swift will warn you about the missing braces and force you to write this:

if (x < 0)
    {
    goto fail;
    }
goto fail;

Or, for those of you who don’t do your braces the right way, this…

if (x < 0) {
   goto fail;
}
goto fail;

This is fine, and hard to argue with. The supposition is that the programmer will immediately recognize the flaw or won’t make the mistake in the first place. On the other hand, I would argue that the same C++ programmer who wrote the erroneous code will write this in Swift:

if (x < 0) {
    goto fail; }
    goto fail;

I always put braces around my blocks, even if they are one-line, so this doesn’t affect me. It’s ironic, however, that while Swift prides itself in eliminating the unnecessary break statement at the end of a case block, it requires two to four additional lines (braces) in if, for, and while statements, which are more numerous.

PocketBible and Swift

I will be more than happy to learn and use Swift for programming on iOS and OS X. I just don’t believe the hype and won’t convert just for the sake of doing something new.

I am a strong proponent of platform-independent languages like C, C++, Java, and, to a lesser extent, Objective-C (the latter is primarily an Apple language, though it has its origins outside of Apple). Such languages allow me to develop code on one platform and re-use it on another. One of the promises of C++ and Java was that you could develop the code for one platform and use it on many others. Swift is an Apple language (the same way C# is a Microsoft language). It only works on Apple devices. While those are numerous, they’re not the only devices out there. So rather than moving toward the “write once, read everywhere” model promised by Java, we’re back to “write everywhere” as each platform requires its own language.

I don’t mind learning a new language. I already jump from C++ to C# to Java to VBScript to Javascript to MS-SQL on a daily basis. For those of us who write code for a living, being multilingual is a job requirement. This is precisely why I care so very little about the supposed advantages of Swift; this isn’t a religious war for me, it’s just a tool. When someone comes out with a new kind of screwdriver, I may or may not buy it until I need it. And then I’ll just buy one and use it — I won’t try to convert all my screwdriver-toting friends.

So will PocketBible for OS X and/or iOS be re-written in Swift? Probably not today, and probably not until Apple requires it. But Swift depends on Objective-C under the hood, so my guess is that Apple will continue to support Objective-C apps for a long time.

Enabling Web Inspector in Web-Kit WebViews in OS X Apps

You can turn on Safari’s Web Inspector functionality in any app that uses WebView to display HTML. First, enable the Developer menu in Safari’s preferences. Then enter the following command in Terminal:

defaults write com.example.myApp WebKitDeveloperExtras -bool true

Where com.example.myApp is the bundle identifier for the app. Launch the app, right-click in the WebView, and as long as the developer hasn’t completely disabled the context menu, you’ll be able to select Inspect Element and see the source code running in that view.

A program can enable this functionality itself by executing:

[[NSUserDefaults standardUserDefaults] setBool:TRUE forKey:@"WebKitDeveloperExtras"];
[[NSUserDefaults standardUserDefaults] synchronize];

Similarly, I believe one could defeat this functionality by setting the value to FALSE inside the app.

Symbolicating iOS and OS X Apps

Many of the errors that happen in Mac OS X and iOS apps don’t actually crash the app, they just dump a stack trace to the console. You can view these using the Console app — select the System Log and you’ll see all the messages the app sends to the console.

Unfortunately, these stack dumps can’t be directly used by the programmer to find the bug. With a little work, however, it’s possible to get right down to the line of code that caused the problem.

A stack trace will look like this:

Sep 13 19:04:32 Users-Mac.local PocketBible[727]: *** -[__NSCFString rangeOfString:options:range:locale:]: Range {3040, 18446744073709551600} out of bounds; string length 3504
Sep 13 19:04:32 Users-iMac.local PocketBible[727]: (
		0   CoreFoundation                      0x00007fff910e225c __exceptionPreprocess + 172
		1   libobjc.A.dylib                     0x00007fff96598e75 objc_exception_throw + 43
		2   CoreFoundation                      0x00007fff910e210c +[NSException raise:format:] + 204
		3   Foundation                          0x00007fff94074985 -[NSString rangeOfString:options:range:locale:] + 186
		4   Foundation                          0x00007fff940945b4 -[NSString rangeOfString:options:range:] + 29
		5   PocketBible                         0x00000001077cec78 PocketBible + 797816
		6   PocketBible                         0x000000010776c771 PocketBible + 395121
		7   PocketBible                         0x000000010776aa43 PocketBible + 387651
		8   AppKit                              0x00007fff92c84c38 -[NSTabView selectTabViewItem:] + 389
		9   AppKit                              0x00007fff92ff8b09 -[NSTabView mouseDown:] + 145
		10  AppKit                              0x00007fff92b76a58 -[NSWindow sendEvent:] + 11296
		11  AppKit                              0x00007fff92b155d4 -[NSApplication sendEvent:] + 2021
		12  AppKit                              0x00007fff929659f9 -[NSApplication run] + 646
		13  AppKit                              0x00007fff92950783 NSApplicationMain + 940
		14  PocketBible                         0x000000010770d244 PocketBible + 4676
		15  ???                                 0x0000000000000001 0x0 + 1
	)

The trick, of course, is to find the last bit of PocketBible code that was running when the error occurred. To do this, we need our symbol map. Fortunately, XCode archives that with our program and we can access those archives through the Organizer. So here’s what we need to do:

  1. Create a working folder somewhere
  2. Go into the Archive area of Organizer and select the archived version of the program from which the stack trace was created
  3. Right-click and select Show In Finder
  4. Right-click on the archive and select Show Package Contents
  5. Copy the .dSYM file from the dSYMs folder into the working folder
  6. Copy the application from Products/Applications into the working folder
  7. In Terminal, go to the working folder

Now enter this command:

atos -o PocketBible.app/Contents/MacOS/PocketBible -arch x86_64 -l [load address] [target address]

To calculate [load addresses], subtract the offset you see on any PocketBible line from the address to its left. So looking at line 5, you would subtract 797816 (decimal) from 0x1077cec78 (hex) and get 0x10770c000. [target_address] is the address you see in the stack trace for the line you’re interested in (for example, 0x1077cec78 for line 5).

If you do it right, atos will tell you the object and method, plus the file and line number in the file corresponding to the line in the stack trace:

got symbolicator for PocketBible.app/Contents/MacOS/PocketBible, base address 100000000
-[NSString(HTMLTags) rangeOfHtmlTagInRange:] (in PocketBible) (NSString+HTMLTags.m:67)

Which sends us to NSString+HTMLTags.m, line 67.

If you want to enter several addresses, press enter after [load address]. You are then in “interactive mode” and can enter addresses and get results without leaving atos or re-entering all the other parameters. Press ^C to exit this mode.

Objective-C Memory Management

Perhaps I’m showing my age, but I’m getting awful tired of language designers trying to improve on C/C++ memory management.

Just for review, here’s how memory management should work:

void foo()
  {
  // x is created on the stack. It is deallocated at the end of
  // the block/function and therefore its lifetime matches its
  // scope with no further effort. 

  int x;

  // pX is a pointer to an int that the programmer creates with
  // new. By using "new", the programmer is taking responsibility
  // for freeing the memory used by pX before it goes out of scope.

  int *pX = new int(0);

  // ... interesting code goes here ...

  // The obligatory delete before we exit the block/function.

  delete pX;

  }

Everything else in C/C++ is a variation on this. You can put pointers and variables in structures and classes/objects but they follow the same rules: If you allocate with new, you must free with delete before you lose track of the memory (i.e. the one and only (or last remaining) pointer goes out of scope).

When we started coding for iOS, we ran into “manual retain/release” which is a variation on the C/C++ technique (or rather, a manual method of the automatic garbage collection used in Mac OS):

@interface bar
  {
  // Like C++, when the pointer is a member (instance) variable, 
  // someone else is responsible for allocating memory for it.

  NSString * memberString;
  NSString * anotherString;
  }

// But if the instance variable is accessible from the outside
// world we can say it's a "property" and some of this is 
// managed for us. 

@property (retain) NSString * memberString;

// Unless we don't specify "retain". Now we're responsible for
// making sure the memory for anotherString is allocated and
// freed.

@property (assign) NSString * anotherString;

@end

@implementation bar

- (void)foo
  {
  // These are the same. They're on the stack and are automatically 
  // released when you exit the method/block.

  int x;

  // This is the equivalent of C/C++ "new", kind of. We can't just
  // do memory allocation without also initializing the object 
  // (handled by new and the constructor in C++, but that's the 
  // subject of a different article). The result is a pointer that
  // we're obligated to release before string goes out of scope.

  NSString * string = [[NSString alloc] init];

  // Another way of doing the same thing, but this time the 
  // resulting pointer is automatically released sometime in
  // the future that we don't care about.

  NSString * arString = [[[NSString alloc] init] autorelease];

  // Yet another way of doing the same thing, but the autorelease
  // is done for us. We can tell because the method name starts
  // with something that looks like the name of the class but
  // without the prefix. Intuitively obvious, right?

  NSString * autoString = [[NSString alloc] stringWithUTF8String:"Automatically released"];

  // Required release

  [string release];
  }

@end

And autorelease isn’t as automatic as you might think. You need to think about whether or not you need to create your own autorelease pool. This is important if you’re going to create a large number of autoreleased variables before returning to the run loop. You may want to manage your own autorelease pool in that case so you can free memory up at more convenient times.

If that’s not ridiculous enough, along comes Automatic Reference Counting (ARC) to “simplify” memory management.

@interface bar
  {
  // Like C++, when the pointer is a member (instance) variable, 
  // someone else is responsible for allocating memory for it.

  NSString * memberString;
  NSString * anotherString;
  }

// Instead of "retain", we create a "strong" reference. Memory
// is freed when this particular instance variable goes out
// of scope (is no longer accessible). 

@property (strong) NSString * memberString;

// We use "weak" instead of "assign" to mean that we understand
// someone else is in control of when this memory gets freed.

@property (weak) NSString * anotherString;

@end

@implementation bar

- (void)foo
  {
  // These are the same. They're on the stack and are automatically 
  // released when you exit the method/block. In reality, they're
  // qualified with __strong by default.

  int x = 10;
  NSString * string = [[NSString alloc] init]; // could add __strong for clarity

  // You can also create weak pointers for some reason:

  NSString * __weak weakString;

  // Unfortunately, that introduces a bug into these lines of code:

  weakString = [[NSString alloc] initWithFormat:@"x = %d", x];
  NSLog(@"weakString is '%@'", weakString);

  // In the code above, weakString is immediately deallocated after
  // it is created because there is no strong reference to it. See
  // how this is getting easier?

  // Not to mention:

  NSString * __autoreleasing arString;
  NSString * __unsafe_unretained uuString;

  // Now we don't have to do this:
  // [string release];
  // And that's really all we saved by introducing "Automatic Reference Counting".
  // At the same time, we created a new way to introduce a bug by failing
  // to have any strong pointers to an object from one line of code to
  // the next.
  }

@end

So we’ve gone from:

new / delete

to

retain / release (or autorelease with no release)

to

strong/__strong/weak/__weak/__autoreleasing/__unsafe_unretained

all in the interest of “simplification” and avoiding having to delete/release the memory we allocate. I frankly don’t see the benefits.

Fixing Mac OS X 10.7 “Lion”

Apple has a bad habit of hiring kids who have no concept of what came before them. This article helps you undo some of the changes they inflicted on Mac OS X in their attempt to make it “better”.

Reversing the Scrolling Direction

In 10.7, using the MacBook trackpad or the scroll wheel on your mouse will cause you to scroll in the opposite direction than you did previously. Instead of conceptually moving a view port over the document, you are now moving the document. This change was made to accommodate tablets and touch screens, where it seems more natural to use your finger to drag the document. However, rather than making the change apply only to touch screens, they changed all input devices. The result was that the screen appears to scroll backwards if you use a trackpad or scroll wheel.

To fix this, go to the Trackpad pane in System Preferences and uncheck the box for “When using gestures to scroll or navigate, move content in the direction of finger movement”.

Stop Apps from Reopening Previously Open Documents

One of the principles we use in iOS development is that the program should save its state so that when you re-launch it, it will appear as if you never left it. The reason this is essential on mobile devices is that historically they have managed memory themselves rather than depending on the user to close apps they are done with. Since the user never knows if an app has been removed from memory, it would be disconcerting if sometimes the app returned to a default state and sometimes it picks up where you left off.

With both Apple and Microsoft moving toward using their full desktop operating systems on mobile devices, they have begun to take principles that previously applied to small devices with limited resources and applying them to their desktop operating systems even if that doesn’t make sense. On the desktop, the user is the king of memory management. The user opens and closes documents and programs as his task requires. As a partial step toward the integration of mobile and desktop operating systems, the latest version of Mac OS X does two things: First, it saves the state of every app when the app is removed from memory, then restores it when it is re-launched. Second, it remembers what was running when you rebooted your computer, and resumes those programs when it boots up.

The problems introduced by this are myriad, but we can’t expect the little kids at Apple to know that, since for them new is always better and the past is for dead presidents and dinosaurs. For example, if I’m privately reviewing a spreadsheet containing everyone’s salary, then exit Excel, then the next day an employee brings me a spreadsheet for us to review together, when I open Excel the first thing the employee will see is my spreadsheet containing everyone’s confidential salary information.

Disabling this behavior is difficult but not impossible. First, go to System Preferences, select the General pane, and un-check the box for “Restore windows when quitting and re-opening apps”. You’d think this would be enough, but it’s not.

Next, you need to find the folder where Mac OS X saves application state and delete any existing state information. Otherwise, your programs will always restore whatever state was current when you unchecked the box on the Preferences pane. Unfortunately, this folder, which was visible in previous versions of the OS, has been hidden in 10.7. To make it visible, run the Terminal app (Applications > Utilities > Terminal) and enter the following:

chflags nohidden ~/Library/

Now select your Home folder in Finder and you’ll see Library. Open the Library folder, and scroll down to “Saved Application State”. Open that folder and delete everything it contains.

Just to make sure your apps don’t ignore the system preference and save their state anyway, go back to the Library folder, right-click on Saved Application State, select “Get Info”, and set the Sharing & Permissions for your user name to “Read Only”.