Adobe's iPhone Hail Mary

snydeq writes "Fatal Exception's Neil McAllister questions whether the move to port Flash to the iPhone isn't a last-ditch effort on Adobe's part to remain relevant in the quickly evolving smartphone market. By allowing developers to compile existing Flash apps into native binaries, Adobe believes it has found a way around Apple's requirements that no non-Apple API interpreted code may be downloaded and used in an app, a clause that has also prevented Sun from porting JVM to the iPhone. The resulting apps will be completely stand-alone, with no runtimes and no Flash Player required — if Apple lets Adobe get away with it, no small feat given how protective Apple has been about its app market. But as much as Apple has at stake here, Adobe may actually have more, McAllister writes. 'Already the idea of using Web languages and tools to build smartphone applications is taking hold. Palm has built an entire smartphone platform around the idea. Apple supports the use of Web technologies like AJAX to build applications based on the iPhone's Safari browser. And developers will soon even be able to build Web-based applications for BlackBerry handsets, thanks to a new SDK from Research in Motion. As late to the game as it is, what Adobe needs now is to convince developers that Flash is better than the other options — and that could be a tough sell.'"

Comments

PHP for mobile phones

[sopssa]

Flash might be great for action games, but I'd really like to see support for PHP in some mobile phone. There's already PHP-GTK and several other frameworks that let you do it in Windows/Linux. Powerful, and still easily learned and used language would make wonders in mobile development (man does Symbian C++ suck) and because PHP has so many functions and api's build-in, it would be easy to program lots of things quickly for your phone.

Re:PHP for mobile phones

[sopssa]

While PHP was originally developed to be a server-side scripting language to generate dynamic websites, it's really capable to work in CLI and even in GUI applications. I do most of my server scripts with it instead of bash or the other popular ones, just because it's a lot more readable and quicker language to work with.

So, you might want to tell me why would I be joking? The only problem currently is that there's no support for multiple processes in PHP and you have to use hacks and forking to accomplish it (not that Flash would have it either). I except this to change at some point too, and with iPhone it's hardly a problem as you cant even run multiple apps at the same time.

Sure, you cant do the next Crysis with it, but I can think of many kinds of games especially on mobile phones that would work great. On top of that PHP-GTK's and other frameworks drawing functions are fast.

WinBinder is one of such extension for PHP that provides easy access to Windows API's and builds an exe from it.

One of the powers in PHP is it's huge build-in function library (+ extensions) which really makes developing and programming faster and more fun, when you dont need to hunt such functions or libraries from Google or make the functions yourself (which in most cases probably aren't as good optimized). I always wish other languages would have such by default (c/c++ especially is pain in the ass and all the dependencies just create problems when moving from environment to another).

Re:PHP for mobile phones

[Jurily]

No, you do all of your scripts with PHP because you're too fucking stupid or ignorant to learn a proper language like Perl, Python or Ruby.

Says the one who's too fucking stupid or ignorant to learn a proper language like C or Assembly.

Once you've moved on as a developer, and learned some decent languages, you'd see how much of a fetal abortion PHP is. It's literally a stillborn programming language.

So what? If he's quicker with it, who are you to decide he shouldn't use it? You already established you don't care about performance.

Re:PHP for mobile phones

[Dr. Zim]

I think someone needs a hug

Re:PHP for mobile phones

[Serious Callers Only]

Can you cite an actual example of something wrong with it?

Sure. I've used it, and it gets the job done, but I didn't much like it compared to the many other options - trying to force development of a GUI application into PHP is my idea of a nightmare, and comparing it to C and saying that it has far more libraries is laughable, considering that most PHP additions (image manipulation for example) are just wrappers around C based tools. My object to PHP is not that it is impossible to use, it's that it's messy and not very well thought out in many regards. It's quick and dirty, with the emphasis on the dirty.

A few problems with PHP off the top of my head:

There is no clean separation of logic and view (or MVC if you prefer that split) - the language itself encourages mixing code and presentation, often with horrendous results. You can work against this, but you're always going against the flow - see the many examples of PHP CMS etc for great examples of this kind of mistake in action. They work, but only just, and the internals are often very messy.

