FAQs

FileMaker Pro


FileMaker Pro

1. How do I try out FileMaker Pro?

You have a couple of ways to go about this. One is to download the trial version from Apple's own Claris web site. This is a fully working version (now that the Runtime feature is gone) but time-limited to 45 days. Alternatively, and knowing the improvements are not significant in the FileMaker Pro arena, you can purchase cheaply a perpetual license version of an older FileMaker Pro app from eBay. Nowadays, you can easily spend less than US$50 on FileMaker Pro 18 (at the time FileMaker Pro 19 came out). The same is true of FileMaker Server 18.

2. Is it true that Apple wants to remove the Runtime feature of FileMaker Pro?

Yes. As sad as this sounds, it is true. And it has as of FileMaker Pro 19 in May 2020. In so removing the feature, it has put off side a lot of FileMaker developers. For example, Thorsten Wolfgang Giessegi, a FileMaker developer from Germany said on 21 July 2020:

"As a Mac user for more than 30 years now, I'm not happy with the direction Apple goes now and as a FileMaker developer, Runtime Solutions take a big part of my business, I'm very upset with the license policy of FileMaker. If there is no cheap client available anymore, selling FileMaker solutions for small businesses or individuals would become nearly impossible."

The technical term used by developers for this situation is called "deprecation". It simply means that a reason has been found by a developer for removing a feature or function. The reasons are varied, but it is mainly because:

  1. It is too hard to support a certain feature or function (unlikely if people see the value in maintaining the feature or function).
  2. Hardly anyone else is using the feature or function (because technology has evolved to something else that is suppose to be better).
  3. To reduce competition from other developers using the software (because it is considered by the developer of the product too powerful in what it can do).

Richard Carlton, CEO of RC Consulting, has raised another possibility: the issue of profitability. As Carlton mentioned in his video on Calendar Improvements in FMSP 2020 on 13 July 2020:

"Claris deprecates very few things in reality. They deprecate some image formats like EPS and some other formats like that. They deprecated the Runtime, which has people squealing. Ah well, I am getting on my high horse about that. I am really happy to criticize Claris when appropriate, but that one? Basically [the original] Claris [Corporation before it was bought out by Apple] came up with a Runtime....I have a big concept in business or even working with my team that it has to be a win-win conversation. If I'm getting something out of the deal, they need to be getting something out of the deal and both parties are winning. When you buy FileMaker for $99 a year or whatever you are doing and then you make a Runtime and you give the product away to a bunch of people, Claris isn't getting any value from that. And people say, "Ah well, they could upgrade the full version". Very few people who get the Runtime [will] upgrade [to] the full version of FileMaker, So Claris (i.e., Apple) determined, and they said this over for the last 15 years (because Runtimes have been around since FileMaker 3, which is [19]95, so 25 years [it] has been out there), that they were not making money off of it. And so, if you build a business model upon where you make the money and the person supplying some of the parts doesn't make anything, then eventually [everyone is] going to go out of business.... And so, the fact that they let the Runtime survive so long was a testament to them kind of being nice. I think they could have solved that a couple of different ways, solving multiple problems simultaneously, but yeah....I'm not on their Christmas card list down there [at Claris] so they do what they do and we just get to watch from the sidelines. So anyway, nothing has been deprecated other than the Runtime [and[ some image formats. There's no fundamental capabilities or script steps that have been removed."

Well, actually the Runtime feature is a fundamental capability for FileMaker developers serving their clients or selling to customers. And if Ronnie Rios, a senior consulting engineer at Claris, is correct in his video on FileMaker 19 Add-Ons when he stated the aim of Claris/Apple was to:

"We make powerful technologies available to everyone."

then it should be obvious how Runtimes should be an important strategy in getting people to be, at the very least, introduced and using FileMaker Pro. However, this is not the case. Apple has another reason.

This brings us back to the profitability question. In other words, is it the lack of profits that has led this behemoth company to make this unfortunate decision to remove the Runtime feature?

This is the thing. We have this really strange claim that Apple is presumably struggling to make a profit by retaining the Runtime feature in FileMaker Pro even though it has been able to sell in the past a large number of FileMaker Pro apps (even with the higher priced FileMaker Pro Advanced) for many years. With every new release. FileMaker, Inc. — as the subsidiary company of Apple was once called, and now renamed Claris, presumably because it would give the impression to customers that this was the original Claris Corporation that created high-quality, feature-rich, and very stable software products — has always been more than sustainable. It made significant profits with each upgrade. Yet, for some reason, the profits were not sufficient. Thinking that perhaps sales of FileMaker Pro might go through the roof at Apple headquarters, the company decided to remove the Runtime feature and force people to buy FileMaker Pro. Does this mean Apple is a megalomaniac that does not know what reasonable profits is all about? Or is this just a normal thing for a shareholder company to do?

