After testing of 2018 and 2019 vrersions you will know. Not from start and nothing happens, okay.
and its shown by apple what is all deprecated. At least three I could verify that they are used but … never mind.
YOUr behaviour is the example for THE problem I’m articulating. Sure, probably off topic, but Norm will certainly sort that out later.
Well, guys, it’s in the Apple release notes:
here you go:
As far as I see, Xojo 2019 and 2023 don’t use these APIs, so I expect this doesn’t show in Xojo unless you trigger it via declare or older plugins.
If you find something otherwise, please show it. (or report to Xojo as issue)
doesn’t excuse your dismissive response earlier… but does show you managed to do a bit of research. Nor your condesending response this time
Had your FIRST response been, this IS an issue if your app uses these two API, it would have garnered a more postive response.
1 Like
The framework was officially deprecated with Xcode 4.6, which was released in December 2012: "Source code using ATS APIs will generate warnings while being compiled. For 10.8, there will be no loss of functionality but there could be areas where performance will suffer. Programmers are instructed to replace all their ATS code (including ATSUI) with CoreText as ATS functionality will be completely removed in future releases of OS X.
So Apple deprecated that framework 11 years ago (and 10 versions of Xcode)
As Christian note IF this relates solely to the ATS API’s then it shouldn’t be an issue
I believe Joe replaced those ages ago
1 Like
Maybe is a language barrier, but why a direct answer makes some people feel so oversensitive and ofended?
2 Likes
I believe that it is okay when and if he tests and does research about it. That’s a good Job, no question. Anyhow the Web 1 Customers should take care to rewrite their projects soon. The day will come that 2019r32 is not running anymore on newer MacOS releases. Nobody knows.
So I like to say thank you @MonkeybreadSoftware while researched the circumstances and gave the correct answer for this case. Thank yoou for this.
While Xojo 2019r32 is long time deprecated - we have 2023 - it is now really time to change the version or rewrite in another language while the risk for this projects is climbing with every day. Not mor not less that what I said in the beginning.
The fact that there is no information list where to look for the used API’s for the IDE, the compiler, the linker and so on is one thing the inc should take care of and change exactly that.
1 Like
No idea
Seems this might affect desktop apps mostly
Few web apps run on desktop OSes
And Macs as servers dont occur much any more
Unless maybe you’re hosting such an app at Mac mini CoLo or similar
So the scope of this might be limited
The problem is: the day will come and 2019R32 will not run on actual MacOS. That’s it. And this day can come fast. And nobody wants a Mac with an outdated OS in the internet. So there would be a few ways to do that. For example with a further computer with an old MacOS installed. But it is a risk. I know that many people are doing stuffs like this in the Xojo environment. But secure is something else. And so I guess it would be better to rewrite as fast as you can to get out of this situation. Even if you rewrite in Xojo 2023 it is better than staying on an old version which is not really running. That hurts much if something goes wrong.
Beside this the resulting Apps are also everything else than secure. We should not forget: we are in 2023 and not in 2019. Wait three further years and the situation is even more dramatically than today. That they switched their framework I can understand, not that they did not took care of their customers that their projects can be existing further. That wasn’t the most brilliant Idea.
Helping is only rewriting in a new technology which follows todays security standards and not yesterdays. And also the IDE should run on actual Macos. That isn’t the case possibly. Not more, not less.
There is no language barrier in this specific case, but I was only annoyed by the constant self-praise and the insidiousness at the expense of the competition. Maybe I’m reading between the lines too much, which I might be.
However, my single almost ad hominem attack is enough for me. It’s not usually my style, but it does happen in the heat of the moment when you’re feeling bugged.
But apologies as this matter was off-topic indeed.
Rosyna provided this list.
From what I understand this happens when the application tries to use that API, not at load time. So if these API are being used somewhere deep in the Xojo Framework, it’s going to be hell to track down what and where.
I can think of a ways to figure it if we’re at risk as a customer.
BTW: @MonkeybreadSoftware This is a good reason as to why Xojo needs a dedicated Mac developer, someone who participates in Apple development communities. Rather than just Xojo.
I’m short of hardware at the moment, so I don’t have the Sonoma beta installed. I’m hoping to rectify that shortly.
There seem to be many in various APIs like Color Sync
a few in AppleEvents , many in Speech Synthesis, Core Printing and many others
What I cant tell you is whether all of those will or might generate that warning or not
The definitely call out the ATS ones very clearly & specifically saying they will cause this behaviour
So maybe this is the only ones that will do this - for now
1 Like
By checking the debug log of Sleep Aid, I see the following repeating a lot.
[com.apple.runtime-issues:NSToolbarItem] NSToolbarItem.minSize and NSToolbarItem.maxSize methods are deprecated. Usage may result in clipping of items. It is recommended to let the system measure the item automatically using constraints.
Yes, Sleep Aid has toolbars in the main window and preferences window. I guess I’ll have to construct the toolbar items myself rather than use the Xojo IDE.
I should be able to construct the entire toolbar myself and bypass the Xojo one entirely.
The tricky part for Xojo is trying to still support older versions of macOS AND not get too far behind that issues pile up with new ones
So even in Xcode they need to build in newer SDK’s but deploy to older ones
tricky balance
Yes and No. It does mean that they have to pay close attention to what is deprecated and ensure that they’re using the newer API on newer versions of the macOS.
Xcode should help highlight this for the framework, but for declares there’s no easy way.
[NSObject respondsToSelector:] Will allow the application to use newer API when it exists, and therefore keep older API working on older versions of the macOS.
My apps contain so much of this nowadays in the effort to support 7 versions of the macOS. But with hardware down, I’m dropping that to 4 or 5.
Again, having someone who just focuses on the macOS platform will make this process a whole lot smoother, especially with someone who is experienced and cares about details.
However, this would enhance the quality both on the forums and at the Inc. Suddenly, the outbursts of joy and the swift wiping away of problems during Sunday breakfast would come to an end. That wouldn’t be a desirable outcome, would it? 
1 Like
They could provide the needed outcome when and if there would be a proper documentation while the most Bugs you get aware when writing the docs and testing the functionality on base of the written documentation. But hey, they don’t need that at the moment.
2 Likes
So it appears that for now it is limited to ATS.
Deprecations
- Starting macOS 14 Sonoma, whenever the OS detects the usage of ATS or ATSUI APIs, the user will be presented a dialog stating that the application needs to be updated. Once the dialog is dismissed by the user, the application will exit. (100521621)
Seems like a lot is deprecated for macOS 14 (not to be confused with 10.14).