# Deploying IOS/Android App

**URL:** <https://the.fmsoup.org/t/deploying-ios-android-app/439>\
**Category:** Floating Topics\
**Tags:** ios, android, filemaker-go\
**Created:** [November 7, 2019, 7:47am UTC](https://the.fmsoup.org/t/deploying-ios-android-app/439 "2019-11-07T07:47:31Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![AndyHibbs](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/andyhibbs/32/3089_2.png) [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)\
**Post date:** [November 7, 2019, 7:47am UTC](https://the.fmsoup.org/t/deploying-ios-android-app/439/1 "2019-11-07T07:47:31Z")

</div>

Continuing the discussion from [Interesting from Apple’s earnings report](https://the.fmsoup.org/t/interesting-from-apple-s-earnings-report/244/10):

Welcome to this forum Brian.

Thanks for your input here and I've replied by creating a new topic (share link and 'New Topic') as I believe your comments shouldn't be buried in my original post heading.

> [@Interesting from Apple’s earnings report](https://the.fmsoup.org/t/interesting-from-apple-s-earnings-report/244/10):
>
> > although our first big iPad project is using FileMaker Go, all interaction with the (FileMaker) server is via APIs and JSON, hence it need not necessarily be FileMaker Go. So there is nothing really stopping us having an Android client that is not anything to do with FileMaker.
> 
> Hi Andy. I know this is an older thread (I just signed up today), but I wanted to highlight and support your quote above. I agree 100%. In my opinion, there are 3 or 4 options as far as deploying a FileMaker-backed mobile app.
> 
> 1. Native development with iOS or Android, using in Swift/Obj-C or Java/Kotlin, resepctively. This is somewhat slower than FileMaker development, but the feature set and performance are **light years** ahead of FileMaker Go. Native apps provide the fastest performance and no compromises.
> 2. React Native can deploy cross platform apps, and they’re still compiled using (mostly) native UI objects. They’re a small step behind option 1, performance and feature wise. If you need to deploy to both iOS **and** Android and want the fewest compromises, this is the best way to go, IMO.
> 3. FileMaker Go (and FIAS)
> 4. Xojo, LiveCode, etc.: These are pseudo apps built using a proprietary IDE and language. The UX and feature set is pretty far behind what’s available in real iOS or Android apps. That may not be critical to your deployment, and that’s fine. Xojo and LiveCode can satisfy a demand for cross platform deployment, and I applaud their efforts in filling that need, but these apps can require a fair amount of compromise. In my case, more than I’m comfortable giving up.
> 
> A few years ago I took option 1. I opted to learn Swift and build real iOS apps in Xcode, with automatic sync, offline use, horizontal collection views, etc., etc. My primary example being the Art Con app – [http://artcon.app](http://artcon.app). It has over 1K users and is backed almost entirely by the Data API. For anyone who has the time and aptitude to learn Swift (or Java, or React), I would point folks that direction if their priority is deploying zero-compromise mobile apps. All of the options are fine, just be aware of what you’re getting (and not getting) with each.

Again, I wholeheartedly support everything you've posted, the Data API has opened up so many opportunities.

The only thing I would add is within the Xojo, LiveCode comment

> [@Interesting from Apple’s earnings report](https://the.fmsoup.org/t/interesting-from-apple-s-earnings-report/244/10):
>
> these apps can require a fair amount of compromise

In many ways this applies to FileMaker as well, as we're constantly having to compromise thanks to the benefits of the amount of output we get for the amount put in, which has always been FileMaker's main strength. Hence, in a world where we already compromise, perhaps many could work within these constraints. If not, you've already addressed that.

Many thanks  
Andy

---

<div class="post-metadata">

**Author:** ![MonkeybreadSoftware](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/monkeybreadsoftware/32/361_2.png) [@MonkeybreadSoftware](https://the.fmsoup.org/u/MonkeybreadSoftware)\
**Post date:** [November 7, 2019, 9:49am UTC](https://the.fmsoup.org/t/deploying-ios-android-app/439/2 "2019-11-07T09:49:28Z")

</div>

Interesting was the comment on Android at FMK.

Until then Android was a topic where FileMaker said no or never.  
Now this changed to maybe. So they may be working on something.  
(and I fear it may be a web client packaged as an installable app)

---

<div class="post-metadata">

**Author:** ![AndyHibbs](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/andyhibbs/32/3089_2.png) [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)\
**Post date:** [November 7, 2019, 10:34am UTC](https://the.fmsoup.org/t/deploying-ios-android-app/439/3 "2019-11-07T10:34:57Z")

</div>

If they don’t do it, then someone else will and they’ll have lost an opportunity.

LiveCode have been working on a convert FileMaker file to Android tool for some time now.

Interesting information, thanks.

---

<div class="post-metadata">

**Author:** ![Markus](https://avatars.discourse-cdn.com/v4/letter/m/b782af/32.png) [@Markus](https://the.fmsoup.org/u/Markus)\
**Post date:** [November 7, 2019, 10:56am UTC](https://the.fmsoup.org/t/deploying-ios-android-app/439/4 "2019-11-07T10:56:36Z")

</div>

I’ve heard that too - but someone also mentioned that they drop (again) linux for fms. Although it was only for amazon, I was somehow puzzeled (if I got that right)

---

<div class="post-metadata">

**Author:** ![harvest](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/harvest/32/231_2.png) [@harvest](https://the.fmsoup.org/u/harvest)\
**Post date:** [November 7, 2019, 12:17pm UTC](https://the.fmsoup.org/t/deploying-ios-android-app/439/5 "2019-11-07T12:17:38Z")

</div>

on the Hamburg Conference last month they asked about interest in fms on linux and only about 20% of the audience seemed interested, then they mentioned the possibility of providing vm-images with fms-on-linux preconfigured

---

<div class="post-metadata">

**Author:** ![harvest](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/harvest/32/231_2.png) [@harvest](https://the.fmsoup.org/u/harvest)\
**Post date:** [November 7, 2019, 12:24pm UTC](https://the.fmsoup.org/t/deploying-ios-android-app/439/6 "2019-11-07T12:24:39Z")

</div>

the tool has been released since

unfortunately it “only” produces an adroid version of your FM-app

I’d have loved to see some code-migration-mechanism since that could have helped me bypath the upcoming death of runtimes

---

<div class="post-metadata">

**Author:** ![AndyHibbs](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/andyhibbs/32/3089_2.png) [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)\
**Post date:** [November 7, 2019, 12:34pm UTC](https://the.fmsoup.org/t/deploying-ios-android-app/439/7 "2019-11-07T12:34:48Z")

</div>

vm-images could work as part of the AWS AMIs, but we’d want the ability to build on other providers infrastructures, we don’t like using the ‘big boys’ as their support is rubbish and in some cases not the fastest.

We’d also need to reconfigure after creating our own server and manage it totally independently to enable some of our more advanced systems and prevent them from breaking.

I’m sure we’ll have interesting times ahead, but at the moment have my head in Windows Server 2019 for the first time.

---

<div class="post-metadata">

**Author:** ![tonni6030](https://avatars.discourse-cdn.com/v4/letter/t/b19c9b/32.png) [@tonni6030](https://the.fmsoup.org/u/tonni6030)\
**Post date:** [March 25, 2025, 12:22am UTC](https://the.fmsoup.org/t/deploying-ios-android-app/439/8 "2025-03-25T00:22:14Z")

</div>

> [@Interesting from Apple’s earnings report](https://the.fmsoup.org/t/interesting-from-apple-s-earnings-report/244/10):
>
> Continuing the discussion from [Interesting from Apple’s earnings report](https://the.fmsoup.org/t/interesting-from-apple-s-earnings-report/244/10):
> 
> Welcome to this forum Brian.
> 
> Thanks for your input here and I've replied by creating a new topic (share link and 'New Topic') as I believe your comments shouldn't be buried in my original post heading.
> 
> > [@Interesting from Apple’s earnings report](https://the.fmsoup.org/t/interesting-from-apple-s-earnings-report/244/10):
> >
> > > although our first big iPad project is using FileMaker Go, all interaction with the (FileMaker) server is via APIs and JSON, hence it need not necessarily be FileMaker Go. So there is nothing really stopping us having an Android client that is not anything to do with FileMaker.
> > 
> > Hi Andy. I know this is an older thread (I just signed up today), but I wanted to highlight and support your quote above. I agree 100%. In my opinion, there are 3 or 4 options as far as deploying a FileMaker-backed mobile app.
> > 
> > 1. Native development with iOS or Android, using in Swift/Obj-C or Java/Kotlin, resepctively. This is somewhat slower than FileMaker development, but the feature set and performance are **light years** ahead of FileMaker Go. Native apps provide the fastest performance and no compromises.
> > 2. React Native can deploy cross platform apps, and they’re still compiled using (mostly) native UI objects. They’re a small step behind option 1, performance and feature wise. If you need to deploy to both iOS **and** Android and want the fewest compromises, this is the best way to go, IMO.
> > 3. FileMaker Go (and FIAS)
> > 4. Xojo, LiveCode, etc.: These are pseudo apps built using a proprietary IDE and language. The UX and feature set is pretty far behind what’s available in real iOS or Android apps. That may not be critical to your deployment, and that’s fine. Xojo and LiveCode can satisfy a demand for cross platform deployment, and I applaud their efforts in filling that need, but these apps can require a fair amount of compromise. In my case, more than I’m comfortable giving up.
> > 
> > A few years ago I took option 1. I opted to learn Swift and build real iOS apps in Xcode, with automatic sync, offline use, horizontal collection views, etc., etc. My primary example being the Art Con app – [http://artcon.app](http://artcon.app). It has over 1K users and is backed almost entirely by the Data API. For anyone who has the time and aptitude to learn Swift (or Java, or React), I would point folks that direction if their priority is deploying zero-compromise mobile apps. All of the options are fine, just be aware of what you’re getting (and not getting) with each.
> 
> Again, I wholeheartedly support everything you've posted, the Data API has opened up so many opportunities.
> 
> The only thing I would add is within the Xojo, LiveCode comment
> 
> > [@Interesting from Apple’s earnings report](https://the.fmsoup.org/t/interesting-from-apple-s-earnings-report/244/10):
> >
> > these apps can require a fair amount of compromise
> 
> In many ways this applies to FileMaker as well, as we're constantly having to compromise thanks to the benefits of the amount of output we get for the amount put in, which has always been FileMaker's main strength. Hence, in a world where we already compromise, perhaps many could work within these constraints. If not, you've already addressed that.
> 
> Many thanks  
> Andy

Thanks for sharing your insights, Andy. I completely agree that the Data API has significantly expanded the possibilities for integrating FileMaker with other platforms. Your breakdown of deployment options is very useful, especially for those considering alternatives to FileMaker Go. While native development offers the highest performance and flexibility, I think React Native presents a great middle ground for teams that need cross-platform support without giving up too much on user experience. Your point about compromise is also well taken, as every platform has trade-offs, and FileMaker’s strength has always been its balance of ease of development and functionality. It really comes down to the specific needs of each project. Appreciate the thoughtful discussion!

---

<div class="post-metadata">

**Author:** ![AndyHibbs](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/andyhibbs/32/3089_2.png) [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)\
**Post date:** [March 25, 2025, 7:18pm UTC](https://the.fmsoup.org/t/deploying-ios-android-app/439/9 "2025-03-25T19:18:30Z")

</div>

Hi @tonni6030

Another addition I’d recommend to anyone who is considering a mobile solution is [https://www.fmbetterforms.com](https://www.fmbetterforms.com)

This integrates very nicely with FileMaker particularly if, like me, you’re not up to speed on React, etc.

All the best

Andy

---

<div class="post-metadata">

**Author:** ![planteg](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/planteg/32/627_2.png) [@planteg](https://the.fmsoup.org/u/planteg)\
**Post date:** [March 25, 2025, 11:44pm UTC](https://the.fmsoup.org/t/deploying-ios-android-app/439/10 "2025-03-25T23:44:20Z")

</div>

I have seen a demonstration in Montréal at CQDF a few years ago, very impressive !
