Can someone please explain why Mac app packaging is so farcically convoluted?
Windows app packaging can be picked up in an hour or so.
But I've spent longer trying to fathom how to package the Mac version than I did building the app.
And it's not done with me yet.
Every single line of code requires a deep dive into a new, unrelated skillset.
So, it’s sidebar after sidebar.
Kafka’s ‘The Trial’ comes to mind.
Why does it have to be like this?
I'm afraid you'll have to provide a bit more context. Do you have a specific question that someone could answer? Are you talking about building or installing?
For building, the standard process is simple. Xcode > Product > Archive. There is no step two.
For distribution, you can choose the Mac App Store or direct distribution. If you choose the Mac App Store, you're done with the installer package at that point. For direct distribution, you'll still need to zip the resulting app. You can do that in the Finder with control-click or double-click and choose "Compress".
Of course, if you're more of a masochist, there are many, many suggestions from the internet on how to make the process more difficult. You're correct that those procedures can get Kafkaesque in no time. But you don't have to do it that way if you don't want. And if you don't like those procedures, then I don't see the point of attempting them.
Etresoft, thanks for the reply.
I assure you, I'm not trying to make work for myself or others, merely attempting to package a Filemaker 18 Runtime app.
A Windows bod, I had no trouble creating a signed exe using Inno Setup, but have been pulling teeth trying to do the equivalent for the Mac version.
I began by reading the official Mac guides, but found them impenetrable, so turned to Copilot and Chatgpt.
After many weeks of toing and froing, I have reached the stage where I can script create a DMG, but am currently having trouble with inherited icons.
Are you saying that if I had merely uploaded my runtime to the Mac App Store, I might have avoided all of this?
Inno Setup was a sweet app. I used to use that when I made Windows software.
I don't know anything about Filemaker. A quick search says that runtimes were deprecated and removed years ago. Apparently Filemaker 18 was the last version to support them.
There is some kind of "iOS App SDK" that may still be supported. It doesn't sound like this would be a quick and/or easy solution, but that seems to be all there is. After Hypercard, there was never the same kind of custom database app community (Clipper, Access, Paradox, etc.) as on PCs.
I don't know what you mean by "inherited icons". A DMG is just a disk image. Its use in installing software is problematic. Why use a zip files or pkg installer when you can use DMGs that make it 3 times more difficult?
Look at the "pkgutil" tool. All you need is a folder with the app you want to install. Create a directory tree of all the locations where you want to install files. Then use pkgutil to create an installer for that.
Forget everything I said about the Mac App Store. That isn't applicable to what you're trying to do. This runtime approach seems like a dead end. I don't know what your higher-level goals might be for this app. There's no good way to approach this on a Mac.
Etresoft, thanks for taking the time to reply further.
You're right about the deprecation of the runtime, of course. Filemaker had been threatening to do as much for a decade. Many developers believed it would never happen, but the company went ahead with the canning just after I completed the first version of my app.
So, I shelved it—for public consumption, at least. I continued to use it for my own ends. It runs on the latest versions of Windows and Mac. I use it almost every day.
Later, noting that no one else had produced a similar desktop app in the interim period, I wondered whether I might offer it for little to no cost as a springboard for development in another programming language. If enough people bought into the premise, I hoped I might elicit interest in the proposal via a crowd-sourcing platform.
So, I returned to it; adding a ‘silent’ data saving script that ensured that, should the app fail under a new OS, the raw data written to the last version would be stored on each user’s harddisk.
I’m still not sure exactly what the deprecation means regarding continued use. None of the features added to FM after 18 would appear in the runtime, but that wasn’t an issue, per se. And I still have ‘canary’ runtimes built in Filemaker 5, 6 and 7 that run today. Of course, there’s no guarantee that what has been will continue to be...
