I am so thrilled, amazed and look forward for new opportunities with new FileMaker iOS App SDK. I’ve developed a technique for updating FileMaker Pro Desktop solutions and published it recently. So I thought to try to use the same approach to update the native iOS App created with FileMaker iOS App SDK. And to my surprise, I implemented the same technique with minor modifications and the update works!
Check these resources before reading further:
- iOS App SDK Instructions from FileMaker Inc.
- Important development considerations before using the iOS App SDK from FileMaker Inc.
- Richard Carlton’s and Todd Geist’s Webinar about Making FM Apps for Apple’s App Store (Youtube video, 1:12:42).
Introduction
This post is about how to update the App when you have created a native iOS App with FileMaker Pro and FileMaker iOS App SDK. Mostly I will be dealing with issues described in the second resource I mentioned above.
There are 2 different architecture strategy considerations for your app which are related to the update:
1. No use of FileMaker Security.
This strategy should be used when you want to create a stand-alone iOS App, which means your App would be installed on a user’s iOS device without any connections to external servers.
When no password is set in *. fmp12 file, everything behaves as a standard iOS App update: the iOS relaunch the App and opens the latest database file. Once the new version is delivered to iOS device, new *. fmp12 file is uploaded to the App as well.
2. FileMaker Security is fully used.
iOS applications created with FileMaker iOS App SDK are designed this way, that if you close the App and then open it again, it reconnects to your old database file asking to enter login and password. You have to delete the App to get a new version of your FileMaker application. The problem here is that every new update is delivered iOS installs new *. fmp file, but it doesn’t launch it until previous file is not closed. When we close the old file and start the new one, we have to transfer data from old file to the new database.
Now, we have to think how to inform the user when a new version is on his iOS device? The easiest way, we can create an Update button and when the user clicks it, update starts up. Here are some other examples where we can put the checking for new versions:
- On entering the particular layout
- When layout changes
- When any button is pressed
- When user comes to a particular place in your app
- And more… You decide!
Once you make a decision where you will add the checking for the new version you have to add this simple script step to your scripts:
If [ ValueCount ( Get ( DocumentsPathListing ) ) > 1 ]
If the answer is “True” that means the new version of your App has been delivered to your iOS device!
FileMaker Script Steps used in the update technique
Only native FileMaker scripts are used in this technique. Scripts should be in the old and new files at the time of updating, so you have to think about this technique before delivering the first version your app.
- Startup Script, it’s the most important and where everything is set to work. Please download Demo file at the end of the post for more details.
- If you chose to use FileMaker Security within your iOS App so you have to close the old *. fmp12 file. The iOS will not close the FileMaker database file until the user will do so. Even closing the iOS App from the background will not help. I decided to use script trigger which will be triggered when user opens the Layout. When the trigger is activated it basically checks if there are more than one database file within iOS App. If the answer is “True”, the hidden text object appears which says:
“New version for this App was released. Update data.“
Place it somewhere where users could see it easily. The button is set for this text, so when the user taps it, current *. fmp12 file is closed. iOS instantly relaunch the file, but it will open the latest version. So, when new version starts up, we have to import records from the old version.
- First of all, we have to open the old file. We use an Open URL script step to open the old file. Then we run “Prepare for update” script which is very important. It goes through all tables and make Show all records in your old file. It requires, because if Found sets has been used, so it may import the last found set instead of all records.
- When the old file is prepared, we run the “Update from old file” script. Which basically imports all data from the old file. At this point we already have all data in our App.
Important. Thinking that it won’t be the last update we have to remove the old file. Because when we’ll deliver update next time our current file will become old file and we’ll have to import from this file. If we’ll keep the old file after next update we’ll have 3 database files and data will be imported from the old file. We don’t want that user will lose his data, right?
- So the latest thing to do, we have to run “Delete old file” script to avoid data import routine problems in the future. I use a very old technique to delete files from FileMaker solution: Export empty found records to the file’s path will delete the file.
That’s it! The native iOS App created with FileMaker iOS App SDK was updated!
Some things has to be kept in mind!
- As FileMaker, Inc. suggests in its development considerations we have to set file names correctly. I use very simple naming for version in my example:
- First App.0001.fmp12
- First App.0002.fmp12
- First App.0003.fmp12
- etc.
- Make sure you prepare the file for the update correctly:
- Delete all test data.
- Set required Settings, Globals etc. for your App.
- Set Startup Tasks correctly.
Startup Tasks are very important in this technique, because it runs the required scripts at the required time. So, please pay attention on this part!
Conclusion
This is the biggest issue with the FileMaker iOS App SDK, I think there will be no more boundaries why Apps created with FileMaker Pro couldn’t be sold through the Apple App Store. I will test it with my other apps and will write a report if this technique got approved or not.
Demo File
I’ve built an example file that shows how everything works. Please use it for your purposes and I hope this technique will help you as much as it does for me.
Note. I’ve removed my URL Schema, so please do not forget to add your own URL Schema to custom functions at File > Manage > Custom Functions…
Please fill up the form to get the demo file:
Contact us if you’d like our assistance in turning your FileMaker solution into a native iOS application – we would be happy to help!
I couldn’t refrain from commenting. Exceptionally well written!
Appreciate the recommendation. Will try it out.
It’s nearly impossible to find experienced people about this topic,
but you sound like you know what you’re talking about!
Thanks
Really enjoyed this post. Great.
Hello… yzysoft
its an informative post on How to update native iOS App created with FileMaker iOS App SDK. I would like to say Thanks for helping. iOS APP Development
At what point are you setting “New Version Task” to 1? It looks like its only in the developer scripts.
New version task flag field is required for Startup script. If you’ll open the startup script you will see, that it controls what has to be done on the startup. Also when you release new version of the file you have to set the field value to 1.
Each of the following tasks do these actions:
0. doesn’t do anything related to an update. Just opens the file for regular use.
1. When you deliver new version the task is set to one which will do the following:
1.1 Opens old (previous version) file.
1.2 Prepares old file for data import, which means remove any founds sets in all tables. If there is a found set, so the data would imported only as is in found set.
1.3 Imports data from old file.
1.4 Sets task to number 2.
1.5 Exit application. This task is required to close both files at once.
2. Your new version of the app has data from previous version and now you have to do a house keeping task:
2.1 Delete old file.
2.2 Set task to 0.
2.3 Show notification for the user that his app was updated.
I hope it will help…
Does this mean that you are going into the New Solution file, creating a record and then setting the New Version Task field value to 1? I am confused here.
Hi, thanks very much for posting this! I am a little stuck on the opening of the file with Open Url. How do you come up with the data to add to the custom URL schema.
Hello,
I have found this method very interesting, and am trying to understand it, but I have a couple questions.
I am to understand that in the updated version of the file, you set the New Version Task to “1”, which causes the startup script to perform the updates. But I don’t understand what to enter for the Custom Function: URL Schema…?
Also, on the desktop the “Check for a new version” script step every time I run the Value Count (Get (DocumentsPathListing), FMP 16 ADV crashes on the desktop, but not the iOS (iPad).
Thanks,
Aaton
Thanks for the questions:
URL scheme is a specific protocol for communication between the apps in the iOS. You can read more about it here.
If you intend to have your own app you have to think about unique scheme name which will be used only for your app.
ValueCount (Get (DocumentsPathListing) calculated function counts all documents which are in your Documents folder. If you have thousands of documents in you computer’s Documents folder, so FileMaker have to calculate them all and will bring you the result. At this moment FileMaker brings ‘not responding’ flag, but after some time it wakes up. And on iOS, Documents folder is intend only for apps, so that’s why it doesn’t take to much time.
Hope it will help you develop even better apps…
Thanks again. I am close to submitting an app using a modified version of this and once approved I will update you with what I stumbled with to get the update to work properly. I am very new to FileMaker and Xcode but have created an app in a couple months. One thing to consider is the configFile.txt and the solution copy option, as a stand alone app if you set this to 4 you can skip the close file step and automate the process. Everyone needs to be very careful to look at all the sorting and import script steps. I doubt that Apple will approve an app where the conversion is not automated. I cannot thank you enough for sharing this information!
Lou, glad you find it useful. Please share your experience about submitting the app to the Apple.
Hello, I noticed that the $url variable isn’t used anywhere in the subsequent scripts. Is this a possible error? I’m having trouble importing data from the old file, and thinking this may be it??
Hi Ramone, could you please be more specific what kind of error you get? It’s hard to define what could be a possible solution. Thanks…
I have not been able to replicate this from the demo file. The new solution is installed but the data is not copied into the new file.
This worked great up until testing on the iPhone X. I receive an error saying “filename.fmp12″ could not be created. Use a different name or make more room on this device.” The process works flawlessly on all other devices I have tested on including all other iPhones and iPads, but when I run on a iPhone X I receive this error and after clicking ok I see no records in the new file, no records are imported from the old file and the old file stays on the device, it is not deleted. Any idea what may have changed with the iPhone X to cause this and any way to fix?
Following up, I figured out the problem with my iPhone X, versus every other iOS device, issue with the above process. Turns out (at least my) iPhone X sorts the files in the documents directory in DESCENDING order, all my other devices sort in Ascending order. The scripts above first look to see if there is more than 1 file in the directory, this works fine. But when figuring out the filename of the OLD file to import from and to eventually delete from the directory, the line “Right ( GetValue ( Get ( DocumentsPathListing ) ; 1 ) ; 20 )” looks for the FIRST file in the directory and sets the variable to that filename. On my X that file is the CURRENT/NEW file so it can’t import anything (because it is blank and trying to import its own content) and it can’t delete it afterward because it can’t delete itself. I hard coded the filename of the original file into the import and delete scripts and it works flawlessly. So the method above needs to be modified to find the old file a different way, the Right ( GetValue ( Get ( DocumentsPathListing ) ; 1 ) ; 20 ) method isn’t consistent across all devices.
Jason, thank you for your effort in making this technique flexible. Great job!
Glad I could help, at least a little. Now if anyone smarter than me can explain how to sort the directory consistently regardless of device, so that this technique can still find the oldest file properly. I don’t think hardcoding the name of the file is going to be foolproof enough, for instance if a person doesn’t download an app update for a few versions, then tries to update. If version 0005 is hardcoded to find and import from 0004 how will it know that the only file in the directory is 0001 and find it to import, etc.?
I have been able to get this up and running and working. But there are a few flaws with this approach I have found.
1. If for some reason the original filemaker pro file is not open within the application, you will run into major issues. This update process assumes that old file is already open. If its not open and they now open the app up, the app will likely open the newest version of the file the first time and automatically being running the update process and this has caused me issues.
2. This doesnt account for multiple files, it only works if there are 2 files. What happens if more than one update is pushed out and the user hasnt clicked the “update button”, its possible that they may have 3 or more files. The update solution has no way of knowing where to import data from. It always just uses the first file in the documents path. I dont see anyway of controlling what order the documents are put into the documents path.
Honestly filemaker needs to put in a solution to update offline files themselves. I have tried building my own solutions and using others like this one. At the end of the day, they are extremely fragile and prone to errors that could cause sizable data loss.
Has anyone tried testing this with Test Flight? I have this working using iTunes on my local environment, but would like to know if anyone has tested this in the real app environment.