First, let’s get one thing clear… Flash is NOT coming to iOS per se. To quote the press release from Adobe:

“With Flash Media Server 4.5, media publishers can extend their already broad mobile reach via Flash-enabled devices, with the new ability to deliver video content to Apple’s iPad and iPhone devices, enabling them to reach the widest audience possible.”

Unless I’m misreading this, it seems that this is only going to allow Flash Video to be viewed on iOS and only when streamed from the new Flash Media Server. This will be achieved by serving the video in an iOS compatible format so there’s no new player or plugin involved at all. Flash content in general (games, interactive sites, &c) will still bring up that familiar
.

This is only a little bit exciting (unless you host a lot of Flash Video). What the end user will experience is potentially more video content available on their iOS device, perhaps from sites that they couldn’t get it from before, and they may notice a performance improvement. It’s a far cry from the headlines stating things like “Adobe releases Flash player for Apple products” or “Adobe Flash coming to iOS”. Still, it’s a (small) step in the right direction.

Frustratingly, most of the articles I’ve seen are tinged with insinuations that this is some sort of surrender, for example, “Apple did not fold, Adobe did.” Really? Are we still acting like these two companies are having a little schoolyard rivalry? Nobody folded or cried “Uncle”. A company just found a solution to a technology problem. As I said in my last post, this sort of talk creates an artificial sense of certain technologies being inherently “good” or “bad”. It misinforms the general public and turns the choice of platform for a project into an emotional or political battle.

On the other hand, as much as I want people to get the story straight, this is more good news for Flash developers. If the general consensus is that Flash will run on iOS then our clients will perceive it as less “bad” and more “good”. So I guess this is bad reporting of so-so news that will make very good PR for Adobe.

Why?

I have always felt that it is our duty as technology experts to help our clients chose the best platforms for their products. And sometimes the best platform is the one that lets the developers do their work the fastest. Flash has always been great at adding a lot of character, subtlety, and interactive flair much faster than other platforms.

Unfortunately, due to recent high-profile skirmishes between Apple and Adobe, most clients currently think that “Flash is Bad.” They don’t understand that Job’s argument is full of half-truths and non-truths and most probably don’t realize that Flash code can now be run on an iDevice and more importantly sold for $$$. While Flash certainly ins’t the best in every situation, it’s actually a fantastic choice for a lot of applications and the programmers who have been using it for a long time who have honed their skills as interactive developers can add a lot intrinsically to their work. To say that it is “Bad” is to ignore much of the bigger picture.

Having a solid example to point to makes the case for using Air for iOS so much easier. And despite our cries, clients don’t really care about technical reasons… they DO care about top-selling apps that look beautiful! So next time you’re faced with a client who’s using some overhyped article from 2010 about Flash not performing well on mobile, you now have one more weapon in your arsenal. The more tools we have to deliver great experiences for our clients, the more everyone wins.

Also, I’ve heard this is a pretty good game!

If this happens to you, it’s because 3.2 isn’t available on the iPhone yet, so regardless of your active configuration, the project has to run on iPad. For now, to fix this, you’ll want to roll your project back to iPhone OS 3.1.3 or earlier. Just go into your project info → Build Settings and set the Base SDK to iPhone Device 3.1.3 (or what have you). You’ll also want to make sure that SDK version is active in the Active SDK run settings.

I know this little fix is only going to be necessary for a short while, but if you were one of the 14 people wondering why this happens, there you go.

So here’s a few screencasts I found around town on debugging, that I wanted to share. Do yourself a favor and watch them.

First up, a series of two screencasts by Jeff LaMarche on debugging basics. I’ll reiterate, even if it starts out basic, you might learn something since it seems everyone uses the debugger differently. Part One, Part Two. Key takeaways:

• Dude. Just drag the breakpoint out of the gutter to remove it. I’ve been right-clicking the damn thing my whole life. Sighhh….
• XCode breakpoints are heckuv powerful. Use symbolic breakpoints, conditional breakpoints, and breakpoint actions wisely.
• Single most important thing: Add a symbolic breakpoint on objc_exception_throw. Newer XCode builds have a menu item for this in Run→Stop on Objective-C Exceptions.

Next, a screencast on debugging EXC_BAD_ACCESS, which is raised when you access an object that has vanished into thin air, most likely because you over-released it. This screencast from Mark Johnson shows you how to debug these errors with Instruments and NSZombies. You’ll see how to generate a complete history of any object, from allocation and including every release or retain. You’ll also see how to find the objects of interest by enabling zombies (you know, after your object is completely released and freed it sticks around, undead). For those of you who see Instruments and aren’t quite sure what to do with it, just watching Mark use it is helpful. My takeaway was that it’s much easier and nicer to use Instruments than to enable zombies by hand.

Finally, here’s a nice tutorial by Owen Goss on using Instruments to find memory leaks. It’s also another good scenario which you can follow to help get your head around Instruments.

Bonus info: XCode 3.2 and later has the Clang Static Analyzer built in. This is a sweet tool that analyzes your code without running it (thus the static part). Just run Build→Build and Analyze and you’ll get a brutal report of how and where Clang thinks your code is totally sketchy. John Muchow shows you how here.

Anything that still baffles you about XCode/iPhone debugging? Care to add any other beginner debugging help? Hit the comments!