We are using dictionaries to hold parameters for network requests on our app.
For example:
var params: [String: Any] = [:]
params["pageSize"] = 20
params["pageIndex"] = 0
We weren't experiencing any issues on Xcode 13, but after updating to Xcode 14 this approach seems to slow down editor extremely. So much so that even deleting a single line takes multiple seconds. Since we cannot change every single network request in our app and continue using Xcode 13 forever, is there a way to fix this issue?
Tried to edit a single line of code in a file that includes lots of dictionaries using Xcode 14, took several seconds instead of being instant.
Related
I have a very basic project set up with 3 json files for Lottie animations, but when I click on one of them in my Project Navigator, Xcode will freeze and eventually become unresponsive. The json file is not big in size either (160 KB). I wonder what's the cause behind this freezing. Is it a bug in Xcode right now or are you not meant to see your json files other than in "quick view" mode? I'm running Xcode 12.5.
This could happen with "minified" JSON (i.e. on a single line, as opposed to "pretty printed" with line returns and tabs/spaces): the longer the JSON, the longer the single line and some editors might have a hard time rendering it.
You could "pretty print" your JSON (outside of Xcode) to make it more digestible to the editor but be aware that this might result in significantly bigger (10x) JSON files.
I have the same problem. i tried this:
My json file consisting of 612 different objects blocks Xcode. So I realized that the problem was that the objects were greater than 599. If I delete 13 objects, everything works fine.
I am posting this after reading many similar posts on here regarding this issue and none of the solutions that worked for other people not working...
Xcode Version 8.3.3 (8E3004b)
Swift 3.1
Things I tried
Deleting Derived Data folder
Deleting Workspace File
Cleaning Build Folder
Cleaning Build
Reinstalled Xcode (after complete removal)
I also looked for Swift Issues:
Removed all concatenating strings
Cleaned up Swift arrays and dictionaries
Added Whole module optimizations
This all started happening after last Xcode update of 8.3.3. My project was compiling within seconds and now I have to wait at least 15 mins for it to index, then 5 minutes to compile after everything I change even something small in code.
When Building, it get stuck in "Compiling Swift source files". Is there way for me to look in to where it is actually getting stuck?
BIG UPDATE
I tried pretty much everything. Read every article, post, ect. NOTHING worked. My project was created right after 10.0.
Solution
Creating a new project and copying each file worked! It used to take 8-9 minuted to build. Now less than 2 seconds!
Apple knows about this problem, and says that Xcode 9 beta will perform much better. Note that if you don't want to update to Swift 4, you can continue compiling in Swift 3 mode using Xcode 9. The big limitation is that you won't be able to submit your project to the App Store until Xcode 9 goes final.
Also, Xcode 9 contains a new build system. You don't get it by default: you have to turn it on for this project. Choose File > Project Settings and switch the pop-up menu to New Build System (Preview). This is experimental, but it will be the default build system eventually, so it would be interesting to know whether this makes an appreciable difference.
If you don't want to update to Xcode 9 beta, you will just have to do a binary search: comment out all your code and start adding it back, piece by piece, until you find that piece that's causing the trouble.
The best way to work this out is to find what out what the build is doing while compiling your code. This is a really useful tool to use: https://github.com/RobertGummesson/BuildTimeAnalyzer-for-Xcode
When you run this tool it will show you what methods are taking the longest to compile, and then you fix those. Once you have done that, you can also try the answer I gave here to decrease the build times: Extremely long compilation times with Swift in Xcode
I've tried Swift3, it looked nice.
After adding some Swift code to existing Objc/C++ codebase (pretty large one), terrible debug delays began to happen.
If I write
assert(false);
somewhere, the message about it appears in console, and Xcode reaches breakpoint after 2 minutes (so I can see exact place of failure, observe variables and so on).
After discarding Swift code (so there're only Objc/C++ files), debugging is just 2-3 times faster.
I have to wait 30 seconds to reach function on button click:
After searching for it, I suppose the problem is with Xcode 8.3.2.
Have you met this problem?
Do you know of some new compiler/debugger flags, which speed up debugging?
Is it proper (for development process efficiency) to add Swift to such codebase?
This Issue Occurred On A SpriteKit Xcode Project
I have an issue with Swift where, once my project reaches a certain level of complexity where I have tons of classes and methods around, my autocompletion breaks so that "Jump To Definition" ceases to work and my IDE is reduced to the usefulness of a basic TextEditor/Notepad.
My code's color will change to white completely, which causes a lot of strain on my eyes, and this seems to only happen when I remove and add large blocks of code as I watch my CPU activity climb up to 75% usage on all CPU cores.
I think this started happening when I switched the target iOS from 9.3 over to 8.0. Is this an issue with the compiler trying to interpret old Swift syntax?
I also will have cases where I wait two minutes for minor changes to compile, only for the build to fail due to "Linker command failed with exit code", which is easily fixed by compiling twice.
Here's my specs:
OS X 10.11.4
Core i7 Skylake 4.0GHz
16 GB DDR4 RAM
256GB SSD
I'm thinking about building a system running OS X with dual processors which might alleviate the issue, since it can take upwards of 2 minutes just to compile code that's different by 1 line.
Okay, I found one solution which resolved my issue.
Remove All Emojis From Variable Names & .Swift File Names
Contrary to Apple's official Swift 2.0 textbook, DO NOT use ANY kind of Emoji's for things like Variable Names and Swift File Names UNLESS you know that the emoji you're using is a very old emoji (but even then, I wouldn't recommend it).
After opening my project in AppCode, AppCode had unicode problems with file names such as: foobar🔵.swift. It was very buggy and it would break Xcode later if I opened and saved a project with pre-existing emojis in AppCode.
So avoid using emojis in your code unless it's for strings like:
let someString = "⬛️🗡💣📚"
Welcome to Swift! Great language, awful tooling.
Joking aside, there are a couple of issues at play here. First off, syntax highlighting disappears when SourceKit crashes. SourceKit is the library which parses Swift on-the-fly so that Xcode can do things like indexing, syntax highlighting and code completion. It's a lot better than it used to be (using Swift 1.0 in Xcode was almost comical at times), but it's still far from perfect. Until SourceKit improves, you won't see much difference.
As for your build times, it's worth trying something like the Swift Build Time Analyzer to see which functions are taking a particularly long time to compile. I recently halved the compile time of the project I work on by removing all lazy vars set via closures. A recent compiler change made type inference for these sorts of closures incredibly slow, so each one was taking ~6 seconds to compile.
I've been working through the DemoBots example and having a lot of trouble getting it to work on all devices.
https://developer.apple.com/library/prerelease/ios/samplecode/DemoBots/Introduction/Intro.html
The current problem I'm having is that on an iPad Mini the app launches but crashes when loading animations. It crashes in AnimationComponent.swift on the line that loads an action from a file:
let bodyAction: SKAction?
if let name = bodyActionName {
// crash here
bodyAction = SKAction(named: name)
}
else {
bodyAction = nil
}
Debugging the app reveals that its trying to load an SKAction called "ZappedShake" but crashing with an array out of bounds exception.
On an iPhone 5S it runs fine. My best guess is its race condition with the faster iPhone 5S is loading the file with the action serialized in it, and by the time execution reaches this point the action is available. But on the single core older iPad the file is not yet loaded and the call fails.
Both are real hardware running iOS9 13A4325c, compiled on XCode Version 7.0 beta 4 (7A165t).
Making the problem more difficult is that I can't see where the file that apparently creates the "ZappedShake" - ReferenceActions.sks - is actually loaded. Its referred to by ReferenceScene.sks but nowhere in any of the code or anywhere else in the project can I see that file being referred to.
Is there some sort of name convention magical file loading mechanism for SKActions? Why does it work on the iPhone 5S and not on the iPad?
UPDATE: Found more on this here: http://asciiwwdc.com/2015/sessions/604
Also this year we focused on referencing and instancing.
We know you spend a lot of time designing high-quality content and animations for your games and we want you to let you reuse that content anywhere where you would like to.
We're allowing you to create serialized data files for your nodes and your actions and then add them as a reference instead of just loading them into your scene.
This way, every time you make a change to the source asset that is automatically reflected in the content of your game.
How do I do this for nodes? For nodes I design part of my scene, maybe a background element, or some scenery in our editor with an Xcode and then I can just drag-and-drop those files into my main scene in Xcode and it will automatically create a reference and it is all set up for you.
If you want to do this in code you can as well, you can manually construct an SKReferenceNode, assign it a file name or even a URL and when that content is first presented in your game we'll load in that content based on the latest version of the file that's in your bundle.
We can also do the same thing for actions. With actions go check out our great new action editor and beyond creating and composing the actions in Xcode you can give all them names.
These names are the key to using them in your game. We have added a selector to SKAction called actionNamed. This works just like it does for SKTexture and textureNamed.
You pass in the name of the action you want. We're going to automatically look inside of your app bundle in all of the serialized action files, find the one with the appropriate name and then surface that to the application.
This looks great but I can't find any documentation on it, or figure out how to debug it when it goes wrong.
It's not you, it's iOS. There's a bug with action references affecting 32-bit devices (like the iPad Mini.)
This issue has been fixed in iOS 9.2 Beta 1, according to this thread on the Apple developer's forum:
https://forums.developer.apple.com/thread/17267
Try running on a more recent 64-bit device (like iPhone 6) in the simulator. Or try upgrading your iPad Mini to iOS 9.2 Beta 1. Or just wait for the next iOS release to fix the problem.
The DemoBots game seems to run reliably when compiled with Xcode Version 7.0 beta 6 (7A192o).
Using a different machine (my home laptop) with a fresh install of Xcode the problem goes away. I also note that the first time I tried there were a few minor compile fixes I had to do such as renaming CGPoint.zero to CGPoint.zeroPoint which I guess should have sounded warning bells that there was some sort of version conflict. This time with the fresh install it compiled and ran out of the box.
I still don't completely understand how the reference actions are getting picked up but at least I now have multiple working versions of Demobots so I can just duplicate the working code there.