There's plenty of precedence for Apple "frameworkizing" subsystems that were previously either embedded in an application or shipped as a private, undocumented framework. For example: InstantMessage, NSImage's support for reading RAW files, ImageCapture, PDFKit.
Although limited, there's even a public email framework: Messaging.framework, implementing NSMailDelivery. Obviously, that's only a tiny part of the potential, but at least there's something Apple can add onto.
The last couple of WWDC's I've attended had several announcements and details about "new" frameworks that were actually older private frameworks made public. It seemed to me that Apple engineers were interested in publishing more frameworks, if there was enough demand.
I think that Apple's frameworks is some of the best work they've done (with some exceptions, like SFAuthorization). It encourages new thinking about problems. Do we really need another email application? I'd rather have tools that can easily use standard formats and protocols, but transcend them towards something new.
by John Labovitz — Jul 18
Although limited, there's even a public email framework: Messaging.framework, implementing NSMailDelivery. Obviously, that's only a tiny part of the potential, but at least there's something Apple can add onto.
The last couple of WWDC's I've attended had several announcements and details about "new" frameworks that were actually older private frameworks made public. It seemed to me that Apple engineers were interested in publishing more frameworks, if there was enough demand.
I think that Apple's frameworks is some of the best work they've done (with some exceptions, like SFAuthorization). It encourages new thinking about problems. Do we really need another email application? I'd rather have tools that can easily use standard formats and protocols, but transcend them towards something new.