Xcode keep using old framework version

Question

From the beginning of my project, I use a custom framework, let's call it "custom.framework". But there was a bug in this framework and now I want to use another version of the "custom.framework".

At first, I simply removed the "custom.framework" file from my project and added the new one. But nothing changed, the bug was still there.

After multiple tries and hours, I understood that Xcode add the old version in memory and used this one instead of the new version. I know it because in the new version I added a method and when I cmd+click the class I've add the method into, it's not there and the file's path is unavailable.

Searching through the web, I tried to change some version parameters to my framework projects: Compatibility version, Curent Library version, Framework version. But this didn't change anything to Xcode which keeps using the old version.

I also tried to make the framework's project as a sub-project and add resulting framework as a dependency to my target. It worked well, but as the framework's project is on a separated remote git repository, I don't think this is an acceptable solution.

So my last try was to build a "custom2.framework", to force Xcode to use the real file and not some cached version. But again, it doesn't work and when building I get errors telling me that all my classes in custom2.framework are duplicated symbols of its cached version of "custom.framework".

So my question is simple: how can I finally tell Xcode to deleted its cached old version and let me use the file I gave him? I already tried to delete my project's derivedData but it seems cached frameworks aren't there.... I'm so desperate :(

Edit: Here are 2 screenshots to illustrate the issue

First screenshot is the path as shown by Xcode when I opened the file from the .framework object in the project navigator.

Second screenshot is the path as shown by Xcode when I opened the file from a cmd+click to a "DCEquipmentManager" in code.

As you can see, the framework linked with the code is not the framework in the project.

Hogtie

Click on Product, Press alt button. Click on "Clean build folder". – Galina

It doesn't change anything. – Hogtie

I think you need to make sure your new version has its versioning set so that it replaces the original. See #6615994 – Amateurish

Have you tried going to Projects->Derived Data and deleting the derived data before cleaning the product? – Lympho

@RoryMcKinnel that's what I did. The old framework have its Compatibility version and Curent Library version set to 1 and Framework version to A. The new framework is 3 and B. – Hogtie

@angelaCartegena I already tried that too. – Hogtie

Any chance you have a version of the library with no version info. e.g. libMyLibrary.dylib. Sometimes this is created with a symbilic link or link to the version that should be linked in. I think the linker will pick this first, then move on to using the latest version. I would do a search for your library and see if this exists and you may want to remove it if it does and is a copy of your original or a link to the original? Might be worth looking at your link line executed in the build as well to see the link command. You can look at this using the project navigator in the builds tab. – Amateurish

Ok, when you "removed the old and added the new" how did you do this? Did you remove reference or move to trash? Some questions: 1. if you delete it all together, will Xcode complain and stop building? 2. Did you check in finder to see if the framework was deleted? – Boise

@jay: i always move to trash when replacing. If I delete the .framework it complains because symbols can not be found. – Hogtie

You said it worked if you used a subproject, right? But the concern was that the source was an external repository? In that case could you clone the remote repository locally so you would have the source yourself and not need to worry about it being hosted remotely, then just proceed with it as a subproject? Or, once you build the framework yourself and add it as a dependency, does it work if you then take that framework version you built yourself, and add it in the normal way as a framework (not subproject)? – Seasonseasonable

Or alternatively, is it possible that your FRAMEWORK_SEARCH_PATHS are pointing to the old framework (or possibly both still)? – Seasonseasonable

Answer 1

it seems problem with binding in new framework, your project still linked with old framework files. try to remove all files and folder related to your "custom.framework and also remove path for that framework from project setting--> build setting --> search Path

Then after Drag and Drop Your "custom.framework" files in project.

it works for me.hope it resolve your problem.

Toddtoddie

the runpath searchPath is $(inherited) @executable_path/Frameworks – Hogtie

Ok, found some absolute path to an old version of this framework in "Framework path" build setting. I don't know why it was tehre but whatever, now it's fixed, ty :p – Hogtie

It seems that when you add a framework, whatever path it is in gets automatically added to "Framework Search Paths" in Build Settings. You have to remove that path manually to stop it finding the old framework. – Sheng

Answer 2

Please try to clear derrived data: Window -> Organizer at the right side you will see projects list. Find your project and tap on it. I the top part of window you will see button delete in front of Derrived data, tap on it.

I guess it will solve your problem.

Dew

As said in my original question and in its comments, I already did that and nothing changed. – Hogtie

Answer 3

It might sound silly, but sometimes restarting XCode or the whole machine fix things.

Did you remove the old framework from Build Phases --> Link Binary With Libraries?

Babysitter

Answer 4

Use Clean Build Folder: option-shift-command-K, or select it from the Product menu when holding down the alt/option key.

Pierette

Answer 5

