Post not yet marked as solved
It is safe to say the HomeKit API seems just as out of date after WWDC21 as it has been for 3+ years now. It is still missing TVs, HomePods, AppleTVs, Airplay2 devices, etc. There was really nothing announced that was actually HomeKit framework related. Home Keys looks like the team that does Wallet. HomeKit Secure Video expansion was just a matter of where and how much video is stored. Nothing related to HomeKit.
The way I read the tea leaves since Apple didn't add anything to HomeKit again this year is this (this is not a real quote just how I interpret the broader direction):
We have spent all of our resources for some years working on CHIP/Matter. We presume that by putting parts of HomeKit into this open source effort, more types and more brands of devices will then become part of it that were previously hesitant to do so. Therefore, we have spent years redirecting our efforts towards that at the expense of essentially everything else.
This seems like a road that will take 3+ years (plus the 3+ years already spent) to come to fruition. Meanwhile, the HomeKit API will still be missing everything that has been announced for the last several years. It's also counter-intuitive as most of the missing devices are Apple devices so they never needed third-party or open source anything to fix that.
Regardless, I think that's what we're getting. At this point, anyone serious about the HomeKit area starting fresh is likely better off using an HAP implementation of their own and basically ignoring the HomeKit API.
Post not yet marked as solved
I am also seeing this. I'm going to experiment with turning on recognitionRequest.requiresOnDeviceRecognition as it has nothing to do with those network services, so presumably removes these limits.
Post not yet marked as solved
Think I'm closer to a solution here. I had to convert 8 different libraries we use from .a files into xcframeworks last Summer to support all the many archs. It is my theory that these unsigned xcframeworks are causing the problem, and available literature on xcframework is.... limited.
So one issue is that the codesign tool and the various Xcode logs do not identify any issue there. Instead, they say "MyKit.framework" isn't signed rather than "libmystuff.xcframework" inside "MyKit.framework" isn't signed. Switching the xcframeworks to "Embed and Sign" elicits the hoped for error that identifies the specific xcframework that it wants to sign but for some inexplicable reason does not sign.
../Build/Intermediates.noindex/ArchiveIntermediates/MyApp/InstallationBuildProductsLocation/Applications/MyApp.app/Contents/Frameworks/MyKit.framework/Versions/A: code object is not signed at all
In subcomponent: ../Build/Intermediates.noindex/ArchiveIntermediates/MyApp/InstallationBuildProductsLocation/Applications/MyApp.app/Contents/Frameworks/MyKit.framework/Versions/A/Frameworks/libmystuff.a
However, I would have thought --deep would at least have glossed over that problem and I did try setting that to no avail earlier. As to how I get these frameworks signed in a static way (we don't rebuild these regularly, they are just part of our repository). I guess I need to go find a command line to sign them somehow before adding them to the project? Something doesn't seem right here. Seems like codesign needs a flag to say "yes, I know this object is not signed, so sign it".
Post not yet marked as solved
Exact same issue still in progress... Developer system status says CloudKit is green, but clearly it is not.
Post not yet marked as solved
Now it has been almost a full 2 years that the HomeKit API is totally out of date. The Home app keeps getting more and more devices that appear as HomeKit accessories, but are hidden from HomeKit apps. No guidance has been provided on this issue that has effectively created a second class citizen out of any HomeKit-related app. Not to mention that just turning on the HomeKit capability seems to turn the 1 day app review process into 7. Some kind of guidance/hope for the future is needed here, and not just waiting until next June at WWDC.
Post not yet marked as solved
Seems like this has been a particularly difficult month for App Review with constant reports of delays. My random guess is they took the whole team that does in-depth iOS reviews and transferred them to train on macOS so that they could approve Catalyst apps. That has caused a massive backlog on iOS. Just a guess mind you.We're in a similar boat. Getting any kind of response seems to be near impossible right now. Not even expedites are working (presumably unless you're a privileged app like Twitter and a few others that seem to update almost every day).While it's a change that simple apps are getting ~24 hour reviews, it seems like a matter of appearances and not substance. If a fair number of apps still go literally weeks without progress, the process is no better than it ever was. The original and still the primary problem with App Review is how opaque the process is. Why are our apps still "In Review" after 11 calendar days? Nobody knows. One of the messages we got back a couple weeks ago, we had to take a guess as to the problem because they're so mired in rules that they don't tell you what the issue is.
Post not yet marked as solved
This is a known issue that I think will not be fixed in 10.15.The way to get around it is to use CloudKit to share your subscription with both of your platforms. In other words, you do the work. A lot of effort, but it seems to be the general workaround for now.Eventually, I'd assume they will offer "universal" apps that will resolve this.Eventually #2, they need to offer subscriptions that apply to multiple apps as well.
Post not yet marked as solved
I wouldn't count on Mojave looking good for long. This started in beta 1 or beta 2, and I can now see hundreds of these undeletable folders in iCloud Drive on every system including Mojave, the iOS 12 Files app, etc.I tried to figure out how to fix it, but feels hopeless until the underlying bug is fixed. One thing I know is that even if you think you've deleted the folders, they just come right back.
Problem. Confirmed that lipo cannot combine multiple same-architectures in the same library even if they have a different target (lipo x86-64 with x86-64/x86_64-apple-ios13.0-macabi is not allowed).Problem. Including multiple same-name libraries in Xcode only shows 1 copy in the project Libraries settings so you can't specify for instance this copy of libcrypto.a is for iOS and this copy is for uikitformac.Thus, I assume the libaries need to be combined with XCFramework in a way that 'xcodebuild -create-xcframework' currently errors out with error 8 or 9.The "correct" answer marked above is referring to libraries built with Xcode which is not the topic of this thread (see previous references to OpenSSL, ffmpeg is also a good example, many more). The only solution apparent right now is to use XCFramework in a way that is not currently documented, and xcodebuild does not seem to generate the needed format right now per previous messages in this thread.One path forward right now might be to create an XCFramework by hand using the pieces of xcodebuild that do work as a guide.
That didn't work for me with OpenSSL 1.1.1c. The error from Xcode says it was Built for macOS not UIKit for Mac (as before).Though, even if it had worked, it would have only solved building. It seems we need either an XCFramework, or all 9 or so variants (the many ARM architectures, simulators, iOS/tvOS, Bitcode, UIKitForMac) bundled up otool fat binary style (not sure that is possible, but it used to work great until 2 weeks ago).And then this whole silliness needs to be repeated for every other library.
-create-xcframework is either buggy or I'm doing it wrong, but since it isn't documented, there's no way to know what error 8 is. I've also encountered error 9 fwiw. Fortunately, the raw build script output each architecture, but seems create-xcframework doesn't like it.xcodebuild -create-xcframework -library ~/src/OpenSSL-for-iPhone-master/bin/iPhoneOS12.2-arm64.sdk/lib/libcrypto.a -library ~/src/OpenSSL-for-iPhone-master/bin/iPhoneOS12.2-armv7.sdk/lib/libcrypto.a -headers ~/src/OpenSSL-for-iPhone-master/bin/iPhoneOS12.2-arm64.sdk/include/openssl -output ~/Desktop/libcrypto.xcframeworkThe operation couldn’t be completed. (XCBCore.XCFrameworkValidationError error 8.)Note that reducing the number of architectures to 1 in the above call does succeed.
Oddly, the information on XCFramework was not in a UIKitForMac talk, but instead in the "Binary Frameworks for Swift" talk even though this whole thing has nothing whatsoever to do with Swift.Anyway, I'm working on OpenSSL and ffmpeg will be next. The problem is that the create XCFramework command is not smart enough to figure out what to do if you pass it existing multi-architecture binaries (the way XCode 10 required) – it actuallu errors out. So have to go back through the build scripts and rip out the last 7 years of improvements along those lines and make sure every single arch is a separate .a file. At least that's what I think is needed, not really sure until it runs and works.
Same problem. It looks from the release notes that we're supposed to build something called an "XCFramework". However, there is no documentation on such a thing, and it is not part of the XCode target templates. I think the idea is to take all the architecture-specific library files or framework files (libfoo.a for intel, libfoo.a for arm, etc), and then build some kind of package containing all the architectures. The appropriate architectures are in my project, but it is looking for a "UIKit for Mac" version even though these libraries are architecturally way below UIKit and thus not relevant to it. I'm presuming we need a "XCFramework" to work around this limitation. At this point only random guesswork with xcodebuild seems like the way to do that, but hopefully some session later this week will reveal the magic command here.
Post not yet marked as solved
It's there and works fine. It's characteristic type is 00000030-0000-1000-8000-0026BB765291.It's absurd for this property to be deprecated as it's the only real way to tell accessories apart if the user has multiple iOS devices, and also the only way to remember which accessory the user was referring to later if they configure something in the app, especially since accessory UUIDs are totally unreliable changing frequently even from simple things like deleting an app and installing a TestFlight version of the app.I think everyone is just assuming if they ever actually deprecate it, they will provide an equivalent replacement. All the hardware people are still required to set it, so it seems there is no reason whatsoever to remove it.Maybe we should file RADAR bugs about this now so that it either doesn't get deprecated or is replaced with a proper solution that is not totally broken like accessory UUIDs.
Post not yet marked as solved
There are many other threads on Notarization not working with that error. Surprisingly, one guy today said it worked for him, but many more it seems not. I have been trying it every day for weeks and still see this error 100% of the time.