Or was there a third-party product from another developer that was the impetus for Apple to make the decision to dumb down its FileMaker Pro product, including removal of the Runtime feature?

Well, it makes no sense to think of it as a profitability issue when you realise there is a simple way to create a "Win-Win" situation for everyone. All Apple had to do to solve this alleged profitability issue was to disable in the Runtime app new and important product features introduced in the upgrades. Let FileMaker developers showcase the new features for customers to run in FileMaker Pro, or else stay with the Runtime option. Just make the features look so good and achieve important tasks people look for and you can be sure a large percentage of customers will want to buy FileMaker Pro. That's all there is to it. Yet, remarkably, Apple was unable to come up with this solution. And on reflection, it is obvious that there could not be any way for Apple not to have noticed it. A reasonable person would have realised that it would have been fine to continue providing the Runtime feature in FileMaker Pro and followed the above approach and Apple would be making a bigger profit today if for any reason the profits were not substantial enough from selling FileMaker Pro and FileMaker Pro Advanced in previous years (well, let us put it this way, FileMaker, Inc., the old name for Claris, Inc,, was not indicating it was financially struggling and nearly on the verge of selling up and disbanding the organisation). Instead Apple has chosen not to do it for another reason.

This leaves us with the only viable explanation for removing the Runtime feature: it was to stop FileMaker developers from creating products that could compete and do a better job than Apple's own free iOS/macOS apps. Even when the Apple Silicon chips arrive to enable iOS apps, such as FileMaker Go, to run on macOS, what users will get is an inferior replacement of the Runtime app with no ability to run plug-ins. Plug-ins have the power to meet many shortfalls in the features available in FileMaker databases, and this is one thing Apple will refuse to provide in the next version of FileMaker Go. It is all done because deeper down there is a reason why Apple wants people to use its apps, not FileMaker apps from third-party developers. It is a question of learning about its customers, developing profiles, and seeing what they are doing and the apps being used through the Push technology, as well as to show anti-competitive behaviour to third-party developers who might interfere with Apple's aims. Among the various ways the company will do this include reducing the price and eventually provide certain apps for free, as well as to use its marketing strength to promote and create the perception of Apple products being better. Furthermore, Apple will try to convince people that simpler is better to the point where the company creates very pretty-looking but significantly dumb-down Apple products. So long as this perception is maintained and the price is very low-cost or free, Apple was hoping to stop other developers from competing and/or making a profit in specific areas that Apple wants to have control over, as well as help the company make a bigger profit for itself in selling the more commercial variety of Apple products like FileMaker Pro to customers. It is not about giving customers the best software it can with all the features people look for. The company's profit mentality and determination to prevent one alternative solution that could have easily avoided the loss of the Runtime feature and still give the shareholder company the profit it wanted. It has to be because of anti-competitive behaviour.

That was why Apple introduced the Bento product some years ago (probably built with FileMaker Pro but with extra features not available in FileMaker Pro and so it required the original source code of Bento to be compiled using Xcode to give Apple the extra competitive edge over FileMaker developers in the hope that certain people making database solutions would not pursue their products) and its pricing designed to undermine that of SUNRISE Contacts by exactly half. Since that did not work and Apple decided to end the Bento product to avoid being seen as giving itself a greater advantage over other competitors because it would not allow the same functions and features to be provided in FileMaker Pro, the only solution was to end the Runtime feature. This was Apple's way of avoiding healthy competition among software developers using Apple products.

Apple does not want FileMaker developers to create more flexible, secure and feature-rich apps. Apple has a reason to provide Mac users with over-simplified solutions of its own as we see on Mac and iOS devices. Unfortunately for the company, SUNRISE Contacts was an example of the type of software that could have forced Apple to be more competitive or else lose customers to the FileMaker community. So to handle this situation, Apple knew SUNRISE Contacts relied on the Runtime feature to create a self-contained app. It was better for the company to use its position of power and control of the FileMaker Pro product to effectively stop third-party competitors from competing with Apple. Instead it wants developers to become "sales people" in selling the Apple product, but not to improve and provide better solutions to Apple's own free offerings. FileMaker databases and the Runtime feature were known to the company's management team to pose too much of a problem when it came to its free contacts.app on macOS and iOS. It gave people choice. and it can also potentially affect Apple's profits if the software can challenge the aims of Apple in pushing people towards a certain pay-as-you-go model of service delivery as Apple prefers. Apple wants people to use its apps (one of the reasons why Apple provides free apps with the OS), or else force everyone to go online and on the Cloud and pay for nearly all the services where it can identify everyone as they achieve some goal (in most cases, it is probably to make a profit). And to make sure of it, any means of having an advantage over FileMaker developers would be highly advantageous for the company. Try to stop others from competing against Apple. Removing the Runtime feature is one way to achieve this anti-competitive aim. Somehow Apple is hoping developers will see the advantage of paying Apple to join its elite Apple/FileMaker Developer's club, and users and businesses to join the Cloud-based club called Claris Connect (for a regular fee, of course) and turn them into advocates and eventually sales people, but not to compete with Apple through better products. There will be some discounts as a reward for those FileMaker developers who do the right thing by Apple. Mainly to provide cheaper FileMaker Pro licenses to sell to their customers. But FileMaker database solutions can never be provided for free or very low-cost. It would cost more for FileMaker developers to sell their database solutions as they must include the price of FileMaker Pro app itself.

