You can create runtimes or databases for the iOS devices that does not require connecting to filemaker server. (Data store on the device within the databases) Filemaker Go is required for the app to run on the devices (Runtime or not). There is a FileMaker App maker to place an icon to the database on the home screen. Note the runtime must be created on a mac to run on an iOS device. You do not have to compile the database into a runtime to use on iOS device.
More info about creating icon on home screen
Filemaker App Maker for GO by Base Elements.
I understand the original question (and agree with many FM users that it would be phenomenal if you could compile a stand-alone app for iOS distribution). Nothing has changed over the two years since this post was first made. I did not know that you could run a standalone Filemaker file on iOS. Never thought to try it. But why would you? What is the advantage over just a "normal" Filemaker file? Is there any difference? My biggest pain with working with FM files on iOS is that everything is housed within the main FM app. I have no problem creating and distributing webclips to provide homescreen icons that launch different FM files, but the problem is that when multiple FM files are running, they are all contained within the main FMGo app. Users are used to being able to switch between open apps on their device by double tapping the home button and moving around. Because FM files are not true independent "apps", they all appear under the FM Go file structure where it is not intuitive for them to switch between FM files. Yes, I know how to do it, I'm just saying that it isn't intuitive for the average person without (sometimes repeated) training. Also, closing an FM file leaves them on the FM app homescreen listing their recently used files, which confuses them even more. So often I have heard "I can't find the app, all I get is this Filemaker Go thing". I wish there was a way to have complete OS separation between filemaker solutions. Does creating a run-time FM file do that? I'm assuming not, since FM Go is still required...
No, the runtime does not change anything in FMGo. You can create a MAC and or a PC runtime. FM runtime is not like other runtimes created in other programming languages. Basically, the databases is not compiled, there is a binding key that is added to the file to bind it to the runtime. The database will still open in FMP. The binding key main purpose is to make sure the correct runtime opens the file. The runtime is of FM and not your databases. A runtime is like FMGo, but for a computer, and it does not allow networking. I thinke runtimes are on the most part useless. Only purpose is for a standalone database on a computer, so the user does not have to purchase FM to run the database.
Webclips for FM are not clean anymore since ios8, the clip will runs but It does not always open the database, it will open FMGo. Also when a webclip opens there are two screen displayed, and you have to close the screens separately.
There are a couple advantages in having a standalone on a ios devices, one such as you mentioned, separation between solutions. Another advantage would be the ability to sell the database in the Apple Store.
I have not noticed any difference between webclips on iOS 8 and previous versions... They could always be spotty for me (the actual file not always opening). Maybe I've just been lucky (or always unlucky). What about iOS8 have you noticed that isn't "clean"?
Like I posted in my above post.
Since ios8 a webclip :
1. will open FMGo, but it will not always open the database or switch to it if another database is running. To reproduce issue. Open database from webclip. then close the database before you exit FMGo, 9 times out of 10 when you reopen the webclip FMGo will not open the database, it will just open FMGo.
2. Two screens open. FMGo and a Safari screen. If you have the webclip set to open full screen then the second screen is black. If the screen is not set to full screen then you can a message "Do you want to open this file".