Why Are UIViewController's Instance Variables Empty When Called via a Singleton?

Below is an explanation with some suggestions:

What’s Happening

Using a singleton means you have one, shared instance of a class for global access. In your code, you’ve declared a shared instance for your view controller:

SWIFTCopied
class MyVC: UIViewController {
    static var shared = MyVC()
    var messages: [[String: String]] = [
        ["role": "bot", "content": "How can I help you"],
        ["role": "user", "content": "What is my balance"]
    ]
    // … 
}

Because you’re using a static shared instance, the singleton instance is created the first time it’s accessed, and it’s a completely separate instance from any view controller you might have on screen (for example, one that comes from a storyboard or is presented in some other way). This is why when you call methods on MyVC.shared from the Utilities class, the instance variables (like messages) are empty—they belong to the already created shared instance, not to the view controller that originally had the data.

In other words, you aren’t “accessing the original instance,” but rather you’re accessing a different instance that was created as part of the singleton’s initialization.

How to Fix It

Because you want the asynchronous methods to access the original instance’s properties, you have a few potential solutions without moving the asynchronous call out of the view controller:

1. Pass the Original Instance to Utilities:
   Instead of having the Utilities class call a method on a shared instance of the view controller, have your view controller pass itself. For example:

   SWIFTCopied
   // In MyVC:
   Utilities.sharedInstance()?.getAnswer(messages, from: self) { answer, error in
       if answer != nil {
           // display answer
       } else {
           // wait for async answer via notification or other callback
       }
   }

   And in your Utilities implementation, change the method to accept a VC instance:

   OBJCCopied
   // Objective-C pseudo-code in Utilities.m:
   -(NSString *)getAnswer:(NSArray *)messages from:(MyVC *)callerVC {
       NSString *answer = [self searchLocalKnowledgeBase:messages];
       if (answer.length > 0) {
           return answer;
       } else {
           [callerVC getAsyncAnswerWithMessages:messages completion:^(NSString *answer){
               // send notification with Answer, or maybe directly callback to callerVC
           }];
       }
       return nil;
   }

2. Delegate or Closure Callback:
   Rather than having your Utilities class call methods on the view controller via its own “shared” instance, adopt a delegate or closure callback pattern. That way, the calling view controller passes a callback (or becomes the delegate) so that when the asynchronous answer is ready, the Utilities class or remote resource simply calls back on that handler. This removes the need for the singleton reference in the view controller.

3. Reconsider the Singleton for the View Controller:
   Using a singleton for a view controller is generally not advised unless you truly intend to have one global instance shared across your app. Most often, view controllers are created and managed by your app’s navigation or storyboard system. If you want the singleton pattern for a shared resource, it might be better to limit that to a dedicated data or network manager (like your Utilities class) rather than the view controller.

Summary

Yes, if you access a class via a singleton (like MyVC.shared), you’re not automatically accessing the instance with the pre-populated properties from your presentation logic. Instead, you’re accessing the unique instance defined by the static property—which in your case is being created as a “fresh” instance.

To ensure that asynchronous calls have access to the original VC instance’s properties, pass a reference to the actual view controller when calling the Utilities methods or use a callback/delegate that lets the original VC supply its instance context. This way, you avoid accidental creation or usage of a new VC instance with uninitialized properties.

This approach allows you to keep the asynchronous calls in the view controller while ensuring that you are using the correct instance for accessing your populated properties.