First lets say something upfront. The build stage is a(are) command line tool(s) that is managed by Xcode according to your Build Settings.

So when Xcode doesn't find your Framework - the Build System will usually also not find it. This forces you to act but may end up in confused Xcode to catch an older reference.

Yes it may happen that the Header Xcode is pointing to is correct but the build system still uses an old copy somewhere. An outdated copy can dangle around literally anywhere depending on the steps you took before.

It (Xcode) assumes where it is located but the Build System still uses another version or the Search Paths just pointing in the wrong Locations even if they are visible to you and even your Framework icons are visible in the lists. So when you erase the last build you actually only force Xcode to rebuild from the known arguments, the settings stay the same, the lists stay the same. Even restarting Xcode does not change anything, the problem persists.

Ergo: Compiler Instructions, Xcode settings and Build System settings don't match what the code tells with #import <NAME/Name.h>

So you will check at least those 6 stages again:

1. Is your Framework Header File published in your Framework project?

2. are Build Settings really pointing to the right Framework Search Paths or System Framework Search Paths?

3. Is your Framework in linking list?

4. Is your Framework in Embed Framework list?

5. Does your framework appear in the Framework Group Folder in Workspace/Project Browser? (usually the very last Group Folder in the Browser below all your other files)

6. Is my Folder Structure correct?

At least 1 to 4 must be right otherwise it will fail.

Here a random list of common causes

• Framework is located outside your Source Paths structure
• Structure got changed after you added it to the project
• You use Workspace's where Framework development and Final Application can appear side by side but you assume Xcode uses this to change its Search Paths
• The contained build settings are misleading from former drag and drop operations, ending up tricking Xcode in the "wrong" corner. In this case recreating a project is just one of the possible ways to fix it but not the solution.
• Also dragging a Framework into your Project > General or separated in Build Phases > Link Binary list or Embed Framework lists does not make Xcode aware of the wrong Build Settings.

The Linking works, embedding works, but compiling does not. The Header information is still missing.

The solution must be to correct your Build Settings.

As mentioned above Build System and Xcode are two different things. In particular only setting the right Framework Search Paths will solve those issues, even if you managed to kick your derived data manually.

Erasing Derived data?

Derived data is the place where precompiler collects data to compile. So it can be seen as expression of what all the settings are told to do. Erasing it does of course not change the settings but may fix inconsistencies related to former Build Settings. It would erase the derived data and rebuild from the Build System Settings you gave.

Correcting Linking?

Also Linking is not the same as making Xcode aware of the desired Headers. Linking is for your final Product to know where Symbols are to call on them at runtime, it does not change Framework Search Paths and System Framework Search Paths, they stay the same as given.

But it is not wrong to start fixing first with Product > Clean Build Folder, it forces your build to parse all and compile all again on the next Build.

When the troubles come up because of folder structure in parallel or Frameworks are simply placed outside the Source Directory then you must point to them directly or relative.

Most likely you should place one extra entry in your Framework Search Paths like $(SRCROOT)/../Yourframeworksource/build/Debug. expression to point to relative higher folder structure.

Needless to say that a Release Build likely needs another entry ending in "/Release".
Hint: Well you can have different Search Paths for different Compile Schemes..

This works particular good after you cleaned Linking List, Embed Frameworks List and then also check the very last Group Folder "Frameworks" for double entries to drag and drop a fresh Framework reference in there.

How to know if leading /../ will fix it?

Click on the dropped Framework Icon inside the workspace Framework Group Folder (lower most) while your Project is the active selected to work on, now watch for the relative Path information on the very upper right side of Xcode, if there is some /../ you know you need it as well.

Sorting of Framework Search Paths

play a role of course, just the same as #import/#include rule sorting matters. Remember the first found, first wins rule because often we use #import that works different then #include but ignores second attempts to declare. This leads to once wrongfully declared headers to hide corrected declarations later on in parsing that share the same filename or define rules

#ifndef xyz
#define xyz
// all your code here.
// a second read attempt would be ignored
// a second read is hidden also when you use #include then.
#endif

So you can sort those entries either by code and/or in the build settings if needed because of course it matters what is declared before other declarations depend on it.

Vacant

yes answer on a closed case 7y later.. it may help others who came here from google – Vacant

Answer 6

I had this issue too: I had dragged a .framework from the Project Navigator into "Frameworks, Libraries, and Embedded Content", and Xcode for some reason moved the .framework to my Project's root directory. When I built a new version of the framework, it was built to my original location, while Xcode was using the old framework in root.

I found out that Xcode will leave the .framework in place if it's located in a group folder, and mov it if it's in a folder reference. Go figure...

You can check the location of the .framework Xcode uses by right-clicking on the entry in "Frameworks, Libraries, and Embedded Content".

Murtha