That's a big F-YOU to 3rd party support.
Recent Reviews
-
I was given the Ipod nano 6th generation for Christmas 2011. I was starting to take up running and needed something to track my run. since I just started I was only using my Ipod roughly 3 times...
-
I have had the iPad Verizon 4G LTE for a month now, and over all I couldn't be happier with the machine. The only issue I have found so far is when on wifi it has a slower speed in processing...
-
I have owned at least a dozen different Mac laptops over the years, starting with a Powerbook 1400 back in the day. The 13-inch Air is my absolute favorite of the bunch. It's the first laptop...
-
I spent quite a bit of time reading the setup manuals and various Apple articles about manually setting up this device since I have an unusual setup, and the setup manuals indicated I would have...
-
all i have to say is i love it its so much faster and i could just slip it into my purse p.s it has a ton of space for the 64gb
Steve Jobs slams Adobe Flash as unfit for modern era - Page 9

The hardest most costly solution is always better? No pain no gain? Why do you think an app is automatically crappy because it may have been written via compiler? I don't think users give a rat's a-- about the code. All they care about is whether or not what it does is useful, fun, or both, and if it works. The apps "written by hand" in native code from scratch are not immune to breaking. There are a ton of bad reviews for buggy apps on the app store right now, I doubt all of those apps were written via 3rd party compiler. Besides, the phrase "so what" comes to mind. Any company with an investment in a popular money making app will promptly update their product by whatever means (further motivated by an opportunity to sell it again to existing customers maybe throw in a feature or two and call it an upgrade). If they choose not to update their apps, again, so what. The user has the use of the original app until it's broken by an OS change. On average they paid all of a few bucks, vs never having the opportunity to use the app at all because it was excluded in the first place. If the app is on the expensive side, again, more incentive for the developer to update their product if it is selling well. If not enough people are buying it to make it worth keeping it running, again, so what if it dies. Do you think users's feel grateful to Jobs if their favorite app disappears from the store because Jobs chose to yank it at his discretion (as can happen no matter what) vs. it dying away because it was broken by an OS update? What's the difference from the users' point of view?
Frankly, I think you're letting yourself be suckered into buying Jobs' BS on this one. I don't believe this is about managing tightly controlled hardware specs tuned to their OS to maintain an optimal "user experience" as is the legitimate model Apple applies to it's computer business. I don't think it's about protecting the user by keeping them safe from sub-par apps or ensuring they won't break in the future (which can't done, no matter how the code was generated). It's about Jobs proclivity towards exclusion to a degree that goes a bit beyond rationality. It's about competition through trying to force developers to create products exclusive to the Apple mobile platform, betting on Apple as the 800 pound gorilla in the mobile market making developers who can't afford the investment in developing separately for multiple platforms chose Apple. It may be an approach that is better for Apple, but it's not an approach that's better for their customers, or developers who want to support their platform. Ironically in the long run, what is not in the best interest of the latter two is probably not the best for Apple either.
I completely agree and think this is a shot across the bow of Android.
Apple would like developers to choose one or the other. At this point in time they believe most will choose iPhone.
Unity clearly does not think that. They have state that, at best, they are uncertain.
I wanted to take a moment today to follow up on my blog post last Friday regarding the recent controversial changes in the the iPhone OS 4.0 beta ToS. The news about this change from Apple has drawn a lot of attention and stirred up very strong emotions in many developer communities, including ours. There’s also been a great deal of commentary about how these changes will be interpreted and applied by Apple and still more discussion about Apple’s intent with these changes. Unity learned of these changes with the rest of you just last Thursday and today, there remains a great deal of uncertainty about these changes being final and what we may need to do to comply.
We’re meeting with Apple next week to discuss the matter, and our engineers have been discussing possible technical solutions as well. Of course, we’ll provide you with immediate updates as soon as we have any new information.
Just in case the ToS changes do end up being a problem, we’re already working hard to find and implement solutions to maintain uninterrupted compliance with Apple’s ToS.
Though any uncertainly about Unity’s future on this platform is unpleasant, our feeling is that we’ll be okay. We remain firmly committed to providing you with the very best game engine for the iPhone, iPad, and iPod Touch. Thank you all so much for your patience and support. It means everything to us.
-David Helgason, CEO Unity, April 14, 2010,
Keyword being 'uncertainty'.
To be clear, you are probably correct in your belief that unity will be allowed, even if it means a exception to the rules. Just that if you are going to argue one way or the other, make sure that what you are stating is actually true.

