Hacker News new | past | comments | ask | show | jobs | submit login
IOS Boilerplate: A base template for iOS apps (iosboilerplate.com)
306 points by jamesjyu on Sept 14, 2011 | hide | past | web | favorite | 82 comments

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/

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?!)

You mean like your "Contributing to acd" instructions? :)

neat, but to much haskell to make an objective-c dev ok with using it.

So true. In fact, this is one of the main reasons (in my opinion) that Node.js has seen such explosive growth. A package manager makes sharing code, keeping it updated, etc., so much easier.

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'd love to do this. The hard part is getting Xcode to cooperate :\

This sounds really cool. I'd love to be a part of this somehow.

had something like that in mind for quite some time.. too much heavy lifting every time you drop in something like.. SSToolkit or stuff. Let's start something!

Sounds brilliant!

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.

Agree 100%.

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.

Please, count the lines of code. This is not a "massive" project. The documentation is very simple. These frameworks won't hurt you in the long run. They are very simple.

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.

ImageManager uses ASIHTTPRequest. So there is just one HTTP library.

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 :-(

ARC can be enabled on a per-file basis, which means you should be able to use third party code without modification in your project.

Big thanks for reminding me, I just found this: http://stackoverflow.com/questions/6308425/ios-5-best-practi...

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.

Forgot JSONKit was in there—that is a solid piece of software. I've used it for all of my projects. My bad.

if anyone has benchmarks, that would be excellent

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.


There are much better choices now, this project is a bit outdated.

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.

"ImageManager is not needed". As a novice to iOS programming, I'm curious to know what is the preferred way to retrieve and cache remote images and display them in an ImageView. Thanks.

SVProgressHUD is non-obtrusive. In the example that uses it you can go back, and the HTTP request is cancelled.

Good job, I love this. I find that FastCells are less useful these days as iphone 3G are less common. I prefer to design my complex cells in interface builder for ease of maintenance. But it's just personal taste. Otherwise, everything in there should be very useful for almost any app. I suggest you add support for external services, like Facebook for instance (which a lot of projects use).

BTW, I love DictionaryHelper, it definitely saves you a lot of headaches if you work with a JSON api!

I still find FastCells useful if you're laying out cells with lots of subviews, even on modern iOS devices.

I have a 3GS and FastCells are a great improvement in performance.

I'm glad to see that DictionaryHelper is great for you :)

How does this project compare to the three320 project originally started by Joe Hewitt from Facebook? 320 seems to have more features:


320 is a little bloated and pretty difficult to keep working in Xcode 4 today.

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).

Nimbus by Jeff Verkoeyen is inspired by Three20 https://github.com/jverkoey/nimbus

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.

This project is much more lightweight. three20 certainly has more features, but it is large and relatively complicated compared to this. IMO, this project has a much more narrow scope. And that is a good thing when I don't need all the three20 features (the majority of the time). For all the good three20 does it can be cumbersome to integrate into a large project, and it's documentation is less than stellar.

320 was written in a manner that is very non-Cocoa like. We cringe when we get a project that uses 320.

I use three20, but only to use TTStyledTextLabel - is there a better way (now) to put rich text in a cell?


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?

I have added the license terms in each file I have created. Any suggestion is welcome. I just want anybody to be able to use it without limitations, just keeping the copyright notice.

Typo 2nd bullet, "freamwork", 3rd bullet "intented".

Actually, I'll stop there. Lots of typos, you should get them fixed, it makes you look sloppy.

Forked, fixed, and pull request sent: https://github.com/gimenete/iOS-boilerplate/pull/1

Thanks a lot. I merged your changes :)

Not the author, just a general question:

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.

Any modern text editor?

Spell check hasn't been the exclusive domain of the big bulky word processors in years.

Despite the typos, it does look interesting.

Is there anything similar for Android?

It's not really a boilerplate version, but there's a great answer on StackOverflow that keeps a list of pretty solid 3rd party libraries.


