At certain point I used Accessibility Inspector (from Xcode -> Open developer tool -> Accessibility Inspector) while running my app in simulator, and ever since the Xcode console is cluttered with accessibility logs, no matter if Inspector is launched or not:
objc[33601]: Class ___MKPlaceBusinessInfoItemAccessibility_super is implemented in both /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/AccessibilityBundles/VectorKit.axbundle/VectorKit (0x11f4817b0) and /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/AccessibilityBundles/MapKit.axbundle/MapKit (0x11ff15f00). One of the two will be used. Which one is undefined.
And there are hundreds of lines of this for all different classes, so it's very hard to find some useful output.
I've tried adding OS_ACTIVITY_MODE with disable value in Product>>Scheme>>Edit Scheme...>>Run as Environment variable, but that doesn't help.
Anyone knows how to turn it off?
Related
My app seems to have a memory problem. I'm not getting any crashing, but when testing on device, both Instruments and the Debug Navigator agree that the amount of memory my app is using keeps increasing depending on what I'm doing in the app.
So, I tried to diagnose the problem.
First, I thought about normal memory leaks -- and there were many. So, after a lot of work with the Instruments -> Leaks template, I was able to eliminate them.
But the memory problem persisted.
So, I decided to look for zombie objects. First, I enabled zombies in Xcode. Because I was unsure whether I needed to enable zombies for "Run" or "Test" or both, I did both. So, that's Edit Scheme -> Run -> Diagnostics -> Zombie Objects and Edit Scheme -> Test -> Diagnostics -> Zombie Objects.
I was also unsure whether to run Instruments through a debug or release build configuration, so I tried it with both (with the same outcome).
Here's a screenshot showing the location of the Debug Navigator:
Here's a screenshot of the memory options I enabled prior to using View Memory Graph Hierarchy:
Now that zombies are enabled, I go to Debug Navigator -> View Memory Graph Hierarchy, and Xcode builds a memory graph that says my app has something like a thousand zombie objects. There are zombies of all kinds -- everything from SceneKit stuff to CloudKit and GameplayKit stuff.
Here's a screenshot of some of those zombie objects:
So, I decided to investigate further using Instruments.
Here's what Apple says on using Instruments to detect zombies:
"If a call is made to a deallocated object, a flag is inserted in the
timeline pane and a Zombie Messaged dialog appears, indicating that a
message was sent to a deallocated object at a specific memory
address."
However, if I open Instruments and use the Zombies template, I never see any such flags/dialogs.
Here's a screenshot showing what I see after running the Instruments Zombies template (notice the lack of flags/dialogs):
Question: Why might the memory graph hierarchy tool and Instruments disagree so markedly on the presence of zombies? Is there some further Xcode configuration I'm missing or something? How should I proceed?
Thanks!
My project runs good in Xcode 11. But when I build it in Xcode 12 gets the above error. I have been struggling for a while and no answers worked for me.
Please help
Thank you
It's quite an old question, but I was struggling with such issue for a few hours today and in my case it was related to the version of the tools that is declared in xib's document structure. To fix it, take a toolsVersion value from any newly created xib file (either in your current project, or a new one), then open failing xib with any code editor (or view its source in Xcode) and replace toolsVersion with the acquired one.
In my case the old version was 18122 and the valid one is 20034.
Old question but I ran into this the other day and wasn't really finding any direct solutions.
What appears to have worked for me was correcting the "builds for" value in Interface Builder. The xib file was from a project that supports a level of iOS several versions later than the project I was copying it into, and there were elements within the interface (like stack views) that weren't supported in the older OS. Once I changed the "builds for" value to an OS version that does support those UI elements, the problem went away (note that this subsequently required me setting up version checks in and around the files associated with the xib to only allow access if the user's device meets the minimum "builds for" value set on the xib).
If you're unsure where the "builds for" picker is:
In Xcode, select the xib file, and select the File Inspector within the Inspector pane (pane on the right hand side). Set the builds for value to an OS that supports all elements used within the xib, and see if that clears up the error.
Before I submitted this to Apple as a bug report, I wanted to double check I am not doing something very silly.
I have attached a sample project that demonstrates the problem. I have two segmented controls, one of which controls the enabled state of the other.
https://www.dropbox.com/s/dq2x9srbme4genb/EnabledControlsProblem.zip?dl=0
If you click on the disabled button, it disabled the second segmented control.
I have a basic UI test that replicates this behaviour which is constructed like this:
XCTAssertTrue(app.segmentedControls.buttons["Enabled"].exists)
XCTAssertTrue(app.segmentedControls.buttons["Enabled"].isSelected)
XCTAssertTrue(app.segmentedControls.buttons["First"].exists)
XCTAssertTrue(app.segmentedControls.buttons["First"].isSelected)
XCTAssertFalse(app.segmentedControls.buttons["Second"].isSelected)
XCTAssertTrue(app.segmentedControls.containing(.button, identifier: "First").firstMatch.isEnabled)
app.segmentedControls.buttons["Disabled"].tap()
XCTAssertFalse(app.segmentedControls.containing(.button, identifier: "First").firstMatch.isEnabled)`
If you run this test on an iOS 11.4 device it works as I think it should and succeeds. However, if I switch to a iOS 12.1 simulator device, the test fails on the last line (which is checking if the second control is enabled). Visually state of the control changes as it should. I have also tried this same test on an actual iPhone device running 12.0
Any attempts to sleep before the last check, don't make a difference.
Is there something fundamentally wrong with what I have done or is this a bug or a change in iOS12 that I missed?
I used to have the same type of problems with UI testing and I discovered a better method in pretty much all cases, and this lies in the key point that all tests rely on the Accessibility Framework. I was getting these weird seemingly buggy results all the time.
1. Better Debugging
Debugging goes much easier when you use the following command, which will show the hierarchy of elements:
print("Current App Tree: \(app.debugDescription)")
The hierarchy will help you ensure that the element does exists and how the app/device/simulator is seeing it.
2. Use Accessibility Identifiers
Instead of finding elements as you are, understand that all the tests are built on the accessibility framework. This seems insignificant at first, but I found it made life much easier. The framework is much happier when all elements have an accessibility identifier. Basically each view has a property: "accessibilityIdentifier". This will show up in the app debug listed above. If you do not set this, the framework will have a hard time finding your elements. If you're using storyboards, this is easy to set under Accessibility. If you're using code, set the property as follows:
myView.accessibilityIdentifier = "Enable State Selection"
Then in your UI Tests you can find the element like this:
app.buttons.matching(identifier: "Enable State Selection").element
In your specific case, it looks like it is part of a UI group of some kind involved in segmented controls. I would make a two step finding like this:
myUIGroup.accessibilityIdentifier = "Controls"
Then you can do a two step finding like this:
let controlsView = app.segmentedControls.matching(identifier: "Controls").element
let enabledButtons = controlsView.buttons.matching(identifier: "Enable State Selection").element
XCTAssert(enabledButtons.exists)
Overall I find that you at the beginning of your UI Testing class define these as class globals:
let app = XCUIApplication()
lazy var controlsView = app.segmentedControls.matching(identifier: "Controls").element
lazy var enabledButtons = controlsView.buttons.matching(identifier: "Enable State Selection").element
Then in your test function the code is very clean, and simply:
XCTAssert(enabledButtons.exists)
I try to add UI test cases to our existing mac application. I already tried UI test cases for iOS, which includes the following steps
I choosed Appium instead of Apple's UIAutomator, because I want to maintain the same flow for our Android apps too.
To proceed the automation, I need to set Labels/Values/Identifiers to the elements. So that they can be accessible. We used drawRect method in most parts, so I followed this post to make drawed components accessible.
I can set/read elements in iOS. What I did is, whenever I draw an element, I simply created an UIAccessibilityElement and added in the corresponding view.
Now, I'm trying to write UI tests for our mac application. As Appium does not have support to the mac application, I considered to use Apple's XCTest UI recording/playback to automate my mac application.
Here is the steps that I took:
NSAccessibility is the class that provides accessibility to the mac application
With XCTest, If I knew a particular elements (say a button) identifier/label, I can proceed with automated tap action
Unlike UIAccessibility, NSAccessibility is a role based object. That is, we need to mention which type of accessibility element that we are going to define.
To start the automation process, I took my mac applications left panel, which has five buttons aligned vertically in it
I set identifiers to those buttons. Then I opened Accessibility Inspector and opened my mac app. The values are properly set.
Then I tried to use record option in XCTest. When tapping the button, crashes the app with the error
"Recorder Service Error: Left Mouse Down: Failed to find matching
element".
I posted about it here.
Questions:
Can someone suggest me the right path to automate mac application? Am I going in the right way?
I googled a lot to see a working sample code about how to implement NSAccessibility. But I can not found anything. Can someone share any useful links/samples?
All I need is, to get elements by identifier/label. Accessibility Inspector shows the right value where as XCTest can not read the identifiers. Did anyone face this issue?
Thanks in Advance
I have a bit of a dilemma — no matter what I do, I cannot get Apple's Instruments.app to symbolicate any of the included instruments while I'm profiling on my devices (it works OK in the iOS Simulator).
I've tried just about everything I can think of, including:
Checking that I'm actually building a dSYM
Switching between Debug and Release build schemes
Making sure that the signing certificate being used in my Development cert
Adding and removing my Derived Data folder from Spotlight's Privacy list
Clean & Build before profiling
Removing the Derived Data folder before building and profiling
I'm not sure where to go from here — I had symbols for an hour or two earlier in the week, but I just can't get them to show up at all anymore. It would be great to figure out what the mystical incantation is to make Instruments always find my app's symbols.
In the File menu there is an option for Re-Symbolicate Document. Choosing this, you can find your binary in the list and use the Locate button to specify the location of the dSYM manually. There is also a checkbox here for using Spotlight to find the dSYM; it's possible it got deactivated if Spotlight was borked at some point but is now fixed.
It seems that you cannot do this while Instruments is actually instrumenting, but it does seem to keep the setting for the next time you hit Record. It does not, however, seem to remember the setting after you close Instruments.
Did you ensure you are signing the app with a development profile (as opposed to a distribution profile)?
Be aware that you are usually using release builds with instruments so make sure you didn't choose a distribution profile for your release configuration...
I've seen Instruments 4.2 fail to symbolicate several times with the correct dSYM file.
After saving and quit/restart Instruments, it will then symbolicate.
(Sometimes I'll capture a small sample and make sure it works before collecting large samples.)
Aside from xcode's tools, you can use atos: https://stackoverflow.com/a/4954949/312725
Be sure to take slide into account as well: https://stackoverflow.com/a/13576028/312725
(I'm adding this information to several related questions that are related to that, but aren't exactly duplicate questions. This is copy-pasted, it's a honest attempt to help someone who googled that question rather then spam.)