3 Replies Latest reply on Aug 17, 2016 10:38 AM by schamblee

    Best practice on rolling out new version of FileMaker Go to users


      I am planning a major rollout of version 15 of FileMaker Go for about 90 people using version 13 or 14.

      They are all acccessing the same served file from FMS 14. No local files.

      These are non-technical people so the current process is too cumbersome.

      Ideally they would click a button in their database which does as much as possible for them.


      What I want:

      1. Download version 15 from the App Store

      2. Open the served database in the new version.

      3. Close the original version with a message to manually remove the app from the device (optional)


      Step 1 is just a link and is something they also can do manually, but step 2 is beyond most of them. Fiddling with url scheme of Fm is too involved. Step 3 is also possible to do manually, but may be optional.


      I would like to hear from others how they have done this, as smooth as possible.




        • 1. Re: Best practice on rolling out new version of FileMaker Go to users

          Unless all the iOS devices are managed centrally there isn't going to be a lot you can do to automate everything you want.


          1) Downloading the new version of Go

          In your existing database you could put a link to Go 15 on the iTunes store. A nice big splash screen that makes it really clear that its time to upgrade. Tapping the link would open the Store app and direct to the app. They'll have to manually start the download/installation and provide the proper credentials. Seems you've got that one covered. Could also be an email with the link to the iTunes store.


          2) Open in new version of Go

          The user has to launch the app themselves and open the new database. Possibly send an email with a link that opens the file - can't assume that it will open in 15 vs the earlier version unless they've manually deleted the old version


          3) You can check the app version on startup and direct the user as to what to do next, but it will be a manual process again. With that many users it may take them a while to do the installation - causing problems.


          What if instead of using Go you created a launcher file and converted it to a standalone app with the iOS SDK? You've still got the installation issues but the app could remain the same over multiple versions - it just points to a new version on the Server.


          Alternatively you create a very detailed and simplified document that steps them through everything.

          2 of 2 people found this helpful
          • 2. Re: Best practice on rolling out new version of FileMaker Go to users

            Thank you David for that detailed reply and your insight.


            I have made a web page with the necessary links and i think I make a rather detailed instruction there.


            I was thinking maybe I should make them uninstall the old version before downloading the new version. That way I can be sure that the link to the database will open in the right version. Also because the app names are identical (doh!) and app icons are almost indistinguishable from each other, it is hard for users to know what app to uninstall after installation of version 15. Another support headache.


            I have been considering making a standalone app for some time, but been holding back. Chief among the reasons were the multitude of bugs in FM Go 14. As one has to make a new app for every update, it is just too much work to maintain versions across a large user base. I will see how version 15 performs after a few updates and maybe reconsider.


            Thanks again.



            • 3. Re: Best practice on rolling out new version of FileMaker Go to users

              I agree with David that it would be better to use the ios SDK.    You have to change version # of your App to do updates with the App store so would have version control.   You should not have any installation issue because it would automatically overwrite the previous version and it would be handled by the app store.   .

              1 of 1 people found this helpful