But there are long term consequences of following this approach, as it will become clear in a few years time. Once the software is out there in reasonable numbers, FileMaker developers will become a dying breed. As Apple simplifies the software and makes it web-based (i.e., "dumbs-down" and make it cost everyone a regular subscription fee to use), FileMaker developers would no longer be needed by the company. They will join everyone else made unemployed by AI technology. They will have to be more innovative and find alternative jobs to pay their way through life.

After losing the Runtime feature in FileMaker Pro 19 as of 20 May 2020, there has been no real compensation to FileMaker developers, especially among those clients that depend on this feature (e.g., the non-for-profit community, or those who may be happy with a simple solution for now). It is assumed by Apple that very few people are using Runtime. To replace the void left behind by Runtime, there is nothing radical or game-changing in the features provided in the new app . Only a couple of new functions to handle conversion of FileMaker Paths to OS paths and vice versa, and a new script command called "Configure Machine Learning Model", and the rest are "add-ons" that involves the ability to extract parts of a FileMaker database that performs certain functions as developed by other developers and distribute them to other FileMaker users as "Add-Ons" to help incorporate in their own solutions. It is hard to see what else has changed apart from the loss of the Runtime option. But even with the few changes, it is not exactly clear why the Runtime feature had to go. If this new Machine Learning technology is suppose to be a real "gamechanger" because it is considered too powerful, just disable it in FileMaker Runtime. Just as we mentioned before, let FileMaker developers show case new features that can only run in FileMaker Pro. And if people find those features useful, they can buy FileMaker Pro. Apple wins with the profits it wants. The developers win by offering choice to users depending on where they are at and what they want from a FileMaker app. It makes this situation very clear that there is no good reason to lose Runtime over ML technology. But still Apple refuses to explain why, other than a claim made by Richard Carlton about the possibility that Apple was losing money from the Runtime feature. That's a load of rubbish. We know it is not a profitability issue, especially since Apple could have quite easily disabled important features to encourage users to purchase FileMaker Pro and let developers incorporate the features as they see fit and where there is a demand for them. There is nothing else in FileMaker Pro 19 to warrant the loss of Runtime. If we leave aside Machine Language and the add-ons, the very few new scripting and functions commands are not sufficient to lose the Runtime feature. For example, the path conversion functions have already been solved through custom function by other developers. Not even the Claris Connect APIs are integrated into FileMaker (this is a separate online service) even though a number of the APIs can be integrated directly into the database solutions from these API developers and service providers. The other add-ons of the Claris Marketplace for things like Javascript features can be created and added to web viewers to display the kind of data you want and communicate back to FileMaker, and web viewers have been in FileMaker Pro since version 12. These Javascripts can be downloaded from other sites and added to older FileMaker solution at any time. There is nothing special about FileMaker Pro 19 to achieve this supposedly magical task (other than to make it a little easier to integrate and perform 2-way communication with FileMaker Pro). So what exactly is so incredibly radical and new in the latest app to deserve the Runtime feature to disappear? It just does not make sense. Unless, or course, there is a hidden agenda from the company, and it has to do with reducing the competition from FileMaker developers in offering free or very low-cost FileMaker solutions to the public.

Apple would rather see FileMaker developers sell more FileMaker Pro apps and force everyone to buy FileMaker Pro just for the privilege of accessing the database files. And eventually Apple wants everyone to be on the Cloud (helped along by Claris Connect as a separate API service). If this isn't enough incentive, in two to three years from now, a new processor with a reduced instructions set will likely see many current Intel-based apps no longer work. Bad for Runtime apps. But great if you are an app developer wanting to get everyone to use online-apps only, seeing what everyone is doing, racking in the profits, and take advantage of the work other people do online. In that way, people will be asked to pay for endless subscriptions and, at the same time people can be monitored, right down to all the tools being used, develop a profile of people and their businesses, gather some business confidential information and ideas that developers can use or "steal" for their own commercial interests, and find innovative ways to encourage people to pay more for extra features that may be useful in the future. Every feature must be used regularly by enough people, and all have to be done online for some reason, and designed to maximise Apple's own profits on a constant basis as if it is struggling to make a profit. Not likely looking at previous releases of the FileMaker product. At the moment, Apple thinks removing the Runtime feature will not affect sales as it thinks very few people will use it. If that was true, why disable Runtime in the trial versions of previous FileMaker Pro versions? Too powerful to let people try it out? Or was it simply the fact that there were people using the Runtime feature and Apple did not want to give away this ability in a trial version?

