There's no free opportunities on this market unless you scrap web results of one of the paid services. With our experience when you start scrapping web results you are promptly spotted. The scrapped site might continue to give you web results but with a rather long lag e.g. 10 secs. This can be OK for the development stage but is too much for production.
We are using XML based FlightAware API. They are the cheapest data provider we found. If you make up to 10K queries per month (Class 3 queries that we employ) you pay only $0.002 for a query. With more queries a fee for a single query decreases. Down to $0.0003 if your application is lucky to generate millions of queries per month. See pricing for details.
FlightAware has excellent coverage of US flights (including non-passenger) but European and especially Asian sectors are missing a lot. There are too many non-US airports and airlines are not supported by the service.
Our statistics shows that we have 35% of searched flights not found by FlightAware for 60% of our customers in Europe & Asia. This is rather dissatisfying and we plan to employ FlightStats API for flights not found by FlightAware. Unfortunately each FlightStat query will cost us triple of FlightAware (see FlightStats pricing).
FlightStats API is used by a handful of mobile app in the Apple's AppStore Travel section. We've analyzed customer feedback for several of them and found that FlightStats tends to provide reliable flight status data all over the globe. Nevertheless we found some complaints on their data accuracy.
Flightradar24 might look like a good alternative if you are interested only in European flights. Unfortunately it looks like there's no public API now. We didn't contact developers directly as Jets app requires world-wide coverage.
I've been hunting for memory leaks in the Jets project this afternoon. One of the things I love so much about programming is that you keep finding new and amazing things day after day.
While trying to remove a leak today, I found out that copy method of immutable objects complying to NSCopying protocol may not actually copy. Sounds weird? It just doesn't make a copy of the object but rather returns same object with incremented retain count.
Another article I would like to recommend in connection with my leaks-hunting is Rules to avoid retain cycles from the same Cocoa with Love blog. I can remember reading it two years ago but it's still fresh and important. I think it becomes even more important with the announced compile-time garbage collection in iOS5.
According to this post, there's now a network link conditioner in the new Mac OS X Lion. It looks like there's no more need to run across the city trying to find a place with poor connection in order to see how an app will behave or configure ipwf. You can just set the connection type and quality you are about to test for.
If you still use Snow Leopard (like I do) or you want to configure the downlink to a particular bit-rate, you can use ipwf on your Mac.
Tables and grouped tables are looking very nice and behave pretty much like native. This alone is enough for me right now to quickly develop a tree of information pages for my application. HTML coding is generally simpler and can be faster accomplished. The system feedback is much faster (no boring builds :) ).
The framework also provides a set of animations and input elements which will help to build a certain number of apps non-distinguishable from native. I guess there are more and more HTML apps appearing in the AppStore nowadays. I can remember seeing a document processor app (like Quickoffice) developed using HTML5 but cannot remember its name.
The developers said on the website that even Swipes (!) are supported but I didn't succeed swiping through the table cells.
I hope that getting web interfaces closer to native ones will facilitate more and more web-sites looking just like native app from your iOS browser (probably same is true for Android). The WWW will unite with Mobile ;)