I have an iOS project with 5600 files in the source code repository. Xcode appears to visit all of those files during its indexing. Some of the files are large images that I can see no benefit to indexing. How can I tell Xcode to exclude those files so that indexing will go faster?
I'm aware of several other questions and answers that describe how to disable indexing entirely, but I didn't find any that address how to keep indexing enabled and tell Xcode how to skip irrelevant files.
One roundabout approach: Create one or more separate targets, and simply link to the object file(s) they produce.
justin's answer is good if you really need to create one or more separate targets. And I've searched but find you can enable/disable the indexing. I've not find anyway to exclude some kind of file when indexing. And you don't let Xcode index, you will lose some feature like autocomplete(Even for images, you can see the image name autocomplete in InterfaceBuilder).
If you are really sure you want to disable indexing. Use this in terminal:
defaults write com.apple.dt.XCode IDEIndexDisable 1
When you want indexing back:
defaults delete com.apple.dt.XCode IDEIndexEnable
defaults write com.apple.dt.XCode IDEIndexDisable 1
Another related article on How to make Xcode faster by solving Xcode slow issues with xcode 4.x
Related
I am trying to copy over my Xcode project from one computer to another but it seems to lose frameworks and the locations for the images although i copied those too.
PS I am using xcode and coding an app with a friend. Is there a useful source that can help us both code at once/ transfer code files.
Thanks for the help.
Try transferring everything from plists to the storyboard. I did this with a friend of mine and it only took about 20 minutes for the code to build and run successfully on his own laptop. the biggest issue is going to be transferring the files that Xcode is going to have to search for, and making sure that the search paths match with where you save the new files.
SDK's and images are difficult because of this path issue - make sure you find where the pictures are supposed to be searched for then add the images there.
Just take your time - even write down where each file should go or where you have put it and you should get it working. Best of luck!
You have to select relative paths in your project for your resources/frameworks (e.g. Relative to group). If you have absolute paths, it won't work on a different computer. Also check in the Build Settings of your target the Framework, Library and Header search paths.
After iPhone app that I'm writing in Swift become quite big (> 150 .swift files + various Objective-C libs), Xcode start behave pretty badly:
every second compilation I get various errors, e.g.:
Command failed due to signal: Segmentation fault: 11
compilation take enormous amount of time (> 2 min on MacBook Pro Retina)
and so on.
I just wonder if everyone has same problems and maybe someone found a way to reduce this nightmare?
What I have done so far — I split project into several dynamic frameworks that I link from main project, it helps to reduce compile time, but introduce some new problems.
I also use iRamDisk to keep DerivedData folder in RAM and periodically delete all files from it, it sometimes helps with SourceKit crashes.
Swift toolchain is still a bit gross, you'll need to use some temporary workarounds until Apple fixes it (see UPDATES below)
Here is a list of items that you can do to keep yourself from going crazy.
Slowness caused by immature Swift compiler
Change your development workflow using Injection for Xcode. Once you installed the plugin, you'll be able to inject code changes in your simulator\device without recompiling. You don't need to hardcode\modify anything in your project. We started using it recently at work and it made a huge impact on our side, even if it doesn't apply to every use case (for example you can't create new functions, you can only modify the existing ones).
Some particular code constructs that the compiler doesn't like and takes too much time to compile. The most common problem is with the Type Checker that slows down compile time exponentially based on how many type checks it needs to do (read more here for practical examples and here for a detailed explanation). In order to identify if you are suffering from this problem you can follow this blog post, you will gather information about the functions that creates slowness by using some compiler additional flags. Alternatively you can use this Xcode plugin to identify the source of the build slowness.
Use dynamic frameworks wisely, where it makes sense. A framework recompilation will be done only when you modify one of its Swift files (dynamic frameworks are only available for iOS >= 7).
Condense code in the same files. Lowering the number of Swift files speeds up the compile process sensibly. You can easily achieve it enabling "Whole module optimization" by adding a user-defined custom flag SWIFT_WHOLE_MODULE_OPTIMIZATION and set it to YES and at the same time set optimization level to none (to disable optimizations that would make it slow) OUTDATED You may consider to use this gist, it's a build script that collapses all your code in a "merge.swift" file.
You'll need to create a new target for it, but it is worth a
try.
Double check things listed here (there are a few some more misc reasons because the compilation is slow)
OUTDATED Try the approach described in this blog post, it involves creating a build script that generates a make file. It requires manual intervention on the build script (it contains the list of swift files).
OUTDATED Try this hacked up incremental compilation technique
UPDATE: Incremental builds introduced on Swift 1.2 (Xcode 6.3)
Apple finally introduced incremental builds with Swift 1.2 (shipped with Xcode 6.3). It's not still perfect, but it's a huge improvement.
From now on a class is recompiled only when it is changed (or when one of the class it depends on has been changed).
However the compiler still can’t understand if the changes to a class are to its interface or not. So any kind of change to a class causes a recompilation of that class and all of its dependencies.
UPDATE: Recompile dependent classes only when public interface changes introduced on Swift 2.1 (Xcode 7.1)
Starting from Swift 2.1 (Xcode 7.1), the dependent classes are recompiled only when you change the public interface of a class, and not at every change. This makes an huge difference in particular for big projects.
Project (mis)configuration (not related to Swift)
Be sure that "Build Active Architecture Only" is YES for debug.
Be sure that you didn't add pre\post compilation scripts that take too much time.
Apple has some advices for speeding up your Xcode build in Technical Note 2190. Have you thought about creating and precompiling an own framework for outsourcing unchanged Swift modules or some/all Objective-C code?
Remove all type inferences in Swift.
This SO topic has some nice ideas and this blog post suggest to
stop generating dSYM bundles and
avoid compiling with -O4 if using Clang.
Although lots of these improvements are related to Objective-C, I am quite sure, that some of them are still relevant for Swift.
The (re)compiling is a known issue that I am sure will be resolved soon. Some recommendations:
Use Objective C where possible - it compiles fast even if it is a part of a Swift project
Split code to frameworks
Specify types instead of leaving it up to the compiler to infer them
Again, there is a good chance that this will be fixed soon, so perhaps it is best not to make big investments in rewriting or reorganizing the code at this point in time.
you could try:
upgrading the amount of RAM in your computer
if you have multiple .swift files that do things on the same view controller, try condensing them into one .swift file per view controller
tweaking the settings under compile sources to see if you have any duplicates or if there are any scripts or settings you can add to make it compile faster...
you can also take a look at this post's answers for some hints as to what you can do to slow down compile time
I've discovered that one of the main causes of segmentation faults and slow compilation is hardcoding big arrays and dictionaries, especially when declaring them as global constants and trying to access values from them from within another .swift file. When I store all that data inside plists, these problems are gone.
In my experience avoid creating the large swift files, when I started a project in my new company, there was a 'UIViewController' with more than 2000 lines, little changes on this file taking much time to build, I made 4 extensions with <500 lines from that class, my speed improvement was incredible.
Background: git -- or any other SCM -- can "successfully" merge Storyboards, xib's, and pbxproj files as at their core they are just xml. Sometimes there are conflicts which can be resolved by the usual conflict resolution strategies. But xib's and Storyboards are serialized formats of some pretty complex data structures, so the fun begins.
Just as with other source code, a successful merge doesn't guarantee all the merged changes work correctly together. With the files in question, git can successfully merge but Xcode sometimes displays a "Could not read archive" error when you try to open it - i.e., the merge corrupted the xib.
I've seen suggestions about having git ignore .xibs (not practical), or in .gitattributes disable diff by setting
*.xib -crlf -diff
Technically, that fixes the merge conflict/corrupted xib problem - but now somebody's changes are lost?
Similarly, the best recommendation I've seen for the project file is merge=union in .gitattributes:
*.pbxproj merge=union
Question: I've searched quite a bit and there doesn't seem to be a good solution. Can people with experience tell me what happens in a few use cases?
In the project I rename a file from x to y, and delete fileA. Meanwhile, another programmer committed changes to add fileC and delete fileD. What is the result of merge? I'm sure the actual file system changes will be correct, but in the Xcode navigator panel:
Will I see both x and Y?
Will fileA reappear because it's still in the other programmer's .pbxproj?
Will fileD still be there because it's still in my .pbxproj?
If git is ignoring .xib files - will I at least get a warning that a file was changed and is not being handled?
I wouldn't set any specific .gitattributes for project files or nibs these days.
Your problems merging concurrent changes to Xcode projects and xibs/storyboards exist in every team with more than one developer.
Xcode projects
A few tricks for dealing with Xcode project conflicts:
Take one side of the merge and manually apply the other changes after the merge. If you've deleted files they'll be in red, if you need to add them they'll be available to add.
When adding files to your targets they will go at the bottom of the 'Compile Sources' build phase. Avoid conflicts with other people by dragging them up this list to a random position.
Use .xcconfig files to configure your projects rather than the build settings section. Config files are trivial to merge.
My best advice if in doubt is to take one side of the merge, relax, and replay your additions.
XIBs and Storyboards
The format of XIBs (and therefor storyboards) has change significantly in recent months. I've found that additional objects are appended to the file's internal collections and merges can be done easily. If you're making changes to the same object, you may have to get in there manually.
This post from Itty Bitty Apps highlights the main changes:
The benefits of this new XIB XML format are many fold:
XIBs are much smaller (fewer lines of code).
A developer can easily read the XML and understand what it specifies in the user interface.
Merging XIBs is now much less likely to lead to broken XIBs. Before we would rarely even bother to try and merge a XIB or Storyboard.
I'm at a complete loss as to what I did to cause this:
For the second time since I started using XCode about a month ago (my first time seriously using it after taking one class several years ago) I try to run my project and the next thing I know I have errors because I have duplicate references. I looked at the project and it appeared that most of the files in my project had duplicated themselves, however I discovered that they are not duplicate files just duplicate references. This happened to me today when I tried to build on an actual iphone for the first time but it also happened to me a few weeks ago while using the simulator. Neither time do I recall doing anything unusual. I have built and tested the project probably 100+ times and normally all goes ok. I was able to fix it the first time but I think I have made it worse this time and am probably going to add the files back into a new project. My co-worker also mentioned this happening to him (he has about as much experience with xcode as I do). He told me he ended up with files nested in folders (groups?) nested in other folders about 20 deep.
My question is this: Does anyone know what I may have done to cause this. I would really like to avoid this problem in the future since it is proving to be quite a headache. Any advice would be greatly appreciated.
E.T.A. xcode version 4.6.2 (possibly an earlier version the first time it happened)
Try this instead:
Highlight all the duplicate files
Right click on one of the files and press "Delete"
When prompted for which delete option, click "Remove Reference"
Also you asked for "any advice".
If you aren't already using git source control in your Xcode projects, start now.
You can spot many mistakes like this earlier and fix them more easily using git.
When you add files as a copy, the Xcode project navigator shows added files with an A and modified files with an M.
If the file is inside a closed group folder, the folder shows an A.
If you add a reference without a copy the project navigator won't show an A but MyApp.xcodeproj will show M.
In Xcode you can discard a change before committing it.
In the case below, you would discard changes to all added or modified files.
Typically you review and commit changes frequently.
Using a gui tool such as SourceTree, you have a good chance of spotting an accidental change before you commit. For example, you can see changes to the project file.
If you accidentally commit an unintended change, you can go back later and reverse a commit.
By committing frequently, you have more control over which changes you undo and which ones you keep.
References:
http://www.raywenderlich.com/13771/how-to-use-git-source-control-with-xcode-in-ios-6
http://git-scm.com/doc (scroll down to see videos)
http://www.sourcetreeapp.com
http://gitimmersion.com
I had the same 20 deep nesting of my main folder of images. If its not a bug its very strange behaviour. I just backed it all up !! Then I opened the folder in finder, found the point at which it was starting to nest and deleted it.
I did a rebuild, but I don't think Xcode even noticed. It made no difference to the size of my app so Xcode was not putting unnecessary files in the binary.
This happened to me when I imported a file. Suddenly I had two nested directories containing what looked like copies of all my files. The compiler complained about duplicate classes.
I found a solution, but it's a ball-ache and a time sink.
1: Click on your project in the navigator to open up the project settings in the main view.
2: Open the 'Compile Sources' accordion entry.
(This allows you to see which files are being used in the compilation process.)
3: Find any duplicates in here and delete them.
(At this stage your project should compile again.)
4: In your navigator view, slow-double-click one of the files that's duplicated there. This should allow you to rename it. Change the name (not the extension) slightly.
5: You should notice that the copy becomes red. Select it and hit delete.
(This avoids the delete operation removing the file from the 'Compile Sources')
6: Rename the original file back to its original name again.
7: Repeat from 4 until done, or until bored.
8: Explain to your boss why a simple copy change took half a day.
This process can be optimised up by first renaming all duplicated files, then deleting the duplicates all at once. However this means that you can't test for successful compilation between steps, which allows you to narrow the culprit down to a single file. And takes even more time.
If compilation fails, ensure all the files you need are still in the 'Compile Sources' section, as this process can cause them to be lost from there. The compiler will normally give some reasonable errors about missing classes and variables, but a missing AppDelegate will produce a more confusing error.
I have been writing iOS applications and completed a project with a lot of frameworks. Now I am using it as a template to start a new project that requires less functionality and hence I should be able to reduce the frameworks required, and hopefully reduce build time and size of project.
Question:
Is there a quick way to check which frameworks are no longer required within the project?
I don't think there is a better way than removing the framework, building, and seeing if there are link errors. You might be able to write a bash script but it's probably more work than it's worth.
Sadly not. The quick way is to remove all the frameworks, look for build errors and add back in the necessary frameworks.
search in the project files(cmd+shift+F).i.e whether you are imported any files related to the frameworks.