As can be seen, the word "deprecation" does not necessarily mean a function or feature has been, or will be removed. Sure, there is a strong indication that a function or feature is likely to be removed, but it need not necessarily be the case that it will. Various factors will determine how likely a feature or function will disappear from an app. For Apple, the term may be nothing more than a cost-saving decision to dumb down software and reduce the costs and time to support extra features. But then again, you would expect the company to be listening to users to see what they want. If people say they don't want to lose certain features, a sensible software developer would avoid removing them. Indeed, for other developers, it is usually a way of determining the reaction of users in hearing about the proposed removal of a feature. Should there be enough complaints from the users, the "deprecation" status of a feature is always dropped. For Apple, this is not the case. It had plans to remove the feature for a long time. It was not the lack of users using the Runtime feature, or whether people would complain about its loss. Apple knew the feature is too popular and useful to a lot of people. Far from it. Nor was it a profitability issue. Apple was constant making healthy profits from the sale of FileMaker Pro and the Advanced version for many years. The only reason Apple had to remove it irrespective of what users and developers want is because the Runtime option was giving some developers the ability to compete with Apple's own free apps or paying Cloud-based apps with alternative and more privacy-protected solutions and features that Apple was not prepare to provide to Mac users in its own apps. Apple did not want the extra competition, so it felt entitled to remove the feature thinking this will avoid the extra competition and so get additional profits while benefiting from constant monitoring and identifying of people, especially when everyone goes online and the FileMaker Pro app only works as a web-only app.

It was not about understanding the needs of the users and developers. Apple was not interested in listening to users on what they want to see in the Apple products. Rather, it did everything it could to hide this "advanced" (or "pro") Runtime feature. Right down to hiding a checkbox in the Preferences dialog to make the Runtime feature visible in the menu. Apple really wanted to push FileMaker Pro to no longer have this advanced feature or at least not be visible to new users. It was not a case of insufficient users using the Runtime feature. We know plenty of people used the feature. At the end of the day, it was a determined decision by the company to remove the feature by any means.

To force further changes on users, FileMaker Pro 19 no longer supports Windows 7 even though there are plenty of PC users out there who are happy to use Windows XP and 7. It is not a numbers game for Apple of how many users are on a version of an OS. For Microsoft, it is a numbers game. Microsoft has not moved on from Windows 10 despite making sure it can run nearly all legacy software on it. The company had hoped this compatibility aspect would encourage users to upgrade, but it hasn't.,For most users, they are happy with Windows XP and 7. Windows 8 had major problems, and Windows tried to improve on the mistakes. Windows 10 is much better but it is a monstrosity to install with little or no added benefits to Windows 7 other than to fill up more disk space. So now, Microsoft is in a quandary on what to do next. Should the company release Windows 11 or not? The decision so far is to stop upgrading the OS. But Apple is different. With a younger market of Mac users who think anything new equates to being better and a must-have feature (so they can brag to their Windows friends about how good the Mac is), they are more likely to adopt almost any kind of changes (if they think it is sufficiently different and better in their minds), even if it seems very minor or cosmetic. And Apple knows this. The company takes advantage of the situation to get people to upgrade who seem silly enough to spend money buying new Macs and upgrading third-party software on a regular basis to get things working again. Now that Apple has some experience in how to do this and brought it down to a fine art, Apple is trying to help Microsoft to force people to upgrade the OS, as well as itself and to capitalise on these continuous "apparent improvements" for the sake of making high profits in selling the latest Mac to run the latest OS, FileMaker Pro to open and use database files, and any other software. Now FileMaker Pro 19 will not work on Windows 7. Only Windows 10. How interesting? It is the endless treadmill of forcing users to change and pay if they want something to work. And even then, Apple is dictating how people should do things, and make a profit along the way in doing so if users are silly enough to accept the changes.

