Support files and their locations

We’re building an app for in-house use, for Windows. We may, however, run this on the Mac at some point, so I want to design this to easily work with both platforms, just in case.

The application will require several support files containing various bits of information (such as preset configurations) that the user will create in a second application, but they’ll read by the main app. These files will all be in XML format.

Questions:

  1. Does it matter to the OS if preferences (on the mac) are stored in the SpecialFolder.ApplicationData folder for our app, vs the /Users/UserName/Library/Preferences folder? It’s a lot easier if all of these files are in one place.
  2. How does it work if we have a second utility application that’s used for building the config files that the main app uses? This utility app will need to be able to place the config files in the main app’s ApplicationData folder (or a folder shared by both). Is that going to pose a problem with the OS? That is, can I use a common name in ApplicationData that’s shared between multiple apps, or can one app write to another app’s SpecialFolder.ApplicationData folder?

Yes. Apple have advised developers for over a decade to NOT read or write files in the “Preferences” folder, giving the impression that one day it may disappear. So pretend that folder doesn’t exist. Apps are meant to use NSUserDefaults or CFUserDefaults for storing and retrieving preferences.

When using the "specialFolder.applicationData’ function, you are meant to create a subfolder using the application’s bundle identifier. i.e.

Dim appSupport as folderitem = specialFolder.applicationData.child( "com.ohanaware.appWrapper4" )
if appSupport.exists = false then appSupport.createAsFolder

Technically you are supposed to use App Groups for sharing data between different applications as it then becomes irrelevant as to which security protocols your application adopts. To use App groups, your applications must be code signed (by the same code signing team) and have entitlements attached which indicate which groups the application should have access to.

Then in your application you use Apple’s API to request access to the group folder, once you get it, do what you want in there.

Last time I checked, you didn’t need to do this properly, but I would advise that you do, because Apple have a habit of tightening the screws with each OS update, which could result in your application being locked out of it needed data.

1 Like
  • The nil check is missing. No, not joking.
  • Pretty please do a if not appSupport.exists.
  • After doing the CreateAsFolder there needs to be an exists check again.

I had some fun where my app crashed on start with the ApplicationSupport folder being inaccessible.

2 Likes

Holy … None of that is meant to happen, but then again the “temporary” folder should never be inaccessible either!

Tsck… Apple PJ “Security”.

Call it what it is: security theatre.

2 Likes

Will this work without code signing if we’re not distributing the app? I mean, we can certainly do that, but like I said, this app never leaves our office.

I believe it does, but I would have to check.

Please note that Apple is encouraging people to code sign their apps even if they don’t publicly distribute the applications.

I do know that Apple treats signed and unsigned apps differently, for instance a file created with the signed version of the application, cannot be opened by the unsigned version.

1 Like

Whaaaaa???

I ran into that one this year. Took me a while to figure it out too. I’d disabled the signing script to test something and forgotten to re-enable it. The signed application wasn’t using the App Sandbox either, so it left me scratching my head for a while.

Once I realized and re-enabled the signing script, it could then re-open the file on launch.

There’s some seriously weird potentially undocumented things waiting to catch us all :slight_smile:

I can see a day when I just give up trying to keep up with Apple (and Xojo’s) changes.

2 Likes

We are just getting older…

2 Likes

The straw that broke the camel…

[Emile Schwarz]

The straw that broke the camel…

Im already there with Windows Xojo. I have another post going on… anything after Xojo 2015 turns the memory footprint of my biggest selling app from 105K to over 2Gb.
Xojo 2015 gets me a working app, but anything later produces a totally unusable and unresponsive exe from the exact same source code.

GroupPanel maybe?

GroupPanel maybe?

Never use them. :frowning:

Then again, some of us don’t really care what Apple says to do as we will never be putting our apps in the Apple App Store. So we store our stuff where we want and how we want. We don’t use sandboxes, etc.

If your app is for in-house use - well then store stuff wherever you want frankly.

1 Like

@Jon_Ogden Please note that my findings were not with an App Store application. I don’t know if you noticed but since 10.13 Apple has been gradually locking down the file system to 3rd party apps.

I suspect that they envision a future where the macOS is locked down just like iOS, Tim Cook would probably rebut it with something, “Apple Cares and gives you choice, you can choose to buy a Windows PC. Windows PCs are so unsafe, like a car without a steering wheel or brake pedal.”

Now If I can direct your attention to the latest Apple innovation, it is a driver-less car that’s controlled by Siri Pro Max. We took our “Courage” to remove all physical controls to the vehicle. Ask Sir to adjust climate, to adjust volume, to accelerate or which direct to steer in.

If Apple locks down OS X to make it like iOS then I will switch completely to Windows. I will also quite possibly sell my Apple stock. I first purchased it in 1996.

And a Siri car? Uh - no thanks. That would be another reason to sell stock.

1 Like

That’s the rumor that sent the stock back up last week! Not quite a Siri controlled car, but a driverless car, with no steering wheel, accelerator or brake pedals.

And what is the fun in that? I am all for innovation and all but seriously, other than something for mass transit or Uber or something like that, what is the point of having a car that has zero controls for me to enjoy driving? Sure, there’s times on a long road trip, that I would like to be able to let the car drive and myself nap. But dang it there is just sometimes when it is plain fun to get behind the wheel and drive the car. It’s an enjoyment and a simple pleasure in life. A car like Apple is rumored to be developing is sterile and dull.

Still (and we are getting WAY off track here from the topic), I have always thought that Apple doing a car is a bad idea. Keep doing what you are good at - supply the CPU, the software, etc. But don’t build the car. Stay in your lane. Automotive manufacturing is a major headache. Partner with someone who’s lane is building cars provide them the software…

4 Likes
Forum for Xojo Programming Language and IDE. Copyright © 2021 Xojo, Inc.