I don’t know much about pricing products as a developer. While I’m a programmer, I don’t have apps of my own yet. So take this with a grain of salt, go ahead and flame me, etc. These are just my feelings.
But nevertheless, I wanted to share how I feel about pricing as a user of software.
I’m going to start with something bold, then work my way back to it: Never let me perceive your product’s pricing is unstable and currently at a high.
When you start using Grand Central Dispatch or NSOperation, you’ll want to perform some actions on the main thread and some intentionally off the main thread.
This is a simple and obvious technique, but it took me a while to adopt it: You can do by asserting with NSAssert or NSCAssert for [NSThread isMainThread], just as you would assert any other condition.
Assertions are a great tool. As an Objective-C programmer, I use NSAssert and NSCAssert liberally.
For various reasons, you sometimes can’t use NSAssert in a block easily. I’m going to explain why and describe a new macro, BlockAssert, which solves this.
Over the years I have tweaked which compiler warnings I use. There’s one in particular that I used to turn on but will turn off from now on: GCC_WARN_SHADOW.
GCC_WARN_SHADOW is essentially drawing your attention to you possibly doing something other than you intended. This is like most warnings, but the difference is that the behaviour GCC_WARN_SHADOW is blocking is very useful.
You probably know CGRectMake, but did you know it’s not the only way to make rectangles? It’s not even the best way, really.
There’s also C99 initializer syntax.
The main advantage to the C99 syntax is that it gives you some very Objective-C like syntax, where the fields are close to the values rather than implied by positioning. (That’s not to say this is intentionally similar, or that it’s the only advantage. But it is nice.) It also provides type checking, and since fields are named it catches drifts in meaning that you otherwise wouldn’t catch.
It’s sometimes slightly more typing, but I use it everywhere now.
In my previous entry, I discussed when id will be promoted to instancetype. But now that I’ve explained this, I’d like to explain why you should understand this but not rely on it. Instead, you should use instancetype directly.
Let me start with this bold statement, then I’ll back up and explain it: Use instancetype whenever it’s appropriate, which is whenever a class returns an instance of that same class.