The getting started file just happens to be a filemaker file, they could have used initial screens instead.
Those things are always compiled with mobile apps. EG apps that prompt you to setup an account when you first launch it but do not repeatedly ask you every time you open the app, or ask you when the app is initialized externally.
Filemaker most likely blocks auto-launching of files from external applications for security purposes, which I agree with. Otherwise I could write a .fmp12 file download link that would crash a users iPad with a memory overflow.
Some sacrifices need to be made in exchange for making it so ridiculously easy to get custom applicationss onto iOS. If you want absolute full control, you might need to look at developing native iOS apps instead.
While I agree with you on the sacrifices that need to be made for security, I beg to differ on your characterization of "ridiculously easy" to get custom apps onto iOS.
If I need to create an instructional video (like other developers have done), or stand by the phone and wait for a tech support call from a first time user who can't figure out how to get out of the "Getting Started.fmp12" file and get to my file, then that makes it ridiculously burdensome and needlessly confusing (not to mention expensive) on both the first time user and myself as a developer to get a custom app onto iOS.
Surely there must be a happy medium where security and stability are preserved without putting up the equivalent of billboards and adware in between the end user and my custom application.
Really? As someone that has been self-training for using Xcode and coding in objective C and swift for over six months now, I can confirm that filemaker is indeed, a ridiculously easy way to get custom apps onto iPhones.
Here’s a few reasons why:
1. 1) No need to register for developers account (paid fee to apple)
2. 2) No need to get app approval for listing in app store.
3. 3) fmp12 files do not require compiling, it’s a single file, instead of a folder with possibly hundreds of files.
4. 4) Filemaker go takes care of numerous complex iOS functions for you, such as container capture functions, all of which take quite a bit of time to setup in native code.
5. 5) Filemaker takes care of iOS compatibility updates for you, you don’t need to rev/test/recompile/redeploy every time an iOS update comes out.
All of these things equate to faster development, and cost savings to customers. This makes FileMaker an easy sell for people that want to augment their desktop systems with iOS apps.
You're preaching to the choir here, there's no need to explain the advantages of developing on FIleMaker in this forum, especially to another developer such as myself.
To bring the discussion back to topic, the issue at hand is that all of those advantages and ease of development are undermined at the last leg when it comes to deploying on iOS for the general consumer.
The expectation from the end user's perspective is that they will download and app, tap on it, and start using your application right away. The end user doesn't care how convenient or not it may be for me to develop in FileMaker, they just want to start using the solution I sent them.
Here's a worthwhile suggestion that is both productive and non-confrontational:
What about if FileMaker were to add a "Skip for now" button and a "Don't show again" button for their "Getting Started" file? That way end users could more easily bypass that process and get to where they want to go.
As as I said, surely a platform such as FileMaker can make that sort of accommodation without sacrificing security, compatibility, and stability. Don't you agree?
I havn't seen that file since I installed Filemaker GO, so I believe there is a "Don't show again" option. I will have to get a older test device so I can remove FMGo and Reinstall. I couldn't find I way back to the app. It may be because I delete that database. I will test can get back to you on that.
The main problems occurred when Apple came out with ios8 which includes Apple Pay on the iPhone 6. My speculation is that Apple increase security and may even went a little overboard because of Apple Pay. If it easy for FMGo to do then it would be easy for other apps to take advantages of these loop holes. Apple wants to make sure that Apple Pay doesn't get hacked. Microsoft went over board on security in Windows Vista, and they made it better with Windows 7 and 8. I think you will see more improvement in the future from Apple and FMI, it just going to take a little time to get there.
It’s already configured to only run when you first launch FMGo after install, so there would never be a need to have a “don’t show again” function.
Since part of my standard setup process includes instructing users to remove all the demo files on FMGo, I never have had complaints or issues from my users about this. It’s just part of the process of installing FMGo. This also teaches your users how to use the file selection menu, which is beneficial later if you need them to use that area.
I'll save you the trouble: there isn't. I just installed and reinstalled FMGo 13 and there is no way to get out of the "Getting Started.fmp12" file other than to tap on the upper right hand corner, select "Windows" and the close the window for it.
The user is then sent to the "Recent" list, instead of to the "Device" list. And since this is the first time they open FMGo, the only file listed under "Recent Files" is (you guessed it) "Getting Started"
I agree on that point, there should be a “skip” button that closes the getting started file on request. That file hasn’t changed really at all since it was first introduced, but it would be easy to add in.
Ok then, so minimally there needs to be a button or some other clear method for a novice/first time FileMaker end user to "Close" or "Skip" this tutorial and get to the list of files on the Device (instead of the list of "Recent Files").
If it takes an instructional video or a phone call/email to the developer before a consumer can start using a solution in FileMaker Go, then it's unnecessarily burdensome.
So, what I would really like to do is to bypass it completely.
To be clear, I am looking to reach the widest possible general consumer audience, a group of users that I can instruct directly. That is why I need FMGo to be as simple and straight forward as possible.
Typo, I meant "NOT a group of users that I can instruct directly"
We’re running in circles, back to the tradeoff of using Go for deploying to iOS.
Given that FMGo as a product needs to be able to run any .fmp12 file you throw at it, as well as multiple files, it’s oblivious to the single-app use case that you are shooting for. FileMaker is also not exempt to the rules of the app store, so FileMaker Go on it’s own, without any of us, needs to do SOMETHING, hence why the demo files come with it, and probably a reason the initial launch file is there.
I get where you’re going, and yes, it would be great if we could package everything together in a single-use app. But that’s just not how Go is fundamentally structured. Until FileMaker gives us the ability to compile runtime iOS apps via FMPA, which I doubt is even on the roadmap, we’re stuck with the “rules” of go.
If you want to break those rules to meet your business need, then you might need to code your own native iOS app. Lets be clear, FileMaker Inc. is a for-profit company, and the only way they make money off FMGo is concurrent connection licenses. It’s awfully nice of them to let us use FMGo with a standalone file, but I don’t see them as having any interest in making a runtime compiler for FMGo, unless they could guarantee the revenue stream.
Even if you decide to go native, FMGo still can make an awesome prototyping tool, you can make a robust prototype and then develop that as a native iOS app.
I agree, it is a bit of a hassle to by pass the startup databases and there should be a skip button. Like Mike states after the user figures out how to close the startup databases, they will know how to navigate FMGo. I guess you can tell your users it is a training tool.
I also delete all the starter databases off the device. Since ios8, if you have a database running then your user tries to start your database from an icon on the home screen, FMGo will open to the database that was already open and not switch to your automatically. If there is only one databases on the device then they can only have that one running. I'm hoping the next version of FMGo will correctly a bunch of these issues.