The naming conventions for the API are all over the map - any language that has functions named stuff like mysql_real_escape_string, as opposed to the still extant mysql_escape_string, has obvious problems with design philosophy. Maybe next year they'll come out with mysql_really_escape_the_string_this_time? It is very difficult to guess function names because there are no clear conventions, and the whole thing has grown organically to a huge bundle of disparate functions, some of which definitely do not belong in a language and should be broken out into modules or put into objects like strings. Stuff like eregi_replace, str_ireplace and str_replace is needlessly confusing because the naming conventions are inconsistent and cryptic.

Strings and arrays are not proper objects, so you have to use a mix of procedural and oo code everywhere - it'd be nice to be able to call methods on strings and chain stuff like Ruby. The object model was also weirdly broken till PHP5 and is really bolted on.

Doesn't have closures (just added to C/Obj-C by Apple).

Unicode strings are still not properly supported.

The syntax inherits everything which is bad about perl (it's quite possible to write very difficult to read code), and doesn't improve on it one iota.

I'm sure I could do a search and turn up a few more issues, but it generally just feels ungainly compared to any other language I've used (Ruby, Objective-C, C, Python). I think the author of the above comment saying everything could be done better in PHP really should explore other languages before dismissing them as somehow lacking, and understand that different languages have different strengths, and learning to use other languages could teach them something about how to write good code in PHP.

Having worked with it, PHP doesn't strike me as a very good language by most metrics, and it certainly is not more complete than the many other options in any arena. There is simply no comparison in my opinion with a properly structured API like cocoa for GUI apps.

Re:PHP for mobile phones

[shmlco]

Don't forget the archaic parsing system that requires all variables, even those in script assignments and function parameters, to be prefixed with dollar signs. Looking at a PHP script makes me feel like I'm back in the '70s writing BASIC programs. ($A=$B vs A$=B$)

Or PHP object methods ignoring the standard dot reference convention in favor of C's pointer convention. ( obj.function() vs $obj->function() )

I know I just love typing three special characters for each and every method reference when one would do.

And you mentioned function names, but what about function parameter order? Some take the target first (arsort(array,sorttype)), and others place the target second (array_key_exists(key,array)).

Or array function names, for example, some of which start with ARRAY_map, others with Asort, and still others like CURRENT() which one can only assume does something with an array, as it could just as easily be the current time.

Or the fact that decent object support came so late to the game that 95% of all PHP code extant is still an embedded procedural spaghetti mess? Rarely does a language work so hard against writing good code. Yes, you can do it, but the odds of actually doing so pretty much equate to the chances of the Mets winning the 2009 World Series. (grin)

Re:PHP for mobile phones

[lonecrow]

I feel so lonely.

Can't someone please berate me for developing web apps in ASP Classic. I know that my clients are happy because I always deliver the features they want on time and on budget and my apps always pass website security audits and are very stable and all but surely there must be someone out there who can tell me how wrong I am for using it.

Re:PHP for mobile phones

[metaforest]

The real problem here is that PHP was designed to be embedded in a static web page as an 'escaped sequence.' to create dynamic html. It has evolved from that into a horrendous mess that some seem to think is a viable, general purpose scripting language.

Tying it back to a real(?) world analogy: Flat bladed screwdrivers make nice pry-bars, scrapers, and even phillips-head drivers in a pinch... but this is generally considered a bad idea: You are more likely to damage yourself, the work piece or the screwdriver if you do this.

I feel the same way about PHP. Yes you can do things with it that it was not designed to do. However using PHP this way is not really a good idea. In the long run it all ends in tears.

That's a silly conclusion

[nahdude812]

It's not a "last ditch effort" to remain relevant. It's just Adobe continuing the tradition of ubiquity of their platform. Apple won't let them put a runtime on the phone, so they'll deploy native code instead.

Apple supports the use of Web technologies like AJAX to build applications based on the iPhone's Safari browser.

Sorry, but there's a big difference between an AJAX app and a native app. Try writing a browser based graphical game on the iPhone; it's going to fall on its face pretty quickly.

for BlackBerry handsets, thanks to a new SDK from Research in Motion.

Hmm, convince developers to learn a whole new SDK for a single platform, when they can stick with a mature language and toolset they already know, deploy it in the browser, on the desktop (via Air), and on basically every phone on the planet that can run custom apps, including the BlackBerry?

Sorry, this whole article is bunk. Adobe isn't struggling with relevance, they're just making sure it doesn't start to slip, as Apple is so strongly trying to make it. In fact, this probably backfired on Apple a bit - Flash apps running as a native binary will probably have access to device functions which the normal Flash runtime wouldn't have.

Adobe needs now is to convince developers that Flash is better than the other options — and that could be a tough sell

I'm guessing this sale has already been made. A lot of developers like working in Flash. Actionscript is a surprisingly elegant language. Based on the number of Flash apps which already turn up all over the web, a whole new segment of developers are seeing this as access to a development platform which was previously closed to them.

Re:That's a silly conclusion

[mdwh2]

Indeed. Whilst Flash and Java may have some drawbacks, the advantage of cross-platform applications is huge. With desktop computing, we had to go through the painful ordeal in the 80s and 90s where every platform were incompatible, making it a pain both for developers and users. Finally we've got to a stage where most platforms run the same code - but only due to having a monopoly platform of Windows, running on only Intel CPUs or clones; not because of any standardisation (well, PC hardware is now standardised, with even Macs now being simply another brand of PC, but the OS still makes a difference, and there is no standardisation there).

Mobile computing today is much like computing of the 80s - so called "smart" phones are ubiquitous - all but the cheapest phones are now Internet enabled phones that can run applications. There are many hardware manufacturers, with hundreds of different models, all running different (often custom) OSs, with different hardware. Yet, the vast majority of them are compatible, thanks to Java.

When I got my first smartphone in 2005, a Motorola V980, I marvelled at how I could download an application from any webpage, and have it run, even if it wasn't made with my phone in mine.

And then along comes the Iphone, and puts a spanner in the works. Yes, let's go back to the dark ages where an application has to be coded natively for that phone, and things like Java or Flash aren't allowed! Let's even make it so that applications can only be installed with Apple approval. It's great for Apple of course - people make applications specifically for the Iphone, generating extra publicity, and the media and fans spin the "app store" as being a good thing.

It's sad that even on places like Slashdot, people would prefer either 80s style computing where every platform is incompatible - or a possible future where compatibility is achieved only through a single Microsoft-like company dominating all of mobile computing (and what if that's a different company to Microsoft, as is likely? We'll have the absurd situation where mobile handheld/phone devices are incompatible with netbooks and desktop devices...). As opposed to having true standardisation and cross-platform applications, which had been achieved by a billion or two Java smartphones, before Apple start to put a stop to it.

Re:That's a silly conclusion

[beelsebob]

The whole premise of the article is bullshit too. The article seems to be suggesting that apple are trying to restrict the APIs you write apps with, what they're actually trying to do is to stop you downloading random malicious code and running it, without it going through their checks.

I'm pretty sure apple will be rather happy about the fact that now *even more* developers can write apps for the iPhone.

It's about the tools

[TheRaven64]

The flash player is a nice Smalltalk VM with a PostScript-like vector drawing model. It's a (very nice) incremental evolution of the Smalltalk 80 system. The Flash authoring app, however, is one of the best rapid application development tools on the market today. You can do everything that Flash can do with JavaScript, the canvas tag, and SVG, but there aren't (yet) any development tools that are anywhere near as nice as Flash for this environment.

Adobe doesn't make much money from the Flash player; they give away the desktop one and sell the mobile one to OEMs quite cheaply. In contrast, they charge $700 for a license for the developer tools. A lot of money, but not much in comparison to the cost of the person using them.

In the long term, the flash player will probably go away. They've already made some first steps towards this, donating the ActionScript VM to the Mozilla project, and producing things like AIR which let you run Flash apps as stand-alone binaries. I wouldn't be surprised if future versions of the Adobe Flash can target HTML5 as well as the Flash plugin, and eventually just HTML6 or a native environment.

Re:They'll lose to Gnash

[TheRaven64]

Yes, that would be a real shame for Adobe. People would be replacing a free Adobe product with an open source program to run content created with... Adobe's $700/seat authoring tools. The only reason that Adobe spends money developing the Flash player is so that they have a platform that runs (almost) everywhere and works with their authoring tools. If Gnash (which can't even handle relatively simple things like iPlayer yet) achieves 100% compatibility with Flash Player, then it just saves Adobe money supporting some less-mainstream platforms.

