I'm using Xcode 13 and I didn't have such problems in Xcode 12 now I don't know what to do. I get built automatically my app after the slightest change (Even one space).
If I leave even a space, it is constantly trying to build. I can't write code anymore.
I recently updated to macOS Catalina so I could update some of my apps with Mac support using Catalyst. Whenever I run the app and it tries to access the CloudKit data (I use CloudKit to sync Core Data, Data if an iCloud Account is available), it then crashes with the following error. [User Defaults] Couldn't write values for keys ( ApplicationAccessibilityEnabled ) in CFPrefsPlistSource<0x600002c07700> (Domain: com.apple.Accessibility, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: Yes): setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access
I have tried changing Permissions and Access in App SandBox settings in my Signing and Capabilities, to read/write. I have also tried changing incoming and outgoing connections to on.
I am not exactly sure what code I should show so here is the area is crashes in.
if isICloudContainerAvailable() {
print("iCloud Available")
let container = NSPersistentCloudKitContainer(name: "Shopping_App")
container.loadPersistentStores(completionHandler: {
(storeDescription, error) in
if let error = error as NSError? {
fatalError("Unresolved error \(error), \(error.userInfo)")
}
})
return container
}
I except the app to create/get the CoreData data and if available (which is in this case) to connect to the CloudKit synced data. But it crashes right now before it even brings up any views which leads me to think that it is crashing in the AppDeleget somewhere.
Update Oct. 14 -- I found that if I force Jump Over the Breakpoint where the app crashes, I can continue into the app and it works fine. Which leads me to think that the error is really in the AppDeleget especially saying that the UI does not appear until after I jump over the breakpoint it sets at the crash.
Update Nov. 4 -- So this problem gets even stranger. I forgot I was using a beta version of Xcode, so ok, it could have just been that after I realized that last week. I tried running the app through the public version and the app never stopped for a breakpoint but instead completely crashes with Thread 1: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0). This error is just really odd. Would this be an error that I should report to Apple? I thought about doing that but I decided not to because it seemed to me like something I could have been doing, but now rethinking whether I should or not. I wish I could find the solution to this problem because I would like to release the macOS version to the public, but have not had any luck finding a solution.
Update Nov. 8 -- In Xcode 11.2.1 GM seed the problem still persists. I have yet to find the exact reason this problem occurs but will continue to try. I have also been unable to reproduce the error written in the update on Nov. 4, on any Xcode version. I have not found anything else but wanted to update this with information about the GM seed and if this still happens.
Update Nov. 13 -- I decided to just go ahead and upload the app to Apple for approval since building the app and running it independently from Xcode worked just fine. Apple approved the app without any complaints of this issue. This just seems to be an Xcode issue. I will continue to update this however and if/when I find a solution I will post the solution to this problem but have not found anything more to workaround or solve this problem.
Update Nov. 20 -- On Xcode 11.3 Beta Build 11C24b, the problem still occurs. Nothing else has changed and I have not found anything else to solve this problem. I will continue to keep this updated but have not found anything else yet.
Update Dec. 11 -- On Xcode 11.3 Public 11C29 the problem still continues. However, now it is not consistent and sometimes I have to go over the breakpoint twice instead of just once for the application to continue launching. It still does not occur though if ran independently from Xcode.
Update Jan. 2, 2020 -- Still occurs but now verified that it occurs on a real iOS 13 device. No other solutions or stepovers found though. I will continue to update this post however with any other information.
Update Feb. 17, 2020 -- Not much of an update but still occurring on Xcode 11.4 Beta (11N111s). Will continue updating this post however not much has changed. (Fixed some misstakes on this post as well)
Update March 10, 2020 -- I did not realize that Xcode beta 11N132i was released but after testing it still occurs. However, though it may still be occurring, it is at least less consistent. Now instead of it happening and doing this every time, it appears to be somewhat random.
Update April 18, 2020 -- Sorry for not updating this post, I have been unable to program until now. I still have not figured out this issue but it seems that now it is not really happening. It still happens just rarely now. This also is on Xcode 11.4.1 (11E503a), and I am not sure why still. I will continue to try and update this post. Thank you. If you have any suggestions to try to find the cause, I am open to hearing them.
Update May 14, 2020 -- Xcode 11.5 Beta 2 (11N605f) This problem still occurs randomly, but now it seems to not always include the error yet still points to that portion of code. Thank you for your support of this post, and I will continue updating it as I find more about this problem.
Update Jun 5, 2020 -- I am sorry for not updating this any sooner, I completely forgot when I had updated Xcode. On Xcode 11.5 this problem still persists like it has been. I have also updated to Catalina 10.15.5 and have seen little to no changes. However, like the comments have said, Catalina 10.15.4 did help this has I heard, but 10.15.5 seemed to not change anything, which is strange.
Update Jun 27, 2020, and July 22, 2020, and Aug 10, 2020 -- I have updated my project to now support Xcode 12 and it appears to still have the same issue. Nothing has really changed and the log is the exact same. I appeaciate everyone willing to contiune in helpin fix this issue as well. This is also the same on Xcode 12 Beta 2. The excat same for betas 3 and 4.
Update Sep 28, 2020 -- This is still an issue on the GM and Public versions of Xcode 12. I have not updated to Xcode 12.0.1 because I am waiting for macOS Big Sur, but at this point, I doubt that would solve it. I really do not have any updates, other then it still is occurring and I cannot find the issue.
Update Nov 3, 2020 -- This still appears to be an issue on Xcode 12.1.1 Release Candidate. Sorry for not updating this for so long, I was holding out updating Xcode as I previously stated, but I decided to go ahead and update. However, updating to the Release Candidate has not changed anything, or not at least that I can notice. One change I did notice; however, was that it seemed to show this issue sooner, but that could just be that it compiles it quicker. To summarize, no major changes to this problem and nothing has really changed with it in a while.
UPDATE Nov 16, 2020
I have since updated to macOS Big Sur 11.0.1 and updated Xcode to 12.3 beta. The problem still seems to occur after having to change a few random things to get it working on Big Sur. However, most everything I changed I think is unrelated because it was mostly related to the UI elements. This may just be Big Sur but it compiles much faster, and the error now shows much quicker; however it still is the same error.
MasterChief96, you are not alone. Here is my setup:
MacOS 10.15.3
Xcode 11.4.1
I create a brand new SwiftUI "Hello World" project, enable Mac as a target device, a.k.a. Catalyst.
I set the iOS deployment target to 13.2 (otherwise I get a MacOS runtime error saying I need Catalina 10.15.4)
Set the scheme to "My Mac", compile and run and get:
[User Defaults] Couldn't write values for keys
ApplicationAccessibilityEnabled
AccessibilityEnabled
FullKeyboardAccessFocusRingEnabled
setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access
Since it refers to the sandbox, I change the "Signing and Capabilities" setting for App Sandbox to include Read/Write for User Selected and Downloads File Access.
I quite Xcode, delete the project's Derived Data, open the project and run. The error messages persist when running on MacOS. (I do not see the messages when running on iOS.)
Just guessing here, but this appears to be yet another bug in the Catalyst environment? Maybe this bug is fixed in Catalina 10.15.4 but that update was such a disaster for me I had to back port to 10.15.3.
For me, I was getting this exact error message but the crash was happening due to the next error message where it was referring to missing CFBundleName in the Info.plist for my Mac Catalyst app.
The snippet of stack trace:
(Domain: com.apple.Accessibility, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: No): setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access
2020-06-27 11:01:52.403837-0700 Manga Relay D[17329:517025] [General] An uncaught exception was raised
2020-06-27 11:01:52.403908-0700 Manga Relay D[17329:517025] [General] *** -[__NSDictionaryM setObject:forKey:]: object cannot be nil (key: title)
2020-06-27 11:01:52.404006-0700 Manga Relay D[17329:517025] [General] (
0 CoreFoundation 0x00007fff2eb82be7 __exceptionPreprocess + 250
1 libobjc.A.dylib 0x00007fff6795a5bf objc_exception_throw + 48
2 CoreFoundation 0x00007fff2ec3160e -[__NSCFString characterAtIndex:].cold.1 + 0
3 CoreFoundation 0x00007fff2ec3c17c -[__NSDictionaryM setObject:forKey:].cold.3 + 0
4 CoreFoundation 0x00007fff2eac0329 -[__NSDictionaryM setObject:forKey:] + 976
5 UIKitCore 0x00007fff6f5f2c8f -[_UIMenuBarItem properties] + 99
6 UIKitMacHelper 0x00007fff5fd6272a UINSNSMenuItemFromUINSMenuItem + 90
...
Once I specified a name in the "Bundle name"(aka CFBundleName), the crash went away but I still do get the error message about setting preferences outside an application's container.
Update with more details: The following screenshot of my Info.plist is defining the CFBundleName as my user-defined variable like $(MangaRelayBundleDisplayName) and I found out I never defined this anywhere, so it was nil which was causing the crash. When I entered the value such as "My App", the crash went away. Now, this solution has nothing to do with the original question, and basically I was mislead by the "sandbox access" warning, but I figured there could be other people who are being mislead by the warning.
I am on macOS 10.5.5 and Xcode 11.5.
I had the same problem.
Solved by deleting the "All runtime Issue" breakpoint.
After tests,
Thread Satanizer (Runtime Issue) works fine
Undefined Behavior (Runtime Issue) works fine
Main Thread Checker (Runtime Issue) works fine
System Frameworks (Runtime Issue) BREAK
This question already has an answer here:
Weird UIAccessibility Crash On Ipad Mini 2
(1 answer)
Closed 5 years ago.
I have taken over a code from someone else and the source code is written in Swift. I have made my changes but when I added the Crashlytics for crash reporting, I keep on seeing UIAccessibility crashes. Mainly 2 crashes keep repeating,
UIAccessibility _copyAttributeValueCallback
and
UIAccessibility _copyMultipleAttributeValuesCallback
I have searched every last thread of stack over flow with the keywords Swift and UIAccessbility but still cannot make out why it's occurring. Any idea what I am missing here?
Edit: This is the crash report from Crashlyitcs.
I was struggling with this same issue and have concluded it's not a crash and an issue with Crashlytics. It was pointing to the AppDelegate class definition, no actual code. I recently uploaded a copy of my app to test with TestFlight as a release version only giving myself access. I launched it a few times had no issues using the app but went back to my debug version. The next time I checked Crashlytics, my error free to me testing showed 7 of these crashes on an iPad Mini 2 while I was testing on an iPhone 6S. No one else had access to this particular build.
Also, a new release to some testing customers showed this error on my latest release for a customer who hadn't yet downloaded it. Strange things are certainly afoot at the Circle K for this particular crash.
In addition, Apple shows none of these crashes! As I type this I'm realizing these crashes only show up on builds distributed via TestFlight. We use Crashlytics for internal testing and TestFlight to test with clients prior to release. Does this match your experience?
I have developed and updated a medical application for cardiac ultrasound since 2011. One feature of the app is a user-generated document library for documents, images, and movies, all displayed using QuickLook.framework. QuickLook has functioned well until now with iOS 10. At this point .csv files (generated by the app to store calculated data) display as simple text (including the commas) instead of as a spreadsheet. I have not found any Apple documentation to explain this change in behavior. The log in Xcode shows no error messages when displaying a .csv file.
I am using the iOS Simulator at this point to test my app with iOS 10. However, I have verified that the El Capitan (10.11.5) version of QuickLook opens a .csv file in the simulator library on the desktop without a problem, with the expected spreadsheet format. Therefore, I do not suspect any problem with the .csv files that my app is producing.
I suspect this problem with .csv display is a bug in iOS 10, but with no resolution after 3 beta releases, I am concerned that the problem persists. Any help would be much-appreciated. My hope is that there will not be a need to adopt a new document display method, since QuickLook has worked so well for several years now.
Of note, my app does not use any Swift code.
iOS 10 is still in beta and will be in beta until at least the second half of September.
One of the main advices there is while testing beta software is to test it on the real device with something like iOS 10 Public Beta build installed.
If you are 100% positive that this is a consistent, well repeatable bug on Apple's side (not on your own or any other 3rd-party library you might use) consider filing a radar.
Concerning your specific problem, as far to my knowledge, Apple didn't make any significant changes to the QuickLook functionality in iOS 10, but once again, you can prove me wrong, by carefully browsing through all the latest changes in the official iOS 10 changelog.
Debugger is telling me this, when I run my app on device:
Program received signal: “EXC_BAD_ACCESS”.
mi_cmd_stack_list_frames: Not enough frames in stack.
mi_cmd_stack_list_frames: Not enough frames in stack.
I don't get information about where in code that happens. That's all I get. Any idea what that could mean?
The app crashes after that. When the device is not connected to the mac, it still crashes, so not a debugger problem.
Building on the 4.0 sdk onto a 3.1.3 phone caused this for me.
Fixed by weak linking UIKit in the target.
EXC_BAD_ACCESS happens when a message is sent to an object that has already been released.
I've seen "mi_cmd_stack_list_frames: Not enough frames in stack" before when trying to release something that's already been released as well.
My suggestion is to set the NSZombieEnabled environment variable and see which released object you are trying to access.
This site has a great tutorial on it:
http://www.codza.com/how-to-debug-exc_bad_access-on-iphone
I've seen this caused by at least three different kinds of problems:
• As described in the other answer, overrelease errors can do it.
• I had it happen when I was upgrading an app to use iAd and IOS 4.0. I think the problem was that I tried to use the iAd framework in the 3.0 version of the app as well, which of course isn't possible because iAd is only around in 4.0 and above.
• I had it happen when I removed a bunch of stuff from an app and recompiled, but vestiges of the old stuff were still around on the simulator. Resetting the simulator cleared the problem. What I was removing was the Flurry API. I'm afraid I don't know what, specifically, in there stuck around and caused the problem.
I have the same issue. My solution is:Quit the Xcode and then restart it after waiting some time.
I've got such a message when was trying to launch an app on iPhone under iOS 3.1.2 with a string like that
Class messageClass = (NSClassFromString(#"MFMessageComposeViewController"));
At the same time that works well when I use a device with iOS 4.
So I can assume that app could crash when start running on device if there are any references to iOS4-only classes.
Creating a new project and copying all the existing files in it solved this problem for me.