That is not correct. You've been able to use hardware acceleration on the Mac for many years - as long as you use the correct APIs (CoreVideo, OpenCL, OpenGL, etc). Other companies did just fine using Apple's proper APIs.
Adobe refused to do so because they would have had to hire some real Mac programmers, and demanded that Apple give them direct access to the hardware - which is ALWAYS a bad idea, particularly for a product like Flash which is so full of security holes, anyway.
Furthermore, hardware acceleration affects only video playback. If that was the only area where Flash sucked, you might have a point. But Flash sucks CPU cycles and battery life and crashes and opens security holes even on sites that don't play back video, so Flash's problems go far deeper than this.
Again, you are generally correct. Adobe has had access to APIs, as others have, that should have allowed them to build a better Flash. But what Adobe was specifically talking about in this case was access to hardware acceleration for h.264. This is not asking for direct access to the hardware, but for access to an Apple API for hardware acceleration through the NVIDIA GPU for H.264. This was not available for Mac developers until recently, except for apps that were simply Quicktime wrappers.
However, Adobe is being intentionally misleading here, as they make it sound like access to this would magically make Flash better all around. It would not. It would definitely make H.264 playback perform better, but that is part of what Flash offers. Even if access to this API made their H.264 playback as good as possible, it doesn't make the rest of Flash any better. It won't make it less buggy, it won't make Flash crash my browser less and it won't help any video type other than H.264. They are also being disingenuous in overstating the scope of how access to this API will improve the Flash experience for Mac users in general. It will only benefit those Macs with the newer NVIDIA cards, so the majority of Mac users will see absolutely no benefit.
But they were being honest when they claimed that did not have access to this specific API. Now they do and it is up to them to show everyone that can actually make a useable Flash. They won't.
"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. Sometimes it's both.
"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. Sometimes it's both.

Well, fair enough. My apologies. This is one of those things that happen on message boards sometimes. You see, from my perspective, that post is NOT how it started. But now I can more easily see where you are coming from, since that's where you jumped in.
If you want more context, go back and look what I was responding to at that point. "SpotOn" had just offered the HP Slate as PRESENT TENSE evidence that Flash is not a problem. You came in just in time for my facetious response, and I (mistakenly) took your information as a continuation of the earlier debate. I honestly thought you were holding up the HP Slate as a valid example of a mobile device that suffered no performance degradation from Flash. I couldn't fathom that conclusion from the evidence you offered, but there it was (or so I thought).
Note: FWIW, I still have my doubts about the HP Slate hitting the market any time soon, if ever, and I also question how good its battery life REALLY will be under the load of Windows and Flash. HP has to realize that if the battery life is only 5 hours and the OS is too "filesystem like", that it will get laughed out of the contest just like earlier tablets have been.
And, note to self: don't be facetious in print. It doesn't come through.
Thompson
No worries man. I figured there was some sort of mixup

AMusingly enough, look what we see this morning regarding the Slate: http://www.dailytech.com/article.aspx?newsid=18269

Show us this proof that using more power doesn't require power. We'll all be waiting right here in reality for you to return.
You can test this yourself so lying isn't going to win any favour. Unplug a laptop, any laptop, then open up Chrome or Safari. Play a YouTube video using HTML5. Check the battery time remaining. Then play that same YouTube video using Flash. Check the battery time remaining. Repeatable, empirical evidence.
Click the links in my signature.
Flash Player 11 upgrades: http://is.gd/ZN8Zp7
Flash Player 11 upgrades: http://is.gd/ZN8Zp7
Click the links in my signature.
Flash Player 11 upgrades: http://is.gd/ZN8Zp7
Flash Player 11 upgrades: http://is.gd/ZN8Zp7
You're buying a lie. Try doing research.
Take them shoes off your teeth and stop runnin your mouth -- Lil Wayne
Flash Player 11 upgrades: http://is.gd/ZN8Zp7
Flash Player 11 upgrades: http://is.gd/ZN8Zp7