Re:A Flash animation writer wouldn't be far off

[ojintoad]

Adobe controls the spec. They keep on adding on new functionality in a way that has to be reverse engineered, so that there is a lag time between when they have developer tools for it and the free software makers have developer tools for it. That has a direct impact on first to market opportunity for new functionality for developers, meaning that the free software version is mostly irrelevant if developers want to stay competitive. Does that sound possible?

Re:A Flash animation writer wouldn't be far off

[TheRaven64]

The Flash specification has been open for people writing authoring tools, but not people writing players, for over ten years. There are a few other flash authoring tools besides the Adobe ones. Hardly anyone uses them, because Macromedia / Adobe Flash is much better, and for most Flash developers / artists it doesn't cost much in terms of hourly rate (and can be offset against income for tax purposes anyway).

Flash is in the same sort of market as Photoshop. The GIMP does more than the average user needs, but it doesn't do what the person willing to pay $500-1000 for a piece of software needs. There will almost certainly be open source things for creating flash apps (there are a few things that output flash already), but none are in the market where Adobe is and wants to be.

Article completely misses point.

[Anonymous Coward]

"A tough sell." Really? Lets see. Write the same app for 4 different phones, then one for general web, or write it once with flash via a great toolset.

Not noted above is Adobe's announcement that flash 10.1 will be out in a few short months. The speed improvements and memory management are astonishing. Also most if not all smart phone OS will be using it except iphone. They demo'd watching movie trailers, playing games and video conferencing directly from android and existing web sites. Being able to save down to iphone app is great, and lowers barrier to entry (who wants to do objective C?) but the larger topic is how iphone was leader of pack and is about to get outpaced by Android (as per many reports predict). Hell even RIM is getting on the flash bandwagon.

