Crickets?

I think you are right, I was just trying to avoid a stack call going from C -> ObjC (c-interface) then to true ObjC with access to class data. I have been encapsulating all the information into a single structure passed as a pointer for as many calls as I can to reduce the overhead of making three calls.. But I can live with it, other options that involve method caching etc seem a bit much.

My env vars look good [Shed-m4:~] milarson% xcrun --show-sdk-path /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk [Shed-m4:~] milarson% echo $SDKROOT /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

My SDKROOT looks fine also

Everything is up to date...

FB21884054

I can reproduce this 100%, you create an initial app add some stuff and refs to the app delegate.. then create another app in the same project and copy an past the items into the window I don't have access to Radar, I suppose I could check bug reporter and follow up with that channel.

Nope.. just two apps, I checked the headers and there is no crossover. I did copy and paste some items from the original project initially.. but I deleted those as the design matured. I think thats probably where the references are coming from. I did a grep on the project directory and the references don't occur in the project file for the app... no clue. I have cleaned the build, quit Xcode.. and they remain.

#define GL_SILENCE_DEPRECATION Close

Never mind, I figured out it was in the build setttings to always install to /Library/Frameworks on build

How do I build for external use?