Post not yet marked as solved
EDIT: I think maybe I wasn't seeing files get rebuilt properly because I managed to get it working!
The 'U' references are not necessarily going to cause link issues. Using "nm -m" I can see that the single remaining 'U' when I do include Joe's workaround is for a "weak external" symbol which, presumably, will not cause a link failure:
(undefined) weak external _$s9WidgetKit22IntentTimelineProviderP15recommendationsSayAA0C14RecommendationVy0C0QzGGyFTq (from WidgetKit)
When I don't include the workaround the other 'U' reference is not weak:
(undefined) external _$s9WidgetKit22IntentTimelineProviderPAAE15recommendationsSayAA0C14RecommendationVy0C0QzGGyF (from WidgetKit)
ORIGINAL COMMENT BELOW:
Joe's solution isn't working for me. I did some investigation to try and work out where the undefined symbol is coming from. If I don't use his workaround, when I use the 'nm' command to look for symbols containing the word "recommendations" in the built widget .appex file I see this:
Villanelle:AdaptivityWidget14Extension.appex geoff$ nm AdaptivityWidget14Extension | grep recommendations
000000010003ff94 t _$s27AdaptivityWidget14Extension22LayoutTimelineProviderV9WidgetKit06IntenteF0AadEP15recommendationsSayAD0I14RecommendationVy0I0QzGGyFTW
00000001000173f4 t _$s27AdaptivityWidget14Extension27DynamicTypeTimelineProviderV9WidgetKit06IntentfG0AadEP15recommendationsSayAD0J14RecommendationVy0J0QzGGyFTW
00000001000292fc t _$s27AdaptivityWidget14Extension27SystemImageTimelineProviderV9WidgetKit06IntentfG0AadEP15recommendationsSayAD0J14RecommendationVy0J0QzGGyFTW
0000000100033b68 t _$s27AdaptivityWidget14Extension28SystemImagesTimelineProviderV9WidgetKit06IntentfG0AadEP15recommendationsSayAD0J14RecommendationVy0J0QzGGyFTW
000000010002c498 t _$s27AdaptivityWidget14Extension32LockScreenLayoutTimelineProviderV9WidgetKit06IntentgH0AadEP15recommendationsSayAD0K14RecommendationVy0K0QzGGyFTW
0000000100077674 t _$s27AdaptivityWidget14Extension37LockScreenSystemImageTimelineProviderV9WidgetKit06IntenthI0AadEP15recommendationsSayAD0L14RecommendationVy0L0QzGGyFTW
U _$s9WidgetKit22IntentTimelineProviderP15recommendationsSayAA0C14RecommendationVy0C0QzGGyFTq
U _$s9WidgetKit22IntentTimelineProviderPAAE15recommendationsSayAA0C14RecommendationVy0C0QzGGyF
I have six different widgets, each of which is responsible for one of the 't' entries. This indicates those symbols are defined in my .appex. The problem is coming from the 'U' undefined symbols. These need to be resolved at dynamic link time.
According to www . swiftdemangler . com, these two undefined symbols demangle to these names:
_$s9WidgetKit22IntentTimelineProviderP15recommendationsSayAA0C14RecommendationVy0C0QzGGyFTq
method descriptor for WidgetKit.IntentTimelineProvider.recommendations() -> Swift.Array>
_$s9WidgetKit22IntentTimelineProviderPAAE15recommendationsSayAA0C14RecommendationVy0C0QzGGyF
(extension in WidgetKit):WidgetKit.IntentTimelineProvider.recommendations() -> Swift.Array>
The lowercase 't' for my own symbols means they are (according to the man page for nm) "text section symbols" that are "local (non-external)" (that's what lowercase means).
_$s27AdaptivityWidget14Extension22LayoutTimelineProviderV9WidgetKit06IntenteF0AadEP15recommendationsSayAD0I14RecommendationVy0I0QzGGyFTW
protocol witness for WidgetKit.IntentTimelineProvider.recommendations() -> Swift.Array> in conformance AdaptivityWidget14Extension.LayoutTimelineProvider : WidgetKit.IntentTimelineProvider in AdaptivityWidget14Extensio
When I do define the recommendations method in each of my intent timeline providers I get an extra 'T' entry for each of my widgets and one of the undefined symbols disappears:
/Users/geoff/Library/Developer/Xcode/DerivedData/Adaptivity-cckxaccqtttwkcadthuihwqqbxkv/Build/Products/Debug-iphoneos/AdaptivityWidget14Extension.appex
Villanelle:AdaptivityWidget14Extension.appex geoff$ nm AdaptivityWidget14Extension | grep recommendations
000000010003fed8 T _$s27AdaptivityWidget14Extension22LayoutTimelineProviderV15recommendationsSay9WidgetKit20IntentRecommendationVyAA022ADTLayoutConfigurationJ0CGGyF
000000010003ff18 t _$s27AdaptivityWidget14Extension22LayoutTimelineProviderV9WidgetKit06IntenteF0AadEP15recommendationsSayAD0I14RecommendationVy0I0QzGGyFTW
0000000100017298 T _$s27AdaptivityWidget14Extension27DynamicTypeTimelineProviderV15recommendationsSay9WidgetKit20IntentRecommendationVyAA010ADTDynamice13ConfigurationK0CGGyF
00000001000172d8 t _$s27AdaptivityWidget14Extension27DynamicTypeTimelineProviderV9WidgetKit06IntentfG0AadEP15recommendationsSayAD0J14RecommendationVy0J0QzGGyFTW
00000001000291c8 T _$s27AdaptivityWidget14Extension27SystemImageTimelineProviderV15recommendationsSay9WidgetKit20IntentRecommendationVyAA09ADTSysteme13ConfigurationK0CGGyF
0000000100029208 t _$s27AdaptivityWidget14Extension27SystemImageTimelineProviderV9WidgetKit06IntentfG0AadEP15recommendationsSayAD0J14RecommendationVy0J0QzGGyFTW
0000000100033a98 T _$s27AdaptivityWidget14Extension28SystemImagesTimelineProviderV15recommendationsSay9WidgetKit20IntentRecommendationVyAA09ADTSysteme13ConfigurationK0CGGyF
0000000100033ac4 t _$s27AdaptivityWidget14Extension28SystemImagesTimelineProviderV9WidgetKit06IntentfG0AadEP15recommendationsSayAD0J14RecommendationVy0J0QzGGyFTW
000000010002c38c T _$s27AdaptivityWidget14Extension32LockScreenLayoutTimelineProviderV15recommendationsSay9WidgetKit20IntentRecommendationVyAA07ADTLockef13ConfigurationL0CGGyF
000000010002c3cc t _$s27AdaptivityWidget14Extension32LockScreenLayoutTimelineProviderV9WidgetKit06IntentgH0AadEP15recommendationsSayAD0K14RecommendationVy0K0QzGGyFTW
00000001000775e0 T _$s27AdaptivityWidget14Extension37LockScreenSystemImageTimelineProviderV15recommendationsSay9WidgetKit20IntentRecommendationVyAA07ADTLockefg13ConfigurationM0CGGyF
0000000100077620 t _$s27AdaptivityWidget14Extension37LockScreenSystemImageTimelineProviderV9WidgetKit06IntenthI0AadEP15recommendationsSayAD0L14RecommendationVy0L0QzGGyFTW
U _$s9WidgetKit22IntentTimelineProviderP15recommendationsSayAA0C14RecommendationVy0C0QzGGyFTq
I don't know enough about linking to know why I still get this outstanding undefined symbol when Joe, presumably, does not.
Post not yet marked as solved
This might not be what you want. An app which supports the iOS 13+ scene lifecycle and has support for an external display will show a full-screen non-interactive view controller on an external display. When run on iPadOS 16, if the main app window is on the internal display then the legacy non-interactive view will be shown on the external display. In fact, frustratingly, there seems to be no way to NOT have this happen (which would be desirable for apps which want to keep supporting the old external display behaviour prior to iPadOS 16 but not use it on iPadOS 16).
Post not yet marked as solved
In my own testing (hoping this Twitter link will work: https://twitter.com/geoffhackworth/status/1537786888626524162 ), I've found that the width only works for the default design. Attempting to vary the width of rounded has no effect, and attempting to vary the width of serif and monospace causes some font weights to actually return what looks like regular weight with the default design.
Post not yet marked as solved
I've been able to experiment with this a bit. You have to set a 'width' attribute trait on the font descriptor. Apologies for the Objective-C, but hopefully this will give you enough to figure it out!
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
ADTSystemFontTableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:[ADTSystemFontTableViewCell reuseIdentifier] forIndexPath:indexPath];
UIFontDescriptor *fontDescriptor = [self fontDescriptorAtIndexPath:indexPath];
NSDictionary *widthSetting = @{UIFontWidthTrait : @(-1.0)};
fontDescriptor = [fontDescriptor fontDescriptorByAddingAttributes:@{UIFontDescriptorTraitsAttribute: widthSetting}];
cell.fontDescriptor = fontDescriptor;
cell.title = [self titleForRowAtIndexPath:indexPath];
cell.showFontName = [ADTAppSettingsManager sharedInstance].showSystemFontsInfo.value;
return cell;
}
However, in my testing it seems that only the regular SF font design, and not rounded, serif and monospaced, work. I'm not entirely sure whether the width is just another way to vary the base default SF design, or whether it is intended to be a separate dimension like point size and weight that should work across all designs.
Post not yet marked as solved
Xcode 14 update to this issue. It seems that Xcode 14 no longer adds the com.apple.developer.user-fonts entitlement when building for Mac Catalyst. That meant my earlier workaround stopped working because I was asking plutil to remove an entry that wasn't there. This caused plutil to (correctly) return a non-zero exit code. Which breaks my build.
The fix is simple: check that the entitlement is there before trying to remove it:
if [ "${IS_MACCATALYST}" = "YES" ]; then
ENTITLEMENTS_FILE="${TARGET_TEMP_DIR}/${FULL_PRODUCT_NAME}.xcent"
# Xcode 14 doesn't seem to add this entitlement for Catalyst builds and plutil returns a non-zero exit code if I try to remove it
if grep -q "com\.apple\.developer\.user-fonts" "${ENTITLEMENTS_FILE}"; then
echo "Removing com.apple.developer.user-fonts entitlement on Mac Catalyst from ${ENTITLEMENTS_FILE}"
plutil -remove "com\.apple\.developer\.user-fonts" "${ENTITLEMENTS_FILE}"
else
echo "No need to remove com.apple.developer.user-fonts entitlement on Mac Catalyst from ${ENTITLEMENTS_FILE}"
fi
fi
Post not yet marked as solved
I also see this issue with both collection views and table views. I'm using Objective-C on Xcode 13.2 release candidate with iOS 15.2 (19C51).
In order to get a leak I have to:
return a non-empty array from the table/collection view delegate that asks for itemsForBeginningDragSession:
return a UIContextMenuConfiguration from the table/collection view delegate that asks for the contextMenuConfigurationForRow/ItemAtIndexPath
long press on the cell and NOT drag
dismiss my view controller that has the table/collection view
I then see that the collection/table view is leaked (and, in turn, its cached table view cells and the diffable data source object)
I have found that I do NOT get a leak if I do any one of these things:
return an empty array from the table/collection view delegate that asks for itemsForBeginningDragSession:
return nil from the table/collection view delegate that asks for the contextMenuConfigurationForRow/ItemAtIndexPath
after the long press, begin dragging
It does not matter whether the drag is dropped or cancelled, just starting to drag will prevent the leak.
Returning a non-nil UIContextMenuConfiguration which has blocks for its previewProvider and actionProvider that return nil (which is visually the same as returning a nil configuration - no context menu is shown on a long press) will still leak.
Post not yet marked as solved
Same issue for me. What’s really frustrating is “Apps with compatibility references to a pre-GM version of an Apple operating system SDK” suggests that it is totally acceptable to refer to a GM version. iOS 15 is in GM (or RC as they’ve called it for a long time).
Post not yet marked as solved
This still seems to be broken in iOS 14.2.1. It might be an issue extensions in general as a request to reload the timeline from a Notification Content Extension doesn't seem to work either.
Post not yet marked as solved
Oh my. This seems to have been fixed in watchOS 7!
Post not yet marked as solved
If you implement the getLocalizableSampleTemplate(for:withHandler:) method in your CLKComplicationDataSourceimplementation, these sample templates will sync from the watch to the paired phone automatically and be the same across both devices. This is preferred to generating complication bundles to include in your project. Are you saying we should no longer be including a complication gallery in our Xcode project? It would be nice if the documentation didn't still tell us to do it the old way: https://developer.apple.com/documentation/clockkit/creating_complications_for_your_watchos_app/adding_placeholders_for_your_complication
Post not yet marked as solved
It seems that Xcode 12 GM completely breaks builds of Mac Catalyst apps which have iOS 14 features. Code that would build fine in Xcode 12 beta 6 no longer builds. It's as if the GM thinks Mac Catalyst is only capable of iOS 13 features.
You can prevent the widget from being included in the Catalyst build (which probably isn't what you want): https://stackoverflow.com/questions/59795971/extension-is-not-available-when-building-for-mac-catalyst
That will get you past that particular error. But you will probably then find code that won't compile for Catalyst. Xcode complains that iOS 14 symbols just don't exist: https://developer.apple.com/forums/thread/660274?page=1#632760022
It seems that Xcode 12 GM can't build Mac Catalyst apps which use classes/properties etc. that were added in iOS 14. I get a similar error in one of my apps when I try and build the Catalyst version:
unknown type name 'UISplitViewControllerSplitBehavior' Xcode 12 beta 6 will build fine but, of course, can't be used to submit for review.
I can build a different app for Catalyst on Xcode 12 GM, presumably because that code doesn't use iOS 14 features.
Post not yet marked as solved
I'm experiencing this too. Only fixed by restarting Xcode. Have to do it a handful of times an hour. For me restarting Xcode didn't seem to fix it. Maybe the trigger happened really quickly for me.
But Xcode 12 beta 4 seems to be fixed for me! I hope so.
Post not yet marked as solved
Oh my god, finally somebody else is seeing this! It seems like all keypresses are being duplicated. Often the second one results in the alert beep, but things like CMD-T will open *two* tabs and CMD-W will close *two* tabs. CMD-N to add a new file shows the template chooser but also an alert saying "An assistant session is already running on this window".
What on earth is going on?
Like the original poster, I only see this on Xcode Version 12.0 beta 3 (12A8169g). But I am seeing it on macOS 10.15.6 (19G73).
Post not yet marked as solved
I have exactly this issue. Interface Builder has "forced" my split view controller into double width style. When run on iOS 13 it all seems to work, when run on iOS 14 I get problems because it isn't behaving like it used to.
In my app (Adaptivity) I deliberately want to be able to show the user how the Classic style split view controller behaves because it is different. For example, in a double/triple column split view the primary view controller is actually wider than what appears on screen (420 points instead of 320) with a leading margin which is 100 points larger than the trailing margin to cancel out the effect.
It would be really useful if we could select 'Classic' in Interface Builder to keep using the old initialiser.