Thank you for the quick and thorough response.
It is unfortunate that you are not targeting my use case. Just to give you some insight, my application uses edge caches, where the data is split up into many smaller pieces, that are cached near the users. Different users request different pieces of data. (But there is some overlap between users.)
Think open world MMO data, real-world map tiles, or songs. These are situations where each user wants a different set of data, so it doesn't make sense architecturally to create or download large bundles.
jackpal
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
Good to know, thanks!
Oh, one correction -- I think it's typical for a music app's "Recently Played" widget to show the N most recently played "containers", that is the most recently played playlists or albums, rather than the N most recently played songs. That makes the average case better. But the worst-case behavior is still there. What should a music app do if the user auditions a large number of playlists in a short period of time?
(Sorry for the italic formatting in my previous message. The symbol is "ios_extension", which is being interpreted as italics.)
OK, I figured it out. The bazel iosextension rule needs to be updated to generate iOS 14-compatible extensions.
Currently it is using -e NSExtensionMain when linking, which is correct for pre-iOS 14 extensions.
That needs to be changed (removed) in order for iOS 14 style WidgetKit extensions (that use @main to mark the entrypoint) to be linked correctly.
I'll contact the bazel folks and to let them know they need to update enhance bazel to handle iOS 14-compatible extensions.
Thanks! Unfortunately, deleting the app from the device and/or erasing the simulator did not help.
It's likely to be a build configuration issue on my end. I am using bazel to build the extension, starting from a working old-style Today extension and from the "EmojiRangerWidget" sample code. Presumably there's some subtle difference between how old-style extensions are built and how WidgetKit extensions are built.
So far the only difference I've seen is that the Info.plist has a NSExtensionPointIdentifier in the WidgetKit world.