{"id":13849522,"url":"https://github.com/kstenerud/iOS-Universal-Framework","last_synced_at":"2025-07-12T16:32:41.890Z","repository":{"id":1403901,"uuid":"1446771","full_name":"kstenerud/iOS-Universal-Framework","owner":"kstenerud","description":"An XCode project template to build universal frameworks (arm7, arm7s, and simulator) for iOS / iPhone.","archived":false,"fork":false,"pushed_at":"2020-10-01T20:18:58.000Z","size":740,"stargazers_count":2943,"open_issues_count":134,"forks_count":471,"subscribers_count":207,"default_branch":"master","last_synced_at":"2024-11-11T23:02:20.776Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/kstenerud.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2011-03-06T16:31:39.000Z","updated_at":"2024-11-05T15:48:40.000Z","dependencies_parsed_at":"2022-07-29T12:49:14.096Z","dependency_job_id":null,"html_url":"https://github.com/kstenerud/iOS-Universal-Framework","commit_stats":null,"previous_names":[],"tags_count":2,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kstenerud%2FiOS-Universal-Framework","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kstenerud%2FiOS-Universal-Framework/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kstenerud%2FiOS-Universal-Framework/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kstenerud%2FiOS-Universal-Framework/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/kstenerud","download_url":"https://codeload.github.com/kstenerud/iOS-Universal-Framework/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":225669608,"owners_count":17505386,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-04T19:01:21.000Z","updated_at":"2024-11-22T01:31:00.605Z","avatar_url":"https://github.com/kstenerud.png","language":"Python","funding_links":[],"categories":["Python","HarmonyOS","etc"],"sub_categories":["Windows Manager"],"readme":"FINALLY!\n=======\n\nWith Xcode 6, Apple has added iOS framework support to their build tools, so this repo can at last be retired!\n\nPlease use Apple's framework target for all new projects, as it is less hacky and is supported by Apple themselves.\n\n\n\niOS Universal Framework Mk 8\n============================\n\nAn XCode project template to build universal (arm6, arm7, and simulator)\nframeworks for iOS.\n\n![screenshot](https://github.com/kstenerud/iOS-Universal-Framework/raw/master/screenshot.png)\n\nBy Karl Stenerud\n\n\nNotes\n----------\n\n### 2013-10-14:\n\n#### Mk 8 is now out of beta!\n\nI haven't been able to solve the problem of deeply nested projects within projects,\nbut the new python scripts have been working in my other projects for over a year now and\nare quite stable for 90% of use cases.\n\nUnfortunately, I don't have the time to solve the last 10% of use cases. As a compromise,\nI've created a branch \"mk7\" which contains the shell script version of the build system.\nIf Mk8 doesn't work for your unique case, give Mk7 a try.\n\nDevelopment will continue in order to keep things working for the other 90% of use cases.\n\nIf you can help, please feel free to contact me or send pull requests. All scripting is done\nin Python now. All template development happens within the \"devel\" directory. build.py\nbuilds the templates and all template source files are in \"src\".\n\n\n### 2012-06-16:\n\n#### Updating your project to use the new scripts\n\nYou can now update existing projects to use the newest build scripts.\nRunning the **update_project.py** script will replace your project's universal\nframework build script with the script in devel/src/BuildFW.py.\n\n**Before upgrading, please back up your project file!**\n\n##### Steps to Upgrade (Mk 7 or earlier):\n\nIf your project was built using Mk 7 or earlier, delete the first two universal\nframework build scripts. The first will be right after \"Target Dependencies\"\nand starts with the following (or something close):\n\n    set -e\n    \n    set +u\n    if [[ $UFW_MASTER_SCRIPT_RUNNING ]]\n    then\n        # Nothing for the slave script to do\n        exit 0\n    fi\n    set -u\n\nThe second script is after \"Copy Bundle Resources\" and starts with the\nfollowing (or something close). Note that this script may not exist in very\nearly versions of the framework project:\n\n    HEADERS_ROOT=$SRCROOT/$PRODUCT_NAME\n    FRAMEWORK_HEADERS_DIR=\"$BUILT_PRODUCTS_DIR/$WRAPPER_NAME/Versions/$FRAMEWORK_VERSION/Headers\"\n    \n    ## only header files expected at this point\n    PUBLIC_HEADERS=$(find $FRAMEWORK_HEADERS_DIR/. -not -type d 2\u003e /dev/null | sed -e \"s@.*/@@g\")\n\nThe final script (the one you want to keep) will start with something similar\nto the first script you deleted.\n\nNow proceed with the next steps below.\n\n\n##### Steps to Upgrade (All versions)\n\n* Make sure the top of the \"Run Script\" phase for the universal framework\n  script starts with the following comment: \"# TAG: BUILD SCRIPT\". If it\n  doesn't, add it in!\n\n* Close your project\n\n* Run the project update script from shell:\n    $ ./update_project.py ~/Projects/MyProj/MyProj.xcodeproj/project.pbxproj\n\n* Reopen your project\n\nThe project update script will create a backup (project.pbxproj.orig) of the\nold project file. To disable this behavior, use the \"-n\" switch.\n\n\n### Selecting Framework Type\n\nThe script now requires you to select which kind of framework (normal or\nembedded) you will be creating, using the **config_framework_type**\nconfiguration variable. Only the selected framework type will be created and\nshown to the user.\n\n**Note:** Xcode requires the normal framework dir to exist, so when building an\nembedded framework, the script simply creates a symlink to the copy inside the\nembeddedframework. Be sure to tell your users not to to copy the regular\n\"framework\" symlink by mistake!\n\n\n### 2012-06-12:\n\n#### New Build Process\n\nWhen you build normally (by selecting Build or CMD-B), the project will **NO\nLONGER** build a universal framework. It will build for the **CURRENT\nARCHITECTURE ONLY**!\n\nTo build a universal framework, you must select **Archive** from the\n**Product** menu. Upon completing the archive build, it will automatically open\nthe folder containing the fully built framework.\n\nThis cuts the compilation time down by 2/3, since it no longer has to do a full\nbuild process when building as a dependency.\n\n#### Building From Command Line\n\nSince \"archive\" is not a supported xcodebuild build action, you must specify\nthe env variable \"UFW_ACTION=archive\" in your xcodebuild command to build it as\na universal framework.\n\nTo avoid opening the destination folder when building from command line, set\nthe env variable \"UFW_OPEN_BUILD_DIR=False\" in your xcodebuild command.\n\n### Only One Script\n\nThe initial beta version had 2 scripts: a clean script and a build script. Mk 7\nhas 3 scripts. With the new build process there is only need for one script.\n\n\n### Older stuff:\n\n#### Xcode Bugs and their Workarounds\n\nWhen Xcode creates the initial header and module file for a framework, the\nheader file won't be included as a member of the framework target (This is a\nbug in Xcode; it does the same thing with Mac frameworks), so you need to do\nthis manually. In **Build Phases** under **Copy Headers**, click the + and add\nthe header, then drag it to the **Public** section.\n\nThe **Run Script** build phases will have the option **Show environment\nvariables in build log** checked. A bug in Xcode causes it to ignore the\ntemplate setting and leave it checked always. This can cause issues when\ndiagnosing a build failure because Xcode will only show the first 200 log\nentries in a build phase, most of which are taken up by spitting out all of\nthe environment variables! So be sure to turn it off manually.\n\nSo to sum up, when starting a new framework project, always do the following:\n\n* Manually add the header file it creates to your build target and mark it\n  public.\n* Uncheck **Show environment variables in build log** in all **Run Script**\n  build phases.\n\n\nWhy a Framework?\n----------------\n\nDistributing libraries in a developer-friendly manner is tricky. You need to\ninclude not only the library itself, but also any public include files,\nresources, scripts etc.\n\nApple's solution to this problem is frameworks, which are basically folders\nthat follow a standard structure to include everything required to use a\nlibrary. Unfortunately, in disallowing dynamically linked libraries in iOS,\nApple also removed static iOS framework creation functionality in XCode.\n\nXcode is still technically capable of building frameworks for iOS, and with a\nlittle tweaking it can be re-enabled.\n\nStatic frameworks are perfectly acceptable for packaging code intended for the\napp store. Despite appearances, it's just a static library at the core.\n\n\n\nKinds of Frameworks\n-------------------\n\n#### Dynamic Framework\n\nA dynamic framework is designed to be installed in your operating system and\nshared by many programs. By default, Xcode only supports dynamic frameworks,\nand only for Mac since you can't use dynamic frameworks in iOS.\n\n#### Static Framework\n\nA static framework gets linked into your app like a static library would.\nHowever, Xcode doesn't include support for static frameworks. These templates\nadd in that support. Frameworks are superior to libraries because they can\ninclude code as well as public headers in a single package.\n\n#### Embedded Framework\n\nAlthough frameworks are an improvement over libraries, Xcode ignores any\nresources contained within frameworks. So if you have xibs, images, sounds, or\nother files in your framework, Xcode won't see them. An embedded framework is\na way to trick Xcode into seeing the included resources. As far as Xcode is\nconcerned, they are simply folders, and so there are a few minor issues with\nembedded frameworks:\n\n* They don't show up in the **Products** group.\n\n* When you delete an embedded framework from a project, Xcode will not delete\nthe outer folder (XX.embeddedframework), so if you try to re-add later, it\nwill complain. You need to manually delete the XX.embeddedframework folder\nmanually using Finder.\n\n* Things get a little tricky when you have a framework project as a dependency\n  if your framework has resources that the parent project needs. You may need\n  to manually add the resources to the parent or sibling project.\n\n\n\n\nChoosing Which Template System to Use\n-------------------------------------\n\nIn this distribution are two template systems, each with their strengths and\nweaknesses. You should choose whichever one best suits your needs and\nconstraints (or just install both).\n\nThe biggest difference is that Xcode can't build real frameworks unless you\ninstall the static framework xcspec file inside the Xcode app, which might be\na dealbreaker for some (this applies to the *PROJECT*, not the framework\nitself).\n\n\n### Short decision chart for the impatient ###\n\nNote: Both types will build the exact same binary. The only difference is in\nhow Xcode treats the project.\n\n* I don't want to modify Xcode: **Fake framework**\n\n* I'm just distributing the final framework binary (not the project):\n  **Either kind**\n\n* I'm distributing my framework **project** to other developers who may not\n  want to modify Xcode: **Fake framework**\n\n* I need to set up the framework project as a dependency of another project\n  (in a workspace or as a child project): **Real framework**\n  (or **Fake framework**, using the -framework trick - see below)\n\n\n### Fake Framework ###\n\nThe fake framework is based on the well known \"relocatable object file\" bundle\nhack, which tricks Xcode into building something that mostly resembles a\nframework, but is really a bundle.\n\nThe fake framework template takes this a step further, using some scripting to\ngenerate a real static framework (based on a static library rather than a\nrelocatable object file). However, the framework's **project** still defines\nit to be of type 'wrapper.cfbundle', which makes it a second class citizen\naccording to Xcode.\n\nSo while it produces a proper static framework that works just as well as a\n\"real\" static framework, things can get tricky when you have dependencies.\n\n#### The problem with dependencies ####\n\nIf you're just setting up a standalone project, then you're not using\ndependencies, so there's no problem.\n\nIf, however, you use project dependencies (such as in workspaces), Xcode won't\nbe happy. The fake framework won't show up in the list when you click the '+'\nbutton under \"Link Binary With Libraries\" in your main application project.\nYou can manually drag it from \"Products\" under your fake framework project to\nadd the dependency.\n\n**Note:** In older versions of Xcode, you'd get warnings like the following:\n\n    warning: skipping file '/somewhere/MyFramework.framework'\n    (unexpected file type 'wrapper.cfbundle' in Frameworks \u0026 Libraries build phase)\n\nThis would be followed by linker errors for anything in your fake framework.\nAs of Xcode 4.3.1, this doesn't seem to happen anymore.\n\nIf you do encounter this issue, you can work around it by adding a \"-framework\"\nswitch with your framework's name in \"Other Linker Flags\" in the project that\nuses the framework:\n\n    -framework MyFramework\n\nIt won't get rid of the warning, which is annoying, but it does link properly.\n\n\n### Real Framework ###\n\nThe real framework is real in every sense of the word. It is a true static\nframework made by re-introducing specifications that Apple left out of Xcode.\n\nIn order to be able to build a real framework project, you must install an\nxcspec file inside the Xcode installation.\n\nIf you are releasing a **project** (rather than the built product) that builds\na real framework, anyone who wishes to **build** that framework must also\ninstall the xcspec file (using the install script in this distribution) so\nthat their Xcode can understand the target type.\n\nNote: If all you're doing is distributing the fully built framework, and not\nthe framework's project, then the end user doesn't need to install anything.\n\nI've submitted a report to Apple in the hopes that they'll update the\nspecification files in Xcode, but that could take awhile.\n[OpenRadar link here](http://openradar.appspot.com/radar?id=1194402)\n\n\n\nUpgrading from previous iOS-Universal-Framework versions\n--------------------------------------------------------\n\nIf you are upgrading from iOS-Universal-Framework **Mk 6 or earlier** and were\nusing the **Real Static Framework**, and are still using **Xcode 4.2.1** or\nearlier, please run **uninstall_legacy.sh** first to remove any patches that\nwere previously applied to Xcode, then run **install.sh** and restart Xcode.\n\nIf you are using **Xcode 4.3** or later, just run **install.sh** and restart\nXcode.\n\n\n\nInstalling the Template System\n------------------------------\n\nTo install, run the **install.sh** script in either the \"Real Framework\" or\n\"Fake Framework\" folder (or both).\n\nNow restart Xcode and you'll see **Static iOS Framework** (or **Fake Static\niOS Framework**) under **Framework \u0026 Library** when creating a new project.\n\nTo uninstall, run the **uninstall.sh** script and restart Xcode.\n\n\n\nCreating an iOS Framework Project\n---------------------------------\n\n1. Start a new project.\n\n2. For the project type, choose **Static iOS Framework** (or **Fake Static\n   iOS Framework**), which is under **Framework \u0026 Library**.\n\n3. Optionally choose to include unit tests.\n\n4. Add the auto-generated header file to the **Public** section of the\n   **Copy Headers** build phase (workaround for Xcode bug).\n\n5. Turn off **Show environment variables in build log** for both\n   **Run Script** build phases (workaround for Xcode bug).\n\n6. Add your classes, resources, etc with your framework as the target.\n\n7. Any header files that need to be available to other projects must be\n   declared public. To do so, go to **Build Phases** in your framework\n   target, expand **Copy Headers**, then drag any header files you want to\n   make public from the **Project** or **Private** section to the **Public**\n   section.\n\n8. Any static libraries or static frameworks that you'd like to have linked\n   into your framework must be included in the **Link Binary With Libraries**\n   build phase. Be careful doing this, however, as it can cause linker issues\n   if the users of your framework also try to include the same library in\n   their project for other purposes.\n\n\nBuilding your iOS Framework\n---------------------------\n\n1. Select your framework's scheme, iOS Device target.\n\n2. Under **Product**, select **Archive**.\n\n3. When the build finishes, it will open the folder containing the framework\n   and embedded framework variants in Finder.\n\nThere will be two folders in the build location: **(your framework).framework**\nand **(your framework).embeddedframework**\n\nIf your framework has only code, and no resources (like images, scripts, xibs,\ncore data momd files, etc), you can distribute **(your framework).framework**\nto your users and it will just work.\n\nIf you have included resources in your framework, you **MUST** distribute\n**(your framework).embeddedframework**.\n\n\n\nUsing an iOS Framework\n----------------------\n\niOS frameworks are basically the same as regular dynamic Mac OS X frameworks,\nexcept they are statically linked.\n\nTo add a framework to your project, simply drag it into your project.\nWhen including headers from your framework, remember to use angle bracket\nsyntax rather than quotes.\n\nFor example, with framework \"MyFramework\":\n\n    #import \u003cMyFramework/MyClass.h\u003e\n\n\n\nTemplate Development\n--------------------\n\nIf you're interested in tinkering with the templates themselves, I've changed\nthe way they are generated. There are now template metatemplates, which are\nused to build the Xcode templates. Inside the devel folder there is a script\n**build.py**, which rebuilds the templates under **Fake Framework** and\n**Real Framework**. The source files are under src:\n\n* **CleanFW.py**: The project clean script (the first script in a framework project)\n* **BuildFW.py**: The project build script (the second script in a framework project)\n* **FakeFrameworkTemplateInfo.plist**: The fake framework metatemplate\n* **RealFrameworkTemplateInfo.plist**: The real framework metatemplate\n\n\nTroubleshooting\n---------------\n\n### Headers Not Found ###\n\nIf Xcode can't find the header files from your framework, you've likely\nforgotten to make them public. See step 7 in **Creating an iOS Framework Project**\n\n\n### No Such Product Type ###\n\nIf someone who has not installed iOS Universal Framework in their development\nenvironment attempts to build a universal framework project (for a real\nframework, not a fake framework), they'll get the following error:\n\n    target specifies product type 'com.apple.product-type.framework.static',\n    but there's no such product type for the 'iphonesimulator' platform\n\nXcode requires some modification in order to be able to build true iOS static\nframeworks (see the two diff files in the \"Real Framework\" folder of this\nrepository for the gory details), so please install it on all development\nmachines that will build your real static framework projects (this\nisn't needed for users of your framework, only for builders of the framework).\n\n\n### The selected run destination is not valid for this action ###\n\nSometimes Xcode gets confused and loads the wrong active settings. The first\nthing to try is restarting Xcode. If it still fails, Xcode generated a bad\nproject (this can happen with any kind of project due to a bug in Xcode 4).\nIf this happens, you'll need to start over and create a new project.\n\n\n### Linker Warnings ###\n\nThe first time you build your framework target, XCode may complain about\nmissing folders during the linking phase:\n\n    ld: warning: directory not found for option\n    '-L/Users/myself/Library/Developer/Xcode/DerivedData/MyFramework-ccahfoccjqiognaqraesrxdyqcne/Build/Products/Debug-iphoneos'\n\nIf this happens, simply clean and rebuild the target and the warnings should\ngo away.\n\n\n### Core Data momd not found ###\n\nXcode builds managed object model files differently in a framework project than\nit does in an application project. Instead of creating a .momd directory\ncontaining VersionInfo.plist and the .mom file, it simply creates the .mom file\nin the root directory.\n\nThis means that when initializing your NSManagedObjectModel from a model in an\nembedded framework, you must specify your model URL with an extension of \"mom\"\nrather than \"momd\":\n\n    NSURL *modelURL = [[NSBundle mainBundle] URLForResource:@\"MyModel\" withExtension:@\"mom\"];\n\n\n### Unknown class MyClass in Interface Builder file. ###\n\nSince static frameworks are statically linked, the linker strips out any code\nit thinks is not being used. Unfortunately, the linker does not check xib\nfiles, and so if a class is referenced only in a xib, and not in objective-c\ncode, the linker will drop that class from the final executable. This is a\nlinker issue, not a framework issue (it also happens when you build a static\nlibrary).\n\nApple's built-in framworks don't suffer this problem because they are\ndynamically loaded at runtime and the complete, unstripped dynamic library\nexists in the iOS device's firmware.\n\nThere are two ways around this:\n\n1. Have end users of your framework disable linker optimizations by adding\n   \"-ObjC\" and \"-all_load\" to \"Other Linker Flags\" in their project.\n\n2. Put a code reference to the class inside another class in your framework\n   that always gets used. For example, suppose you have \"MyTextField\", which\n   is getting stripped by the linker. Suppose you also have\n   \"MyViewController\", which uses MyTextField in its xib file and doesn't get\n   stripped. You could do the following:\n\nIn MyTextField:\n   \n    + (void) forceLinkerLoad_ {}\n\nIn MyViewController:\n   \n    + (void) initialize\n    {\n        [MyTextField forceLinkerLoad_];\n    }\n\nThey will still need to add \"-ObjC\" to their linker settings, but won't need\nto force all_load.\n\nOption 2 is more work for you, but if done right it saves the end user from\nhaving to disable linker optimizations (causing object file bloat) just to use\nyour framework.\n\n\n### unexpected file type 'wrapper.cfbundle' in Frameworks \u0026 Libraries build phase ###\n\nThis happens when you use a fake framework project as a dependency in a\nworkspace, or as a child project (real framework projects don't have this\nissue). Even though the framework project produces a proper static framework,\nXcode only looks at the project file, which says it's a bundle, and so it\nissues a warning during the dependency check and then skips it during the\nlinker phase.\n\nYou can get it to link properly by manually adding a command to link\nyour framework during the linker phase. Add a command to link your framework\nin \"Other Linker Flags\" in the project that depends on the framework:\n\n    -framework MyFramework\n\nYou'll still get the warning, but it won't fail in the linker phase anymore.\n\n\n### Libraries being linked or not being linked into the final framework ###\n\nUnfortunately, due to the way Xcode works, the \"Real Framework\" and\n\"Fake Framework\" templates handle included static libraries/frameworks\ndifferently.\n\nThe \"Real Framework\" template follows correct static library procedure, NOT\nlinking other static libraries/frameworks into the final product.\n\nThe \"Fake Framework\" template tricks Xcode into thinking that it's building a\nrelocatable object file, and so the linking phase treats it as if it were\nbuilding an executable, linking all static code sources into the final binary\n(although it doesn't check for missing object code). To get the\n\"Real Framework\" behavior, you should include only the header files from the\nlibrary/framework in your framework project, not the static library or\nframework itself.\n\n\n### Unrecognized selector in (some class with a category method) ###\n\nIf your static library or static framework contains a module with ONLY\ncategory code (no full class implementations), the linker will get confused,\nand will leave the code out of the final binary. Since it's not present in the\nfinal product, you'll get \"unrecognized selector\" exceptions when any call is\nmade to those category methods.\n\nTo get around this, put a dummy class into the module containing the category\ncode. The linker, seeing a full Objective-C class, will link the module in,\nincluding the category code.\n\nI've made a header file [LoadableCategory.h](https://github.com/kstenerud/Objective-Gems/blob/master/Objective-Gems/LoadableCategory.h)\nto make this easier to do:\n\n    #import \"SomeConcreteClass+MyAdditions.h\"\n    #import \"LoadableCategory.h\"\n    \n    \n    MAKE_CATEGORIES_LOADABLE(SomeConcreteClass_MyAdditions);\n\n    \n    @implementation SomeConcreteClass (MyAdditions)\n    \n    ...\n    \n    @end\n\nYou will also need to add \"-ObjC\" to the \"Other Linker Flags\" build setting in\nany project that uses the framework.\n\n\n### Unit tests crash before executing any code ###\n\nIf you make a new static framework (or static library) target with unit tests\nin Xcode 4.3, it will crash when you try to run the unit tests:\n\n    Thread 1: EXC_BAD_ACCESS (code=2, address=0x0)\n    0 0x00000000\n    ---\n    15 dyldbootstrap:start(...)\n\nThis is due to a bug in lldb. You can run the unit tests using GDB instead by\nediting your scheme, selecting \"Test\", and from the \"Info\" tab changing\nDebugger from **LLDB** to **GDB**.\n\n\n\nHistory\n-------\n\n### Mk 1\n\nThe first incarnation. It used a bunch of script hackery to cobble together a\nfake framework. It exploited the \"bundle\" target, setting its type to a\nrelocatable object file.\n\n\n### Mk 2\n\nThis version took advantage of the template system to do most of the work\nthat the script used to do. Everything (including the script) was embedded\nin the template.\n\n\n### Mk 3\n\nThis version does away with the \"relocatable object\" hackery and builds a true\nstatic framework, with all the abilities of an OS X static framework.\nThis solves a number of linker, unit testing, and workspace inclusion issues\nthat plagued the previous hacky implementations.\n\nIt also includes the concept of the embeddedframework, which allows you to\ninclude resources with your framework in a way that Xcode understands.\n\nJosh Weinberg also added some tweaks to make it build in the proper build\ndirectory with scheme-controlled configuration, and behave better as a\nsubproject dependency.\n\nIt now requires some small modifications to Xcode's specification files in\norder to support true static frameworks, and thus comes with an install and\nuninstall script.\n\n\n### Mk 4\n\nThis version gives you the choice of installing the \"real framework\" template\nor the \"fake framework\" template. Both come with an install script, but only\nthe \"real framework\" installer needs to modify Xcode.\n\nThis also fixes some issues that the fake framework had in Mk 2 (such as\nthe curious behavior of embedding the full path to the compiled files within\nthe files themselves, resulting in warnings when building with that framework).\n\n\n### Mk 5\n\nThis version does away with the extra target and script. Everything is self\ncontained in the framework target, and the framework under the \"Products\"\ngroup is actually the universal framework (no more Debug-univesal or\nRelease-universal folders).\n\nYou can build and clean like you would in any other project.\n\nAs well, the \"Fake\" framework template now builds a proper static library\ninstead of a relocatable object file (although Xcode still doesn't believe\nthat it's real).\n\n\n### Mk 6\n\nThis version makes the Xcode modifications for real static frameworks safer\nby simply adding an extra specification file instead of patching existing\nones.\n\n\n### Mk 7\n\nThis version was *supposed* to be the one that no longer modified Xcode, but\nalas, Xcode behaves differently depending on *WHERE* the xcspec file gets\ninstalled. Take a guess at which location doesn't work...\n\n@wtfxcode\n\nSo instead, this version basically handles the new install location of\nXcode4.3.\n\nTemplates now build armv6 + armv7 by default instead of just armv7.\n\nNote: If you previously installed real framework supprt under the broken Mk 7\n(i.e. if you installed it on Feb 16th, or Feb 17th before 9:00 am PST, 2012),\nrun uninstall_legacy.sh to uninstall the xcspec file from your home dir, then\nreinstall.\n\n\n### Mk 8\n\nThis version replaces the bash scripts with Python scripts. This gives a LOT\nmore control over the build process.\n\nTo build the universal version of your framework, you must now use the\n**Archive** command rather than the **Build** command.  **Build** only builds\nfor the current architecture (to speed up compilation when your framework\nproject is a dependency of another project).\n\nAdded a devel folder for template development.\n\n\nLicense\n-------\n\nCopyright (c) 2011 Karl Stenerud\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in\nthe documentation of any redistributions of the template files themselves\n(but not in projects built using the templates).\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN\nTHE SOFTWARE.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkstenerud%2FiOS-Universal-Framework","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fkstenerud%2FiOS-Universal-Framework","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkstenerud%2FiOS-Universal-Framework/lists"}