As an AIR developer, I am in the position to feel it's problems more than it's capabilities. AIR's lack of extensibility is not an issue because that can be dealt with early enough to be a non-issue. Currently, my deepest concern lies with memory management: how do I keep memory consumption under control?
I am aware of all the potential sources of memory leaks (why are'nt event listeners using weak references by default? why does GC have to be so dumb that it'll dump ongoing HTTP request when nothing is holding a reference to URLLoader? Isn't an activity a reasonable reference?) so I've tried to deal with them proactively but, lacking sufficient tools, I haven't been able to pinpoint and address all the memory leaks, the kind that prevents my app from running for days. My AIR app starts off under 20mb on PC and 50mb on Mac (I have no idea why AIR burns more memory on Mac than PC) then starts adding about 10 meg per day. Reactive nature of AIR GC is not the issue because I've tried forcing GC proactively and can still observe leaks. As it stands, I can demo my app but it's definitely not ready for deployment because of the memory creep.
If Adobe wants AIR to succeed, they must offer better tools that enable developers to get a better handle on memory management because it's all too easy to make leak memory in AIR apps (try writing an Ajax-Flash hybrid AIR app, a double whamy of leak heaven). BTW, I am not interested in direct contact by AIR team to resolve my problems because, when I blog about a problem, it's almost never about just my problem.
Memory situation has been greatly improved by beta2 release of AIR. I still need to do more testing but memory footprint appears to be 10%~20% less and leaks down from torrent to trickle. I can sleep at night at this level. 🙂 Only sour part is that profiler will only be in the professional version of Flex Builder 3. Oh, well. I tried.