* 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/
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)
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?!)
In fact, it would probably be pretty simple just to create a little "packager" tool that packages the code into a special homebrew formula.
After all, this is what homebrew is for. Why reinvent the wheel?
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.
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.
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?
Relevant because HTML5 boilerplate has been insanely popular, though I realise what you're talking about is specific libraries.
JSONKit is faster.
I'm the person behind IOS Boilerplate. I didn't expect to appear at Hacker News. Sorry for the typos, I wrote the web site in less than 1 hour and I didn't check the spelling.
This project is work in progress. I'm learning from your comments and I will improve it. I just hope it to be helpful for some of you.
I will try to reply to some of your comments directly.
I'd base a new app on AFNetworking, not asi.
ImageManager is not needed, as AFNetworking is better suited.
Pull-down-to-refresh is overused already, and most times the wrong context. (Originally, you were loading new tweets ON TOP, not general loading)
The whole tableview examples shouldn't be necessary.
I wouldn't put maps in a example, most apps aren't gonna use it.
JSONKit is great, but also soon iOS4-Legacy.
Adding SVProgressHUD only leads to apps that over-use the modal-loading principle, like the GitHub Issues app. The better way is to make a non-obstrusive, non-modal loading inside the controller, which can be cancelled anytime.
As for the random categories... meh. Get BlocksKit or something actually useful.
BTW, I love DictionaryHelper, it definitely saves you a lot of headaches if you work with a JSON api!
I'm glad to see that DictionaryHelper is great for you :)
The 320 devs appear to still be on Xcode3, and demand a bunch of nonstandard settings on Xcode4 to make it work (including a scary script which edits your project in all sorts of ways).
He realized that Three20 was becoming pretty bloated and outdated and created this spinoff project.
I'd say both this and Three20 are pretty bloated and dated. They are both great reference projects to see how things could be done but in general there are a lot more lightweight alternatives out there.
For this to be really useful though I'd like to see all included projects being MIT licensed or something. Now it's a mixture of no license at all (EGOTableViewPullRefresh), BSH (ASIHttprequest), JSONKit is well licensed with dual BSD License/Apache License, SVProgressHUD has a license but it seems home made. And what is the license of the actual boilerplate?
Actually, I'll stop there. Lots of typos, you should get them fixed, it makes you look sloppy.
There's obviously no replacement for a real copywriter, but is there some service I can possibly run my site(s) through to try and automatically catch stuff like this? Maybe with an API to ignore certain technical words that they think might be misspelled? I could definitely see using that as part of a test or integration step.
Spell check hasn't been the exclusive domain of the big bulky word processors in years.
Is there anything similar for Android?
The rest of this I could really take or leave. Really wish there was something better than EGOPullToRefresh in wide use...
And though I don't have the exact numbers, AFNetworking is really fast, maybe 2-3x over ASI in average cases, from my experience and what other users report.
Take a look at the examples in the README and compare that to how you'd do the same in ASI.
MKPointAnnotation *point = [[MKPointAnnotation alloc] init];
point.coordinate = CLLocationCoordinate2DMake(35.01234, -115.56789);
point.title = @"The title!";
point.subtitle = @"The subtitle!";
You can add my category repo as a git submodule the boilerplate if you want.I have some cool stuff in there!
I feel like it would make more sense as a project template though. It seems like if I use this to start a new project, I need to clone the repo and then change a lot of classes to get started. Or am I missing something?
Alternatives are always emerging to even the most used frameworks. Every time I start a project it is a time to look and see if there are better ways to do things.
Also including frameworks that you will never use is bad practice. Most apps are not going to make use of MapKit. If you're not going to use it why bother bloating your project?
"At this moment iOS Boilerplate is just an XCode project. Is planned to be released as a true XCode template in a near future."
There are some legitimate uses for singletons, but if you need a singleton macro, you're probably over using it.
It's really for creating "shared" instances rather than true singletons, but who honestly needs a real singleton?
Anyone want to work on that and I would be up for it.
What features would you guys want?
Here's what I'd include:
* Robust JSON parsing examples feeding to a..
* Speedy list view
* Grid and List Menu Views
* DataTask examples
* Splash screen
* Palette values, Gradients in XML
* GeoLocation Snippets
* Nice defaults for text appearance
* Background service example
* Internet permissions
Anything you guys would want?