我喜欢基于NSProxy的模型对象和模拟对象的想法，以便在用户选择的内容可以取消时提交或丢弃数据。

传递数据很容易，因为它是一个对象或两个对象，如果你有一个UINavigationController控制器，你可以将对模型的引用保存在内部，所有推送视图控制器都可以直接从导航控制器访问它。

如果要将数据从ViewControlerOne传递到ViewControlerTwo，请尝试以下操作。。。

在ViewControlerOne.h中执行以下操作：

 @property (nonatomic, strong) NSString *str1;

在ViewControllerTwo.h中执行以下操作：

 @property (nonatomic, strong) NSString *str2;

在ViewControllerTwo.m中合成str2：

@interface ViewControllerTwo ()
@end
@implementation ViewControllerTwo
@synthesize str2;

在ViewControlerOne.m中执行以下操作：

 - (void)viewDidLoad
 {
   [super viewDidLoad];

   // Data or string you wants to pass in ViewControllerTwo...
   self.str1 = @"hello world";
 }

O按钮单击事件，请执行以下操作：

-(IBAction)ButtonClicked
{
  // Navigation on buttons click event from ViewControlerOne to ViewControlerTwo with transferring data or string..
  ViewControllerTwo *objViewTwo = [self.storyboard instantiateViewControllerWithIdentifier:@"ViewControllerTwo"];
  obj.str2 = str1;
  [self.navigationController pushViewController: objViewTwo animated:YES];
}

在ViewControllerTwo.m中执行以下操作：

- (void)viewDidLoad
{
  [super viewDidLoad];
  NSLog(@"%@", str2);
}

在给出的许多答案中都有一些很好的信息，但没有一个完全解决这个问题。

该问题询问如何在视图控制器之间传递信息。给出的具体示例要求在视图之间传递信息，但考虑到iOS自称的新颖性，原始海报可能是指视图控制器之间，而不是视图之间（没有viewControllers的任何参与）。似乎所有的答案都集中在两个视图控制器上，但如果应用程序发展到需要在信息交换中包含两个以上的视图控制器，该怎么办？

最初的海报还询问了Singleton和AppDelegate的使用。这些问题需要回答。

为了帮助其他人看这个问题，谁想要一个完整的答案，我将尝试提供它。

应用场景

与其进行高度假设、抽象的讨论，不如考虑具体的应用。为了帮助定义两个视图控制器情形和两个以上视图控制器情形，我将定义两个具体的应用场景。

场景一：最多需要两个视图控制器共享信息。

见图一。

应用程序中有两个视图控制器。有一个ViewControllerA（数据输入表单）和一个ViewController B（产品列表）。产品列表中选择的项目必须与数据输入表单中文本框中显示的项目相匹配。在这种情况下，ViewControllerA和ViewControllerB必须彼此直接通信，而不能与其他视图控制器通信。

场景二：两个以上的视图控制器需要共享相同的信息。

见图二。

应用程序中有四个视图控制器。这是一个基于选项卡的应用程序，用于管理家庭库存。三个视图控制器显示相同数据的不同过滤视图：

ViewControllerA-奢侈品ViewControllerB-非保险项目ViewControllerC-整个住宅库存ViewControllerD-添加新项目表单

无论何时创建或编辑单个项目，它也必须与其他视图控制器同步。例如，如果我们在ViewControllerD中添加了一条船，但它还没有投保，那么当用户转到ViewControllerA（豪华物品）和ViewControllerC（整个住宅库存）时，船必须出现，但当用户转到ViewControllerB（非投保物品）时则不会出现。我们不仅需要关注添加新项目，还需要关注删除项目（可以从四个视图控制器中的任何一个中删除），或编辑现有项目（可以在“添加新项目表单”中允许，将其重新用于编辑）。

由于所有视图控制器都需要共享相同的数据，所以所有四个视图控制器都必须保持同步，因此，每当任何单个视图控制器更改基础数据时，都需要与所有其他视图控制器进行某种通信。很明显，在这种情况下，我们不希望每个视图控制器直接与其他视图控制器通信。如果不明显，考虑我们是否有20个不同的视图控制器（而不是4个）。每当一个视图控制器发生更改时，通知其他19个视图控制器中的每一个会有多困难和容易出错？

解决方案：代表和观察者模式，以及Singleton

在场景一中，我们有几个可行的解决方案，正如其他答案所给出的

赛格牌手表代表直接设置视图控制器上的财产NSUserDefaults（实际上是一个糟糕的选择）

在场景2中，我们还有其他可行的解决方案：

观察者模式单身者

单例是类的一个实例，该实例是其生命周期中唯一存在的实例。单例的名字来源于它是一个实例。通常，使用singleton的开发人员有特殊的类方法来访问它们。

+ (HouseholdInventoryManager*) sharedManager; {
    static dispatch_once_t onceQueue;
    static HouseholdInventoryManager* _sharedInstance;

    // dispatch_once is guaranteed to only be executed
    // once in the lifetime of the application
    dispatch_once(&onceQueue, ^{
        _sharedInstance = [[self alloc] init];
    });
    return _sharedInstance;
}

现在我们了解了单例是什么，让我们讨论单例如何适合观察者模式。观察者模式用于一个对象响应另一个对象的变化。在第二个场景中，我们有四个不同的视图控制器，他们都想知道底层数据的更改。“底层数据”应该属于单个实例，即单例。“了解更改”是通过观察对单例所做的更改来实现的。

家庭库存应用程序将具有一个类的单个实例，该类旨在管理库存项目列表。经理将管理一系列家庭用品。以下是数据管理器的类定义：

#import <Foundation/Foundation.h>

@class JGCHouseholdInventoryItem;

@interface HouseholdInventoryManager : NSObject
/*!
 The global singleton for accessing application data
 */
+ (HouseholdInventoryManager*) sharedManager;


- (NSArray *) entireHouseholdInventory;
- (NSArray *) luxuryItems;
- (NSArray *) nonInsuredItems;

- (void) addHouseholdItemToHomeInventory:(JGCHouseholdInventoryItem*)item;
- (void) editHouseholdItemInHomeInventory:(JGCHouseholdInventoryItem*)item;
- (void) deleteHoueholdItemFromHomeInventory:(JGCHouseholdInventoryItem*)item;
@end

当主库存项的集合发生更改时，视图控制器需要了解此更改。上面的类定义并没有说明这将如何发生。我们需要遵循观察者模式。视图控制器必须正式遵守sharedManager。有两种方法可以观察另一个对象：

关键值观察（KVO）NSNotificationCenter。

在场景2中，我们没有使用KVO可以观察到的HouseholdInventoryManager的单个属性。因为我们没有一个易于观察的属性，所以在这种情况下，必须使用NSNotificationCenter实现观察者模式。四个视图控制器中的每一个都将订阅通知，sharedManager将在适当的时候向通知中心发送通知。库存管理器不需要知道任何关于视图控制器或任何其他类的实例的信息，这些类可能有兴趣知道库存项集合何时发生变化；NSNotificationCenter负责这些实施细节。视图控制器只需订阅通知，数据管理器只需发布通知。

许多初学者程序员利用了这样一个事实，即在应用程序的生命周期中始终只有一个应用程序委托，它是全局可访问的。初级程序员利用这一事实将对象和功能填充到appDelegate中，以方便从应用程序中的任何其他位置进行访问。仅仅因为AppDelegate是单例并不意味着它应该替换所有其他单例。这是一个糟糕的实践，因为它给一个类带来了太多负担，打破了良好的面向对象实践。每个类都应该有一个易于解释的明确角色，通常只需通过类的名称。

每当您的应用程序代理开始变得臃肿时，就开始将功能删除到单例中。例如，核心数据堆栈不应该留在AppDelegate中，而是应该放在它自己的类coreDataManager类中。

工具书类

管理视图控制器之间的数据流在视图控制器之间传递数据Objective-C中的异步JSON请求

对于SwiftUI

将@EnvironmentObject视为在许多视图上使用@ObservedObject的更聪明、更简单的方法。您不必在视图A中创建一些数据，然后将其传递给视图B、视图C和视图D，然后再最终使用它，而是可以在视图中创建数据并将其放入环境中，以便视图B、C和D可以自动访问它。

注意：环境对象必须由祖先视图提供–如果SwiftUI找不到正确类型的环境对象，则会导致崩溃。这也适用于预览，所以要小心。

例如，这里有一个存储用户设置的可观察对象：

class UserSettings: ObservableObject {
     @Published var score = 0
}

使用通知中心将数据从一个视图传递到另一个视图。

观察者-收听者模式效果最好。另一种解决方法是在两个类中创建相同的对象。

在类1中创建类2对象。访问要传递的数据对象，设置它们，然后按下视图控制器。

OP没有提到视图控制器，但有很多答案都提到了，所以我想补充一下LLVM的一些新功能，以便在希望将数据从一个视图控制器传递到另一个视图，然后获取一些结果时更容易。

故事板片段、ARC和LLVM块使我比以往任何时候都容易。上面提到的一些答案已经提到了故事板和片段，但仍然依赖于授权。定义委托当然有效，但有些人可能会发现传递指针或代码块更容易。

使用UINavigator和segue，可以轻松地将信息传递给从属控制器并获取信息。ARC使传递从NSObjects派生的对象的指针变得简单，因此如果您希望从属控制器为您添加/更改/修改某些数据，请将指针传递给可变实例。块使传递动作变得容易，因此如果您希望从属控制器调用更高级别控制器上的动作，请传递一个块。您可以定义块以接受任何数量的对您有意义的参数。如果更适合的话，您还可以设计API以使用多个块。

下面是segue胶水的两个小例子。第一个简单明了地显示了传递给输入的一个参数，第二个用于输出。

// Prepare the destination view controller by passing it the input we want it to work on
// and the results we will look at when the user has navigated back to this controller's view.

- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
    [[segue destinationViewController]

     // This parameter gives the next controller the data it works on.
     segueHandoffWithInput:self.dataForNextController

     // This parameter allows the next controller to pass back results
     // by virtue of both controllers having a pointer to the same object.
     andResults:self.resultsFromNextController];
}

第二个示例显示为第二个参数传递回调块。我喜欢使用块，因为它将相关细节紧密地保存在源代码中——更高级别的源代码中。

// Prepare the destination view controller by passing it the input we want it to work on
// and the callback when it has done its work.

- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
    [[segue destinationViewController]

     // This parameter gives the next controller the data it works on.
     segueHandoffWithInput:self.dataForNextController

     // This parameter allows the next controller to pass back results.
     resultsBlock:^(id results) {
         // This callback could be as involved as you like.
         // It can use Grand Central Dispatch to have work done on another thread for example.
        [self setResultsFromNextController:results];
    }];
}