9

Was there an app switcher or did you have to stop an app and start a new one?

Improve this question

4 Answers 4

Reset to default
15

The app switcher came with limited multitasking. Before that, you pressed the home button and the front program stopped running.

Improve this answer
4
  • 1
    oh, that must have been harsh.
    – Ian Warburton
    Commented Aug 31, 2016 at 14:59
  • 8
    It was actually better than multitasking through iOS 7 and sometimes, I still wish we had single tasking. Far more responsive to many tasks, @IanWarburton also, google images of t637i sony ericsson - that's what came before single tasking iOS.
    – bmike ♦
    Commented Aug 31, 2016 at 15:20
  • @bmike googling that exact phrase t637i sony ericsson brings up a lot of russia links but no links of phones etc. Is this just because my search history?
    – N.J.Dawson
    Commented Sep 1, 2016 at 11:04
  • @N.J.Dawson Try this link
    – bmike ♦
    Commented Sep 1, 2016 at 21:43
23

FWIW, Apple has always allowed some of their own apps or services to persist in the background, i.e. the Phone, Mail, push notifications, Find My iPhone, and so on, based on the need and functionality.

One thing to consider is that multitasking today on iOS is still limited, especially when compared to desktop operating systems (and perhaps some Android environments).

Beginning with iOS 4, Apple gives you the illusion that all your apps are running by having created the app switcher. While some of the apps may still be running, most are in hibernation, depending on what background tasks they've registered to run and what RAM is available.

The app life cycle has generally behaved like this since day one:

  • User taps app icon
  • Launch screen is shown
  • First screen (view) is loaded
  • User does stuff with app
  • User pushes home button (or, with later versions, tapped screen of another app)
  • Previously opened app gets signal that it is no longer in foreground
  • App gets signal that it's about to be suspended
  • App is suspended (state saved in RAM)
  • App's state is moved from RAM to disk (flash) when RAM fills up
  • User returns to app
  • If state is recent enough, state is reloaded from RAM or disk
  • If state is stale, app starts over fresh

Nuances in how state is dealt with have changed over the years, and developers have been increasingly given more control over what they can do in between states.

When people go through and "force close" all their apps, they essentially are throwing away any state saved by the app, and killing any background tasks that app may have started. Many think they are helping to reduce battery consumption and keep RAM clean, but Craig Federighi pointed out that by doing so they may actually cause more battery drain, since the CPU is doing more to reopen those apps every time instead of merely bringing them out of stasis.

Also since iOS 4, developers are now allowed to create tasks that can persist even if an app has been suspended, such as audio playback, monitoring network traffic (VoIP), background data refreshes, and location updates. This is effective because only a portion of the app is running and using resources.

As devices get more powerful (more CPU, more RAM, more storage, bigger battery) and as code gets more efficient, these additional tasks prove to be less of a drain on resources. Newer things like widgets and the forthcoming Siri, iMessage, and CallKit extensions can make it appear like popular apps are always doing something in the background.

Improve this answer
3
  • 2
    Sorry, I believe you are wrong. Do you have a reference for your claim that the app state is saved from RAM to disk ? Nothing is saved to disk unless the programmer does it.
    – Antzi
    Commented Sep 1, 2016 at 8:55
  • Antzi is correct, iOS doesn't use swap space. When the device is running low on memory, it tells applications to reduce their memory use. If they fail to free up enough space, they are terminated. The operating system doesn't move data from memory to disk, it expects applications to do this. developer.apple.com/library/mac/documentation/Performance/…
    – MJeffryes
    Commented Sep 1, 2016 at 10:19
  • Perhaps I muddied the waters a bit in my attempt to simplify. There is undoubtedly some kind of read/write cache in RAM to accelerate disk access. If the app has any state to save before it gets terminated, I would expect the OS to buffer the app's state writes until it deems it appropriate to flush those writes to disk. So yes, the app is responsible for saving whatever state it wants (which views are open, what document was up front, etc.), but it hands that data to the OS, which in turn hands it to physical storage.
    – Bryan Scott
    Commented Sep 1, 2016 at 22:23
7

Initially, iOS did not have multitasking. Their first attempt was in 2010 (holy crap!). The iPhone just didn't have enough ram and wasn't optimized for it. In 2010, Apple enabled the core apps to multitask, but not 3rd party. I remember jailbreaking my device to bypass that to allow all apps to multitask, but it was buggy. iOS has come a long way folks, with 64bit processing and better memory management.

For further reading, take a look at the Wikipedia article.

Improve this answer
2
  • 1
    Being based on OS X, iOS has been multi-threaded since launch. For developers the NSOperation group of classes have been public since iPhoneOS 2 (the first SDK that 3rd party developers has access to). As for garbage collection, iOS does not and has never supported memory management by garbage collection. Instead iOS uses ARC memory management (or if a dev chooses they can use manual memory management). This is one of the chief reason iOS devices are able to be competitive against Android device which have significantly more RAM.
    – alexkent
    Commented Sep 6, 2016 at 17:31
  • You're right, wrong terms. Corrected my answer.
    – megamaiku
    Commented Sep 6, 2016 at 20:40
1

First off --- iOS being a Unix flavor, very similar to the Mac OS, has ALWAYS been "multitasking" in the deepest sense. Many processes run concurrently on the iOS device all the time.

What was limited is USER INTERACTION with programs. User could not interact with more than one program at any given time.

Also, even in the old times, where pressing "home" was needed to switch from one app to another - the old app was NOT killed. It was moved "to the background", which means - it has no access to the screen, keyboard, camera, etc. and it can maintain only very little system resources while in the background.

To completely quit an iOS App you had to double tap the home button and when all running apps started to shake, you could press the little "x" to kill them one by one. Only then apps were really killed.

The reason for this UI decision, was that only this way Apple could achieve good UI responsiveness and battery-life, with the very very limited system resources of older iOS devices.

The situation hasn't really changed much since then - only in specific scenarios, background applications receive little more resources to keep on going (networking in the background, Audio playback in the BG, picture-in-picture, and so on).

System is multitasking as ever, but UI allows more complicated scenarios of more-than-one app partially visible to the user at the same time.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .