Serious problem with IOSAppSDK 17.0.2

Well, I have a problem with the IOSAppSDK 17.0.2. I redesigned a database for use with FileMaker 17 for use with FileMaker Go 17.

I was elated when FileMaker 17 allowed you to attach more than one attachment to an e-mail. This was something my beta testers had requested for more than a year.

Finally!

I went in and basically re-designed the database with the new capability. I went in and cleaned everything up, developed new video demonstrations, etc.

Everything was working swimmingly. It worked great in FileMaker Go17, and I was quite happy.

The problems started when I tried to use the IOSAppSDK 17.01. After running the SDK, my solution would lock up every time when I started the app when it was starting up just after it got to the launch image.

I did a bit of research, and developers had indicated that they had problems with the launch image. I had never had this issue before, but I removed the launch image. The app locked up in the exact same place without the launch image.

To determine if it was being caused by my IOS devices, I attempted to run it in the simulator for IOS 11.4. No joy.

I attempted to run it in the simulator for IOS 11.3. No joy.

I read of a lot of people complaining about Xcode 9.4.1 and wondered if it might be an Xcode issue, so I uninstalled it and installed Xcode 9.3.1. I ran the IOSAppSDK 17.0.2 again, and saw the same problem, and even worse, I could not use it with any of my devices because they were all IOS 11.4.

Extremely frustrated, I researched the problem for another couple of days, and nothing worked.

At the end of my rope, I suddenly wondered if it could be a problem with the IOSAppSDK.

I downloaded the IOSAppSDK 16.0.4, and installed it. I ran it without the launch image. It worked perfectly in the simulator.

I added the launch image, and ran it again from the IOSAppSDK 16.0.4 with the launch image, and it ran perfectly in the simulator. My issue was not being caused by my launch image.

I ran it again, and installed it on my new iPad, and it worked perfectly.

I ran it again, but from the IOSAppSDK 17.0.2 in the simulator, and it crashed at the same point.

If it runs in IOSAppSDK 16.0.4, but will not run in IOSAppSDK 17.0.2, I would have to surmise that the issue is being caused by IOSAppSDK 17.0.2.

I REALLY want to use FileMaker 17, because of the ability to attach multiple files to a single e-mail.

When I first started using iOS SDK 17 I also had the problem of the app crashing on launch. To resolve it, it was necessary to make sure the 'Location updates' Background Mode in the 'Capabilities' tab in Xcode was turned ON.... as shown in attached screenshot... With that turned on, then all worked ok.

An update to FileMaker Go 17.0.3 just arrived today in the App Store, though I don't see an update for the iOS SDK yet, though I guess it will come, and maybe maybe it will become possible to turn off Background Modes entirely for SDK apps and for them to launch without crashing... Will need to test if/when it becomes available.

Would be useful as I do have an SDK 16 app in the App Store that would be great to update to v17, but I haven't done so yet because of it being rejected due to the Location background mode being turned on, and it isn't a function my app actually needs...

Well, iOS SDK 17.0.3 did indeed become available yesterday as well... In my initial testing using the basic 'Hello World' example as documented, the issue of requiring 'Location' Background Mode to be turned on in order to prevent the app from crashing seems to still exist. In fact, when you use the command line tool to create the Xcode project, that setting is already selected, along with the 'Audio, AirPlay, and Picture in Picture' Background Mode also turned on, though turning that one off doesn't make the app crash in the same way as 'Location' does.

Well. I tested my app with the SDK 17.0.3, and you still have to "background modes" and "location services" on to keep the program from crashing. I have experimented with LOTS of different settings, and none of them have worked.

The settings I am using are:

Data Protection - ON

iCloud - ON

iCloud Documents - Checked

Containers - Use default container

Background Modes - ON

Location updates - Checked

I would be willing to send them my file to do testing with, it would give them a reasonably complex database created from someone outside FileMaker that fails using the current version of the SDK. If they come up with a version of the SDK that works, I would imagine it will work for others.

I'm an engineer, and I suspect that their testing protocol is flawed. If I had to guess, I would say that whatever file or files they are using in their testing process need to be updated to more accurately assess their work on the SDK. The problem with the SDK still exists, and their testing process did not catch it.

Also, I would appreciate some sort of contact with someone from FileMaker to indicate that they are working on the problem, and when a solution might be forthcoming.

Apparently, sending everything in was for my solution crashing, nothing else. I never had a problem with the solution crashing. Everyone is having a problem with having to have Background Modes selected and Location Updates checked.

I had to submit my app to Apple so I could use Test Flight with testers.

Since Background Modes and Locations Updates HAVE TO BE SELLECTED TO USE IOS App SDK 17.0.3, the app was rejected. I can’t even use Test Flight!

Some of my testers are a long way away, so I had to send them a FMP 17 file to use with FileMaker Go 17.

This makes FileMaker Pro 17 investment of $350.00 worthless, and all of the time I spent taking advantage of the needed new features wasted.

To add insult to considerable injury, I have to duplicate everything in FileMaker Pro 15 because if you need to insert something from the IOS device into a container field, it will not work if the solution was developed in FileMaker Pro 17, and you use the IOS App SDK 16.0.4 to compile the program.

I can not understand why the IOS App SDK 16 did not require location updates to be selected, and IOS App SDK 17 requires location updates to be selected to function.

I held out such hope when I received the e-mail asking me to send a file last night…

"Important: FileMaker, Inc. does not recommend or support using the App Store to distribute apps created with iOS App SDK. FileMaker, Inc. recommends using the Apple Developer Enterprise Program to distribute your iOS apps. You can also use Volume Purchase Program (VPP) to distribute your iOS apps through the VPP store."

Let's keep talking about this. I clearly understand that FileMaker does not recommend or support iOS SDK wrapped apps in the App Store, but that is what they also said about SDK 16 and they were still approving submissions then...

FileMaker has the potential to be the best iOS app development platform out there but we all need to work together to get it there. So far we have been gaining traction with FileMaker in the enterprise for the past two years. It would be great to take it even further to gain traction with "civilian iOS developers" as well.

There needs to be a reason for Apple to support us with the SDK and so far we have not touched on that yet.

To add insult to considerable injury, I have to duplicate everything in FileMaker Pro 15 because if you need to insert something from the IOS device into a container field, it will not work if the solution was developed in FileMaker Pro 17, and you use the IOS App SDK 16.0.4 to compile the program.

I just tried this with a file created from scratch in FMPA17, and with SDK 16.0.4 and Xcode 10, the app built without any problem and runs fine (with all Background Modes turned off) on my iPhone 7+ with iOS 12. In the app there is a container field with a button that runs a script to do an 'Insert from Device' to take a photo and place it in the container. All works ok.

In regards to App Store distribution, do you really need your app to be distributed that way? If the app is designed for a team within an organisation, then the simplest way I've found is to just create an 'Ad-Hoc' distributed version and deploy via a web page just for those users. A standard Apple Developer Account allows you to register 100 iPhones and 100 iPads for this type of distribution. There are some limitations, such as the app will expire when your distribution certificate expires, but this can be many months away, by which time you may well have a new version to distribute anyway. I've done this with small teams of up to 10 users, and it works really well, and no hassle of requiring Enterprise Developer Account, MDM and so on.

SimpleMDM, and also Jamf Now are great, but really can only use those to distribute FileMaker SDK apps if I (or my client) am enrolled with the Apple Enterprise Developer Programme costing $299/year rather than the standard Developer Programme which is $99/year. Or, for distribution via the VPP programme, then the app would still need to go through the App Store approval process (as well as my clients having to enrol for that), and due to the problem with the Location Background Mode, makes this tricky - i.e. the app has to show a meaningful reason for using background location updates, when in a lot of cases, the apps do not need Location updates at all.

Also, with MDM, then it requires users to agree to their device being enrolled and managed in that way, which can be an issue when it is intended just to be installed on user's own personal devices and they don't want to be enrolled in such a thing. Also an issue when the app is intended for use by people that are not directly employed by the business, such as clients of that business. One example I have is an app that is used in the film industry for signing in/out supporting artistes/extras on set. This app is intended for use by Assistant Directors who are not employees of the agency wishing to provide the app for them to use.

I suppose being registered for the Enterprise Developer Programme is the easiest way to go if you are an actual business, but for a hobbyist or one-man-band sole trader then this is problematic as it requires a number of things such as Legal entity status and D-U-N-S Number etc. ... So it's these hurdles that I've avoided simply by using Ad-Hoc Distribution under a standard Apple Developer Account when it's been more appropriate.

And so for the regular App Store distribution method, and even though it is not recommended or supported, I've been able to successfully get a few apps on the App Store in that way using SDK 16 and earlier and it worked out great - particularly when intended for unknown public users, so it is a real shame that SDK17 is having this problem with the Background Modes....