I 'kind of' understand that, like the Flash Plugin on the desktop, they don't want tons of crashes that they have no control over fixing.
If I'm allowed to release a Flash compiled app for the iPhone and it starts bombing, and then 42,000 others do the same, there's a lot of apps on the iPhone that Apple wouldn't have control over.
Last thing they want is everyone saying "My iPhone crashes ALL the time" and not be able to do anything about it. ESPECIALLY with multitasking coming and maybe somewhat hard to put the 'blame' on what is crashing the phone as it might be a background app?
No this is not correct. This is not about Flash player. This is about coding something in the Flash system that is then "rendered" for iDevices, as if they were coded in Apple's native SDK. As such, the resulting render is just an app, much like any other app, and Apple has just as much control over that app crashing 42K times, or 42K Flash SDK created apps crashing. Apple can simply turn them off (or apparently Apple even reserves the capability to delete them from your iDevice) just like they can with any Apple SDK-created apps that prove buggy.
The "loss of control" is about the idea of the iDevice platform moving forward while these other iPhone app compliers lag behind. More simply, Apple rolls out new iDevice OS features and naturally these alternative compilers would need to be updated so that subsequent programming of updates or new apps could take advantage of those new features. It doesn't mean that all the Apps coded that way would break, not run, etc- just like any other App coded in Apple's SDK keeps running just fine as the iDevice OS moves forward. It would just mean that new OS features would not be able to be incorporated by App developers until these other platforms were updated to accommodate the new coding options. That lag between how long it takes for them to update is the "loss of control" thrown around as part of the whole mix of bash-Flash arguments. The fact is that multiple App SDK programs could drive competition in terms of putting dev tools in the hands of programmers that make it possible to do great things more easily. Competition is always good for end users.
There are tons and tons of games & applications on the net that are not yet in the App store. A great deal of these Apps are coded in Flash. With Adobe's solution, those could be fairly easily transcoded for iDevices, which could bring tons of "new" games & applications to iDevices in the near term. Instead, Apple's block means those reasonably ready to transcode programs cannot come over so quickly... and not at all unless the developers then learns Apples ONE way of coding for iDevices, and then chooses to port that program.
If we put ourselves in the shoes of the little app developers, the ability to develop in a platform that could then render for multiple OSs on multiple devices just means that they can bring their "wow" apps to lots of mobile devices at the same time, rather than having to learn one coding environment for one line of devices, then another for another set of devices and so on. That would give them the capability to make a lot more money by rolling out their App on multiple platforms, which then becomes the tangible fuel for creating more great Apps from that person(s).
Very, very simply: if certain great apps would only come to the iDevices via the Flash transcoder, Apple's block means those great apps do NOT come to the iDevices, unless the coder then takes it upon him/her/themselves to learn to also code in Apple's SDK. I'd rather have the choice of having those apps (NOW), than have Apple's move block them- or delay them- from coming to the iDevices. As with so much of this bash-Flash crap, it would be so much nicer if Apple would allow us to choose for ourselves.
