Apple framework
Dan Tobias (Talk | contribs) (Created page with "{{FormatInfo |subcat=Development |extensions={{ext|framework}} }} An '''Apple framework''' file is one of a number of OS X file types that are actually subdirectories (folder...") |
Dan Tobias (Talk | contribs) |
||
| Line 4: | Line 4: | ||
}} | }} | ||
| − | + | A '''.framework''' file in Apple systems is one of a number of OS X file types that are actually subdirectories (folders), though they appear to the Mac's Finder as single files. It is used to add functionality to OS X or iOS apps being developed in [[Objective-C]] in the Xcode development environment. There are a number of these which are part of the Cocoa framework set to do such things as access audio and video recording and playing on an Apple device. Developers don't normally have to deal directly with the files, as they are provided as part of the overall development environment and can be added to a project through the internal interface of Xcode without directly navigating the file tree, and in fact Apple seems to be trying to make the raw files "hard to get" by burying them deeply in a path such as /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/. Note that several of the directories in the path have file extensions too; this indicates a nested structure of things that look like files to Finder but are actually directories. | |
If you do manage to get to the innards of a .framework file/directory, you'll find that it contains a subdirectory called "Headers" that contains [[Objective-C]] header files (.h) defining the interface of the module (these are viewable in Xcode in the "Frameworks" section without needing to know the long path leading to the actual files), and also one file directly within the main directory that is named the same as the name of the framework (without any extension) and contains the binary code of the framework module that is linked into the app when it is built. | If you do manage to get to the innards of a .framework file/directory, you'll find that it contains a subdirectory called "Headers" that contains [[Objective-C]] header files (.h) defining the interface of the module (these are viewable in Xcode in the "Frameworks" section without needing to know the long path leading to the actual files), and also one file directly within the main directory that is named the same as the name of the framework (without any extension) and contains the binary code of the framework module that is linked into the app when it is built. | ||
Revision as of 20:12, 19 March 2013
A .framework file in Apple systems is one of a number of OS X file types that are actually subdirectories (folders), though they appear to the Mac's Finder as single files. It is used to add functionality to OS X or iOS apps being developed in Objective-C in the Xcode development environment. There are a number of these which are part of the Cocoa framework set to do such things as access audio and video recording and playing on an Apple device. Developers don't normally have to deal directly with the files, as they are provided as part of the overall development environment and can be added to a project through the internal interface of Xcode without directly navigating the file tree, and in fact Apple seems to be trying to make the raw files "hard to get" by burying them deeply in a path such as /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/System/Library/Frameworks/. Note that several of the directories in the path have file extensions too; this indicates a nested structure of things that look like files to Finder but are actually directories.
If you do manage to get to the innards of a .framework file/directory, you'll find that it contains a subdirectory called "Headers" that contains Objective-C header files (.h) defining the interface of the module (these are viewable in Xcode in the "Frameworks" section without needing to know the long path leading to the actual files), and also one file directly within the main directory that is named the same as the name of the framework (without any extension) and contains the binary code of the framework module that is linked into the app when it is built.
