Re-add the xcdatamodel to the Build Settings - ios

While I was busy trying out stuff for this question, I accidently removed the xcdatamodel-package.
I found out that recently there was this question which mentioned the following:
For some reason, the xdatamodel was removed from the build settings. I added it back in and it worked.
I tried doing what he did, but I don't know where to start.
I recreated the package, but when I try to set an attribute value, I get +entityForName: could not locate an entity named 'EN'...
All I know is; it did work until I started fooling around with not-tutorial-attributes and stuff.

What they're getting at in that other question is that when you add a file to a project, it's not necessarily added to the current target. You can have multiple targets in a project, and you can add files that don't get compiled (e.g. developer documentation), so it's possible to add a file but then have it just sit there and not get built.
If you select the file in Xcode and open up the Utilities pane on the right, there's a section that shows target membership. It looks like this:
This one shows that the file belongs to the project momdecTests but not to the project momdec. Make sure your app target is checked here.

Related

XCode "No such file or directory" error after project name change

I'm building my first iOS app in xcode. I have a pretty simple app currently set up, and it was building correctly with no issues. Then I wanted to check how easy it would be to update the project name, since we are currently working with a placeholder project name.
I'm pretty sure that this is where I messed the project up, unless I'm forgetting something. I updated the "Display Name" under general settings for the project, and ever since that I get four different compilation errors about no such file or directory being found.
Here's one of them, the rest all have very similar file paths:
error: /Users/laika/Library/Developer/Xcode/DerivedData/myapp-ios-ctnppilmitfbrnfexnoxivnafaey/Build/Intermediates.noindex/myapp-ios.build/Debug-iphonesimulator/myapp-ios.build/Objects-normal/x86_64/myapp-Swift.h: No such file or directory (in target 'myapp-ios' from project 'myapp-ios')
None of the files are any of the files I've coded it's just these debug-iphonsimulator files, and none of them are referenced in any of the code I wrote.
I changed the display name back to what it was before these issues started popping up, but I still get these missing file issues! I don't know where to update these filepaths, and even if I did know where, I don't know what I should update them TO. Does anyone have any guidance?
Thank you!

Is there any better way to rename an XCode project than the given one?

The given version is described here: How do I rename a project in Xcode 5?
But, as you can see from the following screenshot^, not everything gets renamed, and if one opens package contents, directory names etc. to try to manually change all the references, the project is broken afterwards, so you have to keep the old project name for sub directories etc., which granted is not a massive problem, but is intensely irritating, and I'm not enjoying being intensely irritated at work.
^ apologies for a screenshot, but there's too much information in it to transcribe to written text. Top two-thirds of screenshot is XCode project, bottom third a Finder window.
Renaming projects in xcode in one of the most annoying things in iOS development. I assume you want to rename your app. I faced this problem once and figured out a simple, clean way to do it.
Go back to the point where everything worked.
Open project in xcode and click on the project icon in the project structure( first file)
Go to the info tab
Search for Bundle Name. Most probably it will automatically be set to $(PRODUCT_NAME) which is a shell variable that will set your app name the same as the project name.
Set it to whatever you want your app name to be
Done
Notes :
If you use custom URL Schemes this might produce an error when redirecting.
ALWAYS git or some other SVN in your projects. This will come in handy in this kind of situations

Xcode keep using old framework version

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.
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.
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.
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?
Use Clean Build Folder: option-shift-command-K, or select it from the Product menu when holding down the alt/option key.
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:
Is your Framework Header File published in your Framework project?
are Build Settings really pointing to the right Framework Search Paths or System Framework Search Paths?
Is your Framework in linking list?
Is your Framework in Embed Framework list?
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)
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.

DropboxSDK.framework file not found after relaunching Xcode

