Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

deprecated on 10.7 and later

Recently I've noticed these log messages submitted by different sources including Apple Apps.

Can anyone explain these? The meaning is clear to me but it appears that developers with Apple are still using deprecated library calls. Is my interpretation correct?

I've also checked the logs on my macmini which runs the same OSX version (10.8.5) as a file, media and webserver. No such messages were found.

Sender: UserNotificationCenter

*** WARNING: Method userSpaceScaleFactor in class NSWindow is deprecated on 10.7 and later. It should not be used in new applications. Use convertRectToBacking: instead.

Sender: Mail

*** WARNING: Method userSpaceScaleFactor in class NSWindow is deprecated on 10.7 and later. It should not be used in new applications. Use convertRectToBacking: instead.

Sender: DiskImages UI Agent

*** WARNING: Method userSpaceScaleFactor in class NSWindow is deprecated on 10.7 and later. It should not be used in new applications. Use convertRectToBacking: instead.

Sender: SystemUIServer

*** WARNING: Method convertRectToBase: in class NSView is deprecated on 10.7 and later. It should not be used in new applications.

Sender: EndNote X7

Setting a table column identifier of type '__NSCFNumber'. For applications linked on or after 10.7, NSTableColumns expect NSString identifiers. This app should move to using NSString identifiers for table columns.

MacBook Pro with Retina display, OS X Mountain Lion (10.8.5)

Posted on Sep 26, 2013 1:41 AM

Reply
16 replies

Sep 26, 2013 10:14 AM in response to t.a.51

You are correct. The messages mean that you should use the new class methods moving forward.


The most likely cause of this, though, is the leverage/reuse of older code that still works. The SW developers rarely have time to clean up all deprecated class methods as soon as the become deprecated. Usually they wait until either they are no longer supported, or the effected section of code is being worked on.


This isn't a problem for the user, but is a problem for the developer as they will eventuall need to address these when they become unsupported.

Sep 29, 2013 11:26 PM in response to t.a.51

I can't point you to formal statements. Log messages spew out tons of things and could quickly make you think your machine has gone awol. I don't know the specific answer to your question, but i can tell you they are harmless. They are meant for developers, not users. You are experiencing no issue and my advice would be to simply ignore them.

Sep 29, 2013 11:54 PM in response to nbar

I still worry mainly based on past expercience with an application called EndNote. I had several issues with a version which should be compatible with OSX 10.8 but was not. This app was also generating 'deprecated' messages. Recently I have moved to a newer version of EndNote and the issues, some resulting in crashes, appears to have been resolved. But I still see 'deprecated' messages and I'm worried that new version will not work with OSX 10.9.

Sep 30, 2013 3:08 AM in response to t.a.51

t.a.51 wrote:

If these messages have no impact why are they being generated by the system? It seems that the OSX developers have specific reasons for adding extra code to test these calls and warn users and developers.

OS X application developers are not adding any extra code to test these calls. The tests are built into the OS itself. As has been mentioned earlier, they are not meant to warn users. They are of use only to application developers, intended to warn them that these calls will eventually be removed from the OS.


Typically, Apple won't do this for at least two major revisions, so for instance if you see a warning like this beginning with OS X 10.6, the call will probably still be supported in 10.7 & 10.8. This gives developers plenty of time to rewrite their code using the suggested calls.

Can someone point to formal statements from Apple which address these issues?

Sure. Everything developers need to know can be found through https://developer.apple.com. For example, https://developer.apple.com/library/mac/search/?q=userSpaceScaleFactor will list every item in the developer library for the now deprecated userSpaceScaleFactor call. (Some items may appear only to those signed in with a developer account, for instance anything requiring a non-disclosure agreement ("NDA") to see.)


The info in these articles probably won't make much sense to you unless you have some OS X programming experience, but that's the point several users have been trying to make: the system log info is intended for developers, not users. Trying to interpret these logs without a firm foundation in OS X programming is like trying to understand something written in a foreign language, because basically that's what it is.


BTW, if you are curious why some of these warnings appear on one Mac but not another, it could be that only some Macs use the call that generates the warning. For instance, convertRectToBacking (the replacement for userSpaceScaleFactor) appears in the High Resolution Guidelines for OS X, suggesting it is used when drawing on high resolution displays like your MBP's Retina one.

Sep 30, 2013 3:33 AM in response to R C-R

Thanks for taking the effort to explain all this.

However; I dont agree that the logs are meant for developers exclusively. First because developers cannot see these logs unless users take action or when these messages are forwarded through Apple via de crash reports et cetera. In this case user input is sometimes required to relate messages and users actions. Second because computers like other man-made tools require maintanance. Users like me when experiencing problems must dive into these matters in order to comprehend what part of the machine needs support.


