You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License.

1. The pointer used to point to memory that was ok, but its chunk was deallocated.
2. The pointer is corrupt.

1. Run Build and Analyze. Make sure you fix or understand every single error it flags. I personally have 0 Build and Analyze errors in every project I have and I go out of my way to keep it that way. If I ever get a false positive, I figure out how to make Build and Analyze understand what is going on, so that it doesn’t flag it.
2. Run scan-build with all checks on. This isn’t built in, so if you’re in a hurry, skip this for now. scan-build is the project that Build and Analyze is based on. It can be run with much more thorough settings.
3. Set up Xcode so that it never deallocates. Instead, it turns objects into Zombies that complain if they are used. See Tip #1 on this post for instructions.

1. The pointer could have never been initialized.
2. The pointer could have been accidentally written over because you overstepped the bounds of an array
3. The pointer could be part of an object that was casted incorrectly, and then written to
4. Any of the above could have corrupted a different pointer that now points at or near this pointer, and using that one corrupts this one (and so on)

1. Enable Guard Malloc (Tip #2) - this makes the datastructure that represents the allocations much more sensitive to corruption. You need to use the enhanced features of the debugger to get anything out of it (explained in the tip).
2. The line of code that triggers the crash is a clue to what pointer is corrupt. If you move it around it might be able to help you narrow down the point of corruption.
3. If all else fails and you are desperate, try Valgrind.

1. Corrupting a pointer doesn’t immediately trigger EXC_BAD_ACCESS. Neither does using a corrupted pointer unless it’s specifically now pointing to memory that isn’t mapped to your application.
2. Deallocating an object doesn’t immediately release the memory to the operating system -- only when the chunk is unused, can it be returned.
3. The line of code that is triggering the EXC_BAD_ACCESS might not be the problem. It can be a good clue, but don’t assume the problem is this code.

1. Run Build and Analyze: This kind of Build is very good at finding retain/release bugs. Take a good look at everything it flags.
2. Even better, run scan-build. I did a test recently, and found that some common errors are off by default in Build and Analyze that can be turned on in scan-build.
3. Choose Run > Enable Guard Malloc in the menu, and then re-run your application. This finds a whole class of buffer overrun issues. If this detects it, you’ll see a better error in the console. Read this to see how to use Guard Malloc once it’s enabled.
4. You can instruct the compiler to ignore release calls and then report if anyone is sending messages to objects that would have been deallocated. This results in much better errors in the Console if it detects them.
5. Valgrind is the gold standard for finding memory bugs on Linux, and here’s a way to get it working in the iPhone Simulator.

1. Download scan-build
2. Just unpack it into any directory and add that directory to your PATH
3. Open a Terminal and cd to your project’s root directory
4. Run scan-build and view results

Yay! It took several months but as of today I was able to search for my app and I saw it listed inside the app store. Now you may be saying "so what", but if you have ever looked into the steps that this takes, you know it's something to celebrate.My app is a very simple game, but I think I've learned enough during this process to distill some important lessons that may help you if this is something you've been wanting to do...

• Lose Weight
• Get Your Finances in Order
• Go Greener
• Curb Your Vices
• Get in Shape
• Relax More
• Pursue a New Career
• Upgrade Your Technology
• Organize and Optimize
• Start a New Hobby

Habits by Louis Franco helps users form good habits, which sounds simple enough. But developing habits requires a bit of time and discipline. It requires repetition and awareness. Habits keeps your calendar free from clutter associated with routine tasks or the general stuff of life.

Changes have been relatively slow to come to the App Store. However, with the addition of review copies, as well as limiting ratings to those who've purchased applications, Apple has made changes that have been welcomed by developers. I'm hopeful that the App Store will continue to improve over time and address additional issues.

Having more than doubled over the last two months, Gaming remains the largest category accounting for a quarter of all apps. The fastest growing categories were Education and Lifestyle. Medical is the newest app category and as of the end of November there were over 80 medical apps, the 10 most popular of which were free. Among Game apps, Racing, Music, and Sports were the fastest growing Game sub categories.

Have the iPhone use the gps data... upload where I was a minute ago and where I am now. Figure out my speed and route. Use the data to tell other RadaR users which route is best. It's worth $20 a month if you live in a place with traffic jams. It's a natural monopoly--once someone figures it out, why wouldn't everyone want to use the market leader?

Here's an easier one that you could probably sell as well. I type in a phone number and enter a time. Record a message and press go. I can cue up a bunch of messages that are based on time. I can have groups get the message I record, at the time I want them to get it.

The fix for pricing too low is really simple: raise your prices. Most $0.99 apps should become $9.99, $4.99 apps should become $14.99, and so on. With a $9.99 app, you’d make $7 per copy and at 16 copies per day, you’d make about $40,000/year. That’s not a great income, but that could potentially support one iPhone product being developed in some Iowan’s wheat field.

iPhone apps are typically much smaller and more focused than desktop apps and as such, should be priced accordingly. In addition, you need to take into account the much larger market that you’re dealing with here… Apple is selling well over 10,000 iPhones per day and these are all potential new customers, plus all the existing iPhone owners and iPod touch sales.

Generally, I use Habits to help with Sharpen the Saw type of tasks -- things I want to make sure I do every once in a while, but not necessarily at a specific time. Also, unlike a recurring event in a calendar, I can record how well I do with them (if I do them late, early, or skip them).

[...] crash as early as possible. It's no fun to figure out a crash bug once the culprit function has already returned. You really want the root cause somewhere on the call stack when it's detected.

1. Declare all of your object pointer @properties as retain unless you have a really good reason not to. Then the setter that is generated will automatically call retain when you assign. When you reassign, it knows to call release on the old value.
2. In your dealloc, assign all of your @properties to nil. This has the effect of calling release on the current values if they are not already nil.
3. alloc returns an object with a reference count of 1 -- so you have to balance with a release.
4. If you alloc, then you should try to release in that same function. To retain the value, assign it to something that retains. Exceptions are if you are a factory function that is returning a value up to be retained by the caller.
5. Obviously, each retain call needs a release.
6. Built-in convenience functions return objects that are autoreleased. That means you shouldn't call release on them -- the framework will call release at some point (they are registered in an autorelease pool that that is serviced when you return back to the framework). If you created the object without an alloc/init pair, you don't need to call release unless the docs say you do (but they probably don't)
7. Check all of your work with the leak detector. Also, if you crash, you're probably doing it wrong -- I will have more to say on that soon.

1. Go enroll in the iPhone developer program before you start. Yeah, I know -- it's 99 bucks. But if you have an idea and a reasonable chance of doing it, just take the plunge. I joined after I finished, and that caused a lot of delays -- I could have been completing the other necessary steps in parallel.
2. As soon as you're in, go get your application contracts going. If you want to make paid applications, you have to give Apple your tax and bank information. Again, it takes some time to get approved, so start early.
3. If you don't know Objective-C -- don't worry, that's the easy part. The primer on the iPhone developer site should be good enough if you know C/C++.
4. For Cocoa Touch, I recommend Erica Sadun's iPhone Developer's Cookbook. The chapter on coverflow is worth the price of the book, but everything else is there too (navigation, touch, location, contacts, etc)
5. I also highly recommend iCodeBlog. Once you have some basic knowledge of the framework, check out the to-do application tutorial.