Universal Cocoa Touch Frameworks for iOS8 – (Remix)

Attention: An updated process for iOS 9 has been developed and can be found here: https://kodmunki.wordpress.com/2015/09/22/ios-9-universal-cocoa-touch-frameworks/

So, it appears that Apple® has changed their App validation process; fat binaries are no longer passing validation, and, per our support inbox, this is a very real and present problem for a lot of people.
Well, fear not! After some nifty hacking and finagling we have come up with a process that is simple and straight-forward, continues to support universality in development, and archives artifacts that pass validation.

If you implement this method, please, let us know about it in the comments, and, if it is working for you, be sure to flood your social media with links back to this article. No, this is not a shameless attempt to get traffic, though traffic sure is sweet. This is evidently a very real problem for many developers, and it is certain that if they are currently sitting at their keyboard, slamming their face into it because they can’t resolve this issue, they will be thankful you gave them a heads up!

Alright, enough bloviating. Here is a “step by step” of the new process.

Creating a Framework

  1. Fire up Xcode and start a new Cocoa Touch Framework project (Fig. 1)
    (Figure 1)
  2. Go to the Build Settings of your project target and confirm or set the “Architectures” to “Standard Architectures.” These are arm64 and armv7, and are likely the default. (Fig. 2)
  3. Set “Build Active Architecture” to “NO” – Yes your build times may be a little longer, but this is what is going to allow your Frameworks to be “universal”. So, if you don’t do this, running on your sim will be a problem. Besides, if your builds are debilitatingly slow in a framework because you set “Build Active Architecture” to “NO,” you probably aren’t maximizing modularity. (Fig. 2)
  4. Set or confirm “Valid Architectures” to arm64, armv7 and armv7s. This is likely the default. (Fig. 2)
    (Figure 2)
  5. Go to the Build Phases section of your project target and append a new Run Script phase. Paste this script in in it:UPDATE: Due to the latest version of Xcode changing its compilation process this script can no longer be placed in the Build Phases, as this causes the script to run too early, not giving the build process enough time to generate the module.modulemap files for your framework. If you previously used this process be sure to follow these new instructions for this step and remove the Build Phase Run Script that this step previously requested.NEW INSTRUCTIONS: Add the script below to your project’s build Scheme as an Archive Post-action:
    1. Edit your projects build Scheme by selecting “Edit Scheme” from the Scheme drop down.EditScheme
    2. Add the script below as an Archive Post-action, select your project from the “Provide build settings from” drop down, and click “Close.”UpdateScheme

Archive Post-action script

set -e


rm -rf "${ARCHIVE_PATH}"
mkdir "${ARCHIVE_PATH}"

if [ "${CONFIGURATION}" = "Release" ]; then

if [ -d "${DEVICE_BIN}" ]; then
mkdir "${DEVICE_PATH}"
cp -r "${DEVICE_BIN}" "${DEVICE_PATH}"
if [ -d "${SIMULATOR_BIN}" ]; then

exit 0;

There you go. Now you will simply develop.

Assuming that you are using your simulators and devices to test regularly during development before archiving, you will not need to take special note of this, BUT do know that to get your framework artifact you will have to Archive your project. Doing so will add an _Archive/ directory (Fig. 3) to the root of your project in Finder in which you will find your artifact. Know that you will have to build the project with a simulator and archive with a device to get a universal. If someone out there wants to contribute an xcodebuild or xctool script to build both of these on the fly, please, feel free. It would be a great contribution and a welcome addition for may, I’m sure!

(Figure 3)

(An example of a working framework template can be found on here on kodmunki™ Github.)

That’s it! Now, you have a Framework. But, if you are anything like me, you have likely built a kernel or some other low level Framework and will expect other higher level Frameworks to depend on this Framework. Like, say, persistence, or data. To do this you will do the following:

Creating Dependent Frameworks

  1. Perform steps 1-6 from above to create the Framework.
  2. In the Build Settings of both the project Target and the test Target, set “Always Search User Paths” to “YES”. (Fig. 4)
    (Figure 4)
  3. Add a /lib directory to your Framework that will contain all of your project’s custom Frameworks, i.e. kernel if this is data. (Fig. 5)
  4. Put the desired Framework artifacts in this directory. When done correctly, the /lib directory will contain a /Debug and a /Release directory each containing your binary dependencies. (Fig. 5)
    (Figure 5)
  5. In the “Framework Search Paths” of both your project Target and your test Target add “$(PROJECT_DIR)/lib/$(CONFIGURATION)” (Fig. 6)
    (Figure 6)
  6. In the “Runpath Search Paths” of both your project Target and your test Target add the following paths: “$(inherited), @executable_path/Frameworks, @loader_path/Frameworks, $(PROJECT_DIR)/lib/$(CONFIGURATION)” (Fig. 7)
    (Figure 7)

All should be working successfully! Run your unit tests, build with both the simulator and device, and archive your project to verify.

(An example of a working dependent framework template can be found on here on kodmunki™Github.)

Now you want to add this awesome modularity to an application you say? Okay, here’s how:

Adding Frameworks to an App

  1. Create a /lib directory at the project root that will contain the custom Frameworks that you want to add.
  2. Put the desired Framework artifacts in this directory. (Be sure to add both the Debug and Release bins at the directory level. This is just like in step #4 of the previous section)
  3. In the“Runpath Search Paths” and “Framework Search Paths” of your project target and test target add “$(PROJECT_DIR)/lib/$(CONFIGURATION)”
  4. Navigate to the General section of your project Target and add the desired Frameworks to the “Embedded Binaries” section. Add the binaries that are found in Release! The ones in Debug will not pass validation with Apple®! Note, that this should automatically add them to the “Linked Frameworks and Libraries” below. After this step, you should have see your Frameworks in both sections. (Fig. 9). Point of note: ensure that they aren’t duplicated in the “Linked Frameworks and Libraries” section!
    (Figure 9)

(An example of a working application template can be found on here on kodmunki™ Github.)

Some worthwhile points of note:

  • These instructions are for those projects that support Cocoa Touch Frameworks, i.e. iOS 8+. Efforts to use these instructions for prior versions, may not be futile, but are untested and will, likely, be in vain.
  • If you would like to port an iOS Framework built using the “kstenerud/iOS-Universal-Framework” to a Cocoa Touch Framework, I recommend you do the following: just start a new Cocoa Touch Framework, follow the steps that I have outlined here, copy and paste the files from your old project into your new project directory tree, and add them to the project. To answer a question some of you might have, yes, you could just change the settings, phases, and scripts of your current project, but I do not condone or recommend this, as you are certain to lose hours or days of your life fiddling with settings and scouring the ends of the earth for some obscure missed step. That said; if you decide to go this route, please, do not email me with issues. I don’t recommend it, and I will not offer support for it. — Well, free support anyway … paid, hourly support, maybe :{)}
  • Xcode is horrifically finicky, skittish, and unpredictable. I have tested this method with numerous libraries and have had nothing but success. Though, I must say, I have run into compiler errors and warnings from time to time for no good reason, whatsoever. That said, please be sure to try cleaning your project, clearing your derived data, re-running your build steps, and doing any of the other “regular” Xcode cleans before assuming this doesn’t work. I absolutely hate having to make this disclaimer, but if you have any experience with Xcode you, too, know this sad but inevitable truth.

