featherless

From a quick glance at the docs (http://applinks.org/documentation/) it appears that this standard depends on the web to define app links independently from the apps themselves. Basic flow would look something like:

- user submits content with a link to http://imgur.com/vxKOi to your social app of the month

- another user taps that link in the app

- the app would look at that url's header and pull out any applink information.

- using the downloaded links, the app would try to open the imgur app with the provided url

- the imgur would then open, showing the content for the url that was tapped.

Note that none of the above mentions being on an iPhone, thus the cross-platform nature of the solution.

IRC channel here: http://webchat.freenode.net/?channels=##atom

Thought this was amazing: $20 for a one-way, 35 minute trip from SF to LA.

Which parts aren't working well for you?

I'll look into it.

tl;dr Use Instruments while running on the device (not the simulator) to pinpoint the highest avoidable CPU usage and then optimize the relevant code. Repeat until the scrolling is buttery smooth on a 3GS :)

We definitely had a blast optimizing the app :) Gotta love Instruments.

Glad to hear :)

Done!

https://github.com/jverkoey/iOS-Framework#resources

I'm writing up the guide for resources right now :)

I wrote this article if you have any questions.

It takes a few hours for the app to percolate through the App Store.

Yay!

Three20 is mostly in a bug-fixes only state right now. The fact is that the framework is complex enough that the cost of adding a new feature often outweighs the benefit. This is the main reason why I've decided to start anew with Nimbus and so far the progress has been really great.

Going forward I'm planning to dedicate a chunk of my mornings to working on Nimbus, splitting my time between going over pull requests and building new features. I love building tools to accelerate the development process of other iOS developers and plan to continue doing so for the foreseeable future.

I want to clarify here that feature complete and "done" are two different things. The app was not finished when it leaked and is still actively being worked on.

I also really want to emphasize that my time at Facebook was incredible and my reasons for moving on were remarkably complex, none having to do with any dislike for Facebook or ill feelings. The number of hours I put into the project were out of genuine passion for the product, not because anyone was forcing me to do so.

I want to clarify that the app has not been "done" since May and that my experience working for Facebook was incredible. The amount of time I spent working on the project was purely because I enjoyed it.

Thanks for providing a solid service :)

As a developer of iOS frameworks and libraries, I will vouch for cocoacontrols as a solid site. It's easy to add a new entry and search for existing controls by license.

Hah, just did the exact same thing with a chocolate cupcake.

One aspect of this is that it is easy to abuse. Three20 (the framework currently backing the iOS app) has an implementation of the launcher control but doesn't provide support for the zooming launch animation.

As a result, we've seen apps like rdio using the launcher in a way that goes against the user's expectations of how a launcher should work. Instead of zooming the controller in from the center of the screen, the controller gets pushed onto a navigation stack. In rdio's case, they should have built a simple table view with each 'sub-application' having its own row. Tapping one of those rows would then push the controller onto the navigation stack in the same way that it currently does with the launcher.

-- From a holistic user experience applications "spring forth" from the system launcher, creating a consistent feeling of two functional modes in the operating system. The first being finding and launching applications, the second being using the launched application. Introducing a third layer of launched sub-applications complicates that model, oftentimes unnecessarily.

iPad is 'that' hard because it is non-trivial to take advantage of the new screen real estate. Often-times you must implement a completely new navigation model because the stock split view controller is rarely the navigation model you want to use.

iPod touch is generally easier. It usually comes down to gracefully degrading features. Much care must also be taken to ensure that the app performs well on the iPod touch models which are often running much weaker hardware specs. The reality is that sometimes devs will only test on their personal iPhones and forget to test on older-gen iPod touches, so the iPod touch experience can sometimes be less than ideal.

There isn't one, afaik.

Even more awesome. Thanks for fleshing out the list Jesse :)

Just to ensure the correct people are given credit here, Velocity is Sean Van Koughnett's brainchild and he pushed the university to build the Velocity program. He's a great guy and the city of Waterloo is fortunate to have had his efforts dedicated to this.

Also, I want to address one of the grandchild comments. It's important to enforce the fact that Velocity is not simply a place for engineers or math students. It's a place to meet passionate entrepreneurs and build startups. The mindset of "arts/bus students are surprisingly useful" is outright disrespectful, and discredits the value of fresh insights and diverse skill sets.

I put this together early 2009 as a fun side project. It supports many standard web tools and languages.

I'd love to answer any questions about it.

I'm the project maintainer, so if you have any questions I'll do my best to answer them.

Good to see that Hacker News has now become a place devoted almost entirely towards griping.

That's a really cool implementation. Nice work!