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.
So here is my solution after giving it a little thought:
Instead of a base template project, we need a modular system for adding dependent packages on a case by case basis similar to python eggs and ruby gems. Just a simple set of command line tools.
Then you could build a central repository of formula scripts for adding frameworks to your project (maybe something simple like how homebrew just uses really simple ruby scripts and built in git awesomeness to keep it up to date and power a good portion of itself and allow others to submit forumlas via pull requests).
The formulas could pull down code from these various project's hosts on an as needed basis and they could be downloaded right into a standard "/vendor/" folder in your project directory when installed. A file would created with install info and time it was pulled so you could easily update the project later with another command.
Then maybe update (or maybe not) update your project file to reference it, add target dependencies, add header search paths or copy file operations for frameworks, etc. (This could be done by generating a base xcconfig file that links in xcconfig files provided by each forumla install into the project).
All these packages could be added to this system and allow the user to search and find great libraries, install them, keep them up to date, and whatever.
(If no body else does this, I may end up do it actually)
I have started something like this, although I would barely call it alpha at this point. I would be willing to abandon it and contribute my effort elsewhere if there's another project further along or with a better design, but I offer mine for consideration.
It's in the process of being renamed apothecary. It's based around using git submodules for importing other people's code. I was really tired of instructions like, "copy all of these files into your project." (Really?!)
I agree, it's definitely not boilerplate material but it is certainly a good "starter kit" for a beginner dev, assuming of course that he will need all these libraries for building his app. Otherwise he just downloaded one big bloated project template.
I think this sort of thing would work better as a list of common problems that you encounter when doing iOS dev and the possible frameworks with example projects.
Having one massive Xcode project with all of these things already integrated is just begging for abuse. Novice devs who make this their goto Xcode project template and not really understand what these frameworks do are going to hurt themselves in the long run.
Hi reidmain, I'm a novice dev that is now becoming an iOS dev thanks to this project. I found it quite illustrative in facing the basic stuff when you start an iOS project... hope won't hurt me in the long run though! ;)
My recommendation to you would be to not use any of these frameworks to start. If you come to a point in your project where you think you would need one then write it yourself and use these frameworks and their alternatives as references.
I have written my own version of basically all of these frameworks (except for JSONKit because JSON parsing is incredibly complex and efficiency is very important) and I am a better iOS dev now because of it.
If every time I needed to do a HTTP requeste I just included ASI I would not have learned as much as I did about network connections and iOS.
Lines of codes are a horrible metric. Having 10+ "frameworks" that you don't understand automatically included in a boilerplate project is just bad practice.
Explaining why these frameworks are useful in certain scenarios and how they work are more important in my opinion.
Also including frameworks like MapKit in a boilerplate project is just wrong. Why not add every Apple framework to the build phase so that novice devs will never by accident and an #import and get a compile error because the framework wasn't added to the project?
Agreed to a point. It's kind of apples and oranges to compare the HTML5 stuff to iOS, though. Apple provides pretty much all the boilerplate stuff you could ever need with few exceptions. That's not to say nobody should ever try and improve on the Cocoa APIs.
HTML5 boilerplate isn't exactly minimal. By design, it includes the "kitchen sink" which developers are expected to customise. There's now a customiser to choose what you need, and also http://www.initializr.com/ formore minimal builds.
Relevant because HTML5 boilerplate has been insanely popular, though I realise what you're talking about is specific libraries.
yah, HTML5 boilerplate if you use it as your boilerplate, you will end up using all of it because it provides everything that you will need to end up providing in some fashion every single time time. This project is just a collection of libraries.
I am writing an app using the new compiler with ARC enabled, I am glad no more release and autorelease in my code, but some big third party libraries not working under ARC, it costs me more time on re-creating features :-(
Completely agree. This particular stack of technologies is quite unfortunate, in my opinion. I'd strongly warn against any iOS developer using any one of these libraries, let alone all of them as a foundation.
I don't agree with all of the items listed, but I think JSONKit is a really nice piece of work. What would you use instead? I know there is native support for JSON handling in iOS 5, but 1) I don't know how that stacks up against JSONKit performancewise (if anyone has benchmarks, that would be excellent) - but JSONKit really flies, especially when directly handling raw bytes instead of an NSString and 2) It will take quite some time before iOS 5 is the de-facto standard. FWIW I used to use SBJSON and switched over to JSONKit and have not looked back.