There you have it. Modularity revived in Xcode 6 the remix! This should work now just as it did in the previous article on this topic. Though, now, the processes passes Apple® validation when attempting to deploy your App to the app store! :{)}

I hope that you enjoyed this post and find it useful! And, if you do, you share it with others.

Please, comment on and share this post with others if you enjoy it; follow @kodmunki on Twitter for regular updates on new developments, deployments, articles, and tools; and check out kodmunki™ on github for cool, managed, and tested kodmunki™ projects.

Happy hacking! :{)}


Software development leaders at the forefront of the latest in technology. Whether implementing updates or integrating with existing technology; developing products that push the bleeding edge of the latest in tech; or developing open-source products, paving the way of future tech, kodmunki™ inspires innovation, elevates quality, and drives value to production. kodmunki™ are experts in web, mobile, and hybrid solutions development; local and distributed team management and collaboration; and fast, quality, successful product delivery, offering R&D, training, consulting, and development services. Contact us at info@kodmunki.com. Let's discuss your vision.

Posted in Uncategorized
85 comments on “Universal Cocoa Touch Frameworks for iOS8 – (Remix)
  1. aramik says:

    So I’m able to follow along and archive the .framework file but when I add that framework to another project I can’t seem to access the classes . This is using Swift with “public” classes defined. Is there something I’m missing? I can get it working by dragging the entire project but I really would love to be able to setup one .framework that has to be added to the project. That way the source code cannot be modified. I mean there has to be a way to do it. I see companies like Parse, Mobiquity and more. They have .framework files that you just drag into the project and bamn! is it because i’m trying to do it using swift?

    • kodmunki™ says:

      Hey Aramik! Thanks for reading and commenting! New frameworks add all headers at the “Project” level and are, therefore, not exposed to external projects. To make them public you will need to add the desired headers to the “Public” level under your target’s Build Settings. Here is a link to an annotated image for your reference: http://screencast.com/t/o7HggIFfvVL Hope this helps!

      • aramik says:

        Alright I think I got it! BUT running into another issue. 🙂

        So I noticed that framework only works either in the simulator or on devices. (Depends which one i’m on when I archive) I made sure that I Set “Build Active Architecture” to “NO”. But still not working, can you think of anything I’m missing? I thought this would make it universal so it doesn’t matter if the simulator is selected or a device.

      • kodmunki™ says:

        Be certain that you followed the instructions exactly. — My guess is that you are likely importing the artifact binaries into the dependent project incorrectly (per this process). — I assure you that if you follow the instructions exactly it does work. All kodmunki™ frameworks and legacy applications have been ported to use this new process without incident, and I am actually developing a SpriteKit game at this very moment in which I used this process to leverage a few necessary external kodmunki™ Frameworks. — If there are specific sections that are confusing , please mention them here so that we might update the post for clarity. I hope this helps!

  2. aramik says:

    Okay so I followed everything exactly. I think I may be getting confused on this section here.

    Assuming that you are using your simulators and devices to test regularly during development before archiving, you will not need to take special note of this, BUT do know that to get your framework artifact you will have to Archive your project. Doing so will add an _Archive/ directory (Fig. 3) to the root of your project in Finder in which you will find your artifact. Know that you will have to build the project with a simulator and archive with a device to get a universal. If someone out there wants to contribute an xcodebuild or xctool script to build both of these on the fly, please, feel free. It would be a great contribution and a welcome addition for may, I’m sure!

    So. I did a Build using the simulator (iphone6) to be exact then archived it under iOS device. In the _Archive directory, I see debug and release. Right now i’m trying to import the release version. But won’t work in simulator. (Now I know that sounds dumb, but the way I’m understanding it is “universal” means it’s able to run on both simulator and a device, right?)

    • kodmunki™ says:

      Not “dumb” at all! — Yes, you are correct “universal” means able to run on both. — The short answer is that the Debug version is universal the Release version is not. You need to import both into your dependent project and use the process described so that you can continue to develop with a universal and pass the Apple validation process at deployment time with the thin bin. The post describes this albeit succinctly. — The longer answer is that this process would not be necessary if Apple didn’t stop validating fat binaries at deploy. Our old process (described in a previous post) worked as you are assuming, and worked GREAT, but now because fat binaries are no longer passing Apple validation we had to move to this process. This new process continues to satisfy our need to develop with universals and still be able to deploy products to the App Store. — With all of that said, if you follow this post exactly, you will create a universal dev environment that can archive artifacts that will pass app validation. One of these “exact” steps that it sounds, by your description, is being overlooked is the importing of the Debug and Release directories into your dependent projects /lib folder. Take a look at the second and third section of the post. This is described there. Happy Hacking!

  3. aramik says:

    Okay I get it now, thank you!

    One question tho. How do all these companies do it without this hack? Like Parse or other Third parties that just give you a framework to drop in?

    • kodmunki™ says:

      I am not sure that they can anymore. What you describe is exactly what our old process yeilded, and in fact, this new process does to. The actual universal binary is in the /Debug directory, and this binary will work just like you state. You can find the old process that describes how to do what you are talking about, here: https://kodmunki.wordpress.com/2014/11/07/universal-cocoa-touch-frameworks-for-ios-8/. — One HUGE problem. Apple no longer validates fats, they throw an invalid architectures an exception on the i386 and x86 archs. So, with that said, if you never intend to go live you can use the old process and it will work just like the old third party frameworks and static libs you are talking about, but if you do plan to go live don’t use the old process. — (One final point of note — the Google Analytics fat isn’t passing validation either). Thanks for the comments! Best of luck on your project! :{)}

  4. aramik says:

    awesome thanks!

  5. thxslo says:

    You forgot that Xcode 6 not adds armv7s slice by default ! There will be crach on armv7s devices!!!! Hot to add : project/build settings/Arhitectures / + add/ armv7s … If you think that im joking go in terminal and type: “file pathToBuild/TargetName.Framework/TargetName” and you will see in output that armv7s is missing by default!!!

    • kodmunki™ says:

      Good day thxslo! Thanks for checking in! The lack of armv7s is not an oversight on our end. It was left out, because it is our current understanding that armv7s is not a critical build requirement as it will not cause applications to break, but merely improves calculation speeds on some devices as it will support specific hardware improvements on said devices. We have tested on said devices with this process with no issue. Because of the non-critical nature of this architecture it was omitted for brevity and on the assumption that those parties who were actually privy to this information would add this architecture as needed. Thank you, though, for the heads up. We will look into this further as needed, and if we find issues due to the omission of this architecture we will certainly make the necessary updates to this instruction set. Great to hear from you! Thanks again, and happy hacking! :{)}

      • thxslo says:

        About armv7s & frameworks i didnt make any tests but i can tell you that in the past i had really big project with static library(not framework) and i know that without this modifications i couldn’t build app on iphone 5 . But i have another question for you =) I dont know if you had same problems like i had today ?!… I merged debug device and debug simulator binaries to get universal debug binary.. I see in your script that you copied everything from device build to /debug folder and after that you just override/merged device binary with simulator binary. On my site this was not enough. I also need to copy simulator modules folder…In bash: cp -r ” SimulatorPath/${EXECUTABLE_NAME}.framework/Modules/${EXECUTABLE_NAME}.swiftmodule/” “UniversalPath/${EXECUTABLE_NAME}.framework/Modules/${EXECUTABLE_NAME}.swiftmodule” Otherwise Xcode cannot find my framework code when building for simulator.

      • kodmunki™ says:

        Thank you for posting the info thxslo! We have not encountered any issues with this process on our end. We have a vast array of libraries including kernels, persistence libraries, cryptography, application patterns, communication layers, etc. all supporting various application and this process works wonderfully! In the event that we encounter future issues we will certainly take this under advisement. Thank you for your insights, and best of luck to you on your current project! :{)}

      • thxslo says:

        +++ about copying simulator swift modules that i need ! … Check you old post https://kodmunki.wordpress.com/2014/11/07/universal-cocoa-touch-frameworks-for-ios-8/ and comment from Valm on December 17, 2014 at 07:54 .. he also copied swift modules from simulator!!!!

      • kodmunki™ says:

        Thanks for checking in again, thxslo! You are certainly correct, Valm’s comment on our previous post does describe copying .swiftmodule files in his step #3. — He does also note that his process was resulting in exceptions including a dyld: Library not loaded exception. Due to this fact, adding this step will require testing to ensure that additional steps resembling this one will not taint our process that is currently working internally. We will look into this further, update our process as needed, and certainly note the updates in this post as they become necessary. Thank you for bringing your issues to our attention, and for sharing further detail via referencing Valm’s comment. We greatly appreciate it! Please, stop back and check in with us. It is always great to engage with fellow developers! :{)}

  6. jlnbuiles says:

    Thanks for this! it really has helped me out a ton!!!

    I had a question. In the framework i’m creating there are certain files that depend on external libraries that I would be importing via cocoapods, how can i import these into the framework and at the same time prevent from adding them to the compiled source?

    I would like to just list these in a README where I would ask consumers to add them as a requirement for the project to work.

    How can they be linked/configured in the consuming project once the framework has been successfully set up with the process described in your tutorial?

    • kodmunki™ says:

      jlnbuiles, thanks for checking in!

      It’s great to hear that this process is helping others, and very kind of you to take the time to drop a line.

      As for your question, I cannot say definitively as we do not leverage Cocoapods. We have internal processes for dependency management and IoC that work very well for us. What I can say generally about framework dependencies as they pertain to this process that might be of help is as follows:

      If you notice in this post it discusses linking to your /lib folder for framework dependencies.


      All this is doing is telling the build to look in these directories for frameworks as well. You should be able to do the same.

      Don’t link to your libraries and have them compile with your distributable. Instead, add another path in the build settings to point to your directory that will house your dependencies.

      Then, when you archive, the frameworks will not be included in the archive. This means that anyone who uses your distributable will also need to import the frameworks, or set up the same build setting as you have. Your process will be doing the same thing as ours.

      I hope that this is useful information in completing your objective. Please, let us know how if it works out for you. Thanks again for checking in, and best of luck to you! :{)}

    • Were you able to find a solution? I am in the same situation as yourself

  7. Gangadhar says:

    Thanks for the informative tutorial.

    I currently followed your guidelines and started consuming one framework with in another framework(custom). But encountered the following error

    :0: error: could not build Objective-C .

    Any help on this will be greatly appreciated .

    Note : Both the frameworks consists of code written in Swift .

    Thanks in advance

    • kodmunki™ says:

      I’m glad you found the process informative, but it’s a bummer that you have confronted an error!

      The first thing that I will say, is be certain that if you wish to leverage this process, be sure you follow it to the tee. It is most certainly working in-house.

      That said, there are others who are leveraging Swift that have been running into other gotchas. They have been kind enough to share their hardships in the comments and have even influenced us to look further into their issues (Investigating potential issues with Swift is on our Kanban board and will be looked into).

      In the interim might I point you to a comment from thxslo:


      They appear to have had an issue with .swiftmodule and needed to add a step to copy these in their run script.

      I hope this helps, at least point you in the right direction. If it does resolve your issue, please let us know, so that we can elevate the status of that potential issue.

      If it does not help, feel free to let us know more details about your issue. We are always interested and happy to help any way we can.

      Best of luck to you! :{)}

  8. Jerry Walton says:

    I followed your steps exactly.

    Sometimes it works, sometimes the framework fails to include the symbols?

    any idea what’s up with that?

    ld: symbol(s) not found for architecture x86_64

    • kodmunki™ says:

      We had this issue occasionally some time ago. It was due to how mac was “merging” the existing artifacts when copying ‘new’ artifacts (Debug/Release) into a dependent project. — Can you be more explicit as to when this is occurring for you?

    • Jerry Walton says:

      the Debug framework contains the correct symbols …

      $ xcrun lipo -info CCCPhotoComponents
      Architectures in the fat file: CCCPhotoComponents are: i386 x86_64 armv7 arm64

      the Release framework contains the correct symbols …

      $ xcrun lipo -info CCCPhotoComponents
      Architectures in the fat file: CCCPhotoComponents are: armv7 arm64

      when the entire _Archive folder is included in the project, with the Release framework being present, the project won’t run in the simulator.

      if I remove the Release framework, the it builds and runs OK in the simulator.

      is there anything I am missing to allow including both frameworks (both folders under the _Archive folder), or are you supposed to include one or the other depending on if you are testing in the simulator or on the device?

      • kodmunki™ says:

        No. The workflow is supposed to be seemless. For us, we build our frameworks, Unit Test them, Archive them, drop them into the dependent project, and keep right on developing. It is slick!!! And error free! — I see you just commented again…… I’ll read that one now….

  9. Jerry Walton says:

    i copied the _Archive folder from finder into the app project, and did not check “Copy items if needed”.

    i wanted the ability to have the framework project open and also have the app project open to be able to bounce back and forth and work on both at the same time.

    when I create new projects, it works for a few times/hours and then somehow gets broken.

    i even tried deleting “derived data” but that did not correct the problem.

    • kodmunki™ says:

      Our workflows certainly do differ, but what you describe should not be an issue — For my clarity: Are you copying the contents of _Archive into a /lib directory?

      • Jerry Walton says:


        xcode project tree ..

        TestApp <== top level blue
        TestApp <== second level yellow folder
        lib <== third level yellow folder Archive.

        when go to the TestApp, and attempt to run in the simulator – it says “ld: symbol(s) not found for architecture x86_64”

        if I “monkey” around with the framework project, clean/build/pray and then go back to the TestApp project and clean derived data, and remove/add the frameworks from the build “Embedded Binaries” section, then i can get it running again after loosing about 20 minutes and nearly loosing my mind. yikes! WTF – thanks Apple.

      • kodmunki™ says:

        All of this “monkeying” around is certainly not how this process is intended to work, nor is it what we are seeing on our end. I am sorry to hear this is what you are seeing on your end!

        With that said, one point of note, the process described in this post does state that the developer should be putting “Debug and Release” not “_Archive” into /lib. Assuming I am interpreting your directory structure correctly, and _Archive is in /lib, it is doubtful, but possible (heeding the historically finicky nature of Xcode) that this is resulting in issues for you.

        All of that said, 20 minutes of horsing around with non-value adding nonsense is always unacceptable, but certainly so, for anything that we stand behind. I thank you for bringing your issue to our attention. We will review these comments, look into this further, and make updates with our findings. Thank you again for your comment!

  10. kodmunki™ says:

    Looks like I lost you Jerry — If you have the ability to reply, it would be a pleasure to help you get this issue resolved, or hear what you discovered as your resolution.

    In the mean time: this process has been so incredibly successful on our end, it comes as a surprise that you are having issues. As I stated, one issue that we did find was that our Macs were funny, at times, about how they were copying over the Debug and Release artifacts. Simply, removing the existing dependency and copying new instead of overwriting the existing solves this issue for us if we run into it. I hope that you will take the time to respond. Until then, best of luck!!!!

    • Jerry Walton says:

      Thanks, I will try deleting (removing) and then copying the framework over to the project that is using the framework (by checking “Copy items if needed”) and see if that improves things.

      Thank you.

      • kodmunki™ says:

        Jerry –

        Thank you for your comments! We have been meaning to put together a video post for a few weeks but have not been sure of a topic. Your issue has given cause to create a video tutorial post for this topic. This should be posted next week. In the mean time, you might find the sample projects on Github helpful to verify that all of your settings and structure are, in fact, aligned.

        If you do find the root cause of your issue I hope that you will take a moment to share your findings. This post has extremely high traffic, and if one developer has a problem it is a guarantee that another has an identical problem. I know that they will be thankful for your insights. We will look into this issue further and make any necessary updates from our findings.

        Sincerest Best Regards! :{)}

      • kodmunki™ says:

        Jerry —

        After updating our Xcode version and making an update to our kernel project we ran into an issue that sounds very similar to the one that you described. We have resolved our issue and posted an update to this process to reflect this. — You may want to try updating your process as well, as this update does resolve our internal issue very nicely. Best of luck!

      • Jerry Walton says:

        hey kodmunki’s …

        your recipe was working with Xcode 6.2, …

        1) work-flow using 2 project windows (one for the framework, and one for the test app)

        2) on the framework window ==> building (Cmd+B) both the debug (iPhone6) and release (iOS Device) framework targets, and then running the menu Product => Archive to generate the debug framework file (fat binary with the 386 and x86 stripes) and the release framework file (skinny binary with arm7, arm64, and arm7s stripes).

        3) on the test app window ==>

        3a) if the framework had NOT previously been copied into the project tree (first time)
        then copying the “Debug” -OR- the “Release” folder and the xxxx.framework file into the project tree using drag-and-drop from Finder window (in my experience the Xcode project would not build with both folders/frameworks copied into the folder tree).

        3b) if the framework had previously been copied into the project tree then deleting the Debug or Release folder and its containing xxxx.framework file from the test app project tree, and then deleting the Debug or Release folder and its containing xxxx.framework file from the test app project folder/directory using finder to drag into garbage.

        4) on the project target build properties view, remove the xxxx.framework from the “Linked Frameworks and Libraries” and then add it back to “Embedded Binaries” (which will also add it back to “Linked Frameworks and Libraries”, and the build the test app and run it.

        and then i upgraded to Xcode 6.3 and things got broken upon the first build.

        was a simple fix to the work-flow.

        Under xcode 6.3, …

        for step 3) instead of copying the “Debug” or “Release” folder into the project tree,
        directly copying the xxxxxx.framwork file into the project folder tree, and then continue with step 4) above “worked like a champ”.

        Thanks you kod munkis! you folks rock!

      • kodmunki™ says:

        Hi Jerry —

        Thanks for checking in! It sounds like you have added a few custom steps to your process, but that you do have it working and are making progress. This is excellent! Thank you for all of your feedback. We greatly appreciate it! Best of luck to you on your project! :{)}

  11. This is working for me, except that the modulemap file that is supposed to be with the framework isn’t being included in the generated output. The modulemap file let’s you specify the dependencies of your framework, using statements like `link framework “CoreTelephony”`.

    When I run the `cp -r “${DEVICE_BIN}” “${DEVICE_PATH}”` command manually the modulemap file is included, so maybe the modulemap file isn’t added by the time the build script is called?

    • kodmunki™ says:

      Hi maximiliantiger —

      Thanks for commenting!

      Two items:

      1) modulemaps are certainly copying on our end. So, it appears that we are not having the same issue. With that said, if you are trying to use the process described, please be certain that you are following the process exactly as described. (We are working on a video post for this process that should post later this week.)

      2) If you are not trying to leverage this process exactly, and have, instead, created your own hybrid that merely pulls from these instructions as a supplement or for insights on portions of your process, I might point you to the “Module Map File” and associated Build Settings found under the “Packaging” section of your Build Settings. If you have custom files that you would like included in your build, you might try listing them there.

      If this suggestion, in fact resolves your issue, I hope that you will let us know, as it is certain that if one developer out there is having this issue, many are!

      Thanks again! Looking forward to your reply. In the mean time, happy hacking! :{)}

    • kodmunki™ says:

      Hey maximiliantiger —

      After updating Xcode and making an update to our internal kernel we ran into a similar issue. We have resolved this problem by moving the Run Script out of the Build Phases and into an Archive Post Script. This allows XCode to generate the modulemap file before we copy the framework artifacts over to _Archive. — We will update this post ASAP to reflect this change and include it in our video post. Thank you for commenting on this issue. Happy Hacking! :{)}

  12. Mike says:


    Want to leave a comment without any caveat- this worked for me 100%. I have an app approved and live in the store sharing a framework between app, today extension (widget), AND Apple Watch app!

    Tried many tutorials, yours was the only one that worked, thanks!!

    • kodmunki™ says:

      Mike —

      This is wonderful news!!! Thank you, so much, for checking in at sharing! We, very much, enjoy hearing from others how the process is working for them, and are elated when we hear that it works as well as it has for you. Our sincerest thanks for taking the time to let us know. Too, congratulations on going live!!! Our sincerest best wishes to you on a successful run with your production application. Happy Hacking! :{)}

  13. Locutus says:

    This allows you to keep using fat binaries for debug and release builds on the simulator. In my case I need to test release builds on the simulator.


    • kodmunki™ says:

      Good day Locutus —

      Thanks for commenting! It’s great to hear that you have found a process that helps you achieve your objectives! Our sincerest best wishes to you on your endeavors!

      With that said, although we appreciate you sharing this link, it does describe a process that would not be allowed at kodmunki, as It disregards many of our design principles. I won’t discuss all of them here, but, how about one — How about a principle of “least knowledge.”

      It is important that all frameworks and libraries yield artifacts that can be consumed by dependent projects where those dependents have the least possible knowledge of their dependencies. Namely, that these libraries mandate, only, that dependents be aware of and communicate via their public API. Furthermore, dependents should be able to successfully leverage the stated features of a dependency throughout development and into production, simply by consuming the correct artifact and communicating via its public, tested, side-effect free API.

      The process that you link to here, is problematic for us for a few reasons, but most readily obvious is that it requires dependents to modify the library artifacts of their dependencies some time in the development workflow. This mandates that the dependent take on an enormous responsibility that far exceeds that allowed under our adherence to this “least knowledge” principle.

      So, with that said, if this process that you linked to is allowed by you, is working for you, and is helping you accomplish your objectives, we, sincerely, think that is excellent! For us though, it, simply, is not in line.

      Thanks again for commenting! Best of luck! Happy hacking! :{)}

  14. Locutus says:

    The latest Urban Airship framework for iOS 8 is a fat binary. This is apparently accepted when you submit it. It contains all architectures for the simulator and device.

    • kodmunki™ says:

      Locutus —

      Thanks for the update! This is an interesting find. We’ll have to try pushing a fat and see what we get on our end. Thanks for sharing! :{)}

  15. Ondrej Rafaj says:

    Amazing! Thank you! Credit will be soon on LiveUI.io 🙂

    • kodmunki™ says:

      Good day Ondrej Rafaj —

      Thank you for checking in and taking time to comment! It’s excellent to hear that the process is working for you.

      Thank you, too, for publicly crediting our efforts. Our very best wishes to you on your LiveUI.io venture!

      Happy Hacking! :{)}

  16. kundan says:

    hey kodmunki’s,

    I have followed your tutorial but i am unable to make my framework universal. If i build for simulator it works with simulator and vice-versa for device. I followed your instruction to build with simulator and Archive with device. That doesn’t help me out, by doing so i am unable to run in simulator.Please, guide me how to achieve that.

    • kodmunki™ says:

      Good day kundan —

      You are not the first to make this comment. These instructions do work. They have been used to create countless frameworks by numerous developers on countless projects world-wide. If you follow the instructions exactly, you will be successful.

      Because this “issue” has already been dealt with, I will point you to the comments to aid in general guidance. They hold valuable insights and epiphanies that others have had while implementing this process.

      One word of advice that cannot be stressed enough. If this process is something that you wish to include in your development workflow, just as with any other process a developer might include in their workflow, you must not make assumptions about how you believe it should work, and instead follow the tried and tested process exactly. As we disclaim in this post, deviation from the process proper could yield unexpected and undesirable results.

      All of that said, If you do have specific questions regarding specific hang ups, please let us know. We are more than happy to clarify and help resolve any new and specific issues that fellow developers have!

      Best of luck to you! We look forward to assisting with any new, specific questions you might have!

      Happy Hacking! :{)}

  17. AlBirdie says:

    Thanks Apple for making this such a royal pain in the arse.
    However, thanks A LOT kodmunki for sharing this extremely valuable information, I most definitely wouldn’t have solved this on my own. Highly appreciate your effort regarding this!

    • kodmunki™ says:

      Good day AlBirdie —

      Its great to hear that this process worked out for you! Thank you for taking the time to write a post and let us know! Our best wishes to you on this and all of your future endeavors! Best wishes and H
      appy Hacking! :{)}

  18. AlBirdie says:

    Just wondering if anyone has ever encountered the following issue;

    dyld: Library not loaded: @rpath/libswiftCore.dylib
    Referenced from: pathToLibrary.framework/Library
    Reason: no suitable image found. Did find:
    path/libswiftCore.dylib: no matching architecture in universal wrapper

    This is, obviously, for a framework containing swift code. Note that this runs perfectly fine on the device and archiving works fine as well. It is just the simulator that makes problems. The debug .framework file is getting properly referenced, which makes me wonder why this is happening.

    • AlBirdie says:

      Actually, nevermind. Cleaning and rebuilding the main project and framework solved that issue as well.

      • kodmunki™ says:

        Thank you, AlBirdie, for taking the time to let everyone know how you resolved your dyld issue! — We greatly appreciate your taking the time to write a post to close out the issue!

        Best Wishes! :{)}

    • kodmunki™ says:

      Hi again AlBirdie —

      I see that you have already made yet another post mentioning that you found a resolution to this issue. — Thanks again for checking in!

  19. […] Anyways, you can find the definitive guide as to how to create a fat binary for simulator and all iOS devices (yes, you even have to lipo different architectures in order to get a framework that works on newer and older devices): https://kodmunki.wordpress.com/2015/03/04/cocoa-touch-frameworks-for-ios8-remix/ […]

  20. SiMet says:

    There is error in script
    mkdir “${SIMULATOR_PATH}”
    cp -r “${DEVICE_BIN}” “${SIMULATOR_PATH}”

    should be cp -r “${SIMULATOR_BIN}”

    • kodmunki™ says:

      Hello SiMet!

      Thank you for your comment! Although we can assuredly say that there is most certainly no “error in script,” and, furthermore, that all items are being copied where they need to be, as evidenced by ours and others continued success in using this method (All is working VERY nicely) — We are certainly interested in hearing your case as to why you believe there is an “error in script” and why you believe that the artifact found at DEVICE_BIN would, not only, need to be copied to SIMULATOR_BIN “as well,” but actually “instead” of SIMULATOR_PATH.

      We hope that you will take time to reply with your opinions.

      Thank you, again, for taking the time to comment. We look forward to reading your thoughts.

      As always — Happy Hacking! :{)}

      • Dario says:

        I agree with SiMet on this one. If you are creating a SIMULATOR_PATH directory (_Archive/Debug) then it is reasonable to think that what you copy there is a simulator binary (i386, x86_64), but what you are doing in this script is copying the device binary in the Debug directory:
        cp -r “${DEVICE_BIN}” “${DEVICE_PATH}”
        instead of:
        cp -r “${SIMULATOR_BIN}” “${SIMULATOR_PATH}”

        this can be confirmed by running the ‘file’ command on both directories before running the last command (lipo):
        $ file _Archive/Release/Sample.framework/Sample
        _Archive/Release/Sample.framework/Sample: Mach-O universal binary with 2 architectures
        _Archive/Release/Sample.framework/Sample (for architecture armv7): Mach-O dynamically linked shared library arm
        _Archive/Release/Sample.framework/Sample (for architecture arm64): Mach-O 64-bit dynamically linked shared library
        $ file _Archive/Debug/Sample.framework/Sample
        _Archive/Debug/Sample.framework/Sample: Mach-O universal binary with 2 architectures
        _Archive/Debug/Sample.framework/Sample (for architecture armv7): Mach-O dynamically linked shared library arm
        _Archive/Debug/Sample.framework/Sample (for architecture arm64): Mach-O 64-bit dynamically linked shared library

        comparing the files yields no difference either:
        $ cmp _Archive/Debug/Sample.framework/Sample _Archive/Release/Sample.framework/Sample

        The fact that the resulting Debug/ binary is universal and includes both arm and i386 architecture is because you overwrite the binary with the one from the SIMULATOR_BIN directory in the last script step:
        lipo -create “${DEVICE_BIN}/${TARGET_NAME}” “${SIMULATOR_BIN}/${TARGET_NAME}” -output “${SARCHIVE_PATH}/${TARGET_NAME}.framework/${TARGET_NAME}”

      • kodmunki™ says:

        Good day Dario —

        Thank you for the detailed comment! This was very helpful! In effort to ensure that this process continues to work for others, we have implemented and tested a change on line 21 of the Archive Post-Action script, and have updated this post to reflect this change.

        Thanks again, best of luck to you, and happy hacking! :{)}

      • andrewcbancroft says:

        Hi kodmunki!

        First, thank you a ton for this detailed walk through. Couldn’t have built a framework without it!

        I won’t say there’s an outright error in your script because you’re right – others including yourself have had awesome success with it as it’s written. I, however, was _not_ having success with running my app with a framework in the Simulator. I kept running into infamous errors like “[class] is unavailable: cannot find Swift declaration for this class” and “Use of Unresolved Identifier”.

        The difference in making it work for me was to make the change SiMet points out in the comment above. Interestingly, I was coming back to alert you to this discovery when I saw SiMet’s comment and your response. I had come to the same “Oh no, the script has an error and kodmunki should know about this!” conclusion independently.

        I’d done my best to follow your steps exactly. I’d traced and retraced my steps.

        And then I got to analyzing the shell script you provided and as it turns out, the portion outlined by SiMet is precisely the area of the script where I scratched my head and said, “Hmm… I wonder if it’d work if I change DEVICE_BIN to SIMULATOR_BIN”. Doing so and re-copying things to my app project worked perfectly.

        Further analysis led to this discovery that I’d love for you to consider and verify if you can: It seems that when running the shell script exactly as written for a Swift framework, the i386 and x86_64 slices don’t get copied to the .swiftmodule folder. Using the SIMULATOR_BIN placeholder instead of DEVICE_BIN does include the non-ARM architectures in the .swiftmodule folder under Debug. That, of course, makes running in the simulator work perfectly.

        I wonder if your shell script does work fine for Objective-C frameworks, but has different behavior for Swift frameworks?

        Seriously – thank you (x1000) for the level of effort you put into this walk through and for all the feedback you’ve provided people in the comments. Well done! Hopefully the report of my experience with a Swift framework can help others struggling with the same issues I had.

      • kodmunki™ says:

        Hello Andrew —

        Thank you for taking the time to compose such a detailed comment! It was very informative and invoked action on our end to update both the Post-Action script and this post to reflect the change.

        We are elated that this process did work for you on your project after making an update to the post-action script, and are grateful for your taking the time to share your experiences here. I am sure that other developers will appreciate it as well!

        Best of luck to you! :{)}

  21. Lee says:

    Everything works as expected, the framework is created on achieve. However when it comes to use in libs folder xcode complains of swift compiler errors. import of the sdk is fine in example view controller but any use of the framework code fails. This is only when using the framework generated from this universal script. If the debug framework from device or simulator derived data directory is used then compilation is fine…. Any pointers ?

    • kodmunki™ says:

      Good day Lee!

      Sorry to hear that you did not obtain a working releasable Artifact on your first go! This process certainly works if implemented as described. Countless others are leveraging it and succeeding. In fact we have just received a go from Apple to release a new Sprite Kit game that we have developed that leverages numerous frameworks and dependent frameworks that are developed using this process: ku4objc_kernel, ku4objc_data, ku4objc_persistence, ku4objc_encryption, ku4objc_gameEngine, ku4objc_iosApp, and ku4objc_iap! – These are all private, internal frameworks built and maintained using the process described in this post, and, man, are they SWEET!!! :{)}

      So lets see if we can give a hand and help you get this process working on your end.

      There is a lot going on in your comment and some of it is a little vague. So, let’s see if we can drill down to the root cause. I am going to ask you a series of questions to try and gain clarity on your current state. I will mark each question(s) ordinally. It will be helpful in keeping your reply straightforward and brief if you do the same with your answers to the following questions.

      1) When you claim that “Everything works as expected, the framework is created on achieve [sic].” To which section are you referring? There are three different avenues that this post discusses: A) Creating a Framework, B) Creating a dependent Framework, C) Creating an App that leverages your Frameworks. There are slight idiosyncratic differences between them. Which one are you referencing?

      2) “…when it comes to use in libs folder…” What does this mean? Are you pulling both the Debug and Release directories from your Framework’s _Archive directory into the dependent project’s /lib directory? If not, what are you doing? If so, what do you mean by “…USE in libs folder…”?

      3) What do you mean by “…import of the sdk is fine…” Which SDK?

      4) For the process defined in this post, the compilation unit that Xcode ‘decides’ to use per build process is highly dependent upon configuration and convention. It should really be a ‘black box’ to the development workflow once implemented. If you could please elaborate on what do you mean when you say, “This is only when using the framework generated from this universal script.”?

      5) Derived Data directories should only be accessed by the Post-actions script, and again should really be a ‘black box’ to the development workflow. Did you reference this merely because you were trying to troubleshoot and found that if you pulled manually an artifact that the script was grabbing during execution that things seemed to work fine? If that was not your intention, please elaborate.

      If you could respond with answers to these questions we are happy to help! Thanks again for commenting! :{)}

  22. Hi, I’ve been following your guide (and some others) and it seems to work. But I get a strange behaviour with swift classes. I created a simple test class in my framework like this:

    public class Test{
    public class func test(){

    Now, when I use the framework in a project I am not able to refer to this class when I’ve selected simulator. It works fine while iOS device is selected. See this https://www.dropbox.com/s/7n9qbqw6du0uh52/Screenshot%202015-07-07%2019.34.33.png?dl=0 vs https://www.dropbox.com/s/ebk319vukm0i43p/Screenshot%202015-07-07%2019.34.59.png?dl=0

    Is this something you also have experienced and if so any suggestions to solve it?

    • kodmunki™ says:

      Good day Dan!

      Thanks for checking in! This is something the we have also experienced internally. We have made no real attempts to discover a solution to this issue as there has been no value driven reason for us to do so. Because of the infancy of Swift, lack of support for various common development tasks, rudimentary documentation, and specification volatility, for us, undertaking any Swift endeavors is a negative return on investment. Without a paying client or a real internal product need, short of developer “play-time” R&D, this issue will not likely see a solution shared on the kodmunki blog anytime in the immediate future.

      With that said, if you do find a solution and are interested in sharing it with the others who frequent this blog, please drop a line and a link to what you find or what you compose. If it’s a viable solution, we will certainly link to it here.

      Best of luck to you Dan on this and all of your future endeavors!

      Happy Hacking! :{)}

  23. Alaa says:

    Thank you very much for your tutorial. However, that’s sad that embedded frameworks are not supported by iOS7. Do you have please any solution ? Thank you .

    • kodmunki™ says:

      Good day Alaa!

      Embedded Frameworks do not adhere to our architecture and development standards, therefore we do not use them. — If you own them, you can always convert your Embedded Frameworks to Cocoa Touch Frameworks!

      Best of luck to you! :{)}

  24. Jeremy Bannister says:

    Hey guys,

    Thank you so much for posting this tutorial and, as I can see from the comment section, being so responsive to our issues. I followed every step perfectly (I think) and I am still unable to run in the simulator. I read in one of your responses to a comment that the debug framework is the one that’s universal and the release one is not. Does that mean that we should ignore the release framework until we are ready to submit to the app store, at which point we swap out the debug framework for the release version, archive the project, and then submit? What I have done is this:

    1) I went to project settings -> General and clicked the “+” button in embedded binaries.
    2) I navigated to the root directory of my project, into the lib folder that I created, into the Debug folder which I copied in, and then selected the framework.
    3) Doing this also automatically placed the framework in the linked frameworks section directly underneath.

    With this done I am able to run on my phone with no problem, but when I try to run in the simulator I get 41 errors. The first three lines of the error log are this:

    Undefined symbols for architecture x86_64:
    “_OBJC_METACLASS_$__TtC12JABSwiftCore18JABApplicationRoot”, referenced from:
    _OBJC_METACLASS_$__TtC5Money15ApplicationRoot in ApplicationRoot.o

    and the rest of the error messages are pretty much identical.

    I am desperate to get this over and done with. I’m ready to submit the app to the app store and, ludicrously enough, the thing thats stopping me is that I can’t get the right screenshots because I can’t run in the simulator. Thanks in advance!



    • kodmunki™ says:

      Good day Jeremy —

      Sorry to hear that you are having difficulty wrapping on your app dev. It can be quite frustrating when the light is so bright at the end of the tunnel.

      Per your description, your dev workflow does deviate a bit from ours and that described in the post. As always our suggestion is to follow the process verbatim.

      With that said, it sounds like you are only a few screenshots away from releasing your app. So, instead of trying to resolve higher level workflows, why don’t you just use your device and take the screenshots so that you can go live?! You likely already know this, but if not, you can take a screenshot on your device by pressing the power button and the home button simultaneously. This is certain to be the quickest and most pain free way to get your app live.

      You can always come back and work on fixing your dev workflow following the described process verbatim later — while you are making millions on your initial release :{)}

      Hope that this suggestion helps you get your app out the door ASAP!

      Our best to you on this and all of your future endeavors!

      Happy Hacking! :{)}

      • Jeremy Bannister says:


        Thank you for responding so quickly. Unfortunately, itunesconnect requires screen shots for every type of iPhone. I could of course take device screenshots and then stretch them to the correct dimensions for each screen size, but I don’t stand to make much money from this app, so simply getting it submitted in any way possible is not really worth it to me. The app is pretty much practice/personal use and I just happen to be submitting it to the app store as well, so this is really the time I’m choosing to fix my workflow.

        With that said:

        I realize now that in the post you say to choose the framework file which is found in the Release folder, and I said that I used the Debug one. I actually first used the Release version and when it didn’t work I read through the comments and saw that you said that the Debug version is actually the only one that works with the simulator so I tried using that one. It still didn’t work, as I described in my first comment. Is there any other difference in my procedure that you noticed? Does the error log that I pasted look at all familiar to you?

        It is important to me to get the framework working in the simulator because next month I will be giving it to my development team who will be working in the simulator and at the moment they are not able to, so if you could help me get it working I would appreciate it immensely.



      • kodmunki™ says:

        Good day Jeremy!

        Ah, yes! The iTunes Connect hurdles! — Never fun. :{)}

        So, the short answer is, the process in the post works for us, and we are sincerely sorry that it is not working as and ridiculously awesome for you as it is for us. — Followed completely and correctly, the results continue to be the same: excellent, tested, modular, sweet-ass code! We are running the code in sims and on devices, taking screens in sims and on devices, validating, deploying, maintaining … you name it. Followed exactly, this process is working wonders for us.

        Okay, so a couple of pointers based on your code:

        1) Per our inferences from your comments, your workflow deviates significantly from what is expected. /Debug and /Release should never be interacted with directly from within the IDE any further than wiring them in the Build Settings. — You should never “choose” your framework. All of this is done behind the scenes per the Build Setting configurations.

        2) You should be putting both the /Debug and /Release of your dependencies in your /lib

        3) Your error log doesn’t look familiar, but then again, it’s likely no error log would. We haven’t seen errors in the development process related to this workflow since it was created to fix the issues with Apple’s past decision to stop accepting fats.

        With the info that you have provided the best advice we can offer, based on what you have shared, and the fact that this is an investigatory project, is to create your projects following the process exactly and see where it lands you.

        On our end, we are working on video content for this blog and a walkthrough of this process is on the docket. This content is coming sometime in the very near future. Maybe this will help?!

        Until then, try following the process 1:1 and feel free to continue this conversation. Maybe with more detailed information, we can help you get to the bottom of your issue.

        Sincerest best of luck to you!

  25. Jeremy Bannister says:

    It says:

    “Navigate to the General section of your project Target and add the desired Frameworks to the “Embedded Binaries” section. Add the binaries that are found in Release!”

    But you just said to never interact directly with the framework artifacts – so what does the above sentence mean I should do? I must just be misunderstanding what it is supposed to mean. I suppose I can wait until the video is posted but I think this must be the part where I’m going wrong, so if there’s any chance that you guys could clarify this sentence I would really appreciate it!

    While I’m at it there is one more sentence that I’m unclear on – this one is in the summary paragraph of the “Creating A Framework” section and the sentence is:

    “Know that you will have to build the project with a simulator and archive with a device to get a universal.”

    What is the exact series of clicks that this describes? Do I archive first in order to create the Archive folder, then select a simulator scheme and build the framework, then select the device scheme and re-archive it? Where will I find the “universal” ?

    Thanks very much,


    P.S. I won’t bug you guys any more after this.

    • kodmunki™ says:

      Goof day Jeremy —

      There has been a small update made to the post-action script which may resolve your issues if you are leveraging Swift. We have tested this change in a Swift project and it is working as expected, for both us, and apparently others.

      Hope this helps. Best of luck to you! :{)}

  26. dinesh says:

    I am creating a cocoa touch framework (HTTPLoggingKit) which includes a third party framework and some system frameworks.

    I created a sample app is same workspace and link the debug version inside _Archive to this app under Embedded Binaries section. This sample app also uses the same third party framework.

    Now everything is fine but when I run the app I am getting some logs for the files that are part of the third party framework included by both the sample app and cocoa touch framework.

    TTFileManager is a class inside third party framework.

    objc[6887]: Class TTFileManager is implemented in both /Users/abc/Library/Developer/CoreSimulator/Devices/80B126A9-D516-456B-9289-8497A803494C/data/Containers/Bundle/Application/5BCE6196-FE81-4A13-AE8B-3BA06815E0D0/UsingCHLKit.app/Frameworks/HTTPLoggingKit.framework/HTTPLoggingKit


    /Users/abc/Library/Developer/CoreSimulator/Devices/80B126A9-D516-456B-9289-8497A803494C/data/Containers/Bundle/Application/5BCE6196-FE81-4A13-AE8B-3BA06815E0D0/UsingCHLKit.app/UsingCHLKit. One of the two will be used. Which one is undefined.

    I am getting such logs for every single file which is part of this third party framework. Some system frameworks also common between the sample app and cocoa touch framework but I don’t see any logs for their classes.

    I think that this has nothing todo with the process that you described in your article.
    I am just asking for you help on this.

    I don’t wanna include this third party framework in my cocoa touch framework instead I want the cocoa touch framework to get the reference of this third party framework from the target app. How can I do this?

    Any help is appreciated.

    • kodmunki™ says:

      Good day dinesh —

      It looks to me like you are encountering issues due to poor dependency management. The root cause of which you have not yet identified, or have neglected to reveal here.

      You are correct that this is certainly the wrong thread to discuss this issue(s), but in effort to at least offer you a lead, might I suggest you research dependency management, dependency direction, and curricular dependencies.

      Hope this helps. Good luck! :{)}

  27. Amit Dhawan says:


    Im using xcode 7 and followed the above steps to build the framework and use inmy sample app.
    But i face the error “xxx.Framework/xxx.framework.h” file not found when i import the framework in my sample app file.
    Please suggest any solution.

    • kodmunki™ says:

      Good day Amit —

      Please see the updated process for iOS 9, and report back.


      Thank you!

      • Amit Dhawan says:


        I was able to resolve the issues.Thanks for the help.

        Please resolve my queries below:-

        As said in above comments “Debug” has the universal framework and “Release” has the framework supported for devices.Correct me if im wrong.

        1 ) Now when I import that framework in my sample app and use “Debug” scheme in my app and submit the app to app store.Will this pass the itunes submission process.As per my knowledge it will not as the “Debug” scheme will pick up the Debug version of the framework used in the sample app.Please clarify?

        2) Also if i select the “Release” scheme in my app and submit the app to app store, I suppose the app will be uploaded to app store as the framework used will be the “Release” version that is built for devices.Correct me if im wrong?


      • kodmunki™ says:

        Good day Amit —

        There is a lot here. Let’s see if we can break it down:

        * You are correct Debug will contain a “universal” fat binary and Release will only run on devices.

        * It sounds like your workflow may include steps that ours does not. Namely, scheme selection. There is no scheme selection in our workflow. We simply follow the instructions in the post. In fact, whenever we create a new framework, we actually open the blog and follow the steps verbatim. Then, because of the various items these instructions describe, e.g. Build Settings or run scripts, we can simply develop. There is no scheme switching or other additional steps outside of those described in the post. We follow the steps and then just develop: write unit tests that define acceptance criteria, write classes that satisfy these criteria, build in simulator, build in device, run functional tests, execute code reviews, tune, validate, submit for review.

        To your question: “Correct me if im [sic] wrong?” It is difficult to say if you are “wrong” as this assumes you even could be wrong and that there is a converse, ‘not wrong’. I don’t know that these judgement qualifiers can be used in this line of inquiry. With all of that said, let me see if I can offer something of value.

        1. In our experience, Apple has not been accepting “universal” fat binaries as submissions for review and release. So when you say, “Will this pass the itunes submission process.” I cannot say for sure. You can certainly try to pass a fat. What I can say is that we have not been able to successfully submit fat binaries for quite some time now. Hence, this process. So, if your situation does not differ from ours, no, you will not be able to submit a fat for review.

        2. In our experience the Release version of a given Framework binary is the only version that will pass validation. But, again, there is no “…select the ‘Release'” in our workflow. We simply Archive the application for submission. There are no further steps outside of what is described in the post.

        I hope that this adds clarity for you and any others that might read it. It’s excellent to hear that you resolved your issue! Our sincerest best wishes to you on this and your future endeavors.

        Happy Hacking! :{)}

  28. Amit Dhawan says:

    Thanks for clearing the doubts.
    keep up the good work.

    Also i have noted that if i skip the build step for simulator and strainght away do the archive then also the _archive folder is created with the Debug and release version of the frameworks.
    Any idea?

    • kodmunki™ says:

      Good day Amit —

      Any time you can successfully remove steps or otherwise improve or optimize a process, we encourage you to do so. Inspection of the compiled binaries has shown us that we cannot. As we state in the original post, we cannot support any deviation from the process that we are using and have shared here. Though, your experimentation and sharing of your results in this and all R&D is highly encouraged.

      Thanks for your comments! :{)}

  29. Ricardo Silva says:

    When i try to create the framework i only get the Debug folder, not the Release one.
    Do you have any idea about what could be causing it?

  30. kanna says:

    In “Creating Dependent Frameworks” I am not able to understand 3rd and 4th step.

    3. Add a /lib directory to your Framework that will contain all of your project’s custom Frameworks, i.e. kernel if this is data. (Fig. 5)
    4. Put the desired Framework artifacts in this directory. When done correctly, the /lib directory will contain a /Debug and a /Release directory each containing your binary dependencies. (Fig. 5)

    I dragged my required framework into my FrameworkFolder(directory).I have added the remaining inbuilt FrameWorks in Xcode “Build Settings of my project target”
    but I couldn’t find debug and release please help me out.

Enjoy the read? -- Let us know.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

kodmunki™ Tweets

Enter your email address and receive notifications of new kodmunki™ posts by email.

%d bloggers like this: