iOS RESTful application design pattern

It's perfectly clear that there is no such thing as a background service in iOS. That being said, I'm looking for a standard way to perform network requests under a design pattern.

From an Android background, Google I/O 2010 proposes the design pattern showed in the picture below.

It basically means that you shouldn't make a network request directly from the Activity, but instead send it to a background Service (the orange rectangle). The reason behind this, listed in this document, include the fact that the system might kill the Activity when the user leaves the screen.

Going back to what I said before, I'm looking for the standards or principles related to the design patterns of RESTful iOS apps, as I have noticed that an UIViewController might stop asynchronous operations when:

1. The user press the home button and the app closes (this is to be expected)
2. The device changed orientation

With this in mind, let's step into the scenario where we are making a file upload to a server, let's say it's a picture. The network request might take some time until it finishes and the user might as well change the device orientation or leave the app. How do we address this issue?

Note: I'm aware a solution could be just to use the delegate pattern by making the view controller the delegate of an API client class, but I feel this would violate the Single Responsibility Principle