No, first time was 2.x, a LONG time ago. 3.1.3 wasn't actually such a problem by comparison - blackra1n or redsn0w worked for most (albeit not too well in some cases), and the exploit that would work in the few cases where they didn't was only held back because of the iPad, back when both models were due to launch in late march. The real killer in the 3.1.3 case was the baseband.
Yeah very weak response that is. They can't answer in a straight and direct manner, always try to shift the focus to something else, avoiding the main problems.
Microsoft's take: "Theres been a lot of posting about video and video formats on the web recently. This is a good opportunity to talk about Microsofts point of view. The future of the web is HTML5. Microsoft is deeply engaged in the HTML5 process with the W3C. HTML5 will be very important in advancing rich, interactive web applications and site design. The HTML5 specification describes video support without specifying a particular video format. We think H.264 is an excellent format. In its HTML5 support, IE9 will support playback of H.264 video only. H.264 is an industry standard, with broad and strong hardware support. Because of this standardization, you can easily take what you record on a typical consumer video camera, put it on the web, and have it play in a web browser on any operating system or device with H.264 support (e.g. a PC with Windows 7). Recently, we publicly showed IE9 playing H.264-encoded video from YouTube. You can read about the benefits of hardware acceleration here, or see an example of the benefits at the 26:35 mark here. For all these reasons, were focusing our HTML5 video support on H.264. Other codecs often come up in these discussions. The distinction between the availability of source code and the ownership of the intellectual property in that available source code is critical. Today, intellectual property rights for H.264 are broadly available through a well-defined program managed by MPEG LA. The rights to other codecs are often less clear, as has been described in the press. Of course, developers can rely on the H.264 codec and hardware acceleration support of the underlying operating system, like Windows 7, without paying any additional royalty. Today, video on the web is predominantly Flash-based. While video may be available in other formats, the ease of accessing video using just a browser on a particular website without using Flash is a challenge for typical consumers. Flash does have some issues, particularly around reliability, security, and performance. We work closely with engineers at Adobe, sharing information about the issues we know of in ongoing technical discussions. Despite these issues, Flash remains an important part of delivering a good consumer experience on todays web. Dean Hachamovitch General Manager, Internet Explorer" http://blogs.msdn.com/ie/archive/2010/04/29/html5-video.aspx
The simple answer? Jailbreak. Here's a novel idea, how about you worry about your own goddam phone, and NOT worry about mine or anyone else. If you can't jailbreak your phone, it isn't my problem and I don't care. Not my concern. I specifically use frameworks and languages that are suspect. Flickitty could easily be in violation right now. I'm not losing any sleep over it. I'm a developer. It's a ****ing iPhone. There are tons of other opportunities out there and I am resourceful. If Apple doesn't want me on their platform, I am not going to cry about it. The upside is that the EXACT third-party tools that Apple is trying to stop allow cross-platform compiling. It's not like the the project is immediately at a dead end, it can be pushed to another platform. These apps should be relatively easy to find, don't you think? If this is true, then Adobe shouldn't have any problem complying with Job's VERY SIMPLE request to show proof of Flash running on any mobile device. Personally, I'd like to see it.
Flickitty, what's all the fuss about? I happen to have an opinion that differs from yours. I tried to convey it in a respectful manner. My apologies if I have failed to do that. You've made a ton of great points. I agree with most of what you said -- the iPhone is just one opportunity, and there are many others. There have always been stumbling blocks in the TOS which could cause a great, high-quality, family-friendly app to be rejected. I recognize all this. However, I still stand by what I said. I think the TOS was modified in an immoral way. I signed up for a smart phone. I have no desire to endorse anyone's opinions on what is or isn't functional software, which is essentially what iPhone users are being forced to do. Jailbreaking may help a little with what runs on my iPhone, but it does not solve the problem of the TOS being immoral.
Incorrect. All MC models are un-jailbreakable unless you've already saved your ID on Saurik's servers. Otherwise, you can't downgrade to 3.1.2 and jailbreak. I should know, I accidentally upgraded to 3.1.3
Yes, but only that specific model/firmware combination, meaning not everyone was affected (unlike with 2.x), and those who did upgrade were anyway left with a far bigger problem because of the baseband situation. The only reason a fix wasn't release sooner (it's actually due tomorrow, AFAIK), was because of the iPad delays.
The singlemost reason my browser crashes on my computer is always due to Flash. I hate, hate, hate it when my browser crashes and I lose some (if not all) of my open windows. When Steve Jobs wants to remove that and force the considerably more stable HTML5 onto people, is it wrong? In a way yes… But is it what I want him to do? Most certainly, yes.
I think the other important point here, that Steve Jobs raised, is this: Allowing cross platform middleware (like flash) to generate iPhone app code, will put developers who choose to use it at the mercy of the middleware maker when it comes to supporting new iDevice hardware/sofware features. I think this one is key. Apple of course wants to bring the latest features they implement in sdk/hardware updates to the developers, and so onto consumers. They don't want to have to rely on some abstraction layer controlled by another company, with competing interests, exposing when and how those features should be available.
It's time to move on......steve stand up and go like you did in the 90's... Oh, forgot...you didn't left, they FIRED you ....time to do it again! Some little brainwash and then come back next year. With a better philosophy and the flashcompiler in the bag.
I don't want to paraphrase your quote too much Flickitty, but if we're talking about the iPhone packager in CS5, Flash is perfectly suited for creating touch applications, and it can handle multi-touch gestures as well. As you said yourself, one can make crappy code in any language, even in the "chosen languages" sanctioned by Apple. If done right, I think developers could build some fantastic content using the Flash iPhone packager. I would think all Apple developers should be concerned about the new TOS changes, not because Apple seems to think there's a good technical reason for banning cross-compilers, but because they also seem to think that they're right to tell developers what languages they can and can't program in. I'm sorry, but I just don't get it. If the binary works, and it doesn't crash the phone, why should Apple care what tools/languages I used to create it with? Personally I've heard all the arguments against the Flash iPhone packager, but even the most cogent ones seem to fall a bit short. The only real explanation can be that Apple feels threatened by anything they can't completely control. *** EDIT: Had to edit my response a little... It's very frustrating to engage in this Flash on iPhone argument because the discussion is never very clear-cut as to whether we're talking about Flash in the browser, or the CS5 iPhone packager. I saw a lot of talk about the TOS, so I assumed the packager.
But they have every reason to feel threatened, and react to it. The choice is between controlling or being controlled, on their own platform. There are a lot of flash developers out there who would likely start using the packager straight away. I don't think the argument about how this would allow adobe to control the delivery of apple's features to these developers falls short at all. It's a huge issue, and allowing it would be a very risky (and potentially messy) path for Apple to go down.
Haha. He's completely turned around Apple, he's making billions, and increasing profits by huge margins each year. Why would they ever fire him over blocking Flash?
it's not just because of flash....Questionable Approval Process....No crosscompilers allowed....high amount of restrictions for users&developers and he wants to get in war with any big company such as google, adobe etc. Google entered the mobile market and steve jobs got pissed off, remember? Googles Dont Be Evil Mantra Is Bullshit, Adobe Is Lazy' ... On Google: We did not enter the search business, Jobs said. They entered the phone business. Make no mistake they want to kill the iPhone. We wont let them, he says This guy got totally crazy Google for sure entered the mobile market just to kill the iphone, yeah right. Adobe is Lazy, sure, they have a big Portfolio of superb Tools for Webmasters,Designers,Visual Effects Artists etc. for Win & Mac .... yeah totally lazy So guess why he doesn't allow cross-compilers. This is for sure one big reason. Do the work twice if you want to publish for android aswell.
The "no cross-compilers allowed" thing is open to interpretation. Read the revised 3.3.1 again: Although it says stuff must be "originally written in", how is Apple going to tell the difference between a cross-compiler such as, say, GLBasic, and native C/C++/ObC code when GLBasic converts everything directly over to native Objective-C code that must be compiled in the iPhone SDK? Simple answer: They can't. What's preventing someone from using a cross-compiler that does this? Nothing, unless you want to interpret 3.3.1 to the strictest letter, and to be honest, I don't actually think that's in the spirit of Apple's intent with this revision to the dev agrement. Apple want to prevent third-party middleware from coming between developers and the features of the device. I'm not talking about packaged sets of APIs like Unity that add easy to implement features on top of the SDK. I'm talking about compilers and middleware that get used instead of the SDK. It's all fine and well to use these when they support all documented features of a device. But when new features become available, developers who use these will be at the mercy of their creators as to when such new features will be supported properly. Technically, alternate development environments and languages like GameSalad, Torque, GLBasic, and the rest fall under this category too, but they also produce native Objective-C code, and GLBasic even supports inline Objective-C code, so if it doesn't support a feature you want you can inline and use the real ObC code in your own GLB code. Probably things like GameSalad would be something Apple is intending to cover with the revised 3.3.1, but as it produces native Objective-C code how would Apple ever know? Point is, Jobs does have a point with regard to developers being at the mercy of third party IDEs supporting new features, especially new features of new devices. Apple supports their own new features through new APIs right away. Others will take varying amounts of time to support them. Apple wants to encourage innovation and use of new features, and they can't do that when third party dev environments take their sweet-ass time to add support for them. From their point of view it does make sense. I'd personally like to see that choice left up to the developer -- if they don't want to use certain new features or have no use for certain new features I think they should have the option of using whatever environment they're most comfortable with -- but I'm not going to kick up a fuss about it. There are alternatives, either that do not fall under 3.3.1 or could be used with impunity despite 3.3.1 for lack of Apple's ability to tell the difference.
Exactly why apple won't let flash. They don't want another company to have control on their own platform.
People have very short memories. My last pre-iPhone phone was a Nokia N95, a symbian S60 phone with a 3D chip which, thanks to it's relatively low resolution screen, was effectively more powerful than the original iPhone. It also had an almost identical accelerometer to the iPhone. What was the software like? Mostly crappy java ports, backward compatible with five year old phones with tiny screens. The few that used 3D games were software rendered and chugged along at <10 FPS with no filtering or even perspective correction, giving sub-PS1 results. Apple just don't want to see people coding games that might work better on someone else's device. I can totally understand why they don't want people making slightly compromised generic games for the iPhone but surprised that they have taken this step. It makes them look scared and upsets developers when the app store and it's apps could have kept Apple on top indefinitely anyway.
I don't get it. That sounds like a vindication of what Apple is doing. Why would they want to replicate Nokia's failure by allowing under-performing software?
