This isn't really necessary and most of these packages will be obsolete in iOS 5 and using a few them (like ASIHTTPRequest) will get you in trouble with ARC.
* JSONKit - It's an ok choice but there are literally 5 choices I can think of off the top of my head (not including the now built in JSON support in Lion and iOS 5). I prefer SBJSON because it was once benchmarked with the fastest read speed and it has a dirt simple interface for me as a dev.
* ASIHTTPRequest - I used to swear by it, but now NSURLConnection in Lion (and iOS 5) has async methods with blocks. ASIHTTPRequest doesn't play nicely with ARC because it doesn't have a conventional pattern to object ownership (design to make it less to work to deal by deallocing itself for async usage).
* ImageManager - cute, but it's one of many solutions and this one takes some of the cache control out of my hands. I don't believe it resuses ASIHTTPRequest so now I have two HTTP libraries in my project and I'm juggling between both.
* The numerous category packages to extend and add convenience methods - these are all cute but I like to take things on a case by case basis and not add code bloat and unused functionality in one shot.
The problem that I have is that unlike HTML5 boilerplate which is a common subset of the absolute minimum you are going to need 99% of the time that is put together in the best possible manor, this is just a collection of various packages that you probably will not end up using more than 50% of in most applications. It's not really a "boilerplate" for that reason.
Edit: my coworker sent me this when he saw I wrote this reply - http://xkcd.com/386/
* JSONKit - It's an ok choice but there are literally 5 choices I can think of off the top of my head (not including the now built in JSON support in Lion and iOS 5). I prefer SBJSON because it was once benchmarked with the fastest read speed and it has a dirt simple interface for me as a dev.
* ASIHTTPRequest - I used to swear by it, but now NSURLConnection in Lion (and iOS 5) has async methods with blocks. ASIHTTPRequest doesn't play nicely with ARC because it doesn't have a conventional pattern to object ownership (design to make it less to work to deal by deallocing itself for async usage).
* ImageManager - cute, but it's one of many solutions and this one takes some of the cache control out of my hands. I don't believe it resuses ASIHTTPRequest so now I have two HTTP libraries in my project and I'm juggling between both.
* The numerous category packages to extend and add convenience methods - these are all cute but I like to take things on a case by case basis and not add code bloat and unused functionality in one shot.
The problem that I have is that unlike HTML5 boilerplate which is a common subset of the absolute minimum you are going to need 99% of the time that is put together in the best possible manor, this is just a collection of various packages that you probably will not end up using more than 50% of in most applications. It's not really a "boilerplate" for that reason.
Edit: my coworker sent me this when he saw I wrote this reply - http://xkcd.com/386/