April 10, 2011 
I have been looking at the feasibility of submitting an app to the Mac App Store using FileMaker. When the Mac Store was first announced, it sounded like the apps had to be created in Xcode/Cocoa and nothing else would do. Since that time, I have seen discussion of using Adobe Flash and RunRev’s LiveCode to submit Mac Apps. It seems you have to jump through a few hoops to make it work, but diligent programmers are blazing a trail for these alternate routes.
With that in mind, I started searching for information about creating a FileMaker Runtime to submit to the Mac App Store. I found a couple of threads discussing this topic, one on FMForums and the other on FileMaker Today. There is also a how to video from Camp Software on turning a FileMaker Runtime into a Mac Installer.
Before diving into the details of these discussions however, I decided to generate a test Runtime to see what kind of size I would be looking at for people to download. I know hard drive space is not much of an issue these days, but it would seem that smaller is better just to keep the download speed fast, especially for an app that might be selling for $1-$2. So I took a test file and used it to create a Runtime using FileMaker Pro 11 Advanced. I was shocked at the size of the file. The last time I made a Runtime had been with FileMaker 10 and it had come in at around 100 MBs. FileMaker 11 produced a Runtime of 166 MBs. That is over 300 times larger than the starting file. I decided to do some testing using the previous versions of FileMaker Pro Advanced 9, 10 and 11 to see what they would produce using the same starting file. My test file was not using any of the new features of FileMaker 11, so I was free to move down versions if I could get the file size down.
The starting file is only 422 kilobytes
The FileMaker file I was starting with was small, less than a megabyte in size.
FM 9, 10 and 11 Runtime Sizes
Starting with 422 kilobytes of code, here are the three Runtime sizes created by the different versions:
- Runtime for FileMaker 9 – 47 MBs
- Runtime for FileMaker 10 – 105.3 MBs
- Runtime for FileMaker 11: 150 MBs
Clearly anyone wanting to submit a Runtime to the Mac App Store should seriously consider what features they require and think about using one of the earlier versions if file size is going to be an issue.
For comparison, I mocked up the same functionality in RunRev’s LiveCode and it generated a LiveCode Runtime of only 3.5 MBs based on 594 kilobytes of code. Instead of being 300 times larger like the FileMaker 11 Runtime, it was a mere 7 times larger than the starting file.
My son, who does iPhone/iPad programming, tells me that a simple Cocoa/Xcode app starts at about 100 kilobytes. Obviously Cocoa has the advantage as all the supporting libraries are built-in to every Mac, so they don’t have to include any of this. FileMaker has to include all the libraries of code that it wants to employ in the Runtime, hence a much larger file size. With Cocoa, the operating system is the Runtime.
Why the large footprint?
Each version of FileMaker Pro Advanced has grown in features and file size. Check out the file sizes in the Get Info box for each version:
- FileMaker Pro 9 Advanced 159 MBs
- FileMaker Pro 10 Advanced 333 MBs
- FileMaker Pro 11 Advanced 408 MBs
We get all these great new features, like charting and script triggers, but there is a cost in both application size and the resulting Runtime file size.
Other challenges to using FileMaker to create Mac Apps
There are other challenges to using FileMaker to create an app in the Mac Store. I have yet to see any discussion on the data-application separation issues. Mac Apps are not supposed to modify themselves when they run. This is tricky for FileMaker apps where the application and data are stored in the same location. It would be a challenge to write a FileMaker database that didn’t store anything in the interface, even employing the data separation model. If you separate the interface and data files, how do you present everything as a Package file? FileMaker can’t create it’s own data file on the fly either.
Another challenge to using FileMaker is that upgrades are handled by the Mac App Store’s processes, and you can’t do anything special like export your data and re-import it… everything has to be stored outside the app all the time for upgrades to go smoothly.
FileMaker makes it incredibly easy to create database-centric applications. It is the best thing going, it is fast to develop ideas with, has robust security and a huge feature set. However, file size, data/application separation and upgrading issues seem to be fairly large barriers to entry. It will be interesting to see how the always creative FileMaker community deals with these challenges.
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
HomeBase Software 
Thanks for that…
I think I will just encourage people to buy Go… that seems to be the cheapest option.
Do you know if the Mac app store will accept FM Files… or do they need now to start the Mac app-support store… LOL
The whole runtime thing is also problematic because cross-platform runtimes are separate. This doesn’t matter on the Mac app store… but it is a turnoff that you can’t from a Mac create a Win runtime.
Apparently people are still trying to do it. Not clear if anyone has been successful or not. This thread, which purports to tell all, ends inconclusively. Reading threads in fmdev.filemaker.com, it sounds like no one has succeeded yet. There are apparently issues because the FileMaker Runtime engine contains PowerPC elements. Apple wants apps to be Intel only.
I agree with you that it would be useful to be able to compile both Mac and Windows on either environment and not have to move back and forth to create software for both platforms. LiveCode, another cross-platform development environment will allow you to compile for Mac, Windows and Linux.