I have an Xcode Project I'm working with for a client. The project has around 78 targets in order to facilitate a main app and a split-off of around 77 "sub-apps" that display varying information from a web server (using the main app as a kind of template).
Also, this isn't exactly a small app. There are around 70-80 classes, 5 storyboards and probably 30-40 different screens.
I'm having a problem with Xcode seriously bogging down. There are two problem areas:
Indexing takes forever. Xcode is indexing each and every single target separately.
In Storyboard: Refresh all Views takes around 30 minutes as Xcode builds each target separately before it actually gets around to refreshing the storyboard's views... and I have to do this 5 times, once for each storyboard.
What I need is a way to prevent Xcode from indexing anything except the "Main" target. Likewise the Refresh all Views option.
Any ideas? Is there perhaps a better way to structure the project?
This is a possible answer. I'm not entirely sure yet how well it's going to work in the long run. Note: I use cocoa pods, so I've gotta deal with a workspace, which in the end may cause me the most problems.
I copied both my .xcworkspace and xcodeproj files and renamed them.
In the copied workspace file, I removed the main Xcode project and inserted the copied project.
In the copied project, I removed the main, test and documentation targets mostly to avoid confusion. The only targets left are the 77.
In the main workspace, I removed all 77 of the 'sub-app' targets. It took about Xcode 20 minutes to do this. Seriously comical.
I will do all of my development in the main workspace. In the copied workspace I will only build the sub-apps as needed.
One downside is that I'll need to add any new files to both projects, but I don't think this will be too onerous.
Probably the biggest problem will be when I need to add/update a cocoa pod. I'll cross that bridge when I get there.
Related
I've built a couple dozen projects in Xcode and only one of them experiences this strange issue.
Every time I load Xcode to resume work on the project, Xcode auto-loads the project (good) but in an unusable state (bad). It appears this way:
The project name is grayed out, with no disclosure triangle. I cannot access any of its contents, and trying to build it fails immediately with no error message other than "Build Word Practice: Failed" as you see in the screenshot.
But if I close the project and reload it, it functions fine. The only oddity about when it loads this way is that it appears with all its disclosure triangles closed, and I have to manually "disclose" the contents of all the folders in the list each time:
I have had this issue with all recent versions of Xcode, up to and including the current version, 11.5.
The project does not use any features that are not present in other similar projects I've written that behave fine. So it would seem to be a matter of corruption… but besides deleting derived data and doing a clean build (which I've done), I can't think of any other steps to take.
I would include code here, but short of including the whole project (and I doubt that would help), I wouldn't know what to include.
Any ideas?
I am currently working on a game (Mac, Objective-C) that uses prerecorded cutscenes. All the mp4-videofiles are really big. In total I have 86 video files that are 3.77 GB all together. Whenever I build the app it takes well over 15 minutes. Way too long if you are working on just one line of code and you need to test it.
For testing purposes I always deleted the files from the 'Copy Bundle Resources' so that the files would still be in my Xcode project but not in my app. I only included the files that I needed at that moment (so from 3.77 GB to ±100 MB of files). When I built the app then, it was only 40 seconds or so. This has always worked out fine.
However, this week Xcode started acting strange. Even if I removed all of the files in the Copy Bundle Resources all the video files would still be in my application. This means that every time I have to correct a mistake I made, I have to wait 15+ minutes.
After being frustrated for a while I started to remove the files manually (I clicked on Delete -> Move To Trash). So now all the files are removed from the Copy Bundle Resources and out of my Xcode project. But still Xcode includes them in my application if I build it. How?!
So, a long story short, Xcode does not remove files out of my application. The files aren't even in my project anymore but still Xcode finds a way to include them in my application. Does anyone know why/how Xcode does this? Any suggestions/solutions?
I gave up trying to look for answers and I just deleted the build and made a clean one. Right click on the YourApplication.app > Show In Finder > and delete it from there. Then build the app again and it will only contain the files you selected.
I'm using XCtest with XCode 6.3 to test an app of mine. I've noticed that it seems to be saving a ton of data to my /private/vars/folders/rx/ folder. If I delete my app's Derived Data these XCTest folders don't get deleted, and if I restart my computer it's still there too. Is this data safe to delete or do I need it?
I used DaisyDisk (awesome program by the way!) to take a look at my computer's memory and I see this:
So I thought I'd take a look at what was in each of these folders. When I looked, it seemed like XCTest was the culprit.
When running my tests I include a large bundle of jpgs that is around 1.7 GB. I'm working on streamlining my app testing so that I don't need the large bundle, but I'm still curious if I can safely delete some of these older folders.
Yes, they are safe to delete. This is where Xcode stores built copies of your applications when built in "Unit Test" mode. Just as Xcode has a Derived Data folder for building OS X apps, it has another location for storing XCTest data (storing this data in the Derived Data folder wouldn't be appropriate, since that is used to store built copies of the application intended to be run by the user).
You should note, though, that Xcode will probably put the data back there again the next time you try to run your app's unit tests, and it may take longer to build/run since some of the cached data is gone. It's up to you whether the trade-off is worth it.
And by the way, Xcode builds your entire project to run XCTest, because your tests might depend on certain resources being there in your app bundle. So that's why the folder is so large.
I'm having an annoying issue with Xcode 5 and the shared schemes.
In my team (we're just two, but hey! it's still a team) we're sharing some Schemes to run the app with different configurations (Debug, QA, Release, ...)
Well now Xcode 5 seems to change the BlueprintIdentifier setting of each scheme based, from what I can understand, on the machine of the developer. And of course the change get's noticed bit git and we either have to checkout them, or commit. Both solution don't make sense...
Any idea on how to fix it? I did a google search but found nothing for Xcode 5...
I don't want to give up on those shared configurations! A solution I can came up with to keep having the shared Schemes tracked is unshared them, copy them in a dedicated test folder, then using a strategy like the one used for the Pods to copy those schemes locally, where Xcode can mess up with them without us noticing. Something like a schemes script that reads a Schemefile file which lists the schemes to copy from the Schemes/ folder, and a Schemefile.lock that is updated every time there's some change and that is read by the Xcode build process in order to make sure everything is up-to-date.
This seems a lot of work for such a tiny thing, so before jumping head down into it I would like to know if anyone has some better solution to propose.
Cheers :)
First, I'm assuming you're using CocoaPods because you mentioned it in your question.
I've had this issue for a while and just recently discovered that some of my shared schemes are not getting their BlueprintIdentifier changed with the others. Upon investigation, I noticed that the untouched schemes had a Pods target under builds that was missing–as in it was listed in red like this: Pods (missing). My theory is that pod install and various Xcode events (i.e. crashing, launching, etc) were causing the scheme to change its BlueprintIdentifiers because they had a reference to a Pod target in the scheme build settings.
I removed the Pods reference in all of my schemes and have not been able to reproduce the BlueprintIdentifierchange since. My target that depends on Pods has libPods.a specified under Link Binary With Libraries in Build Phases and set to required, so it still gets compiled before the main target.
Note that switching between branches with this change and without this change might still produce modifications to the scheme files.
#Wes's answer didn't specifically fix this issue for me, but it did lead me to the right place. The solution for me was to turn "Find Implicit Dependencies" from "off" (unchecked) to "on" (checked) from the Edit Scheme screen for the Scheme that keeps changing.
In reference to Problems adding Projects to Workspace in Xcode 4, has anyone found a way of including the same project in several workspaces and having them open in Xcode 4 simultaneously?
For example, I have a project which builds a static library. I want to include that project in a workspace with a Mac app project, and in a workspace with an iOS app project.
It's a known limitation of the current Xcode 4 that it cannot reference the same project several times simultaneously in different workspaces. This has been reported, and Apple knows about it. However, it is not clear whether this is going to be fixed. The only way to increase the likelihood of Apple fixing it is for you to file a bug report.
One way to work around the limitation is to work as if Xcode couldn't open more than one workspace at a time. So for each of your workflow scenario, you simply create one workspace that contains all the projects you might be lead to work on in this scenario.
This leads to unnecessary workspace multiplication, but after all, this is not a big deal.
More critically, that's yet another case where Xcode 4 works hard to prevent the user from adopting a multi-window work style. I encourage you to file a bug report for this too, as feedback from WWDC indicates that Apple didn't find complaints about that loud enough to fix it.