atomkirk

There really needs to be an easier way to do this built into the language, but until then, I use my handy CodeBox app to paste in this whenever I need a weak reference to self:

__weak typeof(self) celf = self;
[self block:^{
  celf.foo = bar;
}];

It's a nifty trick, but Apple, please... I shouldn't have to declare a weak self, I should be able to use self with a predefined symbol for "self" that the compiler will then write the weak self declaration for me.

atomkirk

If you set the timeoutInterval value on NSMutableURLConnection to -1, on mountain lion, it'll never time out, on Lion, it'll time out immediately.

atomkirk

To a parent project, a submodule is essentially a subdirectory in your project that is viewed by the parent repo as a simple text file with a name and a commit number. So, when you pull down a project that uses submodules:

git submodule add <path to repo>

It will add that sub directory and an entry to its .gitmodules file (with the name and commit number). So when you git add . and git commit -am 'message' in the parent repo, the only thing you are adding and committing is the current commit of the submodule.

The git submodule command is how to work beyond this narrow view of a text file with a commit message. As shown above, you would use git submodule add <path to repo> to ADD it, but all you're adding is the text file with a name and commit. To actually pull down the files, you would run:

git submodule update --init --recursive

atomkirk

You can't mix CoreGraphics and ApplicationServices on mac. If you have two targets, and you want to use things like CGFloat, etc. link to CoreGraphics on iOS and ApplicationServices on OSX. On 10.8, it's fine, it'll work, but you're still suppose to use ApplicaitonServices. On 10.7, it'll build, launch and crash with an error about mismatched ApplicationServices versions because CoreGraphics is calling 10.8's ApplicationServices version. (or some such...)

atomkirk

After wresting the traditional git submodule + static library dependency chain, it became a giant headache. I tried to get it all to work for a long time. You must:

1. Create a workspace and drag your child projects in.
2. Add their targets as binary linked libraries.
3. Manually add header search paths.
4. And all your dependency projects must be set up a certain way for this to work too. So that's a lot of work.

A much better way is to use submodules to include the child projects into the parent project and then use cocoapods to include those child projects (instead of linking them in statically and dealing with the millions of headaches that brings).

For example, I've added my dependency tree as a series of git submodules and then I have a Podfile that looks like this:

atomkirk

I forgot that I had turned on this:

![http://d.pr/i/GF8z/3KaIrTfS]

And so the Sparkle.framework for auto updating mac apps was offering to update, downloading, offering to install and relaunch and then would just quit and not update. It said finish_installation' failed: 22 which was because gatekeeper was keeping the app from updating itself.

Turned off entitlements and it works great.

atomkirk

On iOS, to use custom fonts, you add them to your plist:

<key>UIAppFonts</key>
	<array>
		<string>GoodDog_New.otf</string>
		<string>ProximaNova-Bold.otf</string>
		<string>ProximaNova-Reg.otf</string>
	</array>

on Mac, you just add:

atomkirk

For determining the effect of TARGET_OS_IPHONE etc.

http://sealiesoftware.com/blog/archive/2010/8/16/TargetConditionalsh.html

atomkirk

My co-worker at Bloom Built BJ Homer pointed this out to me. It allows you to generate a compile time warning if someone isn't ussing your designated initializer:

http://stackoverflow.com/questions/16861658/inheritance-restricting-rather-than-extending/16866840#16866840

atomkirk

I've been told about this, but it's never bitten me, until today. So, get in the habit:

http://stackoverflow.com/questions/387959/nsstring-property-copy-or-retain

He says immutable and I'm not sure I understand why, but it's clear why you would do this with mutable. UPDATE: he says immutable, implying mutable too, because it's entirely possible to assign an immutable version of an object to a property specified as mutable, so it's not safe to assume that just because the property is NSArray doesn't mean it isn't a mutable array and some statement somewhere isn't changing it's content's behind your back.

One interesting thing to note: if you assign an immutable NSArray to a @property (copy, nonatomic) NSArray *array it will actually retain it, not copy it. So it's is smart enough to just retain rather than copy it when it really is immutable, saving an allocation.