Hacker News Reader

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)

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!

I'd love to do this. The hard part is getting Xcode to cooperate :\

Sounds brilliant!

Something like "kits"?

https://gist.github.com/582228/e1f475afec526b04a585cf517a727...

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

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.

https://github.com/eraserhd/acd

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

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

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?

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.

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.

if anyone has benchmarks, that would be excellent

JSONKit is faster.

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