“FileMaker Go” demonstrates Apple’s double standard on Flash

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.

Lunchtime Gossip


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
5) touch
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.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited). (Source: WIkipedia)

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.

Related Articles:
Using FileMaker 12 Runtime files with FileMaker Go 12
Submitting FileMaker Runtimes to the Mac App Store
Blast from the Past: FileMaker DevCon 2001 Report

18 Responses to ““FileMaker Go” demonstrates Apple’s double standard on Flash”

  1. another dumb ass who doesn’t understand technical challenges
    wasting peoples time with 3000 word essay on how smart he is.

    • homebasesoftware August 31, 2010 at 7:52 pm

      Thanks for sharing. If you have some thoughts on the topic, I and possibly others would like to hear them. The drive-by approach doesn’t give anyone the benefit of your perspective and you make it sound like you know something about technical challenges.

  2. Another idea for Steve: Don’t do any of those things.
    I’ve got Filemaker Go, it’s cool and I was surprised how well it works. But the Go/Flash analogy doesn’t work for me. Filemaker is owned by Apple. Filemaker databases aren’t like Flash advertising or games. I don’t see it.

    • homebasesoftware August 31, 2010 at 7:36 pm

      Flash is not just games ads and movies, Adobe has a whole module for developing RIAs (Rich Internet Applications) called Flash Builder. If corporations can start building their in-house apps in Flash Builder for all mobile platforms, (Windows, Mac, Android and iOS), and apps can be deployed easily on multiple platforms, some of the uniqueness of iPhone/iPads gets lost. I think this may be what Apple is actually afraid of.

  3. Interesting. But appeals to consistency and pointing out hypocrisy are completely ineffective as tools to change other people’s behavior. Even if people are acting inconsistently, when that’s pointed out they will just find a rationale for their actions. You do it, I do it, even educated fleas do it.

    If you want to influence Steve Jobs (or anyone else), think about what they value. Steve Jobs wants to “change the world” or “make a dent in the universe”. He wants to do that while creating “beautiful and magical” things, and he wants to make money. Focus on those three things and your presentation to Steve might look more like:

    Steve, if you embrace Flash on the iPad and iPhone, you’ll be able to reach billions of people who will see the beauty of your devices. Since Flash is buggy, error-prone, battery draining, and a security nightmare, set up a test versionon the iPhone and require Adobe to produce a version of Flash that allows an iPhone’s batteries to last at least 8 hours, follows the Apple Human Interface Guidelines, and is safe from the test suite of malware. If Adobe passes, call the result “Flash Plus” or “Apple Flash” and distribute it yourself. You will have saved the computing universe from the current crappy Flash.

    • homebasesoftware August 31, 2010 at 7:26 pm

      Could be a good test for FM Go as well. Can it last 8 hours on an iPhone, doing continuous transactions. No doubt some enterprising developer is thinking about how to run this testing as I type this.

  4. You know, I tend to hate Flash on web pages and have Click2Flash installed (Even though I wrote some reasonably complex Macromedia Director multimedia programs back in the day!), but your mention of Hypercard and RunRev struck a chord.

    Back in the day, I wrote a great deal of programs in Hypercard and then Supercard and then finally dabbled with RunRev and would dearly love some equivalent user-accessible programming environment be made available to all of us who have a great idea for an iPhone/iPad app, but none of the requisite Cocoa dev skills.

    However, I do concede that certainly back when I was working with it, RunRev was always very kludgy and non-Mac-like because of its cross-platform nature.

    If only Apple resurrected Hypercard or made an easy to use version of the Cocoa IDE that my Dad could use (like he used Hypercard), it would sate some of the hunger, even if it was kept as an iOS-only dev environment. If Apple did it, they could control its destiny and not be reliant on a 3rd party.

    Please Steve!


    • homebasesoftware August 31, 2010 at 7:25 pm

      RunRev is improving all the time. Not sure how long ago you checked it out, but it may be worth a look again.

  5. I think the intent of the Dev Agreement’s Flash ban, regardless of whether it is fair, was to keep Apple from finding itself in the same position as they did with Mac and Windows in the 90s, where industry-standard, cross-platform developer tools were forcing a lowest-common-denominator approach to Mac software development, stifling Apple’s efforts to innovate and distinguish themselves.

    As impressive as Go is, I don’t think Apple would ever have to worry about the FileMaker platform putting them in the same position, even if someone else owned FMI. Can you picture Steve Jobs telling his developers, “We’ve got to get [some new feature] into the next version of iOS, but if it breaks script triggers in Go, no one will be able to upgrade!”

    Adobe, on the other hand, released the latest version of Flash with a feature that, until Apple announced they would block it, was aggressively marketed as a way to prevent developers from ever having to design apps specifically for iOS. You seem to be saying, “Most Flash apps are crappy, so why not let them compete?” but then, most Windows apps were crappy, too. Developers chose convenience and time-to-market over quality and innovation, and they would do it again.

    FileMaker Go is an app that runs .fp7 files. FileMaker databases might be able to do a lot of things that apps do, but they cannot stand alone in iOS. Go isn’t any closer to being able to print in iOS than any other app, and a phone call or home-button push jumps you right out of the database, even if you’re in the middle of a script. If they got any advance notice on what Apple was doing with the iPhone and iPad or received technical assistance beyond what any other third-party developer had, it sure doesn’t show in the amount of time it took them to finally ship Go. Given all of this, I don’t see much evidence that Apple has shown any favoritism toward FMI–yet. It will be interesting to see, as FileMaker seeks to innovate further, pushing into areas like plug-ins and runtimes, whether Apple lets them out of the sandbox, and how they will justify that while blocking things like Flash and RunRev.

    • homebasesoftware August 31, 2010 at 10:01 pm

      I agree with you that FM Inc., probably had no advance on the technology from Apple, as you say, based on length of time it took to get FM Go out the door. Where I differ in my view on the favoritism issue is Apple’s treatment of RunRev. Their software could be argued as being in a similar position as FileMaker — a smallish developer, not going to change the balance with Android etc. RunRev as a programming language is unlikely take over the world anytime soon, so it is little risk and yet they, unlike FIleMaker Inc, were turned down by Apple. If you follow the links in the article, you can read more about their experience.

      I do understand why Apple is worried about Flash, but I believe their fear is overrated for a number of reasons:
      1) the wealth of applications they already have in place.
      2) the developer loyalty for Objective-C and
      3) how poorly Flash is doing on other mobile platforms to date. Flash on Android sounds pretty bad.

      It will be interesting to see how this plays out. I am hoping for more diversity as the iOS platform grows.

  6. If Flash drains iPhone/iPad batteries, Apple will be blamed, not Adobe. Apple bashers will howl about battery life, now that the antenna problem has been debunked, and that is what will get wide exposure. The vast majority of iPhone owners do not know what Flash is and do not want to know. I am a realtor and probably less than 1% of my colleagues have a clue about these issues. Your trust in the market and users’ understanding is naive, it seems to me. At today’s innovation pace, by the time the Flash issue is resolved, the damage to Apple will have been done.

    My other objection to Flash is that it creates its own cookies that cannot be deleted or examined by users and can be read by any web site. If a user turns cookies off via the Adobe page (the only way available), then Flash quits working. Those cookies are a big value to advertisers (and pornographers), so we can’t blame Adobe for designing Flash the way it did, but we don’t have to like it.

    Since pornography drives change adoption in web technologies, that industry will determine whether Flash thrives or withers. If it moves to HTML5 for whatever reason, it’s probably game over for Flash. Early hints are that it is making that move.

    I also use Click2Flash and will probably be happy when Flash is over.

    • I agree with your assessment that most users don’t understand what Flash is. I prefer the term ‘optimistic’ to ‘naive’.

      It is rather strange that you have to go to an Adobe web page to clear your own Flash cookies. I do this once in a while and haven’t found that it damages Flash.

      Click2Flash is great, but I still find myself ‘whitelisting’ a fair number of web sites still so I can view their Flash content. I believe Flash is not just going to go away any time soon, so I would rather have this option on the iOS.

  7. It’s late, but I’ll weigh in on the topic.

    I agree with MW in that FM GO is simply an application that opens .fp7 files for viewing or editing, much like the myriad of Office Suites available for iOS currently. I think what’s key here (and this may be a bit of a stretch) is that the actual FM GO application ‘probably’ does not call any proprietary or undocumented API calls to run the application. If that’s the case, then the .fp7 file is nothing more than, say, a Word file with some scripts to ‘enhance’ the usability of the file/application. It would stand to reason that the actual ‘run-time’ resides in the correctly compiled application and does not directly access the iOS API’s to achieve the end result. A point of proof for this might be it’s impossible sync strategy for non-server based databases and why it’s not 100% compatible with the desktop version. There are other database type iOS applications that allow editing and building on the device (uh-hem – ‘Bento’), but FM GO developers either chose or were required to leave those segments of code out.

    And what about console emulators? I know of at least two available for iOS (look up HudsonSoft in the AppStore). These clearly require a runtime to interpret the assembly language the game was originally programmed in and yet, they live? Perhaps it’s due to the wrapper around the emulator that gets them by the Software Border Patrol. Maybe Adobe could try this approach?

    The above is in direct contrast to how Adobe Flash works, as it requires a runtime that uses various native system or it’s own custom APIs and frameworks that either pass through it or completely create something new and foreign to manage it’s, uh, file (generally speaking). Flash would be more comparable to Visual Basic (pre version 6, I believe) that absolutely required a runtime and had access to the system level API or HAL. However, I have noticed some Development Suites that allow you to program in many languages and use the WebKit to create there iOS app. The only difference here is that they claim the whole thing is eventually compiled to Objective-C (or C, C++ or Java) for the end result. It must work, there are Apps out there created this way. If Adobe could create something similar that would compile Flash to Objective-C AND use the standard iOS components, then they would be in compliance of Apple’s Draconian Software/Hardware policies and be good to (excuse me), go!

    Personally, I love FMGo. It’s a little slow and there are still some redraw issues and control delays, but overall – yah.

    Flash? Flash is a malignant software tumor that is sucking the life out of what was once a great company and polluting the internet. It should be cut off of Adobe’s side, burned and left in a Japanese nuclear reactor as a sacrificial gift to Godzilla. Done!

    Just my $0.02439



  1. 2010 in review « HomeBase Software - January 2, 2011

    […] “FileMaker Go” demonstrates Apple’s double standard on Flash August 2010 12 comments […]

  2. Using FileMaker 12 Runtime files with FileMaker Go 12 | HomeBase Software - July 13, 2012

    […] Related Articles Submitting FileMaker Runtimes to the Mac App Store “FileMaker Go” demonstrates Apple’s double standard on Flash […]

  3. Getting FileMaker Go databases onto an iOS device using Dropbox | HomeBase Software - July 14, 2012

    […] Articles: Where Am I? Using FileMaker Go 12 to track your Location “FileMaker Go” demonstrates Apple’s double standard on Flash ‘FileMaker Go for the iPhone’ […]

  4. Submitting FileMaker Runtimes to the Mac App Store | HomeBase Software - July 14, 2012

    […] Related Articles: Blast from the Past: FileMaker DevCon 2001 Report Using FileMaker 12 Runtime files with FileMaker Go 12 “FileMaker Go” demonstrates Apple’s double standard on Flash […]

  5. ‘FileMaker Go for the iPhone’ – a First Look | HomeBase Software - July 14, 2012

    […] Related Articles: Where Am I? Using FileMaker Go 12 to track your Location Getting FileMaker Go databases onto an iOS device using Dropbox “FileMaker Go” demonstrates Apple’s double standard on Flash […]

%d bloggers like this: