iOS apps cannot snoop on other apps, for privacy reasons. And they cannot run silently in the background except for very specific reasons - VoIP, location recording etc. So what you are asking is impossible.

You can set the delegate of the UITabBarController and respond to the didSelect method. Or you can subclass UITabBarController and override whatever methods you need. Personally I’d probably try using the delegate and broadcast a notification that the selected tab had changed. Then your child view controller could register for that notification and call popViewController:animated: in response. Edit: I would caution you against having a nonstandard use of a tab bar. Users expect that when they tap on a tab bar icon it returns them to that tab the way it was when they left it, with no side effects. You should not have different behaviours if you tap the same icon again. It creates an uncomfortable feeling when your app behaves differently from others on the platform. Might even be a HIG violation; I don’t know.

AuthenticationServices - https://developer.apple.com/documentation/authenticationservices is the framework third party apps can use to provide auto fill content.

You do it exactly the same way in either language, using the UITextFieldDelegate methods. textFieldShould change, clear, return etc. Not sure what a closure has to do with it.

You can probably keep using it. Deprecated doesn’t usually mean it will stop working immediately. It certainly would be helpful if they gave us some hints as to the reason / replacement when they mark something as deprecated.

It’s the Facebook SDK.

You’ll need to get those symbolicated before they can be of any use. Maybe try and open them in Xcode. Then instead of this mumbo jumbo Last Exception Backtrace: (0x1b2838300 0x1b254cc1c 0x1b2736a90 0x1b283ca60 0x1b283ed60 0x1b2783930 0x1b272e234 0x1b2af4e70 0x1b2af487c 0x1b69abc84 0x1b24d6ec4 0x1b24d833c 0x1b24e76e8 0x1b24e7d9c 0x1b253f6d8 0x1b25459c8) You’d see a list of file and line numbers that point to the code that was executing when it crashed.

Not sure where you got that idea Alijoscha. They are very clear about this being supported on Apple Silicon Macs only. Here’s the relevant WWDC video: https://developer.apple.com/videos/play/wwdc2020/10114/

Apple does not acknowledge the existence of backwards compatibility / support for old versions unfortunately. They always assume you’re starting from scratch targeting only the latest version. So from their standpoint there’s no need to talk about what has changed or how to adopt new APIs while still targeting older platforms. It’s a long standing issue.

Core Data stores what you tell it to store. There are likely bugs in your code. You’ll have to post some code that demonstrates the issue before anyone can help.

I don’t think dequeueReusableCell is the right call. That is meant to be used when setting up a new cell, not for getting a reference to an existing one. You could try cellForRow(at:). Or better yet, just set up the selected background view when you first create the cell. Then you wouldn’t have to do anything when the cell is selected. The table view should do it for you automatically.

The problem is you’re creating a brand new instance of ViewController, which is not part of the hierarchy and doesn’t have anything to do with stuff displayed on the screen. You call the method on that then throw it away. So of course it has no effect. You need to call the update method on the actual instance that is active, not a new one. It looks like you’re half way there already; you appear to have a PDSelectFreqDelegate protocol defined, which is the right way to do it in my opinion. So you should just declare a property of that type on the child (var delegate: PDSelectFreqDelegate?), set the delegate when you create the child VC (pickerVC.delegate = self), then in the child call didTapAdd on self.delegate instead of vc. Incidentally there is no need to dispatch anything to the main queue. There’s nothing going on in background threads here from what I can see.

I’m not an expert in how Swift optimizes its memory management. But if you put that first assignment to constraint inside an autoreleasepool { } then it is nil right away as expected. Perhaps in your sample it doesn’t get cleaned up until the next run loop iteration.

Users running iOS versions older than your deployment target will continue to be able to run whatever they currently have installed. And unless you go in and specifically disable the old version(s) in App Store Connect under the last compatible versions, they would be able to delete the app (or purchase the newer version on a newer device) and then reinstall whatever is the most recent version that was compatible with their device. But if you increase the deployment target you won’t be able to offer any new updates for those users. They will only be offered versions that already exist in the store.

You will not be able to publish an update specifically for those users only on older iOS versions. App version numbers must always increase. Users will only see the latest version that supports their device and OS version. For users with an incompatible device/OS they just won’t see any update available.