@steph68 I had a similar experience with HDMI-DVI conversion, and I suspect that's the problem. It worked OK with a TV set that had an HDMI port, but failed with a monitor with DVI and an HDMI-DVI cable. Of course I can't be certain but I filed feedback with details about it in case it can be fixed in an update.

For anyone else who's had trouble with the DTK and an HDMI-DVI cable, please file a feedback about it. I did (FB7824785) and they asked for details about the cable. It seems like they're aware of the issue, and more reports might help.

I get the same result. This looks like an internal issue that probably affects at least some other app names that begin with the same letters as Apple's iOS apps. Here's a workaround that may help. Look at the full stack trace when the assertion happens: 		* thread #2, queue = 'com.apple.root.user-initiated-qos', stop reason = EXC_BREAKPOINT (code=1, subcode=0x184e68d68) 			* frame #0: 0x0000000184e68d68 CoreData`+[NSManagedObjectContext Multithreading_Violation_AllThatIsLeftToUsIsHonor] + 12 				frame #1: 0x0000000184e68c4c CoreData`_PFAssertSafeMultiThreadedAccess_impl + 548 				frame #2: 0x0000000184e68a24 CoreData`__68-[NSManagedObjectContext _PFAutoreleasePoolReferenceQueueTrampoline]_block_invoke + 92 				frame #3: 0x0000000184e32b2c CoreData`-[_PFAutoreleasePoolThunk dealloc] + 40 				frame #4: 0x00000001801858e8 libobjc.A.dylib`AutoreleasePoolPage::releaseUntil(objc_object**) + 204 				frame #5: 0x00000001801857b8 libobjc.A.dylib`objc_autoreleasePoolPop + 236 				frame #6: 0x00000001024f8fac libdispatch.dylib`_dispatch_last_resort_autorelease_pool_pop + 40 				frame #7: 0x000000010250b37c libdispatch.dylib`_dispatch_root_queue_drain + 1428 				frame #8: 0x000000010250b928 libdispatch.dylib`_dispatch_worker_thread2 + 136 				frame #9: 0x00000001bad2175c libsystem_pthread.dylib`_pthread_wqthread + 212 Notice that frames near the middle of the pile mention autoreleasing. That suggests a course of action, since if you can affect how things are autoreleased in the framework, you might change the behavior. And in fact if you add @autoreleasepool to your performBlockAndWait: 				[managedObjectContext performBlockAndWait:^{ 						@autoreleasepool { 								NSError *error = nil; 								NSFetchRequest *request = [NSFetchRequest fetchRequestWithEntityName:@"TestEnt"]; 								NSArray *result = [managedObjectContext executeFetchRequest:request error:&error]; 								NSLog(@"result=%@", result); 						} 				}]; ...the violation goes away. I don't know if this will help in your real code as well as in your demo code, but it may be worth a try.

I'll second that, this would be extremely useful for me. I filed FB9163026 in case that helps.