I am using the DropboxSDK.framework in a project of mine.
I have everything setup and working fine. However, every time I quite Xcode and open it again at a later point I get the error below:
Which is weird because I can see that the framework is in the project and nothing (that I know of) has changed since the last time I had the project open and working.
The way I make the error go away is to:
Right click on the DropboxSDK.framework in my project --> Delete --> Remove Reference.
In my project's Build Settings under Search Paths I remove the path that is under Framework Search Paths (the highlighted selection in the image below).
Then I clean my project SHIFT + CMD + K
Lastly, I click File --> Add files to my project, navigate to the DropboxSDK.framework file which I previously removed reference to and add it back to my project.
Then I build my project again and the error goes away and will remain gone until I quite Xcode and open it again.
Has anyone else ever encountered this happening and fixed it?
Or have any suggestions I could try to fix it? I'm using Xcode V5.1.1
Let me know if there's anything I can clarify. Thank you!
$(SRCROOT)/Application_Folder
Application_Folder is the name of the folder where your whole code other resources resides
Insert above line in Header Search Paths
I had a random thought sparked by Indrajeet's answer that solved my problem.
When a new project is created in Xcode a project folder is created. In that folder there is another folder with the same name as your project, a .xcodeproj file with your project's name and a yourProjectNameTests folder.
Visually like this.
Application_Name --> Application_Name
Application_Name.xcodeproj
Application_NameTests
When I was having the error I described above the DropboxSDK.framework and it's accompanying files were stored here in this folder:
After removing all references to the DropboxSDK.framework in my project I decided to move the DropboxSDK.framwork and it's accompanying files one folder level up to the main Application_Name folder here:
Once I did this, I clicked File --> Add files to my project, navigated to the DropboxSDK.framework file, now one folder level up and added it to my project.
After building no error was thrown. I restarted Xcode and tried again to make sure; still no error. Rebooted my computer to be truly sure... still no error!
I was having the sane problem and just found the answer by chance!
It happens when you create your project name with SPACES between the letters. Somehow it makes XCode crazy when searching for the frameworks.
So if want to create a project called "This is My Project Name", call it "This_is_My_Project_Name" and the frameworks will be found every time. It worked with me.

Loading a different plist depending on the target

I thought it would be interesting to attempt building multiple apps using the same code base, where the only differentiating data is held in a few plists. For example, one plist holds some theme info - a few key/values to drive the color scheme used in the app. I'll call the original version of this theme.plist.
I soon learned that I should create multiple targets in my project, and have been able to add these successfully. Each one, via it's own appname-info.plist, has a different name and bundle id - it's neat seeing all three on my home screen without any real extra work.
But right now they are all identical. I haven't figured out how to use a different set of data for each one.
My first thought was to have some folder for each target - each with its own theme plist named theme.plist - and somehow distribute each target with a different folder. But researching that idea doesn't get me much google juice.
So what about multiple theme files? Ok, so far that looks better - I can create an app1-theme.plist and 'app2-theme.plist' with different values for the same keys in each. And Xcode even lets me use some flags to say which targets should include each resource.
But I don't know how to load the appropriate plist at runtime. I need to examine something (the bundle ID?) and then assign the appropriate name of the theme plist to something (what)?
It seems like this might have something to with #ifdef, whatever that might be...?
Can someone explain how I should be looking to accomplish this? Am I on the right track? I'm happy to put some reading time in but I don't even know what to look up yet.
You are just about there. Xcode supports having multiple files with the same name in a project, one way you can do this by storing them in different folders within your project folder.
Unfortunately at this point Xcode won't give you a lot of help, so open your project in the Finder, create one subfolder for each of your apps, in those folders place a copy of the plist. Now add each copy in turn to your project, making sure you add each to just one of your targets.
You might want to create a group in Xcode called, say, "Theme files", to keep them altogether.
HTH
What you are trying to do is trivial. If you select a file from your project, and bring up the "File Inspector" in the utilities area (Press Command option 1) you should see a section "Target membership". Each target in your project will be listed, with a checkbox next to it. If you check the checkbox for a file and target, that file is built into that target. Un-check the checkbox for a file and target and that file is not copied over to the specified target (you may need to run a clean, and delete the app from the target device, to get rid of files that used to be included but that you have un-checked. Xcode generally won't automatically remove things that used to be included.
You could create a directory in your bundle and teach your app to scan that directory for plist files. Then include a different set of files in that directory for each target and each target app's behavior will change.

Resources