wiki:NoteAboutCocoaVersions

Version 1 (modified by alms, 7 years ago) (diff)

--

From: Gary Byers
Date: May 26, 2008 4:27:29 AM EDT
Subject: Re: [Openmcl-devel] Is the Cocoa bridge still tied to exactly one version of the Cocoa frameworks?

On Mon, 26 May 2008, Axel Katerbau wrote:

> Is the Cocoa bridge (ObjC framework brigde in general) still tied to
> one specific version of the framework?
>
> E.g.: Will a shipped application (as a Mac app bundle) likely break
> with a new version of Mac OS?

No, not in general.

> Some old documentation stated this but a solution to this was kind of
> announced for the future. What is the state of this?

Until a few years ago, the bridge's notion of what ObjC classes and
methods existed was based on introspection: it asked the runtime
to enumerate all classes and methods when it first started up.

This generally included hundreds of classes and thousands of
methods that weren't documented or described in the interfaces
(e.g., private, implementation-level internal things.)  That
set of things changed from dot release to dot release, so
an application saved under (for instance) 10.4.8 found itself
in a different world when running under 10.4.9, and there
was no good way to tell whether the differences were significant
or not.

For the last few years, the bridge's notion of what classes and
methods exist is based on what's declared in the interfaces.  This
usually only changes between major OS releases and newer releases
are usually supersets of older ones, so (for instance) something
built using Tiger interfaces would generally run under Leopard.

Some of this stuff is complicated and there are certainly things
to go wrong, but it's certainly intended that:

- saved Cocoa applications aren't sensitive to minor OS release
  changes

- saved Cocoa applications don't need access to the interface
  files in order to run (though if the application is some sort
  of development system, the interfaces may be needed to develop
  new code.)