The holy grail is for us to not have to worry about what the damn phone is. Instead we can write great apps and they can be used anywhere the screensize makes sense. Computers (in browser and desktop app), phones, set top boxes for TV's, netbooks, appliances, etc. This is what Flash is about to let us do. Theoretically anyway.

And no HTML5 can't do everything Flash can do YET. Least not write once and run on many OS, platforms and browsers. HTML5 will be great when it is a viable option no doubt, but it isn't. Not yet and not in the next few years due to fighting amongst the browser decision makers.

analysis of a Flash app

[Anonymous Coward]

Adobe is claiming that a few apps already on the store were built this way. Here's a guy that disassembled one of these apps and did a writeup:

http://devwhy.blogspot.com/2009/10/flash-on-iphone.html

Certainly worth a read.

[jcr]

The author of that blog, BTW, is an ex-Apple engineer, and one of the smartest people I met when I worked there. He's one of the people I'd go to if I need help with Shark or other performance tools.

-jcr

Re:Adobe can bite back real bad

[asg1]

Your post makes no sense.

Re:Adobe can bite back real bad

[Sir_Lewk]

Yeah agreed. If I were going to make a markov chain from slashdot articles about iphones, flash, and mono, I'm pretty sure the output would be quite like the GPs post.

It'd probably get modded up too because it'd hit all the key words to trigger the brainless mods who just scan for phrases that they like.

Misunderstanding of terms

[cybereal]

There's a major misinterpretation of the situation regarding interpreted languages on the iPhone. Apple has absolutely no qualms about interpreted languages used on the device. In fact, a huge number of games are built around lua-based game libraries. It's a no-brainer! All you have to do is ensure a user can't add and execute arbitrary scripts by way of downloading them later.

The issue here is getting the right balance to make it through the review process. See, your game could allow for added levels for free down the road, a totally acceptable (and relatively common) occurrence. It's entirely okay if those levels are composed by your scripting language. What isn't okay is if the game will execute arbitrary scripting, to essentially distribute a target platform as an app. That's about where the line is drawn. This could be seen with the final result of the commodore 64 emulator app. They couldn't enable basic but they can allow for delivery of additional games, which are obviously interpreted. A developer might choose to use an encryption scheme or signing scheme to ensure they only execute gamescripts that should be, for example.

This relates to flash because there's nothing stopping adobe from porting the flash engine and making it possible to export individual iPhone apps that include it and execute some flash game that is packaged in with the app so long as that game can't randomly pull in more flash to execute. Of course, if you could compile the entire flash application to native code that would be more ideal in the general case assuming you have no consistency of execution problems. But that's not always the best idea. Take java, for example. Its design causes a complete native compilation effort to result in worse performance and lower reliability because the runtime optimization of the JVM is more effective than static code optimizations.

Anyway, I guess my point is that the limitations about virtual machines and script languages aren't quite what is popularly regurgitated. The issues with the iPhone and these technologies is one of post-app-install delivery of arbitrary code execution. It's not a problem with the use of VM/Script itself.