I think it's clear that a norm of using the Cocoa API is implied here:
I don't think it's that clear. I think it's more likely that it's a practical reason for the last sentence of he preceding paragraph:
Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.
They are establishing Adobe's track record of keeping current on underlying platform enhancements.
> I think it's more likely that it's a practical reason
> They are establishing Adobe's track record of keeping current on underlying platform enhancements.
None of that refutes whether or not Apple considers using the Cocoa API exclusively as a norm. I think it's quite clear that they do. Are you really suggesting otherwise?
While the carbon APIs still ship, they are deprecated in favor of Cocoa. Yes, this is true. This fact does not give the author any traction, however, because neither the Finder nor iTunes is a platform that any significant apps depend on. This makes updating them an entirely different engineering decision compared to allowing middleware to introduce dependencies beyond Apple's control.
I don't think it's that clear. I think it's more likely that it's a practical reason for the last sentence of he preceding paragraph:
Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.
They are establishing Adobe's track record of keeping current on underlying platform enhancements.