A Summary of the WWDC25 Group Lab

bob133,Yes, we absolutely need the accessory view. :-)Our product is a plugin to an application, and our plug-in imports files into the host application. Imagine a plug-in for Microsoft Word to bring in a file type that it can't handle by itself.Our product uses the open dialog to choose the file(s) to import, and down below in the accessory view display our logo, a summary of the product settings as well as a button for modifying the import settings.Hope this helps.

You can set the color property on the notification interface controller rather than using a group. This will apply the color to the entire platter.

[Administrivia: I had to edit your post to remove the URL so that I could reply promptly.]What’s your high-level goal here? You started this thread with a very theoretical treatment of the issue but this most recent post seems to be very specific (worrying about App Review rejects of your app and so on). If you can post a summary of what your app does, should be able to provide more concrete advice.Share and Enjoy — Quinn The Eskimo! Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

It might be my WindowServer crashing. There are a lot of these and the timing seems to be close.Process: WindowServer [7583]Path: /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/WindowServerIdentifier: WindowServerVersion: 1Code Type: X86-64 (Native)Parent Process: launchd [1]Responsible: WindowServer [7583]User ID: 0Date/Time: 2015-08-27 19:25:04.843 -0400OS Version: Mac OS X 10.11 (15A263e)Report Version: 11Anonymous UUID: A178737F-1D40-4A04-2AFD-5BC330EB41E0Time Awake Since Boot: 35000 secondsCrashed Thread: 0 Dispatch queue: com.apple.main-threadException Type: EXC_GUARDException Codes: 0x200000010004e68b, 0x00007fabbc15a760Thread 0 Crashed:: Dispatch queue: com.apple.main-thread0 libsystem_kernel.dylib 0x00007fff8d07dbfa _kernelrpc_mach_port_destroy_trap + 101 libsystem_kernel.dylib 0x00007fff8d081c0b mach_port_destroy + 172 com.apple.CoreGraphics 0x00007fff8aab97f1 process_connection_event_ping_port_death + 36953 com.apple.CoreGraphics 0x00007fff8aab668d WSTerminateMatchingConnect

The problem is probably this part:dispatch_group_async(groups[threadIndex], queue) { arrays[threadIndex] = threadIndex }Each dispatched closure is modifying the same array, and if two threads attempt to modify the array at the same time one version will overwrite the modifications of the other.(In detail, I believe that what is happening is that the closure is capturing the local arrays variable, and when the Array value it holds is mutated by setting a new element at the provided index, the local arrays variable is updated to point to a new modified copy of the Array value with the change. If the array has elements modified on two threads at the same time, both read the same previous version of the Array value, but then each updates the local arrays variable with its own modified version, so whichever version ends up being held by arrays will be missing the change made by the other thread.)

@LCS,Many thanks I think you nailed the problem. The following works:import Foundation class MutableReference<T> { var value: T init(_ value: T) { self.value = value } } let numThreads = 16 let threadIndexes = 0 ..< numThreads let numTests = 1024 (0 ..< numTests).forEach { (testIndex) in let arrays = threadIndexes.map { (_) -> MutableReference<Int?> in MutableReference(nil) } let groups = threadIndexes.map { (_) -> dispatch_group_t! in dispatch_group_create() } let queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0) threadIndexes.forEach { (threadIndex) in dispatch_group_async(groups[threadIndex], queue) { arrays[threadIndex].value = threadIndex } } threadIndexes.forEach { (threadIndex) in dispatch_group_wait(groups[threadIndex], DISPATCH_TIME_FOREVER) if arrays[threadIndex].value == nil { print(test (testIndex), array element (threadIndex) = nil) } } }Which differes from the original in that the array is iimmutable and therefore never written

That's a good solution for fixed length arrays.For cases where the array does need to change or the size can't be determined in advance, here's an example of protecting the array with a second serial dispatch queue:class Example { let taskCount: Int let taskRange: Range<Int> let iterations: Range<Int> init(tasks: Int, tests: Int) {taskCount = tasks; taskRange = 0 ..< tasks; iterations = 0 ..< tests;} let group = dispatch_group_create() let workQueue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0) let safetySerial = dispatch_queue_create(protected w/ serial array access, DISPATCH_QUEUE_SERIAL) func test_safe_serial() { for test in iterations { var array = [Int?](count: taskCount, repeatedValue: nil) for index in taskRange { dispatch_group_async(group, workQueue, { var input: Int? = nil dispatch_sync(self.safetySerial, {input = array[index]}) let output = input ?? index dispatch_sync(self.safetySerial, {array[index] = output}) }) } dispatch_group_wait(group

yes, I'm looking for the groups as well. Any word on what happened to them?

I saw the same thing this morning. I just logged back in now to check before posting here and it looks like the groups are back.