OK, then maybe you can explain to me how Adobe managed to break the laws of physics.
When I run Safari and stay away from Flash sites or use clicktoflash, my computer never gets hot and CPU usage for Safari is 10-20% max. As soon as I go to a Flash site, the CPU usage shoots over 100% and the bottom of the computer gets very hot.
Now, if the computer is getting hot and the CPU is doing much more work, where is that coming from if not from the battery? I'm really interested in the mechanism they're using to create heat and power CPU cycles that doesn't use the battery.
Physics? Really? Guy, you're grabbing at straws. iPhone wouldn't run Flash Lite, it would run Flash 10-10.1 and those are proven to outperform HTML5 implementations and 10.1 is optimized for mobile use.
Flash Player 11 upgrades: http://is.gd/ZN8Zp7
Flash Player 11 upgrades: http://is.gd/ZN8Zp7

And yet, Adobe keeps slipping the go-live date. Repeatedly. As long as it's a prototype, it's a prototype. Call me when we can run some benchmarks on performance and battery life.
The thing is, I doubt anyone from the Android team at Google will have the stones to tell Adobe that performance sucks and it's not ready. So I'm sure it will eventually ship, but I'm unconvinced that it will be worth a sh!t when it does.
10 is GPU optimized. 10.1 is even more so. 10 has a 97.0% adoption rate. HTML5 has a 0% adoption rate. If you want to talk betas, consider that HTML5 is just a draft spec. Don't talk about what you don't know.
Flash Player 11 upgrades: http://is.gd/ZN8Zp7
Flash Player 11 upgrades: http://is.gd/ZN8Zp7
Yes, physics. Get yourself an education and maybe you'll understand it.
It's very simple. My laptop doesn't get hot when I'm not running Flash. As soon as I run Flash, the computer gets very hot and the fans come on. Ergo, Flash is generating much more heat than the non-Flash activities.
Physics says that the heat can't appear from nowhere. There must be energy used somewhere. The only energy source is the battery. Proof positive that Flash has excess battery consumption.
None of your Adobe shill web sites refute that simple fact. In fact, none of them address battery life at all. So please stop with the lies. Until you can find a way to break the laws of physics, you're wrong.
I'm also curious why it is that you can't even read Adobe's specs? Flash 10.0 is completely incapable of running on iPhone-like devices. Flash 10.1 (even if it ever comes out) requires an 800 MHz A8 - which doesn't exist on any current iPhone. So where do you get that the iPhone would run Flash 10.1?
(Not to mention, of course, that early reports are that 10.1 isn't all that good even on a 1 GHz Snapdragon).
You Adobe shills aren't very good at what they're doing.
Gatorguy 5/31/13
Gatorguy 5/31/13
He's just trolling. Each post filled with more and more lies. He stated that "HTML5 has a 0% adoption rate" when it's the basis of WebOS and in Android and iPhone OS' browser for years now. He also claims that the Cortex-A8 @ 800MHz system that is needed to run Flash 10.1 is more efficient than the ARM11 @ 400MHz system that can stream video just fine. He's obviously invested somehow or paid by Adobe to troll here. I've reported him to the mods.
- Joined: Jan 2008
- Location: Flyover country
- Posts: 1,780
- offline
- Select All Posts By This User
The only people who are this rabid about supporting Flash are the deluded script kiddies who only know how to do connect-the-dots "development" and insist on calling themselves "programmers".
Google Maps: ("Directions may be inaccurate, incomplete, dangerous, or prohibited.")
MA497LL/A FB463LL/A MC572LL/A FC060LL/A MC700LL/A MD481LL/A MD644LL/A MD388LL/A
Google Maps: ("Directions may be inaccurate, incomplete, dangerous, or prohibited.")
MA497LL/A FB463LL/A MC572LL/A FC060LL/A MC700LL/A MD481LL/A MD644LL/A MD388LL/A
Fair enough, too.
Well, I do believe that it's going to create some turmoil in "developer land", that much is certain. I have no idea how much. I haven't even tried to estimate it, so your statement that I "underestimate" is basically true by default. I guess we'll find out just how many developers and/or SDK creators pitch a fit like that Adobe employee did. That may be our only measure going forward. The two tools that you mentioned (i.e. MonoTouch and Unity) seem to be OK with it... as far as we know at this point. So perhaps it's much ado about nothing.
With regard to the end user in this case, it seems that the "turmoil" is limited since the precedent of control has been set in the early stages. (Of course, other colorful words have been proposed to describe the closed ecosystem, but "turmoil" is not one of the main ones. The other adjectives are best left to another thread!) And likewise this control will minimize "turmoil" to Apple when they need to move the platform forward. Minimizing turmoil to Apple and the end user seems like something that Apple is historically interested in. As for the developer...
What I have been talking about here, and what Steve means too, is something I learned from experience: starting fresh with a useful third-party API to create an application can be very fruitful. Kind of like a marriage in the beginning. And then the honeymoon ends and the maintenance soon begins. (Back talking only about code, lest I piss someone off...) It's the maintenance that becomes a nightmare, and not just for the developer. I'm talking about the end user, the developer, and Apple too (if enough applications used the third-party SDK). When a whole slew of applications either break or get left behind when platform transitions occur, the end user gets mad. And they blame the developer or Apple. The SDK creator gets a free pass, at least in the public eye. The developer can rant and rave all she wants (begging for an updated SDK) but she is at the mercy of the SDK creator. And if she has millions of lines of source built around that SDK, there is lock-in, and there's not much she can do about it but wait, and wait, and wait some more. Meanwhile, the customers are waiting, many of them angry at everyone except the creator of the SDK (whom they know virtually nothing about... nor do they care). It's a bloody nightmare, and if you've never lived it, then I can see why YOU might underestimate or not even appreciate that.
Also, whereas it may seem like I'm talking about something that *might* occur, it's not like that. As a rule, with any application that depends on a third-party SDK, this maintenance issue will happen eventually. That is especially true now that we are in the middle of a technology shift. Who knows what processor the next iPhone will have? Perhaps it will have a different byte-order, and some of these SDKs will break. (This is only an example. There is always something that trips up an SDK if the underlying change is non-trivial.) With XCode, you will only have to flip a switch to compile for the new processor. If you also use something else, you may have to wait a year. Literally. With pissed customers. And if there is another significant change in the meantime... ugh! ... the configuration management becomes very sticky (for everybody, including the end user who doesn't understand why there are so many complicated versions)!
I agree that Apple is interested in maintaining App market space advantage, by forcing developers to choose. But lest you think that is the only, or even the primary, reason, you should know that they made a similar move to control the development tools for Mac OS X when they introduced XCode and froze out Metrowerks. And this was done as an underdog, where it was decidedly NOT in their interest to wall themselves off if all they desired was business dominance. By the way, in case you go there, in order to accomplish this control all they had to do was stop helping Metrowerks and others. (The Mac OS system APIs are far more rich than the iPhone OS at this point in time.) So they didn't have to introduce this language in the developer's agreements. But I figure they would have if it were necessary to accomplish the goal. We all switched over to XCode in fairly short order, and the transition to Intel went much more smoothly than it otherwise would have. (Sure, the emulator helped, but I'm talking about the development of Universal code.)
My conclusion: yes, Apple is interested in maintaining their App Store advantage. But my experience and evidence is enough to convince me that they would have made this move even if it would not have been immediately beneficial to their market share position. (As with Mac OS X in the past.) Two birds with one stone, here.
Thompson
Well, you put a hell of a lot of words in my mouth right there. I didn't say any of that. Using a third-party API can be very useful at first, and the applications can be great. Then the maintenance starts, and it is always an issue, not just sometimes and not just for Apple or the developer. Please look at my response to backtomac just above.
Then you say some things that are true, and I agree with...

I don't think users give a rat's a-- about the code. All they care about is whether or not what it does is useful, fun, or both, and if it works. The apps "written by hand" in native code from scratch are not immune to breaking. There are a ton of bad reviews for buggy apps on the app store right now, I doubt all of those apps were written via 3rd party compiler.
Besides, the phrase "so what" comes to mind. Any company with an investment in a popular money making app will promptly update their product by whatever means (further motivated by an opportunity to sell it again to existing customers — maybe throw in a feature or two and call it an upgrade).
... exactly, and that's where the trouble comes in. What if there is great demand for an updated application, and the developer absolutely wants to sell an update, but the SDK developer in the middle is slow to update the tools that the developer is now reliant upon? Screwed. What if the SDK is finally updated, but in order to maintain continuity across multiple platforms, some of the new capabilities of one particular platform are not exposed to the developer? Then your app starts to become stale and crappy relative to your competition. You might think that these issues give the tool maker sufficient incentive to update their tools, so they can charge the developer again, but that doesn't mean they will be able to do so in a timely fashion. There would essentially be an uncontrollable mechanism smack dab in the middle of the development chain, and in a dynamic environment that is absolutely a serious issue. Show me someone who says otherwise and I'll show you someone that hasn't been there, done that.

Do you think users's feel grateful to Jobs if their favorite app disappears from the store because Jobs chose to yank it at his discretion (as can happen no matter what) vs. it dying away because it was broken by an OS update? What's the difference from the users' point of view?
Well the difference is a matter of scale. The seemingly arbitrary pulling of apps is bound to be maddening to an affected user. In my mind, there is a valid debate that could be had regarding that.
The difference here is that instead of a relatively small fraction of apps going bye-bye (presumably for a reason, which is debatable on a case-by-case basis) we have potential for a significant number of apps going bye-bye for no good reason at all other than the complicated development chain.
It's clear to me that you haven't lived the development nightmare that I've described above. It's also fairly common behavior that if someone hasn't experienced something firsthand, then they tend to question the value of the lessons learned. Add this to a fairly common opinion of Steve Jobs as a manipulative prick, and *POOF* of course you aren't going to believe him. That's your prerogative.
But that doesn't give you the right to assume ANYTHING about me, least of all that I am a sucker. I don't suck up to Steve Jobs. I'm going by my experience, and it just so happens to match his explanation in this case.

I don't believe this is about managing tightly controlled hardware specs tuned to their OS to maintain an optimal "user experience" as is the legitimate model Apple applies to it's computer business. I don't think it's about protecting the user by keeping them safe from sub-par apps or ensuring they won't break in the future (which can't done, no matter how the code was generated). It's about Jobs proclivity towards exclusion to a degree that goes a bit beyond rationality. It's about competition through trying to force developers to create products exclusive to the Apple mobile platform, betting on Apple as the 800 pound gorilla in the mobile market making developers who can't afford the investment in developing separately for multiple platforms chose Apple.
And I believe that BOTH reasons are true. For my reasoning, see my response to "backtomac" above. In particular, I believe that Apple would have made this same move even if they DIDN'T have the market share advantage right now. They've displayed similar behavior before, when they were the underdogs.

It may be an approach that is better for Apple, but it's not an approach that's better for their customers, or developers who want to support their platform. Ironically in the long run, what is not in the best interest of the latter two is probably not the best for Apple either.
I disagree. Given the tectonic shifts that are about to hit, developers and users will be much better off if the development system is streamlined. It looks like there are still going to be useful 3rd party tools out there (backtomac pointed me to MonoTouch).
Thompson

No worries man. I figured there was some sort of mixup

AMusingly enough, look what we see this morning regarding the Slate: http://www.dailytech.com/article.aspx?newsid=18269
I had a hunch that was going to happen after HP bought Palm and provided their reasoning. It just didn't make sense to me that HP would try to march down two different tablet roads at once. And while a HP/Palm tablet has an uphill battle because it will arrive late to the Apple and Google tablet party, success with Windows 7 in the near term is even more unlikely. So that's the one I figured would get punted.
Thompson
- Joined: Jul 2009
- Location: Newport Coast, CA
- Posts: 373
- offline
- Select All Posts By This User
Too long; did not read. IIRC
"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. Sometimes it's both.
"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. Sometimes it's both.
"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. Sometimes it's both.
"My 8th grade math teacher once said: "You can't help it if you're dumb, you are born that way. But stupid is self inflicted."" -Hiro. Sometimes it's both.
I didn't say you said anything. I offered a sardonic response, while taking your statements to implied possible conclusions in question form inviting clarification (notice the question marks). You offered clarification, thanks.

... exactly, and that's where the trouble comes in. What if there is great demand for an updated application, and the developer absolutely wants to sell an update, but the SDK developer in the middle is slow to update the tools that the developer is now reliant upon? Screwed. What if the SDK is finally updated, but in order to maintain continuity across multiple platforms, some of the new capabilities of one particular platform are not exposed to the developer? Then your app starts to become stale and crappy relative to your competition. You might think that these issues give the tool maker sufficient incentive to update their tools, so they can charge the developer again, but that doesn't mean they will be able to do so in a timely fashion. There would essentially be an uncontrollable mechanism smack dab in the middle of the development chain, and in a dynamic environment that is absolutely a serious issue. Show me someone who says otherwise and I'll show you someone that hasn't been there, done that.
Lot of "what ifs" there. What if the SDK developer in the middle is quick to offer an update because they want to remain a viable, reputable player on the Apple mobile platform? Not screwed. What if a particular OS update has no impact at all on existing apps? Not screwed. Apple releases regular updates for OSX, I can't remember when it resulted in a broken application that hobbled me. Most applications running on Apple computers, except ones developed by Apple for Macs, are cross-platform. For the most part there is parity between platform versions for major software, but certainly not always. As someone who does 3D work I can tell you there is often great disparity between platform versions of 3D apps. If Apple applied the same rationale to their computers, Macs would disappear for lack of software. Why does it makes sense to ham-string their mobile platform developers using that logic? You run the same risk using a computer (like switching from PPC to Intel) of software usability being substantially lessened or outright broken within a platform as you would with a mobile device. Code, native or compiled, can be broken by any update. With regard to iPhone/iPad if the app is selling will enough, the developer can rewrite it from scratch or should be able to use whatever tool they want to use if it suites their bottom line. It should be their choice. In reality, we're talking about $3 to $5 dollar apps that usually no user will find brings their life to a grinding halt if an update breaks it. If it's worth while for the developer to find a way to fix it, they will, if not, they won't. Same as any app, no matter the code. You could argue that any 3rd party SDK has a very high incentive to stay up to date and release timely fixes to allow their customers to fix their products in turn.

It's clear to me that you haven't lived the development nightmare that I've described above. It's also fairly common behavior that if someone hasn't experienced something firsthand, then they tend to question the value of the lessons learned. Add this to a fairly common opinion of Steve Jobs as a manipulative prick, and *POOF* of course you aren't going to believe him. That's your prerogative.
But that doesn't give you the right to assume ANYTHING about me, least of all that I am a sucker. I don't suck up to Steve Jobs. I'm going by my experience, and it just so happens to match his explanation in this case.
Er, uh, talk about rather arrogant assumptions. You have know idea the nature of what I do for a living or the projects with which I've been involved. I can tell you from experience that I know full well the headaches of broken products due to bugs in authoring apps. However, I'm not going to declare being involved in said process at whatever coding level something to abandon because no authoring ap (or programming language for that matter) is full-proof or guaranteed free of trials and tribulations. Every developer is the one assuming the risks of their capital, and their resources to develop for any platform. They should be allowed to decide what risks they want to take as far as which tools they want to use, not Jobs, unless he is going to get into the app development business to keep his mobile products worth buying. I think Jobs' declaration that he doesn't want to be bothered in any way with considering what he does to his OS and hardware doesn't break apps that are written for it, so he will dictate what tools developers use is too one-sided. He might as well say he doesn't want to be bothered with developing products based on what users want, instead of what he wants them to want. Oh, wait...
- hill60
- Tomorrow Calling
- Joined: Dec 2008
- Location: straya
- Posts: 5,056
- offline
- Select All Posts By This User

Except those technologies can't do half of what Flash can and to develop with the canvas tag (which is not really open standards either) takes a zillion times longer to do even the simplest animation. Furthermore to deploy an HTML5 application is more difficult as it is not encapsulated like an swf. It has several bits an pieces, which in some cases, conflict with other parts of the Javascript on a page and is difficult to debug.
I totally agree that Flash is made for PC and not for mobile so no complaint about the lack of Flash there, just the criticism of Flash in general as serving no purpose in today's Internet, that I disagree with. Until there are better development tools for HTML5 and universal browser compatibility, it amounts to nothing more than dumbing down the web. Flash is a much more powerful application platform than javascript and your code can be encrypted so others cannot steal your work. Not so much with Javascript (is possible but trade secret)
"The cobbler's children have no shoes", is a saying that applies a lot to companies who provide products and services. -KDarling on Google Search.
"The cobbler's children have no shoes", is a saying that applies a lot to companies who provide products and services. -KDarling on Google Search.
In my experience, when a slew of sardonic questions come out in rapid fire, the intent is usually to score points via rhetoric rather than invite clarification. Given that you were actually inviting clarification and that you thanked me for my (clearly valuable) clarification, I can only say "you're welcome".

Lot of "what ifs" there. What if the SDK developer in the middle is quick to offer an update because they want to remain a viable, reputable player on the Apple mobile platform? Not screwed. What if a particular OS update has no impact at all on existing apps? Not screwed.
Yes, there are a lot of "what ifs", and there are a whole bunch more that I left out. The point to realize is that it only takes ONE of these "what ifs" to bite you, as opposed to requiring all of them to happen simultaneously. And as I said earlier, given the pace of technological transition these days (which puts the 1980's computer revolution to shame) each of these "what ifs" have a nontrivial probability of occurring, especially as multiple companies jockey for domination of the huge emerging mobile market.
So here's a thought experiment for you:
Premises:
* The next big technology market is the mobile market, and it is enormous.
* The technological landscape of this market is highly dynamic.
* The bigwigs at Apple have forward strategy meetings on a regular basis.
Conclusions:
* At their regular strategy meetings, the Apple leaders strongly consider "what ifs".
* Because of the dynamics involved, the Apple leaders realize that they must stay nimble.
* The Apple leaders realize that they can't have a third party in their development chain, else their ability to stay nimble is compromised.

Apple releases regular updates for OSX, I can't remember when it resulted in a broken application that hobbled me. Most applications running on Apple computers, except ones developed by Apple for Macs, are cross-platform. For the most part there is parity between platform versions for major software, but certainly not always. As someone who does 3D work I can tell you there is often great disparity between platform versions of 3D apps. If Apple applied the same rationale to their computers, Macs would disappear for lack of software. Why does it makes sense to ham-string their mobile platform developers using that logic?
You are comparing a relatively steady state situation (in computer OS's) to an unbelievably complicated and competitive one right now (in mobile devices). In the early days such as this, there is always jockeying for position. You can't apply the same rules and expectations.
Apple goes to extreme efforts to ensure that whenever they make a major change that requires recompile of applications, they simultaneously (if not a bit in advance) release a development system that makes it easy on the developer to make the transition. (You just saw it with the developer's release of iPhone OS 4.0) But they can't force a third party to stay in lock step. Time and time again, the third party lags and/or underwhelms. You may be inclined to simply dismiss that argument because I can't offer any better proof than my own experience (and you want to discount it). These are FACTS from a developer's experience. That's what you're not getting.
I already DID argue that in the very message that you are responding to. But for whatever reason (manpower, perhaps?) I am telling you that timeliness is the exception, not the rule. I am speaking from experience here, not idealistic philosophy (as you clearly are).
This is a freaking mobile gold rush, from the very bottom (vendor hardware specs and software operating systems) to the middle (developers doing battle, services doing battle, file formats doing battle, etc) to the top (users looking for best capabilities). Delays due to circumstances beyond your control are harmful right now.

Er, uh, talk about rather arrogant assumptions. You have know idea the nature of what I do for a living or the projects with which I've been involved. I can tell you from experience that I know full well the headaches of broken products due to bugs in authoring apps. However, I'm not going to declare being involved in said process at whatever coding level something to abandon because no authoring ap (or programming language for that matter) is full-proof or guaranteed free of trials and tribulations.
If you are making the analogy to "authoring apps" then you just proved my point. Your level is about 4 layers up from the platform, and by the time the changes propagate up to you, we're a year or two down the road from the fundamental change. In the mobile devices world, things are changing too quickly for that. You won't see 3rd party authoring tools on this platform for a very long time (if ever, since the screen is too small anyway). The "coding levels" that you admit to not "being involved" with are one level above the platform, which is far more relevant to this discussion.
Thompson
Outstanding.
He's given his reasons. Adobe and 'Flash' fans may not like them. But that's that. And there is no way Adobe are going to extend their desktop of monopoly onto the 'true' portable revolution that is going to hit them and Microsoft like a Tsunami.
He's offered them an olive branch, such as it is. 'Get back to creating 'creative' tools...and support open standards and you won't get yourself in this sort of mess in the future. Or get off your lazy ass and create lean, innovative programs.' Their design and programming model are going to have to change as the enter the 3rd Great Age or they will die. Or certainly be significantly diminished as a force. Adobe, a 'creative software' company who think they are a 'standards company'. They've lost sight of who they are because they spent a few billion on a company to take out all competition. Now their ten year complacency ride on the desktop is coming to an end (just like Microsoft...) as we enter a new age where 'monopolies' in one area don't guarantee success in another area. Create and innovate. Apple are. Apple nailed the 'eco system' and the rest of their competitors to the cross. In Adobe's case? Upside down on that cross. In short, they've had it coming for a long, long time. For ten years we've had to put up with their laggardly, grudging support, lack of feature parity and the shabby treatment of Mac users as 2nd class citizens and charging us exorbitant prices for that privilege of being Adobe customers and insulting us with 'Windows' interfaces with buggy ports. And to add insult to injury, the shoddy port of flash to the Mac. Buggy, insecure crash bait...with crap video quality...a complete cpu hog running on ancient tech'. Jobs must be rubbing his hands that his competitors are rushing to implement flash on their ultra portable devices. See how they'll do in battery comparison tests... And even if Flash gets GPU support for video, I doubt that acceleration will work across the board...
I'm looking forward to what Apple do next. 10.7 is going to be...very intriguing. I'm guessing a U.I makeover and some more 'killer' features. The candy floss will return. I suspect a '7 inch' iPad possibly at some point. Maybe even a hybrid 15 inch iPad/iMac touch crossover. Signalling a future without the traditional 1984 desktop metaphor..?
Apple are well placed.
Applauds Job's 2nd Era at Apple. A masterclass in execution of products and the competition.
Lemon Bon Bon.

Seems to me that Flash is about doomed. H.264 has been on the rise, while Flash has been declining, according to Encoding.com. There's a whole chart about it here
Flash is far from doomed and has many, many years ahead of it as the de facto method for interactive animated content. . It's been pushing H.264 video for quite awhile now.
What is on the way out is Flash being the ideal way to push H.264 video across the web. On the desktop, it will take awhile for the majority of browsers in use to accommodate the HTML5 video tag so Flash as a fallback option will still be an option well after it's not the most commonly used option, something that may happen sooner than people think considering the growth of devices running mobile OSes over growth of devices using desktop OSes.
Taking out the competition and creating a 'creative' monopoly..?
If the current price hikes and glacial feature innovation are anything to go by then Adobe is indeed a monopoly.
The fate of 'Freehand' is an interesting story in the context of Adobe's public bleating.
Lemon Bon Bon.
- Steve Jobs slams Adobe Flash as unfit for modern era
Recent Discussions
- › Inside iOS 7: Apple's Weather app gets animated 2 minutes ago
- › Steve Jobs discusses his legacy in rare 1994 video interview 5 minutes ago
- › Adobe releases major update to Creative Cloud desktop apps 6 minutes ago
- › Inside iOS 7: iBeacons enhance apps' location awareness via... 6 minutes ago
- › Google's Nexus 7 tablets dying early, possibly due to cheap memory 15 minutes ago
- › High resolution images claim to show 'iPhone 5S' and iPhone 5... 26 minutes ago
- › Apple tweaks Siri responses to help prevent suicides 37 minutes ago
- › New Mac Pro's radical design draws admiration, criticism via Photoshop 55 minutes ago
- › Rumor: Russian video shows iPad version of iOS 7 beta 1 hour, 7 minutes ago
- › ISLAM WATCH 1 hour, 18 minutes ago
Recent Reviews
- › Apple iPod nano - 16GB, Silver MC526LL/A (6th Generation) by cc420
- › Apple iPad with Retina Display Wi-Fi + Verizon/Sprint 4G - 64GB,... by Aaron Krahn
- › 13.3-inch Apple MacBook Air MD231LL/A (Mid-2012) by ahilal
- › Apple Time Capsule - 2TB (MD032LL/A) by biyahero
- › Apple iPad Wi-Fi - 64GB, White (MD330LL/A) by raeganapril
- › Apple Magic Trackpad (MC380LL/A) by WisdomSeed
- › Aperture 3 by bcbcbroderick
- › 17-inch Apple MacBook Pro MD311LL/A (Late 2011) by bcbcbroderick
- › Apple iPod touch - 32GB, Black MC544LL/A (4th Generation) by bcbcbroderick
- › Apple iPod touch - 8 GB, White MD057LL/A (4th Generation) by bcbcbroderick
New Apple Wikis
- › Midtown Space-Dyed Dress by anthinfrank
- › Striped Day Dress by anthinfrank
- › Click here to buy the leave two OL dress by billedwarder
- › Adding in some fashion elements in ol dress, by billedwarder
- › 2013 'Modified' iPod touch by Mikeycampbell81
- › 2013 MacBook Pros by Mikeycampbell81
- › iPad mini 2 with Retina display by Mikeycampbell81
- › 2013 iPhone 5S by Mikeycampbell81
- › Trade in your old devices for holiday cash by Kasper
- › How to sell your old iPad for cash by Mikeycampbell81
About AppleInsider | Join the Community | Advertise
© 2013 AppleInsider is powered by Huddler Tech | FAQ | Support | Privacy/TOS | Site Map





