Just wanted to clarify.... Adoby is not providing an IDE like in your comparison. They are providing a layer that is common to all phones. Developers use this layer to write the code so it can run on iPhone, Android and anything else.
In my opinion there are several issues here:
1) Programmer not commited to the iPhone platform
2) Programmer wants one program to run everywhere just like the promise of Java (run anywhere) which did not work well, tends to cater to the lowest denominator.
4) Because of 1 and 2 above, the programmer is not interested in learning the iPhone APIs and the Apple provided tools.
5) Apple is interested in iPhone developers also being Mac deveopers which is another reason they want the developers to learn the tools.
6) The layers added by the Adobe environment are not likely to keep up with changes made in the iPhone APIs so they will rarely be taking advantage of better APIs and new capabilities.
7) The way the code is produce may interfere with the Apple way of doing multitasking and may in turn drag all the other applications down and drain the battery.
8) Additional layers makes applications bigger, also may introduce additional security risks.
9) When issues arrise, it is difficult to tell if the problem is with the iPhone, Apple's APIs, the programmer code, or Adobe code. This results is longer time to repair the issue and Adobe may take months to correct an issue. This can easily cause the developers all sorts of headaches and lose customers, but today they don't seem to have taken that into consideration.
I think the key here is: Is the developer a dedicated iPhone developer or do Is the developer going to write for all other phone also?
Is the developer willing to learn the tools and produce optimal code?
Is the developer going to keep up with the API and correct bugs as quickly as possible?
Ugh. I really think that the manner Apple wants developers to write will typically allow for the best programs, but I have to argue for not having these restrictions because the Apple way will not *always* be the best. Sometimes, maybe a good portion of the time(I don't know since I'm a windows developer not an iPhone developer), the different manners will produce equivalent programs. Many programs just aren't that complex technically, in terms of middleware or API needs.
I think issues you mentioned aren't dependent upon middleware or language:
1. Programmers can be uncommitted to the iPhone even if they're going Apple approved route. Most programs only require a small amount of the API and thus don't really require that much commitment from the programmer.
2. Since the iPhone market is already healthy, lowest common denominator apps shouldn't be an issue - they will fail compared to apps optimized for the iPhone. An app can be written using middleware and still be optimized for the iPhone.
3.
4. If using middleware, programmers only need to know what is necessary to optimize for the iPhone. Some middleware will have code for platform specific optimizations.
5.Programmers can use middleware and other languages to write for the Mac too.
6.If they don't keep up, and the api in question is important, then the middleware will fail because of competitors that don't use the middleware. This means middleware companies will be fairly responsive. Middleware companies have these issues between various versions of windows - the succesful ones keep up with changes and allow you to optimize for different platforms.
7. Apple simply shouldn't allow these apps in the marketplace. The middleware companies will fix their code to be multitasking friendly.
8. This is really dependent upon the middeware. Good middleware will make your program more secure despite possible increase in code size. This is because, with good middleware, they have experts working on their code that can concentrate on security. This leaves less stuff for the App developer to worry about and possibly get wrong. Most application developers are horrible about security (across all platforms).
9. This is sometimes true. But using middleware can also save a developer time when creating feature, so this is a trade-off.
Additionally, I think people are ignoring the fact the alternative language or middleware could be used just for the business logic. The business logic is the part of the code that should have little to no exposure to the API. This can be cross platform without affecting usability.