Could this explain why a number of business executives, including the CEO of the former FileMaker, Inc., decided to leave the company? The official Apple explanation given for losing these people was because they were not being innovative enough to try out new things like Claris Connect. Not likely. When the big decision came to shake up FileMaker management team with the new direction and where the FileMaker platform would be pushed, people were not happy or saw no future in the product. The decision to dumb down FileMaker Pro in achieving this web-only app aim by losing a key developer feature as ordered by the Apple management board was not to the liking of the previous FileMaker management team. The team knew if would erode the fundamental customer base of genuine FileMaker developers and anyone else who saw the Runtime feature as being integral in their work. As for "not being innovative", it was quite likely to be the opposite. The previous FileMaker management team probably did try to be innovative but kept being restricted by Apple. The team were required to be sales people promoting the Apple aim for the product. Then the Runtime feature disappeared. Huh? Clearly people are going to notice something strange in FileMaker 19. So Apple wanted Claris (the new company name) to emphasise the Dark Mode and the Add-Ons feature as if these were meant to be the replacement for Runtime as compensation for developers who use the Runtime feature. Well, the Dark Mode design is not exactly innovative. This is a straight copy of Adobe Creative Suite/Cloud products. Unfortunately, one can't apply the "lack of innovation" to Apple as you can't take the Apple management out of Apple as easily as it can at the former FileMaker, Inc. And Add-Ons are not exactly a game-changer in the sense that developers can already copy and paste features and functions of other FileMaker databases. It might save a bit of time if set up correctly and perhaps to allow some developers to make money selling Add-Ons, but not a "game changer". Apart from that, machine learning might be useful and seems like a logical evolution as one would expect of an upgrade, but do disable it in Runtime if Apple considers it too powerful a technology to be made available to everyone unless Apple has made a profit from selling enough FileMaker Pro products. As for the rest, mostly a handful of new script commands and Javascript add-ons that developers can already do in previous FileMaker versions using custom functions and the web viewer. And now certain APIs are being separated from FileMaker Pro and put into the Cloud as Claris Connect to start enticing customers to move away from the desktop and eventually do everything online. The implications of this separation of features and forcing people to go on the web is that the plug-in feature in the desktop product will be deprecated. Soon after, FileMaker Pro will be web-based only, done on the web browser for Apple to see and rake in the profits continuously (as part of the motivation from Apple to make these changes). As a result of this loss of the Runtime and where Apple wants to take the FileMaker Pro product in the coming years, this was probably enough of an impetus for those who worked in the former FileMaker, Inc. company to move on.

