I ran into the "Declared Objective-C type "[String]" for attribute named..." issue too. The thing that seemed to help was changing the Custom Class from "[String]" to "NSArray". Hope that helps!
Post
Replies
Boosts
Views
Activity
Thanks! I'm wondering if you have any advice about making an NSManagedObject subclass Sendable? I'm not really sure how I'd go about it.
Based on the Xcode 15 release notes (https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes), it sounds like this is a problem with the simulators for the iPhone 15 Pro models. I was able to get the Settings app to work on an iPhone 15 and 15 Plus simulator.
I ran into the same thing and my guess is that it's a bug. (Filed as feedback FB12247784.) For the time being I worked around it by switching my enum's raw values from String to Int.
I doubled checked the Debug Information Format setting for my main target and it's set to DWARF with dSYM File. (Screenshot included.)
I also did a new archive for both iOS and Mac (Catalyst), with no code or configuration changes between the two aside from the build number. When I inspect the contents of the archives, the dSYM for the main app is present in the iOS archive, but not the Mac archive. I'm using Xcode 13.3.1 and MacOS 12.3.1.
The first thing I tried was using the built-in Xcode crash reports in the Organizer. I assumed that since Xcode has access to the archives and is fetching the crash reports itself, it would be able to locate and use the appropriate dSYMs, but I see unsymbolicated entries for the parts of the stack trace that are in my app.
So that led me to trying to symbolicate manually. I looked up the UUID and then used this, which produced no output:
mdfind "com_apple_xcode_dsyms_uuids == E49A5EB3-C560-3895-B2AE-4CEE263E45CA"
Next I tried looking in the archive for the dSYM itself. I right-clicked on the archive in the Xcode organizer and chose Show in Finder, then used Show Package Contents on the xcarchive. In the dSYMs folder, I see dSYM files for some frameworks the app uses, as well as some of its extensions (intents, widgets) but there isn't a dSYM for the app itself.
Yes, exactly - the version in the Mac App Store uses the same codebase as the iOS app (with a few Mac-specific tweaks) via Mac Catalyst.
I received a response to Apple developer support seeming to confirm that updates remain available:
If you are dropping support for iOS12, as long as the latest version that is compatible with iOS12 has not been removed in App Store Connect, users who are running iOS12 will be able to update to the latest version that is compatible with their device.