Big Sur prise? Bug Surprise?

So this missing link file

/System/Library/PrivateFrameworks/UIFoundation.framework/Versions/A/UIFoundation for architecture x86_64

Is installed in R1.1 but not again until in R3.2?
lrwxr-xr-x 1 root wheel 29 25 Oct 2019 UIFoundation -> Versions/Current/UIFoundation

So something you installed previously you stopped installing but now you need it because this operating system needs it? but I can’t have it because it was taken away but i can have it back if i buy a license???

So something you installed previously you stopped installing but now you need it because this operating system needs it? but I can’t have it because it was taken away but i can have it back if i buy a license???

If I’m understanding you, no, this is not something that Xojo took out and put back in. This is a baked-in Apple framework, on which the Xojo IDE (actually, I think the compiler) depended, which was changed or moved in Big Sur. 2019r3.2 dealt with this change. I’m sure there are folks here who can give more detail but, in a nutshell, Apple broke it, not Xojo. :slight_smile:

2 Likes

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.

2 Likes

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.

1 Like

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.

2 Likes

Well, not “my” own–I don’t represent Xojo, I’m just a user. :slight_smile: 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.

3 Likes

I kept on reading…
I feel like this is a code signing issue! :unamused:

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.

1 Like

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:

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”.

1 Like

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.

1 Like

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.

1 Like

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. :frowning:

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).

  • Run the Xojo app at least once, so that Gatekeeper is out of the way and you can modify Xojo.
  • Right-click the Xojo app and choose “Show package contents”.
  • Go to the folder Contents/Resources/SDKStubs/macosx10.14/System/Library/Frameworks/AppKit.framework
  • Open the file AppKit.tbd with a text editor like BBEdit.
  • Under “reexports”, you’ll find the problematic UIFoundation framework that’s referenced in the error message from the linker (/System/Library/PrivateFrameworks/UIFoundation.framework/Versions/A/UIFoundation).
  • Simply remove this text (/System/Library…) and the preceding comma. Don’t delete the closing bracket, it should now be where the deleted comma used to be.
  • Save the file.

Now Xojo will run your apps again.

1 Like

Thanks for the Tip! I will try this!
:grinning:

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