It is amazing. All this effort to remove a key feature of FileMaker and considered unique to database development at its price point (even if one had to pay an extra $300 for the privilege, and far less than Microsoft's own Runtime solution for Microsoft Access) despite the fact that Apple offers the free Xcode for developers to create any software they like. Developers can make a CRM if they want with Xcode and sell it. No doubt Apple hates the idea. So the only thing Apple can do to control this potential extra competition should some developers decide to go in that direction is to apply the regular upgrades of the OS in order to make slightly old software not work again, and so forcing developers to regularly pay their annual developer's subscription to receive the code-signing certificate and update their software with the latest Xcode just to make their software work again, and all the while Apple wants to claim the new OS is an improvement and necessary for all Mac users (cough!). Somehow FileMaker Pro cannot be allowed to do the same. It does not matter if most people describe it as foremost a software development tool with a database feature added on, especially for the Advanced app version. This is not how Apple wants to see it. Rather, the development of FileMaker databases should serve a more dumb-down purpose of simply storing data, allowing the data to be found, and having it used in-house together with a pretty interface should people want to go that far with it. There is no point as far as Apple is concerned in having a self-contained and running app that could be used and sold to "external customers". FileMaker Pro is not Xcode and Apple wants to make sure of it. Furthermore, Apple will not offer an alternative to the Runtime option in FileMaker Pro, such as a tool to migrate and compile FileMaker databases into Xcode to work as self-contained apps. FileMaker developers are required to find alternative third-party solutions for creating a Runtime solution if one exists.

After losing this key feature as Apple tries to create apps that "surprise and delight" people, what do we have left in FileMaker Pro 19? One or two new scripting commands, a couple of path conversion functions, some support for Linux systems (those people desperately need it), the ability to turns parts of a FileMaker database into Add-Ons to share with everyone else, a new command to handle Javascript integration, and the rest is a fancy Dark Mode user interface presumably to wow the pants off customers and think they have a better product now. Anything else Apple has done over past 12 months was to acquire a few APIs and monetise them through a separate online "Claris Connect: store while permitting database developers and users to bring together a few Javascript "add-ons" and some useful plug-ins already on offer for the past 10 years to keep them busy. And still after losing the Runtime feature we cannot get the GetNthRecord bug fixed (the one with a "?" in the calculation after around 277 records, making it less of a delight to use, but a "surprise" that it hasn't been fixed after so many years) nor can FileMaker Server 18 receive the necessary bug fix for its startup restoration feature to work properly. So much focus on alleged innovation (mainly to create a fancy looking dark mode user interface and dumbing down the app with the removal of the Runtime feature), taking pictures of cities where the Claris office is located in the Contacts page (sounds like Apple has more money than sense and too many people support and do nothing more than sell ice to the Eskimos), a change in business name to Claris International, Inc. (Apple definitely has too much money to spend if it wants to update the letterheads and other stationery items, and yet this company is nothing like the original Claris Corporation that did quality software development work in the 1980s and 90s and was noted for being the most bug-free solid-as-a-rock products on the planet), and later compile some URLs of third-party APIs, Javascript modules and a few ready-made plug-ins that people can use, and that's about it. Yet not enough on the fundamentals of making a solid bug-free and flexible app.

So where are we at with FileMaker Pro?

At the moment FileMaker Pro 16, 17 and 18 can generate Runtime apps to run in current OS versions. This means SUNRISE Contacts will continue to run for at least the next 5 years on a Mac, and twice that on Windows. We will continue to offer this feature while there are enough interest by users in having a Runtime solution.

After that time, you can create a virtual disk made with VMWare Fusion, Parallels Desktop, or VirtualBox to run an older OS (Windows 7 to 10, OS X/macOS 10.10 to 10.14, or Linux) version. SUNRISE Contacts will run happily on this system, together with FileMaker Pro if you choose to have this tool as well. You can also use Boot Camp. However, when the new microprocessors arrive in approximately 2 to 3 years from now, your better option will be in the use of a virtual disk. In terms of performance, this should not be a problem thanks to the speed of Solid State Drives (SSDs) these days. Of course, if you do happen to have the latest FileMaker Pro available on your desktop (and before the day when Apple chooses to make everything web-based), you will have no trouble running SUNRISE Contacts. However, if you want a self-contained and running app that does not require FileMaker Pro, FileMaker Server/Cloud, or be locked into a particular OS to use it, there is a movement online to read/convert FileMaker files into a suitable programming language. The benefits of this approach is that the files can be compiled into compact and faster running self-contained apps with greater compatibility on a wider range of platforms for you to run the app. At the moment, the ability to convert FileMaker files is about 90 per cent there as of May 2020. Over the next five years, this will increase to at least 99 percent. Already there is an effort to completely reverse engineer the FileMaker "fmp12" file format. And once that is complete, conversion will be 100 per cent effective. In fact, FileMaker developers can continue to create FileMaker apps in FileMaker Pro until such time as Apple chooses to push its product as a web-only app. After that time, developers will have a permanent Runtime solution and one that is more flexible than Apple's offering. It will be the solution to the Runtime loss and one that can run more flexibly on Linux and Android as well as Mac, Windows and iOS.

The only good thing to come out of this news is that SUNRISE Contacts with its Runtime app will continue to work with all Windows 7 to 10 and the next couple of macOS versions. Later, you will have a choice of running it through an emulation program on a virtual disk, or the fact that an alternative solution exists to enable a standalone app to be created and not be influenced by the decisions of Apple in stopping it. Or else Apple will inadvertently allow FileMaker Go to run on macOS on the new Apple Silicon Macs to behave like a Runtime solution, since FileMaker Go is free. But for how long? If there is any substance to this "profitability" claim as the reason to lose the Runtime feature, then we should expect Apple to eventually decide to put a price tag on FileMaker Go in the next few years.

To learn more about some of Apple's anti-competitive practices to prevent SUNRISE Contacts (and other similar solutions) from competing with Apple's own similar OS X apps, click here.

If you need the final and latest Runtime app to run for as long as possible, download Mac or Windows file and drag-n-drop the FMP12 database files into this new SUNRISE folder. These are the final stable and most compatible apps you can get today. For iOS, use the free FileMaker Go app (which is not yet obsolete). For Android, Linux and other users, wait for a compiled version of SUNRISE Contacts in the near future, or you can use WebDirect on FileMaker Server if you want to financially support Apple in its aims.

As a side-note, a number of Not-For-Profit organisations that have relied on FileMaker Runtime solutions to lower licensing costs are being forced to move to another platform as of May 2020 using one of the competitors' alternative "database solution" products, most notably SalesForce. It is considered the lesser of two financial evils when compared to the increasingly higher costs of Apple's FileMaker platform. This is especially true when we are talking about FileMaker Pro and Server in the numbers required to be effective and useful to an organisation and in order to meet the new licensing requirements. Unless CEOs are the Elon Musk's of the world with money to spend, most ordinary organisations will no longer see the FileMaker platform as a cost-effective strategy. We can only re-iterate our earlier question: "Why remove the Runtime feature?" There is certainly nothing particularly innovative about this decision from Apple to do away with the feature. Clearly there were people out there who found the feature useful and, in many cases, essential. Instead we have a spiteful company that is too heavily motivated by excessive profits (as you can expect from a shareholder company that does not understand sustainable and sensible profits, only excessive profits to keep shareholders happy) and wants to be anti-competitive where it can to protect its own interests.

3. My FileMaker Pro 18 Runtime app crashes on launch. Why?

Funny that should appear at this time (just before the release of FileMaker Pro 19 that comes without the Runtime feature). As part of the effort by Apple to discourage people to use the deprecated the Runtime feature, the company has conveniently put in a bug of its own (with absolutely no testing performed if it was accidental). It concerns whether the runtime app is allowed to launch on the latest macOS High Sierra or higher versions. Fortunately there is a solution. If the generated runtime app from FileMaker Pro 18 is not launching on your Mac because it shows the message, "EXC_CRASH (Code Signature Invalid)" in the crash report, you need to:

  1. Show Package Contents of the Runtime app itself.
  2. Inside is a folder called "_CodeSignature". Delete it.
  3. Close the folder.

Launching the Runtime app on a Mac should now work. This is the only difference to be found (apart from the general FileMaker engine updates, which is extremely minor) when compared to older Runtime apps and the reason why those older apps can still run on macOS High Sierra or higher.

4. Why is FileMaker Pro 16.0.6 is now generating damaged Runtime apps on a Mac?

Did you update from 16.0.5 to 16.0.6(.666)? The final update to FileMaker Pro 16 (version 16.0.6.600) released in June 2020 and with its infamous 666 incorporated into the version number now creates incomplete / damaged Runtime apps to prevent people from using this feature (or force users to upgrade). It is imperative that you maintain a copy of the 16.0.5 update or FileMaker Pro app with version 16.0.5. Unless you already have the Runtime created and working for you in your solutions, you will have to downgrade.

We will investigate the changes made to the Runtime app...

The Runtime apps for the Mac have been analysed. The critical change that stops the Runtime from running is in Info.plist. Use Get Info on the app and choose Show Package Contents to find this file. Here are the differences between 16.0.5 (left) and 16.0.6 (right).

As you can see, some information has been lost at the end of the text file in 16.0.6 compared to 16.0.5.

If you have created a Runtime app in version 16.0.6, you can move the latest package contents except Info.plist to your 16.0.5 Runtime app version containing the same database files and having the same date/name identifier. It will work.

Have you already updated to 16.0.6.600 by mistake and don't have a way to go back with the right updater and/or installer? You can download FileMaker Pro Advanced 16.0.4.403 (use your serial number to install) and apply the FMPA 16.0.5.500 Updater.

Now testing the PC side....

Runtime apps generated on Windows by FileMaker Pro 16 appear to be working fine for version 16.0.6.600. This final update should be fine for PC use.

5. How do I import SVG images into FileMaker Pro?

A good choice of a graphic file format. SVG images are resolution-independent and infinitely sharp images. You can scale them up to any size on a layout and it will look sharp. However, the only way to import SVG images into FileMaker are as follows:

  1. In Layout Mode, choose Insert-->Button from the menu.
  2. There is a button with a + sign. Click on it.
  3. A dialog box appears to let you select the SVG image.
  4. Adjust size according with the slider.

But as you will discover, Apple/Claris has not provided a field box to enter a custom image size in pixels to any amount. All SVG images will be kept to a maximum of 128px. If the company is so eager to promote innovation, how about putting in a field box to control image size properly?

There is one more thing you have to do prior to importing SVG images for them to benefit for FileMaker design features:

  1. Open the SVG file in a text editor.
  2. Do a search for those text lines that start with "style=" and contains within the quotation marks the words "fill" and "stroke". After the ending "greater than" symbol, put a space character and type class="fm_fill". What follows after this should be the data to draw the shape of the image starting with d=". The purpose of adding this class information is to permit button icon color to be applied to the image by FileMaker.
  3. Repeat step 2 for all other lines with this fill and stroke information for each shape making up the image.

Now you can import the SVG image into FileMaker Pro.

NOTE: Not all SVG files will show a fill and/or stroke information, so knowing where to put the FileMaker class information can be tricky. You either have to import into Adobe Illustrator and re-export to get that information visible for you to add the FileMaker requirement (and with the added metadata and other crap that comes with Adobe generated files, or wait for Apple/Claris to be more innovative in getting this whole process streamlined and working in one go within FileMaker Pro. It is time to have this fixed.

6. I have FileMaker Pro. Do you have advice on how to organise my FileMaker solution during development?

You have probably seen various standards of naming fields, tables, scripts, layouts and so on and other standards, such as this one from RCC. What is in common with all such standards is a means of organising your solutions in a way that not only help you to understand what you did in 6 months time, but anyone else who may be required to look at your solutions (sounds likely? It is only when you work for a team of developers will you understand the importance of keeping your app well-organised.

The way RCC does it is mainly to get a lot of the beginners and intermediate FileMaker developers on the same page with each other, and with the assumption that FileMaker solutions may get dissected and improved by other developers. It is about helping everyone to understand what has been done in a solution. However, despite the good intentions of the people at RCC and anyone else who has developed this organizing convention, there are drawbacks. For example, the idea of putting numbers against layouts such as L10, L11, L12, etc might help if you are talking to another developer a million miles away about a particular layout (because they might be required to work on the layout), but it makes no sense in the scripting environment using a simplified and powerful script to handle multiple layouts in the simplest way. As an example, some auto update scripts may require running for a selected range of layouts (e.g., card layouts versus standard layouts). Otherwise you will end up writing in your script a complicated IF Get(LayoutName)="L10..." OR IF Get(LayoutName)="L11..." OR and so on THEN DO THIS SCRIPT. Really? This is a PITA.

Some organising is acceptable, and probably necessary if you intend to go back to your solution at a later date.

For example, use folders as a means of organising layouts based on their function and how they are related by the relationships established in the tables underlying the layouts. Also think about the scripts and what they need to do with those layouts. If you like, add at the beginning of the layout name a word like "Layout" or "L" for standard layouts, "Card" or "C" for card layouts, and so on. Don't worry about numbering every single layouts, scripts, and fields to the nth degree, or else you will find your scripts and custom functions will get overly complicated. And if you have to rearrange the layouts in order of priority or importance or realise another layout needs to be associated with a different group of layouts in another folder, it is going to be extra work in renumbering the layout names.

We agree that variables (both global and local) as well as fields should have meaningful names (e.g., Last Name is better than LN). And there should be just the right amount of comments in scripts or in folder names to provide an understand of what each important section of the script or layouts do. But don't write copious amounts of comments every second or third line. This is something that we have seen RCC do, perhaps for the sake of explaining things to FileMaker beginners in a sample file, when the coding and comments could so easily be dramatically simplified. A classic example has to be the application of REST APIs, and the shocking number of $variables used presumably to break things up and explain things (together with lots of comments) when a simple LET statement can prepare the data compactly prior to sending the data off through the SEND AS URL statement and yet still be able to explain the guts of it easily enough).

At the end of the day, you use whatever organising system that works for you. But as your solution grows and with the possibility that other developers might get involved, you should come up with a system that anyone can understand and helps to fully document what you did. And what that system should be will depend on the type of solution, how sophisticated it is, and how you you design your scripts to be simplified to handle many aspects of your solution.

If you need rules to follow, there are really only four basic rules to organising a FileMaker app:

  1. Keep It Simple S*** (KISS) as the old adage goes still applies to FileMaker apps. If you can think of a simpler and more elegant way of achieving the same task, whether it is on the user interface (through fewer clickable buttons etc.), within the scripts, or even the tables and relationships you form within your database solution, then do it. The simpler something is and makes sense (i.e.becomes intuitive) to you (and for other people), the easier it will be to use the solution and with ruthless efficiency and effectiveness, or to debug later. In fact, in the latter case, it will help you to see the big picture of how the various important parts of the app works with respect to everything else. And it can have another unintended benefit in keeping things simple: it can speed up your solutions (especially while Apple is not able to provide a compiler to convert FileMaker solutions into proper 'machine code' apps, and yes the company has stupidly removed the Runtime feature from FileMaker Pro version 19). It kind of lends into the idea that RCC and Nick Hunter keeps banging on about with users in regards to "Lean Design". Or alternatively, just give FileMaker developerss a compiler to get the speed users are looking for (not likely since Apple has a reason to keep FileMaker Pro where it is).
  2. Name all your layouts, fields, tables, scripts, custom functions, LET variables and so on in a way that makes sense not just to you but also the average Joe Blow on the street. The test to see how well you have done this is to come back to the solution in 6 months time. Ask yourself, can you pick up from where you left off or look at any other aspect of the app and know exactly what is going on in less than 5 seconds? If you can, brilliant. You have the right organising system in place. If you can't, you have not named everything clear enough and easy enough for you to do your developing work on it.
  3. Provide the right amount of comments for important sections of your scripts or guts of your custom functions, and essential layout groups, to help you understand what those key sections are doing. Try to use the fewest words to describe it. To test if you have done this right, can you be asked by another developer to find several lines of a scripting code quickly not just by the way you have named the scripts, but also the comments that help you to hone in on that important piece of coding sub-script?
  4. Finally, use your solution day-in and day-out. Ask yourself every time you perform a task, "Could I have done this easier?" Not only will the bugs emerge to help you wipe them out faster than than a frog with a 7 inch tongue at a fly convention, but you will simplify the solution and number of clicks to achieve your tasks and with an interface that is totally intuitive to a level that will be ridiculously easy for anyone to use (and no need for a Dummy series of instruction books to explain what is going on).