I believe that is a file that APPLE ships with the OS (not Xojo) and quit shipping with Big Sur. So Xojo made a new version that uses the new Big Sur alternative to the file mentioned. I think the problem here is APPLE changed their rules and does not care about backward compatibility. And Xojo issued a new release to help work around that (among other things in that release).
Or that is my understanding anyway.
If I remember, the release was a hot fix for this issue, more than anything else. This was while they were feverishly working on r2020, which wouldn’t be shipped in time for a number of licensees. I give them credit for that.
Edit: BTW, r2020 shipped well before BS left beta.
If I understand you the private framework you rely on was not your own but was apples and it was removed during the Operating System Upgrade?
That appears to be correct, plus a fix for the IDE when run on Apple Silicon, at least according to the release notes. But note that this is for 2019R3, first released Dec 11, 2019 according to the main Release Notes page.
And even 2019R2 was released after the July 2019 date in question, according to that page. It shows 2019R1.1 was the last version released by July 2019.
The fact they released a fix in July 2020 for a 2019 release to fix an OS version that was only a few weeks out of WWDC beta status and would not be officially released by Apple to the public until fall 2020 seems commendable to me.
This kind of lack of backward compatibility on Apple’s part is a little reminiscent of the days of Windows’ developers lamenting “DLL Hell” where Microsoft released DLL components that were not backward compatible.
Well, not “my” own–I don’t represent Xojo, I’m just a user. 
But yes, the framework is/was literally a part of the OS.
Let’s bottom line this:
Apple made changes in macOS Big Sur that broke Xojo’s compiler. Xojo fixed this in a point update called Xojo 2019R3.2. In order to compile Xojo apps on macOS Big Sur, you must use Xojo 2019R3.2 minimum. If you think your license should be extended to cover that update or have other licensing questions, you need to email hello@xojo.com.
I kept on reading…
I feel like this is a code signing issue! 
Private frameworks are frameworks which you are not allowed to use. They are not expected to be used outside of Apple, hence “Private”. They are often lower-level libraries which may “break” the system if not used correctly. (But the frameworks have to exist because Apple’s apps and public frameworks do use the private frameworks.)
Since the private frameworks are not for public use, Apple doesn’t need to give any headers or documentations away.
If you’re writing for AppStore, you should not use private frameworks (unless you’re from Apple). The system will immediately reject your app even before the review process begins.
None of that hints at a signing issue. It reenforces what I’ve already said. It’s clearly an issue with linking during compilation. The error message even tells you that it’s an issue with linking because that framework cannot be found. It was moved without warning, and your version of Xojo keeps looking for it where it used to be.
I just don’t want you wasting a lot of time on this when it’s not something you can fix. I’ve shot a message to Alyssa at Xojo, and she will probably be in touch soon.
are you sure??
i manage to use 2017r3 on m1 macbookpro with big sur.
maybe the 2019r3,2 means if you want to build for arm version of big sur
I’m almost certain that the release notes (and maybe even a blog post?) said that was the purpose of 2019R3.2. And who knows what might have changed between 2017 and 2019 in terms of what frameworks Xojo uses.
Yep. Here you go:
https://documentation.xojo.com/resources/release_notes/2019r3.2.html
60739 Build Fixed linker error that occurred on macOS Big Sur.
I always dream of what we could do with our applications if these headers were provided anyway (outside of the App store, obviously).
As an example, all the applications made to replace the Finder are lacking some features that the Finder uses because Apple can use them and not other companies. In this regard, it’s “unfair”.
It is not just unfair, there’s something else to describe this behavior. I have fought with Core Image for over a decade now. When Apple sold Aperture, Core Image was far more reliable because that’s what they used for their photo editor (probably iPhoto too).
However since 10.10, some Core Image simply doesn’t work in some OS versions, yet the same effects work in Apple’s Photos, which leads me to believe that Apple don’t use Core Image for Photos or they work around the problems in Photos, rather than fix the problems in their frameworks.
This makes it harder for 3rd party developers to create compelling apps, as either you leave the bugs in your application or you spend way too much time working around it, because it’s undocumented and the workarounds are not published by Apple.
Ok… so i wonder if i can copy it from my other mac that i haven’t yet upgraded.
I’m using Xojo 2018r3 on Big Sur and seems to work (debug and compile) fine.
Any luck with that, copying from an older Mac?
If not, it looks like my days of using Xojo are over because for what I was doing I didn’t need to upgrade anytime soon. 
Jay
I ran into this problem today when I wanted to use an older version of Xojo (2018 R4) on Monterey. I found a simple solution that works at least for running the app from Xojo. I could not test if it also works for building Mac apps, because I don’t have a desktop license. Obviously, the better solution is probably to modify your code so that it runs with a more recent version of Xojo (and buy the Xojo upgrade if necessary).
Now Xojo will run your apps again.
Thanks for the Tip! I will try this!