A much easier way to add async HTTP and image requests would be to just use AFNetworking (https://github.com/gowalla/AFNetworking)

The rest of this I could really take or leave. Really wish there was something better than EGOPullToRefresh in wide use...

I typically use PullToRefresh from https://github.com/leah/PullToRefresh instead of EGOTableViewPullRefresh. It positions itself as a superclass that handles all of the logic, rather than an external object that handles the delegate methods (as EGO does).

Obligatory plug for Resty: https://github.com/lukeredpath/LRResty ;)

How is AFNetworking easier than ASIHTTPRequest?

Simple block-based API, significantly less lines of code to accomplish the same tasks, and smaller, more understandable codebase that uses Foundation classes (e.g. NSURLRequest, NSURLResponse, etc.), rather than re-inventing the wheel

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.

doesn't ASI also use blocks? its syntax is very similar. but i didn't know about that it's much faster than ASI, thanks for that

This is awesome. Thanks for the tip.

AFNetworking looks great, but I'm also curious as to what the advantage is over ASIHTTPRequest.

Ever since HTML5 Boilerplate was launched, a whole plethora of projects have been popping up which were inspired by it. Thanks to all the main devs of H5 Boilerplate and projects a like. Makes learning easier and fun!

Looks good. Just FYI: There's already a MapKit class called MKPointAnnotation that provides a simple implementation of MKAnnotation, so your Place class is redundant:

    MKPointAnnotation *point = [[MKPointAnnotation alloc] init];
    point.coordinate = CLLocationCoordinate2DMake(35.01234, -115.56789);
    point.title = @"The title!";
    point.subtitle = @"The subtitle!";
    [point release];

Thanks for your comment. I didn't know about MKPointAnnotation.

>There is an example of how to calculate the directions between two points using the Google Maps API and showing it on a MKMapView using map overlays. See DirectionsExample.m.

FYI I believe using the Google Maps API in this manner runs afoul of Google's terms. Google only wants you to use their directions information on top of maps loaded for web sites via their JavaScript interface. MKMapView doesn't qualify.

I stole a few categories from you into my Category Repo.Hope you dont mind. https://samyzee@github.com/samyzee/Additions

You can add my category repo as a git submodule the boilerplate if you want.I have some cool stuff in there!


When I saw this, I thought "wow, this is pretty much exactly the same stuff I include every time I start a new iOS project."

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?

Having to copy in 4-5 frameworks every time you start a project is not a bad thing.

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?

i agree with you, especially on not including MapKit

From the site:

"At this moment iOS Boilerplate is just an XCode project. Is planned to be released as a true XCode template in a near future."

You are. There are much better choices out there. Check AFNetworking for example.

i had never heard of AFNetworking until today. definitely going to try it out.

As someone just getting into iOS, this looks very useful, because it's a bunch of coherent ObjC code to read, presented in a beginner-friendly way. I'm also glad I read the HN critiques, though - knowing that some of this will be batteries-included in iOS 5 is valuable.

Interesting stuff. Does anyone have a "goto" list of IOS libraries documented anywhere? I've heard there's a nice DRM library for IOS apps but I haven't had any luck finding it so far.

This is great so far, you have an excellent taste in frameworks. It's also nice and light weight. I would suggest adding a singleton macro. Will try and put some of the boilerplate stuff I use in as a pull request when I get the time.

I used to love the Singleton (anti-)pattern. It's a huge improvement from using your AppDelegate as a global storage area, but it still encourages sloppy code. I find it the code much cleaner when you pass in the objects a class needs instead of calling up the singleton from all over the place.

There are some legitimate uses for singletons, but if you need a singleton macro, you're probably over using it.

I'm no fan of singletons either, but writing one with GCD dispatch_once is pretty simple. Nevertheless, I do have a macro for it:


It's really for creating "shared" instances rather than true singletons, but who honestly needs a real singleton?

This is cool!

Typo - "It is not intended to be a freamwork"

Thanks. Solved :)

This would be much more interesting for the Android IMHO.

Anyone want to work on that and I would be up for it.

I've been thinking about doing this for a while - I basically have one that I use for my personal projects, but I could clean it up and document it and use make it a public boilerplate.

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?

Code to extend the Google Map component (such as a clickable BalloonOverlay, fast OverlayItem grouping). I'd contribute my own code for this to such a project.

Very cool, thanks!

This is awesome!

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact