UPDATE Sept. 9th, 2010.
Apple: We have listened to our developers and taken much of their feedback to heart. Based on their input, today we are making some important changes to our iOS Developer Program license in sections 3.3.1, 3.3.2 and 3.3.9 to relax some restrictions we put in place earlier this year.
In particular, we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code. This should give developers the flexibility they want, while preserving the security we need. Source
Nice move Apple. Thank you Steve Jobs. I don’t want to take too much credit for this. I believe it was the only logical thing for them to do at this point. It is good to see that they are listening to their developers on this issue. They also promise improved App Store Review Guidelines.
Ordinarily this blog is focused on techniques and tricks for getting FileMaker to do simple and amazing things, but in this post, I am inspired to talk about something different — the newly announced “FileMaker Go” and how it impacts Flash and other development software languages on the iPhone.
“FileMaker Go” in action
Image: – listing the events at FileMaker DevCon 2010 in San Diego in “FileMaker Go” on my iPhone.
FileMaker Inc., announced and shipped “FileMaker Go” just shortly before the August FileMaker DevCon. They have done a great job of translating 95% of the code that will run on a desktop version of “FileMaker Pro,” to run on an iPhone or iPad. It is a very versatile client, opening database files full of complex scripting locally on the iPhone or remotely on a local area network and even over a 3G telephone network. It truly is an amazing piece of technology.
As developers, we knew this was coming based on a non-disclosure demonstration at last year’s conference, but I don’t think anyone had any idea of how comprehensive the feature list would be. The only things missing from my wishlist are the ability to read bar codes and import photos into container fields directly from the camera and camera roll.
I recently attended FileMaker’s Developer’s Conference (DevCon) in San Diego. The star of the Conference this year were the versions of FileMaker Pro, FileMaker Go for the iPhone and FileMaker Go for the iPad. Presenter after presenter expressed how they had not been as excited about FileMaker since… well, ever. While I really like the new “FileMaker Go” and the new opportunties it opens up, it got me thinking about Apple’s response to Adobe’s Flash on the iOS platform.
A big plus at FileMaker DevCons is meeting with your fellow developers. They are an interesting bunch and always ready to share ideas or techniques. One lunch at this year’s convention, I sat at a table with a woman who claimed that she had heard that there was a fair bit of conflict between Apple Inc. and FileMaker Inc. over the launch of “FileMaker Go”, and it’s ability to run ‘apps’ on iPhones/iPads/iPod Touches (iOS platform). This confirmed that others thought that “FileMaker Go” was controversial in terms of Apple’s anti-Flash stance.
From the first iPhone, through the iPad launch and the announcement of iOS4, Apple has consistently denied Adobe’s Flash the capability of running on their platform. Partly it was because there was no Flash runtime available for the devices, but as Adobe got its act together and started preparing a runtime for iPhones, Apple told Adobe basically to go jump in a lake. Much teeth gnashing and snarls came out of frustrated executives at Adobe. Then in April 2010, Apple CEO, Steve Jobs posted an article on Apple’s website called ‘Thoughts on Flash’ to articulate why Apple continues to reject Adobe’s attempts to get Flash running on Apple’s massively popular mobile platforms.
Steve Jobs thinks bad ‘Thoughts on Flash’
Steve Jobs and Adobe management in happier times.
Steve Jobs’ main points in ‘Thoughts on Flash‘ were:
1) Open vs Closed systems
2) the full web
3) reliability, security and performance
4) battery life
6) and finally Apple’s relucance to allow a third party cross-development language to control their destiny.
1) The Open vs Closed argument seemed to be a bit of posturing about which is a more ‘open’ environment: Flash or the iOS. To my eyes, they are about even on this. Both big companies, Abode and Apple want to lock you down. I would call this a wash.
2) The ‘full web experience’ refered to is Adobe’s argument that iPhone/iPad/iPod Touch users are being denied the full web experience because they are left out of the loop on Flash games and video. Jobs argues that most of the important sites are moving their video to HTML 5 and H 264 video, so who cares about the loss of Flash video? As to the games argument, Jobs states that the iOS platform offers over 50,000 games, many of them free. In his estimation, Apple users won’t miss Flash games. This is not an argument, it is a diversion.
3) Jobs argument gets strongest when he cites reliability, security and performance. There is no denying that, on the Mac platform at least, Flash does at times behave like a pig. Given Adobe’s track record, Jobs probably has a right to be cautious.
I cannot speak to the security concerns of Flash, but security problems are also an issue for Safari and other web apps. Basically anything that opens a port runs risks on today’s wild and woolly Internet.
It seems that it might be real that Adobe has a problem with some of these issues around speed and security. The first revs of Flash for Android are not exactly getting rave reviews. The good thing is that Flash is software and can be changed to improve over time. Whether all these things happen or not remain to be seen, but the potential is there to address these issues given half a chance and a little support from Apple.
4) We have to take Jobs’ word on battery life. Because no Flash exists on the iPhone, there is no real way of testing his claim. It remains to be seen if this is going to be a big problem on Android, but my sense of it is that if it turns out to be too big of a dog, most people will turn it off, if they are able to, or avoid Flash websites. Problem solved.
5) The touch interface is a key argument for Jobs. He states that most Flash applications were written with a mouse in mind. Things like roll-overs and onmouse down commands are what drive the current generation of Flash apps. Jobs is correct here, but he doesn’t seem to allow that developers will respond to the demands of the new platform. If people want a touch interface, my guess is that Flash developers will have an incentive to create one. There is nothing inherent in Flash that prevents an app from being reconfigured into a touch-friendly interface.
6) The final point Jobs makes in ‘Thoughts on Flash’ concerns the control of Apple’s destiny. Jobs worries about letting another company have too much control over the programming environment. I will respond to this point further in my argument.
Apple Developer Agreement bans Flash
“FileMaker Go” is what got me thinking about the Flash issue again. It appears to me that “FileMaker Go” resembles Flash in a number of ways. “FileMaker Go” looks a lot like a runtime environment, specifically the kind that Apple has recently forbidden on the iOS, seemingly expressly to keep Flash out.
With the launch of iOS4, Apple’s latest operating system for the iPhone and iPod Touch devices (and soon to be on the iPad), they made a small but significant change to their Terms of Service for iOS developers.
The original iPhone OS 3 section 3.3.1 reads:
3.3.1 Applications may only use Published APIs in the manner prescribed by Apple and must not use or call any unpublished or private APIs.
The revised iPhone OS 4 sections read:
3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. Unless otherwise approved by Apple in writing, no interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s). Notwithstanding the foregoing, with Apple’s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application.
With these changes to the Apple Developer terms of service, they have effectively shut the door to Adobe’s plans to create a runtime for iOS 4. Adobe had a two-pronged approach to Flash on the iOS. First, Flash was to run inside the browser just as it does on your desktop computer. But Adobe also had a plan to allow Flash developers to be able to click an option in the Flash development environment that would compile an app for the iPhone. This would have allowed Flash developers to put ‘apps’ into the iTunes Store and sell Flash apps, the way iOS developers using Apple’s Cocoa/Objective C development tools do now. Adobe has a similar approach on desktop computers called ‘Adobe Air‘. They position it as “a browser-less runtime for Rich Internet Applications”.
RunRev iOS strategy rejected
In employing a ‘shotgun instead of a laser‘, Apple also blocked a number of other developers working on programming options for the iPhone. Long-time Mac users will remember HyperCard, a programming language Apple developed for the Mac platform. When Apple abandoned development on HyperCard, a company called Revolution (now RunRev) came along and picked up where Apple left off. They offer a unique software development environment that allows non-developers and experienced programmers alike to work in an English-like programming language and compile their programs to Mac, Windows and Linux. The company had been looking to extend their platform to the iOS platform, spending hundreds of thousands of dollars on development in the process. In Apple’s rush to keep Flash off their hardware, they closed the door on RunRev as well.
Larger developers like Adobe and RunRev (OK, not so big, more like medium-sized) were not the only ones hit hard by this change in the terms of service by Apple. Numerous small developers were hit by this as well. One small developer is currently in limbo over an app called “Brief” that allows developers to quickly prototype iPhone apps. It is incredibly hard for small companies to put months into developing an app and then be told that it won’t fly by the iTunes Store guardians. A clearer policy is needed.
A plethora inside of a cornucopia of apps, all written in Objective-C
Recently, the number of apps listed in Apple’s iTunes app store surpassed 250,000 with predictions that this number could go to half a million apps in the not too distant future. (Memo to iOS developers: the gold rush is probably over, your chances of become a millionaire off some goofy app you whip up in a few days are now approximating zero.)
How many apps does Apple need to control before it has enough control? Would introducing Flash at this stage really be such a problem? If Flash apps run badly, people will just avoid them. There are plenty of i0S apps to look to as an alternative now and if some new amazing thing comes along in Flash, iOS developers are going to whip off an iOS version of it as well.
The argument that Apple will somehow lose control of their platform by allowing Flash in this late in the game seems dubious with this many apps written in Objective-C. This kind of head start will not evaporate overnight.
If we look to the Mac platform as an example, where great apps are always written in Objective-C, this loss of control issue is not currently a problem. Personally, if I am given something written in Adobe Air, or Java or anything that looks too much like Windows, I usually turn up my nose and start looking for an alternative. I have to believe that the same thing will happen on the iPhone and with a quarter of a million alternatives — there has to be something written in Objective-C that will do the trick.
FileMaker Inc. owned by Apple Inc.
This is where the bit about “FileMaker Go” comes in. It appears to me that “FileMaker Go” is basically a runtime that allows non-Objective-C programs to run on the iOS platform. This is exactly what “FileMaker Go” does. And it is what Apple Inc is telling Adobe, RunRev and other software developers they can’t do.
FileMaker Inc., was able to clear the hurdle because it is a wholly owned subsiduary of Apple Inc. Others are not so lucky.
“FileMaker Go” is a crucial part of FileMaker Inc’s strategy going forward. Apple Inc., sets FileMaker’s targets for financial performance and growth. If all of a sudden someone in Apple’s iTunes Store tells FileMaker Inc., they can’t sell “FileMaker Go” through the app store, I would predict some fiery corporate discussions about it. This seems unlikely to happen. So if it is not going to happen for FileMaker, why does it have to happen for Adobe and others?
What is going to happen when the EU and US Federal investigators get to looking at this issue thoroughly and see the favoritism that Apple is applying to FileMaker Inc.?
Something is missing
Image Source: Wikipedia
Steve, I know you know how to run more than one multi-billion dollar company and I am just a guy who likes to play around in FileMaker for fun and occasional profit. With that said, I want to be the first to tell you that Apple is looking like it is not wearing any clothes in this situation. “FileMaker Go” is a demonstration of what other software programming languages can look like on iPhones and iPads. FileMaker developers are busy modifying their solutions, as you read this, to make their progams friendly and easy to use in a touch-centric environment.
So here is my unsolicitated and entirely free advice:
* Allow Flash and other software languages, such as RunRev, Scratch and Briefs to work on the iOS. Work with Adobe to make Flash run as quickly, securely and reliably as possible.
* If Apple were to purchase ‘ClickToFlash‘ from its developer and put the functionality of controlling Flash in every copy of Safari your users would get the best of both worlds. (ClickToFlash allows users to turn off Flash in their browser and then selectively reactivate it if something looks interesting, or if Flash is required to interact with the web site. There is a whitelist function that you can add sites you trust and regularly visit to ClickToFlash.) Any problems with Flash could be quickly shut down. Peope who don’t want Flash in their browsers could continue to live blissfully unaware of Flash on their iPhones and iPads.
* Label apps in the app store by their compiler. If something is made in Flash, or RunRev, or whatever non-Objective-C language, and they get a reputation for insecurity or crashing all the time, people can avoid them. Cocoa/Objective-C can be the locally grown organic alternative, and everything else gets labelled as genetically-modified BGH containing stuff that is bad for you, but may be fun nonetheless.
It is time to get the critics as well as the EU and US Federal bureaucrats off your back. Move on, let the platform grow. “FileMaker Go” is a great product that expands the capabilities of the iPhone and iPad. Just think of the possibilies of letting other software languages blossom and grow on these great mobile platforms. All indiciations are that Apple’s success is pretty secure for the forseeable future and if something is going to bring it all crashing down, I don’t believe it is going to be whether Flash runs on the iPhone or not.