Found the solution myself:extension Product { @objc var computedName:String { // @objc is crucial for making it KVC compliant! get { if belongsToCategory != nil { return belongsToCategory!.name! } else { return "special" } } } }In the NSFetchedResultsController use "computedName" for section name key path instead of "belongsToCategory.name".Data model here is: entity "Product" <<-- "belongsToCategory" ---> entity "Category". Both entities have name attributes.

Same problem here. Did you ever find a proper solution?

For me, the "stopped" state is indicated as "open" - which is correct, if you consider "half open" (or anything not fully closed) as "open". My major problem is that any click in iOS toggles the "target state" like open-close-open, but the actual door opener device does open-stop-close-stop-open (unless it hits the endpoint, then it's the same). Overriding the target state with a notification from the device does not work reliably, unfortunately.

Not even compiling for MacOS works for me (on Catalina). I installed all prerequisites with "brew" according to the instructions. But "make all" results in a bunch of HAP related linker errors. Any hint how to fix this? ld: warning: dylib (/usr/local/Cellar/openssl@1.1/1.1.1j/lib/libcrypto.dylib) was built for newer macOS version (10.15) than being linked (10.14) mkdir -p Output/Darwin-x86_64-apple-darwin19.6.0/Test/Tests/ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -Wall -Wextra -Werror -DHAP_ENABLE_DEVELOPMENT_ONLY_CODE=1 -mmacosx-version-min=10.14   -DDARWIN=1 -Werror=unused-function -Wno-expansion-to-defined -Wno-nullability-completeness -Wno-deprecated-declarations -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk -IHAP -IExternal/HTTP -IExternal/JSON -IExternal/Base64 -IPAL -ICommon -I/usr/local/Cellar/openssl@1.1/1.1.1j/include -I/usr/local/Cellar/mbedtls/HEAD-2a02787/include -O0 -g -DHAP_LOG_LEVEL=1      -DHAP_TESTING -IPAL/Mock -I/usr/local/Cellar/openssl@1.1/1.1.1j/include -o Output/Darwin-x86_64-apple-darwin19.6.0/Test/Tests/HAPAccessorySetupGetSetupPayloadTest.OpenSSL   -framework Foundation -framework CoreBluetooth -framework Network -framework CoreGraphics -framework ImageIO -framework CoreServices  -L/usr/local/Cellar/openssl@1.1/1.1.1j/lib -lcrypto Output/Darwin-x86_64-apple-darwin19.6.0/Test/PAL/HAPPlatformSystemInit.o Output/Darwin-x86_64-apple-darwin19.6.0/Test/Tests/HAPAccessorySetupGetSetupPayloadTest.o Output/Darwin-x86_64-apple-darwin19.6.0/Test/hap.a Output/Darwin-x86_64-apple-darwin19.6.0/Test/Mock.a Output/Darwin-x86_64-apple-darwin19.6.0/Test/OpenSSL.a  ld: warning: ignoring file Output/Darwin-x86_64-apple-darwin19.6.0/Test/hap.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64 ld: warning: ignoring file Output/Darwin-x86_64-apple-darwin19.6.0/Test/Mock.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64 ld: warning: ignoring file Output/Darwin-x86_64-apple-darwin19.6.0/Test/OpenSSL.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64 ld: warning: dylib (/usr/local/Cellar/openssl@1.1/1.1.1j/lib/libcrypto.dylib) was built for newer macOS version (10.15) than being linked (10.14) ld: warning: ignoring file Output/Darwin-x86_64-apple-darwin19.6.0/Test/hap.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64 ld: warning: ignoring file Output/Darwin-x86_64-apple-darwin19.6.0/Test/Mock.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64 ld: warning: ignoring file Output/Darwin-x86_64-apple-darwin19.6.0/Test/OpenSSL.a, building for macOS-x86_64 but attempting to link with file built for macOS-x86_64 Undefined symbols for architecture x86_64:   "_HAPAccessorySetupGetSetupHash", referenced from:       _Test in HAPAccessorySetupGetSetupHashTest.o   "_HAPAccessorySetupIsValidSetupID", referenced from:       _Test in HAPAccessorySetupGetSetupHashTest.o   "_HAPAssertInternal", referenced from:       _Test in HAPAccessorySetupGetSetupHashTest.o       _main in HAPAccessorySetupGetSetupHashTest.o   "_HAPPreconditionInternal", referenced from:       _Test in HAPAccessorySetupGetSetupHashTest.o   "_HAPRawBufferAreEqual", referenced from:       _Test in HAPAccessorySetupGetSetupHashTest.o   "_HAPStringGetNumBytes", referenced from:       _Test in HAPAccessorySetupGetSetupHashTest.o   "_HAPStringWithFormat", referenced from:       _Test in HAPAccessorySetupGetSetupHashTest.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

I am afraid that you misunderstood the issue: It is not about missing EXIF data after downloading the image from the camera. At that stage, EXIF data is present (e.g. in Preview) and there are ways to retrieve it via UIImage or CGImage. The issue is about accessing the EXIF data before downloading the actual images from the camera. The goal is to compile a list of image thumbnails and image meta data, and to let the user decide which ones to actually download, or to automatically select only certain images based on names, dates, or possibly other criteria. Access to this data on the camera itself should work via ICCameraFile, but for the EXIF dates, I always get nil. The (less reliable) file dates of ICCameraItem are available, though. The Image Capture app on MacOS displays this last date, and currently so do I in my own app. However I am wondering under what circumstances the actual EXIF date (which I would prefer) is accessible, considering that there already is a dedicated property for it.

I have just noticed that I can in fact access EXIF "DateTimeOriginal" (among others) via requestMetaData() and didReceiveMetadata(). This still does not populate the ICCameraFile.exifCreationDate, though. While I now have a workaround, I still wonder what the purpose of this empty field is.