Your efforts in helping clarifying this 'foreign' language is much appreciated. It also helps further my knowledge and perhaps the understanding of this community in general. So please continue to educate and assist me in enhancing our understanding of our complex environment. Because I firmly believe that developers and users needs to work in close relationship.

Sep 30, 2013 4:54 AM in response to t.a.51

t.a.51 wrote:

However; I dont agree that the logs are meant for developers exclusively. First because developers cannot see these logs unless users take action or when these messages are forwarded through Apple via de crash reports et cetera. In this case user input is sometimes required to relate messages and users actions. Second because computers like other man-made tools require maintanance. Users like me when experiencing problems must dive into these matters in order to comprehend what part of the machine needs support.

It is the responsibility of developers, not users, to make sure their apps work properly with the versions of OS X they claim to support. There are many ways they can do this, including paying Apple a modest yearly fee for technical support through the Mac Developer Program, private or public beta tests of prerelease candidates, & so on.


Developers who are diligent about maintaining their software do not need to see user-submitted crash reports to know they are using deprecated system calls -- if a developer needs that, it is a strong indication that they are not keeping up with the development of OS X, & that you should look elsewhere for products you can continue to use with future OS X versions.


Accordingly, if you are experiencing problems with some software the first thing you should do is not to dive into system logs but to check that you are running the latest, most up-to-date version of it. Nine times out of ten, updating to the current version will solve the problem, & do so quickly & easily, without requiring any effort on your part other than downloading & installing the update.


When that doesn't resolve the issue, the next thing you should do is check the developer's support info to see if yours is a known issue; if anything is being done about it & if so when a resolution is expected; & if there are any suggested workarounds available until the issue is resolved. If you can find nothing like that, consider that the problem may well have some other cause, like an incompatible third party addition to your system, corrupted files or the file system itself, etc. System logs are sometimes helpful in diagnosing such things, but since the issue is not with the developer's software itself, there is no point in sending the log to the developer or hoping they will fix something they have no control over.


Only if none of the above solves your problem should you assume there is any reason to 'dive into' the system logs. Even if you are willing to do that there is little reason to think you will see anything helpful unless you are an experienced OS X programmer, or at least have a good understanding of how the OS works & what the terminology means.


That will take considerable effort on your part. You can begin by browsing through the Apple's developer docs, particularly the Getting Started section of the Mac Developer Library.

Sep 30, 2013 5:31 AM in response to R C-R

When all logical steps mentioned (e.g. updating, contacting apps-support and following their instructions) doesn’t resolve the issues, I think this forum has proven to be an excellent source for pointers to the diagnose process.


Where do I start when trying to diagnose incompatibility or hardware issues? Is there another source taking a more ‘systems’ view not requiring diving into the overwhelming Mac Developer Library and leading to a more gradual understanding of the inner workings of OSX? E.g. trying to get an overview of the OSX components and relate these to “DiskImages UI Agent” and “SystemUIServer”?

Sep 30, 2013 6:28 AM in response to t.a.51

Where do I start when trying to diagnose incompatibility or hardware issues?

You have already mentioned an excellent source for help with that: these forums. You may want to try Etrecheck for gathering relevant system info, which can be pasted into a post in these or similar forums if you need help understanding what might be causing compatibility issues. The Apple Diagnostics or Hardware Tests are useful for finding hardware issues, although they are not 100% reliable.


And as I mentioned, the first things to do when you suspect software problems is to make sure you have the most current version installed & to check the developer's support info for anything that might already be known about it.

Is there another source taking a more ‘systems’ view not requiring diving into the overwhelming Mac Developer Library and leading to a more gradual understanding of the inner workings of OSX? E.g. trying to get an overview of the OSX components and relate these to “DiskImages UI Agent” and “SystemUIServer”?

You can try searching the web using the name of an app or process to see what that turns up if you want to know about one of those things in particular. And since OS X is in part based on the BSD UNIX kernel, learning a little about UNIX concepts in general will help you get started. There is always http://en.wikipedia.org/wiki/OS_X, which gives you an overview of the OS & some useful links for further study.


But keep in mind it is a very complex OS with thousands of components. I doubt any one person understands them all, including Apple's engineers. Some parts are open source, so you can find out all there is to know about them, but some of it is closed source so it will be "opaque" -- meaning the most you can find out without signing a NDA (& maybe even then) is how to use it, but not how it works "under the hood."


Whatever you decide to do, accept that it will require a lot of study to get started, & you will eventually get to the point where you will have to concentrate on one or a few areas of interest to go further.

deprecated on 10.7 and later

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.