You have good tutorials from Apple. Did you read those: https://developer.apple.com/tutorials/swiftui/

Is "vc1" and "vc2" meant to match the class of the viewControllers in the project? I just used the info you gave in OP: I have a collection view in VC1 embedded in a navigationController. The collection view contains buttons that go to VC2.  so vc1 is the instance of VC1 and vc2 instance of VC2 This is in viewWillDisappear of VC2. Exact ? Then, you could write (I adjusted for optionals): func viewWillDisappear() { if let vcs = self.navigationController?.viewControllers { let vc1 = vcs[0] // may need to write if let vc1 = vcs[0] as? VC1 { vc1.functionToUpdate } vc1.functionToUpdate } } The navigation controller starts after the Home Screen, btw, I didn't mention that before. I have three navigation controllers branching off from the initial VC, is this bad practice or normal in IOS development? initial VC is Home screen ? How do you go from there to each navigation stack ? I see nothing wrong there, as long as user can understand where he/she is navigating to. For the code above to work, what is key is to have the following sequence (in IB): Home Screen NavigationController VC1 VC2 That would also work with a pattern as Home Screen NavigationController VC1 VC1bis VC1ter VC2

Another note: if you want to be sure to return to Home, just use popToRootViewController (line 31)         self.navigationController?.popToRootViewController(animated: true) And in viewWillDisappear: override func viewWillDisappear(_ animated: Bool) { super.viewWillDisappear(animated) if let vc1 = self.navigationController?.topViewController as? VC1 { vc1.functionToUpdate } }

Did you try this: var index = s.endIndex while index != s.startIndex { index = s.index(before: index) print(s[index]) // Just to see }

As I told you, rejecting app on your side creates a big delay. I don't know why, but it seems the app goes into a special review queue, much slower (may be the queue of "problematic apps" that require human review. Don't forget to close the thread.

There seems to be known vulnerabilities on port 55555. Is it the reason for the blocking ? Is it something you observe recently (which MacOS version ?) Search on Google to find the link (there are problems now on the forum to post links): Search for : port 55555 exploit

I tested in playground, did not get a crash with a "" String. In fact, in that case s.endIndex == s.startIndex, so we don't enter the loop. I tested direct and reverse exploration (100 iterations on a string of about 40 chars) Elapsed time Reversed: 0.1168900728225708 seconds Elapsed time direct: 0.33927905559539795 seconds Twice as fast in reverse…

To install on a Mac, you need now to have the app notarized.

If your views are rectangular, just test if their frames intersect. Use func intersects(_ rect2: CGRect) - Bool let intersect = rect1.intersects(rect2) To know if it overlaps, test if rect2 in included in rect1 func contains(CGRect) - Bool let contained = rect1.contains(rect2)

I do not see how UserDefaults.standard.bool(forKey: "MyAppSettingsResetState") could ever be true in your code. When app launches first time, key does not exist, hence it is false. But as pre installed is false also, || condition is met and "MyAppSettingsResetState" is set false?

Whatever you do, at some point you'll need a Mac and an iOS device at least to be able to publish app and even just to test. So, if you seriously consider iOS go and find a Mac, get a developer contract and download Xcode. Wish you good development.

functionToUpdate is a generic name. I don't know the name of update function you want to call. So, in HerdViewController, you should have: func functionToUpdate() {     // update the collectionView here } And in HorseViewController override func viewWillDisappear(_ animated: Bool) { super.viewWillDisappear(animated) if let vc1 = self.navigationController?.topViewController as? HerdViewController { vc1.functionToUpdate() } } May be you can pass the list of cells to update or to remove as a function parameter, to avoid reloading the full collectionView. Note: effectively, you must not dismiss a view in a Navigation stack.

Did you test on device or in simulator. Should test on an iOS 13 device, that may "just" be a simulator issue.

That is what you should use. Of course, pass the actual Strings, with the exact meeting identifier removePendingNotificationRequests(withIdentifiers identifiers: [meetingID]) Note also : This method executes asynchronously, removing the pending notification requests on a secondary thread.

I notice it is now possible to get notification (on a thread by thread basis, not a a complete tag). But that's already better.