The effect that the Exit Application script step has is that it will still close our current file (and any hidden but referenced files) and immediately try to re-open the main file. In our custom iOS App the files interface does not exist. The Exit Application script step in FileMaker Go usually takes us back the files interface. We've turned several existing iOS solutions we've built into standalone apps and based on that experience I've put together four articles that go through the technical "nuts and bolts" of the process. As this is all still very new I may not have everything perfect - let me know if I’ve missed anything and I will update the article/questions as we go.īefore you start it's worth keeping in mind that there are things that will not work as they do in FileMaker Go so you may want to make a few changes to the solution. More on deployment and distribution options later. In fact you can even sell (or give it away) through the App Store if you've built something that you want to distribute widely. It opens quickly, with it's own splash screen and it's easier to install. The other advantages are that it just looks and behaves like a standard native app. The key thing is that once you've got a standalone app, it's much easier for users to have your database as an app just like any other app, as an icon sitting on the iPhone or iPad rather than buried away under FileMaker Go. The process is a little tricky and there're plenty of things to be aware of. Building an iOS App from a FileMaker DatabaseĪs you may be aware FileMaker Inc have given developers a toolset ("SDK") for creating standalone apps for iPhone and iPad, from FileMaker databases.
0 Comments
Leave a Reply. |