Thanks for the reply. I filed FB12185065

Solution from this Stackoverflow post seems to work: https://stackoverflow.com/questions/28500507/can-i-make-a-uipresentationcontroller-have-userinteractionenabled-on-presentingv But was hoping for a more elegant way.

Adding a fallback image isn't working for me for iOS 14 ('m using a symbol introduced in iOS 15 and I'm getting this warning in a storyboard file). I tried: Adding a normal image asset with the same name as the symbol in my Asset catalog. Adding a "Symbol image set" with the same name as a symbol in my Asset catalog. Neither worked for me. The symbol has dots. like key.radiowaves.forward.fill

Whoops made a mistake in the last code block in my previous post (can't edit it). It should be: theVC.modalPresentationStyle = UIModalPresentationCustom; theVC.transitioningDelegate = transDelegate; theVC.strongTransDelegate = transDelegate; I'm assuming the transitioningDelegate property was declared weak anticipating cases where someone would set self as the transitioningDelegate I guess.

Declare a initializer like this in your ToDoListTableViewController header file: -(instancetype)initWithCoder:(NSCoder*)coder persistentContainer:(NSPersistentContainer*)persistentContainer; Then in your implementation: -(instancetype)initWithCoder:(NSCoder*)coder persistentContainer:(NSPersistentContainer*)persistentContainer { self = [super initWithCoder:coder]; if (self) { _persistentContainer = persistentContainer; } return self; } Then you can do this: UIStoryboard *mainSB = [UIStoryboard storyboardWithName:@"Main" bundle:nil]; ToDoListTableViewController *toDOVC = [mainSB instantiateViewControllerWithIdentifier:@"ToDoListTableViewController" creator:^UIViewController * _Nullable(NSCoder * _Nonnull coder) { return [[ToDoListTableViewController alloc]initWithCoder:coder persistentContainer:persistentContainer]; }]; But I wouldn't stop there. You could make the code cleaner by also declaring a factory method in ToDoListTableViewController so you can write the UIStoryboard code from many different places: //In ToDoListTableViewController's header file: +(ToDoListTableViewController*)makeWithPersistentContainer:(NSPersistentContainer*)persistentContainer; //Implementation: +(ToDoListTableViewController*)makeWithPersistentContainer:(NSPersistentContainer*)persistentContainer; { UIStoryboard *mainSB = [UIStoryboard storyboardWithName:@"Main" bundle:nil]; return [mainSB instantiateViewControllerWithIdentifier:@"ToDoListTableViewController" creator:^UIViewController * _Nullable(NSCoder * _Nonnull coder) { return [[ToDoListTableViewController alloc]initWithCoder:coder persistentContainer:persistentContainer]; }]; } Then you can just use the +makeWithPersistentContainer: to make the ToDoListTableViewController. Alternatively you could look for documentation on the hidden IBSegueAction feature but it's probably not necessary.

Thanks!

Would be nice to be able to tell what's being blocked so I can see if my WKContentRuleList is working properly. Testing one of these lists is kind of a nightmare.

So after some research it appears that there is no javascript event to detect url changes. So the javascript code I have won't work for "web apps" that modify an already loaded DOM and change the URL programmatically.

Thanks again for your replies! So after some research it appears that there is no javascript event to detect url changes. So the javascript code I have won't work for "web apps" that modify an already loaded DOM and change the URL programmatically. Usually a combination of onhashchange and onstatechange will capture all the ways JS programmatically changes the apparent URL without loading a new document. Both those aren't relevant for the back/forward cases. I heard about onhashchange but I can't seem to find documentation for a onstatechange event? It is my understanding that onhashchange won't pick up url changes in all cases? Being able to run a script after a "page change" in a reliable fashion is surprisingly complex.

Under option 1 you say you archive with: [NSKeyedArchiver archivedDataWithRootObject:(array of objects of type A) requiringSecureCoding:YES error:&error] And then unarchive with: NSSet *classesSet = [NSSet setWithObjects: [NSMutableArray classForCoder], [A classForCoder], [NSString classForCoder], [NSNumber classForCoder], [B classForCoder], [C classForCoder] , nil]; NSKeyedUnarchiver *unArchiver = [[NSKeyedUnarchiver alloc] initForReadingFromData:decryptedData error:&error]; [unArchiver setRequiresSecureCoding:YES]; unarchivedArray = [unArchiver decodeObjectOfClasses:classesSet forKey:NSKeyedArchiveRootObjectKey]; Which doesn't match. Why are you specifying all those classes (NSString, NSNumber, etc.) if the array only contains TypeA? If you archive a single array that only contains TypeA objects then why don't you you use -decodeArrayOfObjectsOfClass:forKey: NSArray *unarchivedArray = [unArchiver decodeArrayOfObjectsOfClass:[TypeA class] forKey:NSKeyedArchiveRootObjectKey];

I filed FB12771317

Being able to enforce numberOfLines would be desirable. It seems like a pretty common need to enforce a button to fit on a single line and I would think having a button wrap multiline would be more uncommon. In my case a button with a configuration initially displays with 1 line, but after toggling the Dynamic type setting to a smaller value, then increasing it back to the original value causes the button to start character wrapping even though there is plenty of room to fit all text on one line. It seems that UIButton (with a button configuration) can't really properly respond to the -sizeToFit method. Calling -sizeToFit just constrains the button to the current width and increases the height which is the opposite of what I often want.

Am I supposed to work on making my apps work on a platform that's letting me know I'm already deprecated pre release? Doesn't seem like a great way to entice developers to jump in. IMO.

Seems pretty absurd. Why bother implementing and deprecating something before the platform is even released? Many apps are complex and have taken years to write and their entire navigation structure is tied to one or more storyboards. Tearing the entire thing down isn't something you're going to do in a week (unless the app is very simple). So they want us to: Ship our storyboard based app on visionOS using deprecated "walking dead on arrival" API. They break the functionality and tell you to use SwiftUI. You now have a non-working app. Either rewrite the entire app with a new UI framework that has a different app lifecycle (can reuse very little code) or pull your live app from the store. No thanks. Instead of just letting developers choose which UI framework works best for them they have decided to force feed it. I mean if they want visionOS to be SwiftUI only like watchOS they should just enforce that policy from the start instead of trying to paint you into a corner. Feels like they are forcing SwiftUI because they're worried developers will choose UIKit if given the option. If SwiftUI is better, developers will use it so why force it? Oh yeah, interface builder products are being deprecated as well. I already miss the good old days where you could design custom table view cells in Interface Builder in like three seconds. And you didn't even have to wait for a preview to load. Even making the most basic custom table view cell now with the "content configuration" API is a pretty awful way to waste 30-45 minutes of your life.

I filed FB13188396