Daniel Eran Dilger in San Francisco
Random header image... Refresh for more!

iPhone 2.0 SDK: The No Multitasking Myth

200803130018-1
Daniel Eran Dilger
Certain pundits have developed a rash of malignant concerns about iPhone 2.0′s SDK. The first issue they’re scratching at is the iPhone’s apparent inability to run multiple applications at once. The suggestion is that the iPhone is a multitasking impaired appliance just like the original Mac or the Palm Pilot, and unlike the supposed multitasking powerhouse that is Windows CE, which powers Windows Mobile devices. That’s wrong, here’s why.

Auf Deutsch: iPhone 2.0 SDK: Der „kann kein Multitasking“ Mythos
Übersetzung: digital express


The iPhone is Unix.
The first clue into discovering how the iPhone works is a look at its core OS. The iPhone runs Apple’s same kernel as Mac OS X: a hybrid of Mach and BSD that hosts a standard Unix subsystem. It supports multiple concurrent processes and multiple users.

At this point, it’s useful to point out that the Palm OS was also built on top of a multitasking kernel, but Palm only licensed it for use from Kadak as a single-tasking environment. That made the Palm OS very much like the classic Mac OS from the mid 80s: to launch a second application, the first had to be shutdown.

Apple doesn’t face the same problem with the iPhone; it owns the iPhone’s kernel and faces no other external technical limitations to prevent multitasking. The ability of the iPhone to answer a call, pull up the Maps app while the call is in progress, and then follow a link to a web page before ending the call was demonstrated in one of its first advertisements.

The iPhone rings when browsing the web, music plays in the background while performing other tasks, and can check emails periodically in the background. It can clearly multitask. So why does Apple state in the SDK docs that “only one iPhone application can run at a time?” For starters, it is useful to point out that the iPhone does not suffer the same architectural problems as the Classic Macs or Palm Pilot.

iPhone OS X Architecture: the BSD Unix Userland
The Egregious Incompetence of Palm

Multitasking Macs before Unix.
The original Mac didn’t have the resources to run multiple applications at once. The first Mac users quickly found that running one application at a time was indeed a serious limitation. In 1985, Andy Hertzfeld developed a utility called Switcher that allowed users to pause the running application and start a new one. By 1987, Apple released MultiFinder, which allowed Macs to display multiple concurrent applications and rapidly move between them.

However, the Classic Macs weren’t doing Unix-style preemptive multitasking, where the operating system strictly manages the processing resources given to each running application. Instead, the system relied upon applications cooperating to take turns on the processor; if an application fell into a loop, it could cause the whole machine to stall.

That doesn’t happen in Unix because processes aren’t trusted to cooperate; they are explicitly managed by the kernel. If they stop working, they are bypassed and can be purged from the system. The only process that can freeze the system is the kernel itself, which is why all software in the kernel has to be extremely stable. That’s also why Apple discourages developers from writing kernel extensions unless they are really necessary.

Folklore.org: Macintosh Stories: Switcher

Just Because You Can, Doesn’t Mean You Should.
The iPhone has the same Unix ‘kernel in command’ architecture. However, just because the system can run multiple concurrent applications doesn’t mean it’s a good idea to allow developers to load up all the processes they care to run in the background

In Mac OS X, opening lots of concurrent applications isn’t usually a problem. If the system runs out of RAM, it can page inactive applications onto the hard drive using Virtual Memory, where they can hibernate until they are called to activity again.

The iPhone has the same virtual memory system, but doesn’t have gigabytes of RAM or a hard drive to use as a Virtual Memory swap space. Instead, it has 128MB of RAM, of which something like 11MB appears to be used for VRAM and 19MB looks to be used by system overhead, leaving around 76MB reported by sysctl as user memory.

By limiting the amount of background processes running, the iPhone’s OS X can offer more of that available RAM to the foreground application, along with a less distracted processor. The iPhone is not a general purpose computer; it is primarily a phone, browser, and iPod. Due to the restrictions imposed by the SDK, it will also be a credible gaming platform and pack the power to run significant productivity applications, all without giving up the ability to be a responsive phone, browser, and iPod. Other devices can’t make that claim.

furbo.org · What the iPhone specs don’t tell you
The Microkernel Myth

The Problem With Background Processes.
While the iPhone has around twice as much RAM as the typical smartphone, 76MB is easy to eat up if you have lots of background processes running. In addition to RAM, those processes will also consume the processor power available for media playback, WebKit rendering, telephone audio and radio signal processing, VoIP data encryption, and processes listening for push email, incoming calls, SMS messages, or configuration information, all of which are critical features that users won’t be happy about if they aren’t all working flawlessly.

In addition to taking up bandwidth important to the core operations of the phone, extra background processes will help keep the processor consumed, which means it will be running hotter and eating up more energy at all times, resulting in a shorter battery life and perhaps a shorter device life as well.

Apple has a responsibility to iPhone users to develop guidelines that ensure that the system continues to work as expected, doesn’t overheat, and doesn’t plunge in battery life as new applications are installed. Not allowing third party developers to install background processes is part of that plan. It would be irresponsible for Apple to kick open the floodgates for developers and then blame users for not understanding how to manage their own process allocation within the iPhone’s thermal envelope and resource constraints.

iPhone OS X Architecture: the Mach Kernel and RAM

iPhone OS X Architecture: the Mach Kernel and RAM

The Problem with Foreground Multiprocessing.
In addition to the processes running in the background, there’s also an issue of running multiple applications in the foreground. Of course, the iPhone does appear to run multiple foreground applications at once. While on the phone, you can return to the home screen and launch in and out of other apps. During the entire call, a green strip appears at the top of the screen to act as a quick hyperlink back to the call progress screen.

iTunes will also play audio while other apps are running (although this will anecdotally make it more likely for Safari to crash while it navigates between web pages). At any time, the Home button can be double clicked to bring up an iPod playback controller screen overlay.

In both examples, the shared, concurrent UI presented is rather limited. This is no accident. Not having any other applications running concurrently not only gives the active app and critical background processes more resources, as noted above, but also greatly simplifies the UI for the user.

The persistent phone call is unique in that the iPhone is primarily a phone; the iPod features are also a key element of the device. However, if every application could reserve a spot at the processor table, there frequently wouldn’t ever be anywhere to sit. Even worse, the iPhone’s display isn’t really big enough for apps to share. Of course it could, but thank Apple for knowing better than to crush applets into the same screen with an interface inappropriate to a handheld mobile device.

Rocket Launching.
The idea that the iPhone should let apps decide what they’re going to do when asked to leave, rather than setting an enforced system policy, might sound good but isn’t well thought out. Apple’s decision is to do with third party apps exactly what it does to Safari: when the user hits the Home button, the system saves the currently running application’s data, quits the app, and presents the Springboard menu of apps. When the app is next launched again, it starts up from where it left off.

Because the launch time is so rapid, there’s really no difference for users between trying to leave an application running in virtual memory and simply quitting and then relaunching it again later when needed again instead. The technical difference is that quitting apps results in better use of resources, including better battery life. Users will notice that.

That’s why Apple decrees in its SDK: “Only one iPhone application can run at a time, and third-party applications never run in the background. This means that when users switch to another application, answer the phone, or check their email, the application they were using quits.

Invent, Suggest, Panic!
Non-engineering savvy blogs such as the ironically named BoyGenius Report have joined arms to sign up petitions demanding equal rights for third parties’ applications to run in the background and not have to quit when users switch between apps. Sounds good, but do they know what they’re talking about?

Zach Epstein spelled out his fears of the potential doom of “no true multitasking” on the iPhone by citing developer Robert Balousek as saying, “If you are running an application such as AOL Instant Messenger on your iPhone, every time you receive a call or browse away from the application you would be signed out, you would lose any unread messages, and your conversations would end.”

However as Christopher Cox noted, “the author of this article is exagerating big time [...] the app will be able to suspend and save current data when something interrupts it. When you go back, your old messages will still be there. [...] the AIM server doesn’t actually disconnect you unless your program sends a disconnect signal or you are not connected within a specific timeout. This means it can pick right back up where it left off when you come back to the application (and you don’t initiate a re-connect). The only disadvantage this brings from the norm are if you want to stay on AIM 24/7 in the background or other daemons. This will not be a show stopper for most people.”

iPhone SDK Honeymoon Over – No Background Processes?! | The Boy Genius Report

What Would Happen If Apple Didn’t Know Any Better.
While it’s comforting to know that iPhone SDK panic related to multitasking is overblown and ill informed, is it still possible that the iPhone might be much better off without Apple’s engineered limitations? There’s no need to speculate. We already can get a clear picture of how disastrous things would be if the iPhone were engineered by a committee primarily interested in pleasant sounding buzzwords; that picture is delivered by Microsoft in WinCE.

Microsoft conceived of WinCE as offering a multitasking architecture like Unix, but despite giving it a paged virtual memory architecture, it still only supports 32 concurrent processes and each is limited to its own 32MB virtual address space. This is supposed to be addressed in WinCE 6.0, which should be available in a couple years. Until then, multitasking in WinCE is fundamentally flawed. Of course, it gets worse than that.

In addition to Microsoft’s architectural limitations that stymie developers from making efficient use of its multitasking features, WinCE proves that the general idea of having no limitations on third party background processes and concurrently running applications on a handheld device is a bad idea for a number of reasons. The first relates to the resource issues I already raised. In the words of WinCE Enthusiast Chris De Herrera:

There are times when having multiple applications running at once causes the foreground application to slow down noticeably. This slowdown is due to the amount of time that the operating system is spending servicing background applications. In these instances, I recommend that users consider performing a soft reset.

Like kill on the road,
Windows has failed to respond.
Control! Alt! Delete!

But there’s another reason why running multiple applications together on a mobile is stupid: there’s no room to see them at the same time. Without the screen real estate, there’s not enough pixels to support a desktop style arrangement of multiple overlapping windows as introduced by the Lisa, with close boxes and title bars to switch between the windows.

That reality hasn’t stopped Microsoft from trying to crush its clone of the Mac desktop UI into tiny screens since the late 90s, but it did result in making those efforts unsalable. WinCE devices are plagued with complexity to the point that it’s hard to get anything done with them. They crash frequently and have abysmal battery life. The iPhone is so plainly simple that it’s easy to pick it up and start using productively without any training. It just works. If Apple had tried to force in the same Dock and menu bar and Finder desktop and floating windows from Mac OS X, the iPhone would have been tragically unusable as well.

The Spectacular Failure of WinCE and Windows Mobile

The Spectacular Failure of WinCE and Windows Mobile

Less is More; More with Less.
So while the iPhone has a better multitasking kernel than WinCE, its engineers knew better than to deliver a system like Microsoft’s, which could seemingly do everything on paper, but in reality could do nothing very well and subsequently couldn’t sell either. Instead, the engineered limitations of the iPhone 2.0 SDK will make the device more useful to users.

Even before the new software’s availability, the existing iPhone is already outselling Windows Mobile phones in the US with a 27% share of the market and a whopping 71% share of all mobile web traffic.

And just as with the desktop PC, Microsoft will find it impossible to back away from its legacy of complexity to offer anything remotely similar to Apple’s iPhone in WinCE, because existing Windows Mobile applications all assume the right to hog the processor in the background and keep Windows Smartphones running slow, inefficiently, and awkwardly complex enough to only appeal to the most devoted of Windows Enthusiasts.

When they complain that the iPhone doesn’t share the same problems, it should now be more clear why practical simplicity is such a difficult concept for them to understand.

Apple’s iPhone vs Smartphone Software Makers

Apple’s iPhone vs Smartphone Software Makers

More on the iPhone 2.0 SDK

iPhone 2.0 SDK: The No Multitasking Myth
iPhone 2.0 SDK: Java on the iPhone?
iPhone 2.0 SDK: How Signed Certificates Work
iPhone 2.0 SDK: Video Games to Rival Nintendo DS, Sony PSP
iPhone 2.0 SDK: Readers Write on Certificate Signing

I really like to hear from readers. Comment in the Forum or email me with your ideas.

Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!

Technorati Tags: , , , ,

126 comments

1 kusmi { 03.13.08 at 5:01 am }

I think, Apple might come up with somthing to allow some sort of background apps in the future.

Just look at Apple’s launchd (launch deamon), which is a replacement for cron and other lauching services on MacOSX. It already allows to watch for an incoming TCP connection to a specific port (e.g. 22 for SSH) and in case someone connects to it, it will automatically launch the corresponding SSH server. This means, the SSH server does not need to run all the time in the background. It will just be launched, when a request comes in.

Similar things could be done for the iPhone: No application needs to be running in the background, but in certain cases, the “launchd” of the iPhone will just lauch a certain application.

Of course the current version of launchd is still quite limited (e.g. it would not allow “monitoring” an active TCP connection and trigger an application launch, when a special TCP packet is coming in, does not send any keep-alive messages, etc.)

BUT: It could be, that Apple might building such functionality into launchd? I could also think of adding other functionality into launchd, e.g. the recent LocationServices from iPhone (you could then think of configuring launchd, to start you application, if the user just entered a specified location)

2 pinion { 03.13.08 at 5:03 am }

Hey Daniel,

Long time reader… first time poster.

I agree completely that the hysteria over the lack of “true” multitasking is WAY over blown. However, I would expect a compromise to emerge from Apple at some point in the near future. What I have in mind is some (limited) ability to register events with a kind of system daemon. There would obviously have to be constraints on the interval time that these events would check for updates, but at least functionality like this would allow for some type of background notification to third party apps.

For instance, in the case of the AIM client… if the user switched applications then the AIM client would save its state and unload from system memory (without sending a logout message to the AIM server). With a daemon sitting in the background checking for new messages periodically (at whatever interval Apple allowed?) the user could be notified for new incoming messages.

I’m not very versed in the technicalities of any of this, so I’m not sure what the most prudent solution is, but my hunch is there is some type of same compromise out there.

3 starkruzr { 03.13.08 at 5:50 am }

Less is not always more, Dan. An example of a really popular, really well-done application that will be impossible with the official SDK is MobileScrobbler.app, the iPhone implementation of the last.fm client. Currently it’s available for jailbroken iPhones and iPod touches, and it is a really, really slick piece of software. It runs as a daemon in the background and listens for MobileMusicPlayer.app to start playing something. When it does, the scrobbler takes note of what you’re listening to and queues it up for submission to your last.fm account.

In the foreground, it can also play last.fm radio or scrape various data from your profile and present it to you. It’s really well-done and I definitely recommend you take a look at it to get an idea of what I’m talking about.

Of course, the Apple SDK defeats a lot of the rest of the purpose of having UNIX on your cell phone, too. Gone will be local file access, apparently — each app only gets its own sandboxed storage. Gone will be sshd, pure-ftpd, afpd, daemonized RSS (for downloading feeds in the background on a schedule), almost certainly Terminal and a host of other things that make my currently jailbroken 1.1.4 iPhone indispensable.

It’s great that the iPhone is such a wonderfully successful consumer toy. But more advanced users like you and I see a much, much bigger future for OS X Mobile if it’s allowed to flourish. It can easily be everything to everyone without ruining anyone’s experience. The problem, I’m afraid, is Apple’s ideology getting in the way of innovation.

4 Jon T { 03.13.08 at 6:03 am }

I’m curious. Couldn’t Apple up the iPhone RAM to 500kb or even 1gb if they wanted too?

Thanks for another myth busted Dan.

5 Jon T { 03.13.08 at 6:06 am }

starkruzr said, ‘Apple’s ideology’ is the problem.

Perhaps we should take that to mean that they want to prove it all works without promising the world a la Microsoft and simply never delivering.

6 Wim Leers { 03.13.08 at 6:18 am }

I’ve come accross a minor content error:
“In addition to taking up bandwidth important to the core operations of the phone, extra background processors will help keep the processor consumed”

That should be “extra background processes”.

Thanks for the interesting article! I’m sure that Apple will increase the CPU power and the amount of RAM over time. Multi-tasking will come, just not yet. Perhaps it’s already possible, but it’d push the price tag too far up.

7 starkruzr { 03.13.08 at 6:30 am }

I’m not sure what you mean, Jon. Apple would be entirely capable of delivering a full featureset; the fact that it exists on jailbroken phones/iPods right now is proof of that. They simply chose not to, because of their ideology.

What ideology? The concept that less is always more; that simple is always to be chosen over feature-rich.

This is actually a recent development. This ethic is nowhere to be found in Mac OS X, which is a beautiful synergy of the elegantly simple and staggeringly powerful.

The standard answer to this observation when applied to cell phones is “it’s just a phone.” It is manifestly not. Mobile OS X machines can do more than Windows 3.11 machines could do 15 years ago; a LOT more, actually. The iPhone and iPod touch have an enormous amount of computing power available for their size. They are not the delicate little flowers Apple and AT&T would like you to believe; in fact, many cell phones and other handheld devices these days are not. The popular perception that Mobile Computing Sucks(TM) is not due to inherent limitations with these devices but rather a horrible dearth of good software and good design (c.f. Windows Mobile and Palm OS). Apple has given us both of these and held out on the functionality — STILL, with the arrival of the native SDK. It is frustrating and not a little puzzling.

At least, it’s puzzling unless you’re a conspiracy theorist like I am. :)

8 John Muir { 03.13.08 at 6:32 am }

@starkruzr

Well I agree that less is not *always* more, but that wasn’t the article’s point. There’s one huge engineering and usability tradeoff here between a free for all approach like on the resource rich Mac, and a well regimented lockdown which makes the iPhone so well behaved an iPod and phone.

You get one *or* the other. You do not get both.

Fortunately for MobileScrobbler users and the like, jailbreaks have become such a hobby among a certain iPhone niche – not withstanding the vast majority of hacked iPhones run no extra software but just take foreign simcards for unlicensed markets – so it’s safe to assume that hacked iPhones are here to stay for quite a while to come. Presumably you can run all the hackware you want, managing resources you understand yourself, while not troubling Apple and its millions of mainstream customers with the consequences. In that case the tradeoff is broken and we have a winner!

I have the SDK myself and while delving through the docs I’m continually intrigued with new app ideas which seem to be suggested by these rich frameworks. The AIM example above is a good explanation of a convenient workaround when the one-at-a-time rule does come into play. That is until iPhone 5.0 has a couple of gigs of RAM and presumably some sort of hologram screen we can expand whenever necessary. ;)

9 OlivierL { 03.13.08 at 6:51 am }

Go and look Android SDK presentation video. They present their multitasking model : applications are pushed and poped, saving their previous state whenever a push or a pop is done. This way, the phone just keeps a state stack in memory. It can close when it needs memory or launch an application to restore it to its previous state when reverting to this application.

In the iPhone SDK videos, the same concept is used when handling UIViewControler instead of directly using UIView. The UIViewControler holds the UIView state. When the fmk calls the UIViewControler to be displayed, it creates the UIView to be displayed. When the fmk tells the UIViewController that it is not displayed anymore, it can destroyer the UIView, freeing memory and ressources, just keeping the bare minimum state.

10 OlivierL { 03.13.08 at 7:09 am }

“Of course, the Apple SDK defeats a lot of the rest of the purpose of having UNIX on your cell phone, too”
So, for you, having UNIX on your cell phone is just about going dirty on your phone inner working (file, ftp, terminal), etc …

For me, the point of having a REAL OS is not to be able to get back to the old computer paradigm but to, at least, get all the good things a computer have : a powerful environment.

The iPhone/iTouch is a device in my opinion : you just take it and it works. You don’t even have to power it up. I don’t care about file system, terminal access or multithreading on my iPod. I want it to play music and allow me to browse thru my music at any time. This is the kind of user experience I want on my iTouch.
The desktop computer is a general purpose computing device. Because of its nature, it should be able to do anything. This is its purpose. For historical reason, we have grown accustomed of having our computer crash, hang or reboot for no reason. This is wrong. I don’t want to get used to have my phone have such a behavior (this is too late, I’ve already accepted that I have to hard reset my Samsung i320 at least once a week).

Now, if Apple have to put limitation so that the iPhone/iTouch platform ends as a really user friendly device, then I’ll accept those limitations. Because right now, even before 3rd parties application are available, my iTouch has proved to be a much better device that my WinMobile phone has even been.

So, if I have only 100 applications availables but those 100 applications are smooth, stable, great and add value, this is much better than having 1000s of shaky, crappy and barely usable applications. I like my hammer better than my WM phone because, even if my hammer can just drive nails, it has never failed me while my phone regularly prevents me from calling.

11 OlivierL { 03.13.08 at 7:11 am }

The only 3rd party application I’ve installed on my WM phone is a process explorer so I can kill apps when my phone becomes hysterical !

12 Rich { 03.13.08 at 7:18 am }

Haha, I came on here to extol the virtues of MobileScrobbler but starkruzr beat me to the punch. :)

MobileScrobbler is the only reason why my iPod touch is jailbroken. It’s such an incredibly useful and easy to use piece of software. I’d love to see Apple create their own version of last.fm but for now last.fm does the job nicely. As starkruzr said, it’s a background process and therefore won’t be possible with the SDK. That really annoys me as jailbreaking my touch every time a new firmware is released is a pain in the ass.

I haven’t seen any slowdown or significant battery loss whilst using the app either.

As an aside, my Nokia N95 8GB will happily run 10 applications without running out of RAM and switching between the applications is child’s play. Multitasking is one area where Nokia have got things spot on although it’s taken them many years to get it right.

13 Dalekrium { 03.13.08 at 7:47 am }

Something to consider is that no one said that Apple would never allow background process. Just that at this moment is not allow. I can see several methods, a special review procedure for programs with background subprocess, better wait until the first tsunami of apps arrive in June. A especial program slot with a limited number of “background” process allowed and some very specific resource limitation in each one of them, and a very specific procedure about how to kill them and how must be check if available to run before even trying, or the limitations and a special and more thorough procedure to apply. That are some of the examples I could think of and I am sure there is a lot a intelligent people that could think of other solutions

But what’s for Apple doing that just now. They would get a ton of new applications any case, and they could work with several developer what are the optimal compromises for the background process.

To lift restrictions is always a lot easier that to forced it a posteriory

14 duckie { 03.13.08 at 8:38 am }

Alas, multitasking is one area where Nokia still don’t have it right. I was running their VoIP app recently on an E61 and had to disable it because the battery was running red hot and out of juice in an afternoon (this is just as a background task, making no calls).

While it would be lovely to run last.FM style apps that are well behaved, what happens when you’ve installed 5 or 6 such apps and the cumulative effect is starting to impact on the performance of the phone, battery and other standard apps? Fine for technically adept users such as the ones that contribute here, who can locate the issue and terminate as necessary, but the majority of iPhone customers are not. In fact the reason most of them bought one in the first place is because they don’t have to understand or think about such issues, so allowing a free-for-all for developers would probably put a serious dent in Apple’s credibility as anecdotal evidence grows about how “iPhones aren’t as reliable as they used to be” – translation “I’ve installed loads of apps and I don’t understand what they’re all doing in the background”.

I think it’s the right decision.

15 Rich { 03.13.08 at 9:12 am }

“Alas, multitasking is one area where Nokia still don’t have it right. I was running their VoIP app recently on an E61 and had to disable it because the battery was running red hot and out of juice in an afternoon (this is just as a background task, making no calls).”

The E61 is about two years old now. I’m talking about the very latest phones like the N95 8GB and N82.

16 duckie { 03.13.08 at 9:21 am }

Sorry, I meant to say E61i, which is less than a year old, about the same as the N95. So my criticism still stands. I’m glad your N95 is working for you though.

17 countach { 03.13.08 at 9:45 am }

I’ve never heard of a networking program that can stay logged in when the program quits. When a program quits, the socket closes. I’d be surprised if AIM can do that. Even if it can, it would not be typical of networking applications.

What is a myth it seems to me, is that having multiple running programs need take up resources. An idle program doing nothing, or even nothing but listening on a socket, should take no resources except swap space. You don’t want too many programs sucking up that 8GB, but hey 8GB is a quite a bit, and there are so many neat things you can do with background processes, there is no need to be too precious with it.

Having the program quit might be a good general policy, but it doesn’t make for a good hard rule.

As for multiple programs taking up screen real estate – again, good general rule, but what if I WANT a program to give me asynchronous notification of something? It’s a legitimate need.

Sorry, but I find this article to be FUD.

[An 8GB iPhone has that much Flash storage; apps don't run in Flash storage, they run in the available RAM, which is 128MB worth of chips that apparently supply a user environment with about 76MB.

I outlined reasons why quitting apps rather than leaving them in the background running is a good general rule; perhaps you can elaborate why you think it isn't rather than just decreeing that it is not. As you do so, keep in mind that iPhone 2.0 is SDK 1.0. It's a lot easier to add complexity later than to invite trouble and then try to sort things out after the fact. See also Palm, Windows Security, WinCE, etc. - Dan ]

18 ewelch { 03.13.08 at 11:11 am }

I’m thinking that as Apple expands the iPod Touch into more powerful mobile platform with larger screen real estate, with more RAM, etc., it can start adding capabilities such as multitasking.

A phone, on the other hand, needs to be snappy and speedy all the time. So I accept the argument set forth here that there are limitations so that people don’t get bogged down in things that have nothing to do with it being primarily a phone, browser and iPod.

I wonder when people are going to start whining about how Apple screwed up because their jailbroke phone is sluggish and hangs. We’ll just point and laugh.

19 John Muir { 03.13.08 at 11:37 am }

@countach

128 megs of RAM and *that is it*. No swap. No borrowing from that tasty bank of flash. Just RAM. I’m sure Apple have their technical reasons for that. They make no secret about it in the documentation. Daniel is pretty much saying exactly what they’re saying to devs.

@ewelch

I wouldn’t count on the iPhone and iPod touch drifting into incompatibility anytime soon. Indeed, Apple seem to be taking the most practical approach they can to ensure this platform gets traction and apps. Currently the only differences between running your app on iPhone and the touch are the lack of camera and lack of microphone input. Everything else is the same: resolution, processor, memory, API’s. That makes support for both automatic. This is one hell of a well thought out advantage to surrender to differentiating the touch as some sort of superior tablet.

The general Mac web consensus is that there is a tablet Mac in the works. I’m not so sure about that, but it is more plausible than splitting the touch platform from right after the get go. The Mac is clearly the better platform for model differences.

20 UrbanBard { 03.13.08 at 11:39 am }

The only problem that I ever had with the iPhone hackers and unlockers was a persistent refusal to accept responsibility for their actions.

Apple sells a product and says how it can be used under warranty. The FOSS community latches onto the iPhone as a hand-held computer and immediately acts to use it in ways it was not designed for. That is all well and good if the hackers take the responsibility for when things break. But they didn’t. It was their actions which “bricked” the iPhone, not Apple’s. But, they tried to childishly push the responsibility onto Apple when they broke their warranty.

Now, Apple has delivered an SDK which has limitations on how the iPhone can be used as a handheld computer while under warranty.

Again, these same people bridle at any limitations. Fine. Complain all you want, for all the good it will do you. Hack your iPhone to get around the SDK. Just stand up like a man and take on the responsibility when you do.

21 gus2000 { 03.13.08 at 11:47 am }

Loading up the iPhone system resources with background craplets seems bad. Resources are limited, not the least of which is the battery.

Still, Apple does do some things in the background, such as run the stopwatch for months at a time, or check for mail on a schedule.

You would think the SDK would permit scheduled background jobs, or at least a “launchd” style of event-response. But I’ve not delved into the SDK deeply enough yet.

Still, I wish there were some things I could run on a schedule. For instance, I wouldn’t mind if the stocks and weather were updated hourly. It would be even nicer if the Home-screen icons were updated with that information also, so that I could get the info at a glance.

Regardless, I expect creative individuals to come up with solutions. There is already a solution for last.fm, which is to sync when you dock your i(Pod/Phone). If the market determines that the limitations are too much, then Apple will be forced to re-evaluate their position. At the moment, the limitations do not seem to be slowing anyone down.

22 gus2000 { 03.13.08 at 11:53 am }

countach wrote: “Sorry, but I find this article to be FUD.”

Ummm, I don’t think that word means what you think it means.

23 lehenbauer { 03.13.08 at 12:03 pm }

Most of the bitching I’ve seen appears to come from trolls. The developers I know and people who are considering taking it on understand the need for the restrictions and can pretty much live with it.

Perhaps down the road Apple will create some sort of remote notification/activation mechanism for stuff like AIM, maybe not where it auto-launches the app back but can at least put a “1″ with a star around it on the icon and play a sound or something.

24 dicklacara { 03.13.08 at 12:03 pm }

About screen real estate… The original Mac had a 512 x 342 pixel, 9″ diagonal display– 175,104 pixels

The iPhone has a 480 x 320 pixel 3.5″ diagonal display– 153,600 pixels

So, while the iPhone display is 61% smaller than the original Mac, it only contains 12% fewer pixels

It’d be kinda’ fun to see the original MacWrite and MacPaint running on the iPhone… better than the BSOD!

25 addicted44 { 03.13.08 at 12:04 pm }

Starkruzr, and OlivierL are completely missing something. The jailbroken iphone did not have an SDK that was downloaded over a 100,000 times in a couple of days. The jailbroken iphone was not available to every iphone user. And the iphone was jailbroken only by above average users, who knew what they were doing.

Unfortunately, none of these conditions are true with iphone 2.0. The large no. of developers (especially the windows ones) will lead to the development of badly coded software. Apple does not want that to ruin the iphone experience.

Also, I dont see how people have missed this, but Apple has quite clearly shown a pattern of slow but regular improvements with the iphone. They have created an SDK for it in less than a year (creating an SDK is HARD work. Completely ignoring the code itself, and all the testing, the documentation is extremely rough, and they already have an HIG for it), and have continually made improvements. There is NO reason to believe that multi-tasking will not be added in the future, once Apple has solidified the stuff it is currently working on.

26 David Dennis { 03.13.08 at 12:25 pm }

It would surely be nice to have a two-part AOL IM application. The user interface part, which takes all the resources, would be managed as Apple wishes, but there would be a very small application that reads data from the socket and adds a badge to the home screen (like the “Mail (1)” you see when you have mail) saying you have new messages.

Problem is, the data would have to be continuously read to get the alert up on a timely basis, so the launchd solution really wouldn’t work. You have to have a continuously running background process.

What I wonder is if this would manage to mess up the phone’s performance. There is no doubt at all in my mind that there really isn’t room for any kind of heavy background processing but simply receiving messages and saving them somewhere where they could be picked up seems like a reasonable idea.

In short, I’m sure that if we were told that we could have very tiny background applications to supplement user interface applications, that would be a workable idea.

But as others have said, eventually too many of these applications would bog down the CPU of your phone. I have already noticed that it can get bogged down when you have too many Safari windows open and so I can understand why they want to do this.

I suspect this will be one of those “big company options” where for a fee AOL will be able to do what it needs to. That will ensure that few background processes will exist. I’m not against this because for most applications you won’t need it.

We can gripe all we want, but I think Apple’s given us more than we can get on any other phone, and that should make us happy indeed. As others have said, hopefully when iPhone gets more powerful processors, we can get even better support.

I have a quick suggestion.

That application running in the background that sends information to last.fm might be retained by simply duplicating the iPod functionality of the device. Pretty much every cool special effect you see there is exposed to you and so building a doppelganger application that then sends your preferences to last.fm would probably be easier than building a working background process!

I know there are flaws to this – when you receive a call, your fake iPod goes into the background and terminates, while there is background music playing on the real thing. But I think it might be cool to try and see how far you can get.

For the nice fellow who said “Mobile OS X machines can do more than Windows 3.11 machines could do 15 years ago; a LOT more, actually.”, you are right. However, we don’t want our phone to work as badly as Windows 3.11 machines did. The crashy applications, the dysfunctional multitasking and the endless UAE errors are mercifully obscure in my mind, but I do remember the experience wasn’t fun.

When I jailbroke iPhone and ran third party software on it, I noticed that it would often slow down due to erratic third party applications. I think Apple’s approach will fix this and keep my iPhone fast and safe … and that’s what we all really need, or third party applications will get a bad rap everywhere, just as they have on Windows Mobile. (Palm doesn’t count because it doesn’t have multitasking at all.)

D

27 John Muir { 03.13.08 at 12:27 pm }

@dicklacara

Sorry to contradict you, but the original Mac was 512×384=196,608 pixels, which puts it further ahead of the iPhone: which only has 78% of the pixels.
http://docs.info.apple.com/article.html?artnum=112162

You’re quite right about revived editions of old Mac classics. Afterdark anyone? ;)

28 punkassjim { 03.13.08 at 2:03 pm }

I’m a big fan of the game plan Apple is using. By taking slow steps in the right direction, leaving out certain things so that we can all make the most of what we’ve got to work with, they’ve proven two things: 1) we’re far more capable than we thought we were with web applications, and 2) the platform is already damned impressive as it is, the possibilities are nearly limitless.

But see, taking it slow is necessary in order to not screw it up. And I think they’ve got that luxury, since they smacked it out of the park in terms of hardware. What we cannot accomplish with SDK-driven apps, we will be able to do with our grass-roots jailbreaking efforts. The problem is, since all the “above average” users have gotten used to wide-open access to the file system and frameworks, it’s gonna feel like a huge step backward to accept Apple’s SDK and its inherent limitations. But you’ve got two reasons to jump in with both feet: 1) you’re gonna make an ass-load of money through the AppStore, and 2) your development is gonna be much, much easier now that you can do it in Xcode.

29 glenn { 03.13.08 at 2:12 pm }

What I think is really interesting is that for all this excitement about the iPhone SDK, few people seem to realize that ultimately this is not about the iPhone or iPod Touch of today, but about this new Apple Platform that apparently will include the “Newton” reborn device with larger screens and more advanced processors.

30 dicklacara { 03.13.08 at 2:26 pm }

@John Muir

The link you provided says the video memory is 512 x 384… but the note at the bottom says the screen size is 512 x 342

Also, I used the following:

http://www.aresluna.org/attached/computerhistory/articles/macintoshbytereview
-Dick

31 John Muir { 03.13.08 at 2:35 pm }

@dicklacara

Ah, I see you know the ways of the Macintosh. :D

The closest experience I’ve had to the 128k Mac is fun and games in Mini vMac, an emulator. I played around in that as a study aid while reading Andy Hertzfeld’s Revolution in the Valley. Honest!

You could get a whole lot done with that dinky little screen … not to mention teeny weeny 1024 times smaller than an iPhone’s RAM. I can so see Mac Paint and a few other old favourites appearing on the iPhone in free form. Too much monochromatic fun to miss.

32 beanie { 03.13.08 at 2:39 pm }

1GB DDR SDRAM Samsung reported by iSuppli teardown of iPhone. If I recall the serial number on the RAM matches Samsung 512MB DDR SDRAM and there are two of them stacked on top of each other which makes 1GB.

Interesting the iPhone system only reports about 128MB. So what happened to the rest of the RAM?

33 John Muir { 03.13.08 at 2:53 pm }

@beanie

Perhaps the other 896 megs are all reserved for Apple’s secret background process: a distributed Folding@Home style number-crunching project to perfect the design of the next iPhone?

Or perhaps bits and bytes differ by a factor of 8…

“Samsung supplies 1Gbit of Double Data Rate SDRAM worth $14.00.”
http://www.isuppli.com/news/default.asp?id=8117

34 Dalekrium { 03.13.08 at 3:00 pm }

beanie Gb no GB that is a factor of 8
so 1Gb/8= 128MB

35 beanie { 03.13.08 at 3:12 pm }

$14 for 128MB SDRAM? $14 for 1GB sounds more reasonable. Maybe the 1Gbit is a typo.

36 raja { 03.13.08 at 3:48 pm }

The available memory is not the only issue, having multiple applications means that the processor is less likely to go into deep sleep modes. Constant polling for data over the internet or polling the accelerometer etc means keeping them on all the time. The OS turns the devices off when any app doesnt use them, even if an app polls for data say every 5 mins, if there are 10 processes running, they are polling every 30s on avg, and if you include the connection/disconnection time for each connection, then that leaves very little time for the devices to stay in low power modes between use.
How many of you see the battery life you browse in safari for couple of hours continuously loading websites? the same effect will be seen if background apps (especially the ones using edge/wireless repeatedly).
The next issue is security, i would never want to have these applications running while I am browsing or on the phone. Even though they are running sandbox mode and they will be tested by apple before listing on the app store, these apps might still hack into the rest of the apps. Also the people who want the background apps and multiple simultaneous apps “features” added, they also want more flexibility in access to filesystem and shared memory between apps or communication between apps. This leads me to think that there will be even more ways to try to bypass all the security measures put in place by apple, if these requests were in fact fulfilled. Like others have stated before, I would rather have stable & working apps than having to install mobile versions of antivirus/little snitch/activity monitors/etc on my iphone.

37 Generation 5 » The Wisdom of a Closed Platform { 03.13.08 at 3:51 pm }

[...] a leading writer about the iPhone since before it came out,  and this week he writes about the choices Apple made about concurrency in the iPhone.   Unlike Windows Mobile,  the iPhone only allows the user to have a single third-party [...]

38 jshell { 03.13.08 at 4:10 pm }

I’m pretty sure that a large part of Apple’s restrictions stems from trying to remind developers that even though the iPhone shares many OS components and frameworks as the desktop Mac OS X, it’s still a portable device. The other mobile OS’s have no desktop counterpart (Windows CE being a slight exception). When programming for Newton OS, Palm OS, or whatever, one knows that the environment is different. That it’s a quick-start / quick-stop environment that goes to sleep constantly. That users expect everything to come up instantly. It’s not like traditional desktop apps at all.

Some of what we encounter on the desktop are legacies of the restrictions faced by the original Mac developers – restrictions that the Lisa did not have, by the way. The Lisa (particularly the Lisa Office System) was much closer in spirit to what OpenDoc tried to be, where the concept of the application and of open/save dialog boxes and ‘quit’ commands do not exist. That’s why the Lisa was so expensive. It was much more ahead of its time than the Macintosh, but it that caused it to be priced out of reach.

Anyways, developers need to be aware that the iPhone and iPod Touch are not pocket macs, despite sharing so much DNA. These kinds of restrictions will remind them of that. Battery life, privacy, potential roaming charges (remember the stories of people getting $3000 ATT bills because they took their iPhone to Canada? They thought they didn’t use the EDGE network while up there, but forgot that the Mail system was checking for new messages every few minutes), etc. And user expectations of pocket devices are just different.

One never thinks about “Save As…”, “Quit”, etc, when using Palm OS or Newton. You just tap the calendar button and blammo! You’re in the calendar. Immediately. Since those platforms were entirely unique from the desktop, developers knew that instant state saving and recovery was expected. The iPhone is no different. Just because it’s Mac/Unix doesn’t mean that it’s a platform meant to run ffmpeg, Pro Tools, QuarkXPress, and Final Cut; and it’s not a platform where one can just recompile their desktop application (think VoodooPad, which I bet would be a great iPhone app) and have it run. It’s more than just putting a different Interface Builder front end onto your app.

I expect to see many of these restrictions ease over time. Besides, it’s better to be more restrictive now and adjust over time than it is to allow carte-blanche access to everything and end up with a painful lifetime of backwards compatibility support issues (classic Mac OS and Palm OS being two great examples of platforms rapidly hindered – genius at coming out with such neat features at their price points, but then weighed down by the architectural limitations used to come in at said price points and by opening up too much access to low level APIs that couldn’t be easily adapted later).

39 kimhill { 03.13.08 at 4:46 pm }

Daniel, I’ve read you since the beginning and have really enjoyed your work, but I think you’re wrong here. To see the significance of the multitasking issue, I suggest this blog post by a long-time Mac, and current Android developer, who would like nothing more than to write iPhone software:

http://whydoeseverythingsuck.com/2008/03/apples-iphone-sdk-prohibits-real-mobile.html

================
Excerpt:

Communication Notification

In order to innovate in the communication area, you must have notification. Without it there is no push email, no phone ringing, no instant messaging, no twitter notification, and on and on. Of course some of you will argue that you don’t need third parties to do this stuff because Apple will handle all that internally. But Apple didn’t invent instant messaging. They didn’t invent Twitter. They didn’t invent VOIP. And they certainly didn’t invent the phone. By making third party communications related innovation on the iPhone impossible, they are potentially killing the next great thing that could only be done on a mobile device, but won’t be because Apple forbids it.

Environmental Notification

Of course, there is more to this than just communications. You can’t even implement something as simple as an alarm clock without notification. More interestingly, there are a whole host of location-based applications that are impossible with the current restrictions. I’d love to have an app that notified me when I was near something that I have been looking for, like perhaps an open house for a piece of real estate in my price range. Personally, I believe that location based notification is the most fertile of all the potential new areas of innovation.

Presence & Location Broadcasting

Presence, the concept of notifying others that you are “available” in instant messaging applications, is a huge and important functionality. It has become important in a whole host of applications beyond pure instant messaging. In the mobile world the concept of presence takes on even more significance, and with location aware devices we can broadcast not just “presence” but location. Again, neither presence nor location broadcasting is possible without background capability and the Internet is filled with discussion about how these concepts can change social dynamics. But as it stands now, none of that innovation or exploration will happen on the iPhone.

40 danieleran { 03.13.08 at 6:03 pm }

@kimhill:

I’m sure there are lots of good examples of background tasks that might be useful, but the article you cite gives really bad ones. Should Apple really convert the iPhone platform into a testing ground for the next Twitter? Does the phrase “security issue” raise any flags? You can’t invent a new communications protocol and roll it out in real time over a mobile device network–without any controls in place–and expect things to work out well.

The iPhone isn’t a development lab, it’s a phone. It has to work. It can’t be run down dead because some developer releases what they think would be a good neo-Twitter/IM/VoIP client, and finds mass adoption before realizing they’ve introduced major performance problems or perhaps exposed significant security issues.

Look at the security holes that have been discovered in Sun’s Java or QuickTime or IM or HTTP or any other protocol, and you have to second guess the ability of individuals primarily interested in “cool” to recognize every security issue they might raise in building apps on a platform that, unlike the iPhone, has no parapets at all.

The second idea of ‘location notification’ sounds great, but how many notifications will your iPhone alert you to before the battery is dead from constantly polling its location? Real satellite GPS draws so much power that it typically needs to be plugged in (or have big batteries). That’s why the iPhone has a click to locate button rather than providing a constant update on your location. The author who wrote up this idea didn’t give this much thought.

Apple also knows a thing or two about presence indication, and has worked hard to make Bonjour as efficient as possible in announcing itself and listening for available services. This is an OS level service, not something you want every third party app implementing independently, for many of the same performance, battery, and security reasons.

I followed your link to see other examples he pointed out, only to find that he’s calling the the iPhone SDK “another to attempt to trick the market with a disingenuous marketing event,” and “a lie.” That’s a bit too much over the top in hyper-emotional politics to even address.

Certainly there are great examples of tools that will need some sort of special dispensation from Apple in order to work as desired. As I noted earlier, it’s a lot easier to initially limit what can be done than it is to clean up after a mess caused by allowing bad ideas to flourish into a crisis choking point.

I really liked the idea of installing software on my Palm back in the day, but after doing so, everything would stop working right and you’d have to figure out what was conflicting with what app or service and what had dumped in so many files that you were now out of room and had to manually clean things up before you could sync again. The result was that I didn’t install any apps that I actually used for the final two years of owning a Palm.

Had I only been able to install 10% of the stuff due to some appropriate tight controls that should have been put in place by Palm, I probably would have had a lot easier time actually using those apps that actually worked. I’d also likely have bought a lot more Palm Pilots over the years, and probably wouldn’t hate the platform so much, based on my hair-pulling decade trying to make its crap work.

41 kimhill { 03.13.08 at 6:30 pm }

Daniel, how about I just want to write an iPhone alarm clock? Can’t do it. Or maybe an IM client — can’t do that effectively either, unless I’m AOL, and Apple gives me special dispensations.

I agree with you that “lie” was over the top, but I do also agree that for Apple to present the AIM client as just something developers can now do is misleading.

OS X is a tremendously powerful OS, as we all know. It’s Apple’s ace in the hole here, and it has great facilities for throttling process utilization, and it could throttle stuff like GPS access as well. My interest here is to see the iPhone fulfill its vast potential and become the focal point for mobile innovation.

42 hank777 { 03.13.08 at 6:47 pm }

Daniel,

I am the author of the article that kimhill linked to. I thought I should jump in here since there are some misquotes, and some things that I think technically inaccurate that I thought worth addressing.

“Should Apple really convert the iPhone platform into a testing ground for the next Twitter? Does the phrase “security issue” raise any flags? ”

I am not sure where, for example, implementing twitter on your iPhone would raise security issues.

“You can’t invent a new communications protocol and roll it out in real time over a mobile device network–without any controls in place–and expect things to work out well.”

Hmm… Not quite sure where I mentioned anything about communications protocols. But even if they were relevant to my argument, there is no dangerous magic in communications protocols. And in any case the SDK does not prevent creating communications protocols. Its a full C compiler with access to TCP/IP. You can put anything on the wire you want and as far as I can tell, apple could care less.

“The iPhone isn’t a development lab, it’s a phone. It has to work. It can’t be run down dead because some developer releases what they think would be a good neo-Twitter/IM/VoIP client, and finds mass adoption before realizing they’ve introduced major performance problems or perhaps exposed significant security issues.”

Dan, this is just technically inaccurate. One of the great things about unix is the ability to control processes. You can control how much CPU they get, how often they can access services, etc. There is absolutely no reason apple could not provide for the ability to run daemons in such a way to limit their resource usage.

Also you keep referring to security. As far as I can tell there is no security axis here at all. Unix is quite secure. Its been around a few decades now and security has always been at the center of design requirements. Nothing the iPhone is doing should make unix any less secure than it has been for the last 30 years.

“Look at the security holes that have been discovered in Sun’s Java or QuickTime or IM or HTTP or any other protocol, and you have to second guess the ability of individuals primarily interested in “cool” to recognize every security issue they might raise in building apps on a platform that, unlike the iPhone, has no parapets at all.”

hmm… again with the security. Background apps have absolutely no correlation to security. And background apps have no correlation to Java, or quicktime. And java is not a protocol. These are completely orthogonal software concepts and services.

“The second idea of ‘location notification’ sounds great, but how many notifications will your iPhone alert you to before the battery is dead from constantly polling its location? Real satellite GPS draws so much power that it typically needs to be plugged in (or have big batteries). That’s why the iPhone has a click to locate button rather than providing a constant update on your location. The author who wrote up this idea didn’t give this much thought. ”

Actually, I gave it a lot of thought. And so have lots of other people. Its not exactly a new idea, and it is most certainly not my idea. First of all, the iPhone doesnt have a gps to burn so it would be hard to expend the battery using a service the device doesnt have. What it does have is location based facilities based on wifi and cellular, which are presumably services that can be used without burning out the battery otherwise the iPhone would be pretty useless. In any case, given that apple is smart, it would be trivial to restrict the number of times the daemon could call the location based software services from the background.

“I followed your link to see other examples he pointed out, only to find that he’s calling the the iPhone SDK “another to attempt to trick the market with a disingenuous marketing event,” and “a lie.” That’s a bit too much over the top in hyper-emotional politics to even address.”

Actually you misquoted me here, I guess since the actual concept is pretty troubling. Apple showed AIM as a product built with the SDK. You cant build AIM with the SDK since the SDK does not allow for background tasks to handle presence and notification. For apple to present AIM as the type of app that could be built with the SDK was a lie. It was not an emotional statement. I am quite dispassionate about this. I was developing software for Macs starting in 1984. I built a company developing mac software through the mid 90′s. I happen to think the iPhone is great. I have given it great reviews. But the truth is sometimes people do bad things. Sometimes they lie. (like jobs backdating the options). It happens.

As I see it, you should switch sides and be supportive of the idea that they should fix this. I agree that they should do it in a way that prevents too many resources from being consumed. This is apple and that will not be a problem for them if they decide to do it. They are smart. My fear is that with commentary like yours they will feel comfortable that they can get away with not bothering. That would not be good for any of us.

Hank

43 danieleran { 03.13.08 at 7:37 pm }

@Hank,

Thanks for your comments. You are quibbling over words to ignore the point however.

When you say, “I am not sure where, for example, implementing twitter on your iPhone would raise security issues,” you miss the point that security issues are everywhere. Who would have thought an imaging library like libtiff would provide access to the phone and allow software (including malicious stuff) to run on the system? It does the same thing on the PSP and other platforms.

If a graphical library exposed in the browser can open a backdoor, don’t you suppose a communications server installed in the background to chat with some next generation twitter system might possibly introduce security issues? Refusing to recognize such risks makes it harder to take your other comments seriously.

There have never been any protocols that jumped fully formed from the forehead of Zeus as perfect and flawless. So what new ideas do you want to test drive on Apple’s new platform, with the naive expectation that there won’t be any security issues to be concerned about? And how many million nodes will chatting up this new protocol as a background process before the issues are known and the damage is caused?

Apple is clearly working to prevent another Windows PC from happening. Your recommendation to kick the doors wide open to “see what happens” is great for developers who have no accountability involved, but not so great for Apple or for users who will be suck with real problems when things break down.

“As far as I can tell there is no security axis here at all. Unix is quite secure. Its been around a few decades now and security has always been at the center of design requirements. Nothing the iPhone is doing should make unix any less secure than it has been for the last 30 years.”

Well, yes, the iPhone doesn’t make Unix less secure. Being mobile and ubiquitously connected does make the same software more vulnerable than if it were sitting behind a DSL firewall in a home PC.

“Background apps have absolutely no correlation to security.”

Yes they do; users can exit an app knowing that it will be quit. If the app lingered on in the background, it can continue to do things the user isn’t aware of. This is a security issue in itself.

“location based facilities based on wifi and cellular, which are presumably services that can be used without burning out the battery otherwise the iPhone would be pretty useless” … oh come on. You don’t think there is any difference between accessing the network here and there to browse the web or check email and polling for location regularly? Unless you want notifications that only trigger if you stand next to something for 15 minutes, such an idea is not well thought out.

If you fail to see any wisdom in not allowing constant background polling, it’s hard to take you seriously. One app might be able to get away with it, but what happens when 6 apps are phoning home, sending out location requests, and uploading data every 15 minutes? Your antennas would melt along with your battery.

And how would Apple be able to vet every 3rd party app to make sure that when it sits in the background demanding data, it’s doing so with reasonable efficiency and not doing anything scandalous?

Sometimes, it’s better to know that the software you download has restrictions in place that prevent it from hanging out in the background to do things like snap pics and upload them to a developer’s server. Without Apple’s control, there’s no way to know that’s not happening. That’s why it’s there.

I didn’t intend to misquote anything out of context. Your accusations on AOL’s IM have yet to even be proven, because all we’ve seen so far is a demo of a buddy list. Even so, there’s nothing scandalous or dishonest about allowing known partners to do things that are not allowed by the general public as SDK users. If AOL spies on my stuff or causes damages, iPhone users can sue them in a class action and win an award; if a small developer does, they could fly away bankrupt without any accountability.

The world is not equal in any respect. Your comments the demand equal treatment of known and unknown parties just sound juvenile and naive. Suggesting that security isn’t a big deal because Unix is involved is equally absurd.

You can’t advocate change while demanding everything stay the same. Insisting that Apple give developers enough rope to hang themselves sounds great for those who can think up uses for lots of rope, but it’s better to start with just enough to get 80% of things done, carefully examine what needs to happen next, and then dole out extra rope to those who really need it.

Apple is at a critical juncture where it could deliver a strong future platform or uncover another pestilent epidemic of malware. You’re advocating a lack of constraint with scant basis for explaining why that might be a good idea, and also ignoring the reality of any security issues. Are you also offering to retroactively solve any problems your advice might result in, and do you have the billion dollars to make good on your assurance that “nothing bad could ever happen” with such a permissive, wide open SDK?

If I’m not understanding your position, I would appreciate a clarification because so far, it doesn’t seem to make any sense.

44 countach { 03.13.08 at 8:53 pm }

“apps don’t run in Flash storage, they run in the available RAM”

But they could SWAP to flash storage, if Apple has bothered to implement that, like a REAL os would.

“I outlined reasons why quitting apps rather than leaving them in the background running is a good general rule; perhaps you can elaborate why you think it isn’t rather than just decreeing that it is not.”

Firstly I never said it wasn’t an ok general rule, I said it was only good as a GENERAL rule. Not a hard rule.

And I already said why: (1) Programs can’t keep sockets open when they have quit. This is a major problem for many protocols. (2) Programs can’t receive data when they are quit. So you can’t get asynchronous notifications.

“Constant polling for data over the internet or polling the accelerometer etc means keeping them on all the time.”

Networked programs waiting for data DO NOT POLL. The OS awakens them when the data arrives. As I said, networking programs need use NO resources other than a trivial amount of swap space.

128MB of RAM folks! I’ve got a Mac running OSX here with only 256MB.

45 David Dennis { 03.13.08 at 10:05 pm }

@Hank & @Daniel

Daniel, the truth is very simple. I don’t think Hank is a dummy, or someone who hates Apple, or anything like that. You lessen your own stature by dropping to that level.

Hank’s heartbroken because he can’t write the very specific application he wants to write, and I think he deserves a little tea & sympathy instead of being called “juvenile”. He’s not juvenile; he just wants to create the application that’s been bouncing around in his head. I’m sure you realize how frustrating that can be.

The daemon process he wants to write is probably extremely simple and would take up very little CPU or RAM if written correctly. So he is puzzled as to why daemon processes are prohibited.

I think the fellow who said that Apple wants to let the customer hit the button and get instant gratification in stopping a runaway application hit the nail on the head.

What I think might be best for Hank is to pick up the phone or email and call one of those nice developer fellows who are smiling at you in the videos telling you to email them. Talk to them about your needs and see what the official policy really means. Maybe there are workarounds or other ideas they can share.

I think that eventually Apple might provide handlers for specific inputs that you could then work into your programs. Realize that these are very early days yet. Both Apple and developers are working together to produce great software.

I don’t think there’s any doubt that great things can be produced with Apple’s SDK as it stands, even if they are not the specific applications Hank wants so badly to create.

What I think is far more interesting is that Hank is an Android developer and it sure looks like he’d love to jump ship and develop for iPhone, if they would only change the terms a bit to accomodate the needs of his applications.

That seems to be good testimony to how much Apple has gotten right, as well as what they have done wrong. Otherwise he’d ignore iPhone and just develop the next great Android applications …

D

46 mmbossman { 03.13.08 at 10:34 pm }

Undoubtedly there will be possible developers who upset about the restrictions dictated by the SDK. Take a look at the porn industry, I’m sure many of them are pissed that they can’t produce xxx material. However, I do think that many of the fears about the SDK, while possibly valid now, will be dealt with in the next 18 months. Both the iPhone and SDK are still in their infancy, and I agree with the idea that Apple would rather keep their phone stable above all else. Once a platform gets a bad rep for being power-hungry, unstable, or having poor security, it’s almost impossible to recover (look at how well Palm is doing right now).

Sure some developers will be aggravated right now. But if they have a good application idea that they can’t implement at the moment, no one else will be able to beat them to the punch. So have some (more) patience for the platform to further mature. I can guarantee that this will not be the last revision to the SDK, or the restrictions that Apple has in place.

47 raja { 03.13.08 at 11:44 pm }

From what I have seen in the SDK, polling of location data is allowed in the normal applications.
“The daemon process he wants to write is probably extremely simple and would take up very little CPU or RAM if written correctly.” here the key word is “if written correctly.” Now how many developers can be relied on to do this correctly? certainly not all developers who will be writing iphone apps, i wouldnt trust myself to write such a daemon to be completely secure AND fast AND small. Only a few can be trusted with absolute power, Apple is one of them, they will add more features to the sdk and the OS as time passes.
I feel the point made by daniel is important, every aspect of the iphone and its OS does not need to be exposed right now, if most of the developers’ needs are fulfilled. These advanced features can be added later, who knows they might be added in some secure way by the time 2.0 comes out in june. There are still many (most likely a majority) developers like me who dont need these background app features at all, and I think that small developers like me will be happy with what we already got.

48 iPhone 2.0 SDK: The No Multitasking Myth via RoughlyDrafted | Just Another iPhone Blog { 03.14.08 at 12:19 am }

[...] iPhone 2.0 SDK: The No Multitasking Myth — RoughlyDrafted Magazine [...]

49 thgd { 03.14.08 at 12:49 am }

@ David Dennis…..” What I think is far more interesting is that Hank is an Android developer and it sure looks like he’d love to jump ship and develop for iPhone, if they would only change the terms a bit to accomodate the needs of his applications. ”

Give us a break !
Apple isn’t going to change their rules for every programmer who claims they need special dispensation to make their dreams come true.

There are plenty of developers creating great apps within Apple’s present guidelines. For those who can’t, there are other devices to write for that presumably don’t put such rigid restraints on creativity. Apparently we’ll need to look for those programs on competing devices.

50 John E { 03.14.08 at 1:08 am }

well, look …

in June 2007, Apple ‘opened’ the iPhone to 3rd party web based apps only. a lot were created, some pretty good. but no game changers.

in June 2008, it will open the iPhone to pretty much sandboxed 3rd party apps (also inventing a whole new app delivery system). a lot will be created, there seems to be a lot of excitement. we all expect some to be terrific. will there be any game changers? we’ll see as the year unfolds.

in June 2009, Apple will probably add some more software options that take advantage of its next gen of iPhone hardware, expected by then. exactly what is anybody’s guess right now.

point is, Apple is clearly taking it (just) one leap at a time with the iPhone’s development. give them a break. the SDK is a huge leap even in its current form. let them and all the 3rd parties get that much working right in the real world this year.

then come back next year for more.

i swear, tech people are such an incredibly impatient bunch. we want the world and we want it now!

(TOTH to jim morrison)

51 Scott { 03.14.08 at 1:23 am }

For a sec I felt like Daniel was being a little bit harsh when calling Hank’s take on issues “juvenile” (“The world is not equal in any respect. Your comments the demand equal treatment of known and unknown parties just sound juvenile and naive.”) That was before I went to Hank blog site and read the rest of his take on issues related to the SDK, Apple, people who love Apple products and SJ. Hank is a troll! A juvenile one at that!

@ David Dennis

Hank is indeed a “dummy”. Security, battery life and available resources are real concerns anyone who denies these is a “dummy”…

52 beanie { 03.14.08 at 1:30 am }

iPhone does have 1Gbits SDRAM in the form of two stacked 512Mbits SDRAM. The SDRAM serial number is K4X1G153PC-XGC3 and other sites say it is 1Gbits. I was mistaken since I was not use to the the lower case “b” in 1Gb. Why don’t people just use 128MB instead of 1Gb?

53 yuhong { 03.14.08 at 2:50 am }

“The jailbroken iphone was not available to every iphone user. And the iphone was jailbroken only by above average users, who knew what they were doing.”
Many “open” devices uses approaches like this to isolate the “above average users” so they would not ruin the reputation of the device. If you don’t know what I mean, replace the words “jailbroken iPhone” with ” with custom firmware”, “iphone was jailbroken” with “firmware was replaced”, and “iphone” with “”. In fact, if not for the carrier locking, I don’t think Apple would discourage jailbreaking as much.

[It's an interesting idea to say that jailbroken iPhones wouldn't reflect on the stability or functionality of the iPhone, but keep in mind that much of the media panic over security--including the "somebody can install a spy camera on your iPhone without you ever knowing!!" idea--was only relevant to jailbroken phones, were were applied to iPhone users in general, tarnishing Apple's reputation. By exercising control over the iPhone software made available, Apple can actually say, "No, that isn't possible." - Dan]

54 starkruzr { 03.14.08 at 3:26 am }

“What I think is far more interesting is that Hank is an Android developer and it sure looks like he’d love to jump ship and develop for iPhone, if they would only change the terms a bit to accomodate the needs of his applications.”

This is a really important point that I think everyone should think about:

Do we really think that OS X Mobile is going to be a *better* platform than Android *because of the restrictions it applies on developers?* Do we really think that Google *can’t* figure out a way around the drawbacks of (for example) daemon software?

55 dssstrkl { 03.14.08 at 4:05 am }

@countach: There’s a reason why the iPhone doesn’t swap to Flash, and that’s due to the physical nature of flash memory itself. Basically, every time something is written to flash, the substrate is slightly damaged, due to the intense energy required to move electrons through it, which itself is needed for the chips to maintain state without power. So, if you use flash for swap, you’ll reduce the lifespan of the chips from years to hours.
To illustrate this, Steve Gibson of grc.com likes to tell the story of a friend of his who tried out a flash drive as a windows swap partition. The drive died completely after 4 hours.
That’s why SSD’s are so hideously expensive right now, they have to do extensive caching to keep their lifespan on a level on par with HDD’s.

56 dicklacara { 03.14.08 at 4:05 am }

@beanie

I think they use 512Mb because that is the capacity of the chip. How these chips are deployed determines the storage capacity of the device.

Sticking with 8-bit Bytes:

1 x 512Mb chips / 8 bits = 64 MB
2 x 512Mb chips / 8 bits = 128 MB
*
*
*
16 x 512Mb chips / 8 bits = 1 GB

Now, the same chips could be used in a speciality instrument that had lots of measurement points, but each point could only hold a value from 0-15. It would take 4 bits for each measurement point. Let’s call each 4-bit group a Nibble.

So, with 4-bit Nibbles:

1 x 512Mb chips / 4 bits = 128 MN
2 x 512Mb chips / 4 bits = 256 MN
*
*
*

or

256 MN = 128 MB = 1Gb = 2 x 512Mb chips

As with a lot of things: It’s not (only) how big it is… but, how you use it!

-Richard

57 Rich { 03.14.08 at 4:42 am }

“To illustrate this, Steve Gibson of grc.com likes to tell the story of a friend of his who tried out a flash drive as a windows swap partition. The drive died completely after 4 hours.”

I thought Vista’ Ready Boost techology used a flash drive as a swap partition?

Does anyone know how Symbian achieves paging on flash memory? I know that it certainly does it in the latest phones. Maybe the type of flash memory used is different.

58 demallien { 03.14.08 at 6:36 am }

@beanie

It’s a historical thing. Back in the day, it was common to sell memory chips that were bit-addressable. Typically, a computer would have a bank of 8 of these chips that would all be accessed simultaneously to read or write a byte.

The advantage was that all the address decoding took place inside the memory chip, rather than needing decoding logic on the mother board. It also reduced the pincount on each chip, as you only need one data pin, rather than 8.

These days with high-capacity chips, and out of this world pincounts, the considerations are no longer the same, but the use of bits instead of bytes to specifiy storage capacity remains…

59 David Dennis { 03.14.08 at 11:20 am }

starkruzr, Google’s going to have it even tougher than Apple because its phones don’t have the processor power or memory iPhone does.

@raja, I was expressing myself to show how Hank might be thinking, and how his thinking is reasonable from his point of view. I was not taking a position on how Apple should respond, just that he should talk to them and hear their official position.

I think it would be good to have simple daemon processes available if it would not kill performance. I’m sure Apple’s people will be considering how this might be possible in the future. It certainly would be as mobile CPUs get more powerful.

D

60 Michael P { 03.14.08 at 3:55 pm }

Apple looksl iek they are building a system much like Palm OS. With the Treos, you can have RealOne in the background, and some other apps running behidn the scenes, but the foreground application takes precendence.

And yes, I’ve noticed how hitting the Date Book hard button on my aging Sony CLIE T665C takes me immediately to the calendar. It’s a user experience that I almost like.

61 starkruzr { 03.14.08 at 4:11 pm }

Michael P: That is precisely how it is NOT going to work. No apps can run behind the scenes.

62 starkruzr { 03.14.08 at 4:13 pm }

David Dennis: What are you referring to? Google isn’t manufacturing any phones themselves, they have a number of companies who are interested in manufacturing them. I don’t know that we’ve seen any confirmed reports of specifications but I can’t imagine why any of these devices would be any slower or less capable in general than a phone that will be a year old by the time phones featuring Android are released.

63 Mr. X { 03.14.08 at 6:38 pm }

Isn’t there another factor everyone is missing? Namely EDGE?

A phone can’t be connected to EDGE and voice at the same time. That’s why if you’re actively browsing the web in Safari, incoming calls will go to voice mail.

Now, people are saying they “need” to be connected to instant messenging 24:7. “Everythingsucks.com” wants his phone to be constantly checking EDGE to see if there are any houses for sale in his vicinity.

If you have background processes connected to EDGE 24:7, doesn’t that mean you can’t receive phone calls? Wouldn’t that “suck” a lot more than not having your phone tell you about a house for sale?

The fact an Android developer suggests something does not necessarily mean it’s a good idea. Android phones have fewer limitations because they don’t exist. You’ll never miss a call because your nonexistant Android phone is using EDGE to search for houses. On an iPhone, you might.

64 starkruzr { 03.14.08 at 8:03 pm }

Mr. X: Some people (like myself) actually use text communications more often than voice communications. Text is more important to them than voice. If they miss a call, the call will go to (visual!) voicemail. This is not at all a deal-breaker as long as the user is informed that voice calls cannot be received while the IM system is active.

65 yuhong { 03.14.08 at 9:22 pm }

“because existing Windows Mobile applications all assume the right to hog the processor in the background and keep Windows Smartphones running slow, inefficiently, and awkwardly complex enough to only appeal to the most devoted of Windows Enthusiasts.” Though to be honest, it is still better than Palm, where you could actually crash the whole device using a badly behaving app because of it’s lack of memory protection. With Windows Mobile, usually it is just reduced battery life and you can easily kill the process that is misbehaving.

66 Rich { 03.14.08 at 9:40 pm }

“If you have background processes connected to EDGE 24:7, doesn’t that mean you can’t receive phone calls?”

You’re correct, you can’t have an active EDGE and voice connection at the same time. The key word is active though. An open connection not transmitting data won’t stop incoming calls.

And it’s beyond doubt that a 3G iPhone is on the way. 3G isn’t just about speed – it also drops a lot of the limitations of EDGE.

67 Mr. X { 03.14.08 at 10:01 pm }

” If they miss a call, the call will go to (visual!) voicemail. ”

Yes, but you can’t even listen to voicemail messages unless you kill the background process that’s blocking them.

68 iPhone 2.0 SDK: Java on the iPhone? — RoughlyDrafted Magazine { 03.14.08 at 10:02 pm }

[...] ← iPhone 2.0 SDK: The No Multitasking Myth [...]

69 Mr. X { 03.14.08 at 10:19 pm }

“Networked programs waiting for data DO NOT POLL. The OS awakens them when the data arrives. As I said, networking programs need use NO resources other than a trivial amount of swap space.”

If the OS can listen for your data and awaken your program when it’s received, couldn’t it also launch your program when it’s received?

I think you’ve just undermined the who argument for background apps.

70 Mr. X { 03.14.08 at 10:40 pm }

“An open connection not transmitting data won’t stop incoming calls. ”

Receiving data appears to have the same effect. (I just tested it with a Youtube video).

“And it’s beyond doubt that a 3G iPhone is on the way. 3G isn’t just about speed – it also drops a lot of the limitations of EDGE.”

Yes, and future versions of the SDK may add capabilities and drop limitations, too.

The complaining about Apple limitations remind me of the saying about the man who thinks the glass is half empty, except in this case, people are complaining because the glass is 5% empty. Everythingsucks.com (interesting name) complains that Apple won’t allow him to write three types of programs and then generalizes to say they’re “making third party communications related innovation on the iPhone impossible,” as if no one could ever think of any type of program they could write. I don’t think everything sucks but that attitude sure seems to.

71 yuhong { 03.14.08 at 11:43 pm }

>If the OS can listen for your data and awaken your program when it’s received, couldn’t it also launch your program when it’s received?
And that is exactly what launchd is supposed to do.

72 John Muir { 03.15.08 at 12:57 pm }

@dssstrkl

I was foolhardy enough to actually run Mac OS X from a CompactFlash card for most of a year, a writeup here:
http://lowendmac.com/macdan/07/0529.html

My card did eventually die, but it was months instead of hours. Reportedly more expensive UDMA “pro” CF cards can take a beating from VM even longer. But it’s still obviously not as good as SSD … and even those right now: I have my doubts.

No virtual memory on the iPhone seems like a good idea. It follows nicely from the general restrictions on CPU and battery drain anyway.

73 harrywolf { 03.16.08 at 12:03 am }

Who would be Apple when so many want so much from the iPhone?

It MUST be a phone, first of all, because that is what it is and what it does. Thats its core competency.
Secondly, its an iPod, with all that entails.
Next its a Web-machine; email and browser.

Add all the other things it does and its almost perfect.

Its great just as it is.

Am I the only person who thinks that all this SDK might bring problems to a great device?
Thank goodness we have the choice to download/implement 3rd party apps or not.

Apple has the power to restrict certain core device-endangering activities, and they will use it.
Good.

I dont want a windoze pc mess on my beautiful and incredibly useful iPhone.

I doubt that 99% of the developers can do things as well as Apple, unlike Windows, where developers, as Monkey Boy reminds us, are the lifeblood of Windows, and can easily write better stuff than Microsoft themselves.

But this aint a PC, its a phone plus – and has already proved itself, without the SDK.

Tread carefully with the already fully-realised iPhone, as Apple is doing.

I believe the developers NEED the iPhone more than the iPhone needs them, hence the complaints.

74 starkruzr { 03.16.08 at 3:22 am }

Harry, your belief that freedom makes things worse is both funny and frightening.

Software freedom not only means that you *can* install whatever you want on your phone, but also that you can *refrain* from installing things on your phone. If Apple were to open the iPhone and iPod touch wide open tomorrow, how exactly would *your* experience with *your* device somehow be worse?

75 countach { 03.16.08 at 7:41 am }

“That’s why SSD’s are so hideously expensive right now, they have to do extensive caching to keep their lifespan on a level on par with HDD’s.”

Ok, let’s say it can’t swap. But you can write a network program in a few kilobytes which does the listening, and it could wake up an app to do the hard work.

“If the OS can listen for your data and awaken your program when it’s received, couldn’t it also launch your program when it’s received?

I think you’ve just undermined the who argument for background apps.”

No cigar, because network protocols weren’t written with the idea you can close the socket any damned time you please. A tiny custom written program taking a few kilobytes could handle these issues and wake up the “big” app to do the hard work, but it’s not something that could be generically handled by the OS.

76 Mr. X { 03.16.08 at 2:40 pm }

“No cigar, because network protocols weren’t written [past tense] with the idea you can close the socket any damned time you please.”

Every network protocol ever written?

And it’s impossible for anyone to create a new network protocol, if the old ones don’t work in a new situation?

In that case, you’re out of luck, because there is *no way* to guarantee a mobile connection will remain open. On any platform. A user can walk into an elevator, tunnel, or no-signal area at “any damn time” he pleases. The battery can even die or a cell phone tower blow down while you’re in the middle of a communications session. If you’ve chosen a protocol that can’t handle an LOS “at any damned time,” then you’re SOL.

Choice of protocol is a design decision. Suddenly, your complaint has changed. Instead of arguing that Apple is making it impossible for you to be innovative, you’re arguing that Apple is making impossible for you to do something exactly the same way you have in the past.

Given that this is a new platform, that isn’t surprising. You’ve stated that one way of writing a communications program that won’t work on the iPhone. That doesn’t mean there aren’t other ways that will work. Be creative. Remember what Kipling said: “There are nine and sixty ways of constructing tribal lays, And every single one of them is right!”

77 Mr. X { 03.16.08 at 2:52 pm }

“Software freedom not only means that you *can* install whatever you want on your phone, but also that you can *refrain* from installing things on your phone.”

There’s no such thing as “software freedom.” Software does not want to be free, no matter what the Free Software Foundation says. Software does not want anything. Only people do.

Freedom means that you can accept any license terms that are offered to you. It also means you can reject any license terms. It also means that *companies like Apple* can accept or reject any license terms they choose.

If you have to follow certain license terms with the iPhone or the SDK, that does not violate your freedom because you accepted those license terms. If you think Apple shouldn’t be free to offer the license terms they choose, then you’re trying to restrict other people’s freedom.

78 countach { 03.16.08 at 5:39 pm }

You can’t re-write the whole damned internet and its protocols just for the sake of the Apple iPhone.

That’s the whole point of protocols – everyone already agreed on these things. Some of them are in RFCs – standards documents.

Concerning batteries dying blah blah, yep that happens and it usually means you have to start the procedure FROM THE TOP.

Oh yes, and most protocols aren’t symetrical. If you connected to some server, you can’t expect the server to contact you back to finish the conversion, courtesy of some imaginary iPhone launchd thing.

But if you had a background process, you could have it wait to finish sending that email, or downloading that document or finding that friend online in chat or finishing whatever it was you started.

In the mean time, good luck re-writing thousands of standards documents to make anal retentative Steve Jobs happy.

79 Mr. X { 03.16.08 at 7:18 pm }

“You can’t re-write the whole damned internet and its protocols just for the sake of the Apple iPhone.”

Can you please stop being so melodramatic?

No one said anything about rewriting “the whole damned internet.” There’s no need to, because “the while damned internet” is not broken.

Most of the Internet works very well with the iPhone. Even you are not disputing that. We’re talking about your program, not “the whole damn internet.”

“That’s the whole point of protocols – everyone already agreed on these things. Some of them are in RFCs – standards documents…. Oh yes, and most protocols aren’t symetrical.”

“Some”… “most”…

If “most” protocols won’t work, that implies some will.

Why not use one of those that will, instead of whining about those that won’t?

“But if you had a background process, you could have it wait to finish sending that email,”

No, because you’ve already said that the protocol you’re using can’t cope with a connection getting closed. And you won’t even think about using a different standard protocol or, God Forbid, inventing something new if the current standards don’t work.

“In the mean time, good luck re-writing thousands of standards documents to make anal retentative Steve Jobs happy.”

So, you think no can ever invent anything new because all of the existing standard documents would have to be rewritten?

Have you considered the possibility that someone might just write a new standard to describe the new idea?

80 duckie { 03.16.08 at 7:28 pm }

Well done Mr X, a bit of lateral thinking for a change

81 starkruzr { 03.16.08 at 10:01 pm }

No, that’s not “lateral thinking.” All of you who are supporting Apple’s decision to keep the iPhone crippled in some way are missing the point: all of these problems cited with the crippling (breaking standards, reducing functionality, etc.) are caused because Apple has decided to ask developers to solve problems using a more complicated method that have already been solved for no real gain.

Background applications do not introduce a performance problem. They do not introduce resource management issues. This has already been proven over the 9 or so months that the iPhone has been available and jailbroken. Once again we are being given silly justifications for things that ultimately boil down to ideology and desire to improve the bottom line on Apple’s part. What happened to how “rogue applications” were going to “bring down AT&T’s network?” What happened to the massive security problems with 3rd party applications owing to unpredictability? Suddenly, Apple has changed its tune because they think they can monetize other people’s work.

No one is denying that Apple CAN choose to manipulate their product however they want. The question is whether or not they SHOULD, and whether or not that behavior is characteristic of a company that puts its customers first.

82 kimhill { 03.16.08 at 10:33 pm }

@daniel:

quote: “I’m sure there are lots of good examples of background tasks that might be useful, but [Hank Williams'] article you cite gives really bad ones.”

I think you’re wrong on this one, Daniel. And it seems John Gruber agrees, calling Hank’s article “the best argument I’ve seen against Apple’s ‘no third-party background processes’ policy”:

http://daringfireball.net/2008/03/iphone_flip_side

When I posted originally, I didn’t expect Hank to chime in here, or I would have pointed out that I’m working with him. It’s important to note that there’s nothing Hank or I would rather do than develop our product for the iPhone- if only the SDK allowed it. Apple has demonstrated that it does respond to outside concerns/critiques, so I think it’s important to keep this issue in front of the community. As soon as we’re able, you can bet that we’ll be innovating on the iPhone and loving it. I say that as someone who was waiting in line on June 29th…

83 gus2000 { 03.16.08 at 10:45 pm }

Did you read the same article I read? If Daniel cannot convince you, then I shall not waste my time attempting to sway your position.

84 kimhill { 03.16.08 at 10:50 pm }

Well, if Gruber cannot convince you, then I shall not waste my time attempting to sway *your* position…

85 yuhong { 03.16.08 at 10:56 pm }

Anyway, if the restrictions have to be loosened, Apple can always loosen them later as nesserary, which is better than going the other way. Maybe Apple can add support to the xnu kernel to limit the resources used by background apps, as well as what it can do.

86 gus2000 { 03.16.08 at 11:29 pm }

Sorry Kim, I was responding to the post before yours, and apparently I type too slowly. :)

But since you brought it up (heh heh), Gruber is is only mildy skeptical and does not believe the background policy “implies any spite or shortsightedness on Apple’s part. It’s simply the result of Apple’s decision to focus first and foremost on maximizing battery life and performance.” That’s very different from believing that Apple is trying to wring every last cent out of its customers without regard for their needs, which I don’t believe at all.

87 Mr. X { 03.17.08 at 12:10 am }

“Apple has decided to ask developers to solve problems using a more complicated method”

Well, people have gone from saying Apple has made it “impossible” to write innovative software to “Apple has made it more complicated.”

That’s quite an admission.

“Background applications do not introduce a performance problem. They do not introduce resource management issues. This has already been proven over the 9 or so months that the iPhone has been available and jailbroken.”

Hardly. Hackers are seldom concerned about performance and security problems. Is it possible to file a bug against the self-styled “iPhone Dev Team”? Do you know how many performance and security bugs are in their database right now? Do they even have a bug tracking database?

Did the iPhone Dev Team take responsibility when their software bricked iPhones? No, they blamed Apple. Did they fix the bricked phones? No, Apple did.

There’s a big difference between proving you can hack something and having a stable supported platform.

“What happened to the massive security problems with 3rd party applications owing to unpredictability? Suddenly, Apple has changed its tune because they think they can monetize other people’s work.”

No, Apple has created an environment in which iPhone applications will be able to run securely — something the jailbreakers never did. And gotten precious little in return for it except abuse.

If you believe Apple’s evil and don’t think security’s a legitimate concern, why do you care what Apple does? Go jailbreak your phone and do anything you want with it. Just be careful you don’t brick it in the process.

88 Mr. X { 03.17.08 at 12:42 am }

“Well, if Gruber cannot convince you, then I shall not waste my time attempting to sway *your* position…”

Kim, you’re quoting only one small portion of Gruber’s article. He then goes on to say that there’s a tradeoff, which you and Hank refuse to acknowledge.

There’s something else to consider. Everyone who installed the beta SDK signed a nondisclosure agreement with Apple. A few developers immediately chose to violate that NDA in order to trash Apple publicly. The merits of the argument notwithstanding, that approach is unprofessional, and I don’t think it will encourage Apple to go the extra mile for those developers.

89 starkruzr { 03.17.08 at 12:45 am }

Mr. X, you clearly don’t know anything about what you’re talking about.

“Well, people have gone from saying Apple has made it “impossible” to write innovative software to “Apple has made it more complicated.”

That’s quite an admission. ”

It is actually quite an accusation — especially when you read the rest of my sentence, which is that the reason for this is not pro-consumer, but pro-Apple.

“Hardly. Hackers are seldom concerned about performance and security problems.”

Wrong.

“Is it possible to file a bug against the self-styled “iPhone Dev Team”?”

Yes. Shall I provide you with an example? http://code.google.com/p/independence/issues/list

“Do you know how many performance and security bugs are in their database right now? Do they even have a bug tracking database?”

See above.

“Did the iPhone Dev Team take responsibility when their software bricked iPhones? No, they blamed Apple.”

That is because Apple intentionally stomped on the seczones of unlocked phones so they could later appear to be saviors. Except their plan backfired.

“Did they fix the bricked phones? No, Apple did.”

Guess who fixed the bricked phones FIRST? These guys: http://code.google.com/p/iphone-elite/wiki/RevirginizingTool

Oops. In actuality, the jailbreakers have embarrassed Apple over and over again. First by demonstrating that great applications could be written against an unstable API (and that the software development community was entirely capable of keeping up with changes). Then by demonstrating that freed iPhones were not security hazards. Then by demonstrating that performance was not a concern on iPhones running third-party software. Then by fixing problems caused by Apple’s software updates BEFORE APPLE COULD FIGURE OUT HOW TO DO IT. The jailbreakers have run faster than Apple at every turn.

“No, Apple has created an environment in which iPhone applications will be able to run securely — something the jailbreakers never did.”

Engineers understand that running any device — a phone, a car, an airplane — under any circumstances carries some degree of risk. What Apple has done is set another precedent that it is okay for a multinational corporation to decide FOR YOU what level of risk YOU can assume.

I already jailbroke my phone and it’s doing wonderfully, thanks. How do you suppose it is that I’ve avoided having my credit card information stolen? How do you suppose I’ve avoided someone putting a porn dialer on my phone?

Moreover, no one has ever bricked an iPhone by jailbreaking. Ever. The only way to brick an iPhone is to attempt an unlock, which I have no interest in because I’m an AT&T customer. I care what Apple does for two reasons: I want Apple to be a pro-freedom company, like they have shown themselves to be in the past with the Macintosh, and I want Apple to avoid stepping on the freedoms of their technical users while they seek to enhance the experience of their nontechnical users.

90 Mr. X { 03.17.08 at 1:08 am }

“Moreover, no one has ever bricked an iPhone by jailbreaking. Ever. The only way to brick an iPhone is to attempt an unlock,”

Unlocking is one of the prime purposes of jailbreaking. The “iPhone Dev Team” boasts of that fact in their “PWNED” video.

“I want Apple to be a pro-freedom company,”

Again, freedom means companies are free to decide what products and what license terms they will offer.

It does not mean that they must offer the products and terms you deem Politically Correct.

91 countach { 03.17.08 at 4:12 am }

“Most of the Internet works very well with the iPhone.”

No, most o the internet protocols do NOT work with the iPhone.

And the ones that do, do so in large part because Apple has not subjected their apps to the same restrictions they expect others to conform to.

“We’re talking about your program, not “the whole damn internet.”

No, we’re talking about the whole damned internet.

“”most” protocols won’t work, that implies some will.

Why not use one of those that will, instead of whining about those that won’t?”

So to use an analogy, you’d be happy to have say email protocol working and forego web browsing? How silly.

“”But if you had a background process, you could have it wait to finish sending that email,”

No, because you’ve already said that the protocol you’re using can’t cope with a connection getting closed.”

Huh? If you have a background process the connection doesn’t get closed.

“God Forbid, inventing something new if the current standards don’t work. ”

Again with the stupidity of expecting the whole internet to conform to iPhone. How arrogant.

92 demallien { 03.17.08 at 4:31 am }

countach, no offense, but for anybody that has actually done any programming using TCP/IP, it’s blatantly obvious that you don’t have a first clue what you are talking about. Comments such as “Huh? If you have a background process the connection doesn’t get closed.” are just plain wrong, and demonstrate that you don’t understand the underlying technology.

You may wish to consider discretion, rather than mouthing off about subjects that you obviously don’t understand…

93 countach { 03.17.08 at 5:24 am }

Are you joking? I was programming TCP/IP before you were born. Background processes can keep connections open as long as they want. Don’t make a fool of yourself.

94 kimhill { 03.17.08 at 5:24 am }

Mr X quote: “Kim, you’re quoting only one small portion of Gruber’s article.”

Umm, yeah, but that portion is entirely consistent with my point: John Gruber agrees with Hank’s article being “the best argument I’ve seen against Apple’s ‘no third-party background processes’ policy.”

95 starkruzr { 03.17.08 at 5:28 am }

You are purposely misunderstanding what countach said. Of course simply having background processes does not magically cause connections to remain open. Some amount of work has to be done to permit this. This work is possible when you have background processes doing it for you. It is not possible when at any moment something can pre-empt the job you are doing (including, perhaps, the user) and suspend the application.

96 demallien { 03.17.08 at 6:01 am }

countach, feel free to enlighten us all to all these amazing internet protocols that keep connections permanently open.

Twit.

97 rambo's ramblings { 03.17.08 at 8:24 am }

iPhone multitasking: Call me when I am ready or go to hell…

very informative post on roughly drafted but sounds awfully like a Jobs’s sales pitch.
iPhone will not be able to run multiple apps or worse even one background task.
Now why not let the user decide which apps to run and when. isnt that simple? l…

98 Mr. X { 03.17.08 at 12:01 pm }

“Are you joking? I was programming TCP/IP before you were born. Background processes can keep connections open as long as they want. Don’t make a fool of yourself.”

You must be world’s oldest living programmer.

No, I’m not joking. Even if you’re 85, you can’t violate the laws of physics. If radio waves are physically blocked or transmitter power fails, the connection will be broken no matter what sort of processes you are running.

99 Mr. X { 03.17.08 at 12:11 pm }

“We’re talking about your program, not “the whole damn internet.”

“No, we’re talking about the whole damned internet.”

Am I imagining all those web pages I see on my iPhone? Well, it seems to work for me.

“So to use an analogy, you’d be happy to have say email protocol working and forego web browsing? How silly.”

If I could do what I needed to do using email rather than a web browser, yes. And the web browser does work, excluding Flash and Java, so yes, your statement is silly. :-)

“Again with the stupidity of expecting the whole internet to conform to iPhone. How arrogant.”

Again, I can see most of the Internet just fine on my phone. (By the way, it’s spelled “Internet” these days, not “internet.” :-)

100 mmbossman { 03.17.08 at 2:41 pm }

Sure, I’ll claim comment #100 for myself:) Now if only I could claim an iPhone for myself so I could feel like I have a reason to praise and/or criticize Apple’s decisions.

101 John Muir { 03.17.08 at 2:59 pm }

#100?

Is RDM the new Crazy Apple Rumors?

No, no. Don’t even think about it!

102 Scott { 03.17.08 at 3:10 pm }

So why must I be a damn programmer to use the damn phone? I know absolutely nothing about what your dreamt out applications will do with my iPhone. This is the reason why I want Apple to police the whole damn thing so that my phone works as I expect it to work. Of primary concern to me are security, battery life and performance.

Here is a good idea: If you cannot make you vapor app work with the current restrictions maybe its time you give up. Your app is probably some boring piece of vapor only fit to run in some junk phones running Windoze.

Thanks SJ; these restrictions will filter out a lot of spaghetti, and upside down coded apps from amateurs! The true creatives will develop for the iPhone with or without the restrictions!

103 countach { 03.17.08 at 5:39 pm }

All the people saying to “code around” the restrictions are the same people who were saying how smart Steve Jobs was for not allowing native apps on the phone, and that programmers should just work around it by writing web apps. If you can’t make your vapor app work as a web app, you should just “give up”.

Well sure, we can “give up”, but it means you either won’t get that app, or you’ll get an app that has an extremely brain damaged user experience, similar to being a web app. Aka, no asynchronous notifications, and you must sit there staring at the screen until it completes some activity that you could have let complete in the background while you move onto another task. May as well go back to web apps.

104 starkruzr { 03.17.08 at 6:15 pm }

Scott, let’s travel to a magical land where these restrictions on iPhone applications no longer exist. Thought experiment, right? No restrictions on background apps.

How does this make your experience on YOUR phone worse, when you don’t want any of these applications? All you have to do is not install them.

To be more practical about it, Apple could simply implement two levels of security on the iPhone: the one they have now, with approved applications, and something else that amounts to jailbreak, where the only tech support option they’ll support is “restore your phone to factory standards.” This would result in a minimal expenditure of extra effort on their part and everyone would be able to have their proverbial cake and eat it too.

105 danieleran { 03.17.08 at 7:22 pm }

@ countach: “All the people saying to “code around” the restrictions are the same people who were saying how smart Steve Jobs was for not allowing native apps on the phone, and that programmers should just work around it by writing web apps. If you can’t make your vapor app work as a web app, you should just “give up”.”

I know of no one who advocated that Jobs was “smart” for not allowing native apps. I would imagine I’ve written among the most of about iPhone development issues without repeating the same old saw about how disastrously uninformed and stupid Apple was not to release the SDK before anyone had the iPhone.

What I wrote was not that Jobs was God and that all should bow to Apple, but that Apple had good reason for maintaing control over the iPhone development environment, and failing to do it properly from the start would result in the same clusterfck as Palm, Windows Mobile and other junk mobile platforms.

What Apple is doing with signed code is what Rim, Symbian, and other platforms are attempting to do. Apple is also paying more attention to mobile performance issues, so rather than running a few apps poorly right from the start, the iPhone will have a wide and deep software selection that works well. Sophistication can be added later; problems can’t be solved so easily once they’ve been allowed to explode and cause widespread, complex issues.

@ starkruzr: “How does [No restrictions on background apps] make your experience on YOUR phone worse, when you don’t want any of these applications? All you have to do is not install them.”

The same way that no restrictions on malware makes using Windows worse for everyone, or that no restrictions makes Palm/Windows Mobile software largely worthless.

Suggesting that Apple should maintain safe and unsafe environments for iPhone users is like saying the US should run two sets of airport security: none and whatever exists now, and then let the market decide which people want to use.

However, your recommendation that Apple implement two levels of security on the iPhone is already in place: everyone using the iPhone as Apple directs will get a workable phone, and those who hack the phone to use undocumented APIs, run things in the background, and load plugins and unsigned apps will be able to complain that Apple is persecuting them when their stuff stops working or fails to find official support.

And the wags will devour every bit of it as proof that Apple is evil and that that the road to Nirvana is paved with romantic chaos that corporations should somehow remove any risk from for users.

106 casadapinga { 03.17.08 at 9:38 pm }

Lets talk about the SDK like it’s entire purpose was to make money for the people using it to create something special. We can talk about idealogical point of views about how Google is allowing the vast majority of developers create and sell their applications the way they want it. The problem is they have the following in unknowns:

1. Will the device be touch sensetive ?
2. Will it have buttons ?
3. What is the screen resolution ?
4. Will it have custom hardware functionality ?

More problems In selling it :

1. How do I market it to the wide audience ?
2. How do I make sure I accurately convey the possible problems with my program and updates ?
3. How do I deal with promotions and making sure people know I have a special deal ?

Problems with Performance :

1. Only geeks would know how to go to tasks and kill it.
2. How do you deal with expectations of bad battery, response and usability of the whole device in general ? Whose responsibility is it finally, the user’s for installing programs or the developer for writing a program that is CPU or network intensive or the mobile provider who allowed you to install it in the first place.
3. The delusion that operators will allow you to do anything and abuse the system.

Bullshit is what I call on that. Anyone who believes in the success of society based on pandering of developers is just out of their mind. Open source has it’s purpose and has it’s place.

I will wage a bet that developers selling their applications on the iPhone will sell 10 times as much as those on the google platform. Nobody buys software because it is open source, they buy it because it fulfills a need, does what they want and is easy to find. When google allows that and understands what it means to market to consumers will they get it. You might think that they do know because of their success in the search arena but they have had no financially successful venture other then what they are known for in pandering to consumers and making money. If you are a developer then neither are you. If you want personal satisfaction and want to feel good, continue developing for the google platform just don’t expect a big reward.

107 demallien { 03.18.08 at 1:10 am }

@starkruzr
“How does this make your experience on YOUR phone worse, when you don’t want any of these applications? All you have to do is not install them.”

Well, how is Scott, a hypothetical no-nothing-about-technology consumer, supposed to evaluate whether software is going to kill his system? What you are suggesting is that Scott, not being able to accurately determine the tradeoffs of various apps/performance, should simply not install any apps if he wants to be safe.

OR, he could use an iPhone, where Apple’s rules will ensure that ALL applications give him a good experience. I suspect that Scott would much rather the second option.

You see, take away the Apple gatekeeping, and the utility of the iPhone will actually drop for people like our hypothetical Scott, because they won’t be able to trust 3rd party apps.

On the other hand, if you’re a real star alpha-geek, you can always just jailbreak your phone, and put whatever sofware you like on it. The current Apple solution lets both groups get whatthey want. The only people that are missing out are people that want to write commercial apps that break Apple’s rules. hardly a great loss.

108 starkruzr { 03.18.08 at 1:12 am }

Daniel,

“The same way that no restrictions on malware makes using Windows worse for everyone, or that no restrictions makes Palm/Windows Mobile software largely worthless.”

Except it doesn’t. The reasons Palm and WM are terrible is because of design (or lack thereof), not because they allow background applications. WM is a terrible user experience because after 10 years it is STILL an attempt to squish a desktop PC UI onto a tiny screen. Even the non-touchscreen “Smartphone” version of the software hasn’t changed that. It doesn’t even look like WM7 or 8 will address the deficiencies of the UI. The kernel, as many of us probably know, is actually a really well-built piece of software, but the system suffers because of its terrible UI.

I don’t know anyone, and have never even heard any stories, about problems with malware on WM. What I HAVE heard about (and experienced myself) is tons of crappy software owing to Microsoft’s restrictive software development practices. Is this sounding familiar yet, kids? You absolutely NEED Visual Studio in order to develop any kind of real software on the WM platform, and it costs hundreds of dollars. Sure, you can download the *compilers* for free, but you can’t see what you’re doing, and that’s a much bigger problem on WM than it is on Mobile OS X.

“Suggesting that Apple should maintain safe and unsafe environments for iPhone users is like saying the US should run two sets of airport security: none and whatever exists now, and then let the market decide which people want to use.”

Actually, Dan, that’s a terrible analogy, and I know you’re smarter than to think it’s actually a good one, so why did you bother with it? Airport security exists to protect travelers from *DEATH by other party*. Mobile OS X software restrictions exist to protect users from *themselves* and protect Apple’s revenue stream. That was a nice try, though.

casadapinga,

“We can talk about idealogical point of views about how Google is allowing the vast majority of developers create and sell their applications the way they want it. The problem is they have the following in unknowns:

1. Will the device be touch sensetive ?
2. Will it have buttons ?
3. What is the screen resolution ?
4. Will it have custom hardware functionality ?”

What are you even saying? Why is any of this a problem? You write software for hardware with the capabilities you need. If a device is physically incapable of the software, the installation process says so. This is not difficult and is a solved problem in the Windows Mobile world.

“More problems In selling it :

1. How do I market it to the wide audience ?
2. How do I make sure I accurately convey the possible problems with my program and updates ?
3. How do I deal with promotions and making sure people know I have a special deal ?”

Uh. The same way you market any software? The same way you do ANYTHING with any software? Why are you painting these problems as if they are a) new b) unsolved?

“Problems with Performance :

1. Only geeks would know how to go to tasks and kill it.
2. How do you deal with expectations of bad battery, response and usability of the whole device in general ? Whose responsibility is it finally, the user’s for installing programs or the developer for writing a program that is CPU or network intensive or the mobile provider who allowed you to install it in the first place.
3. The delusion that operators will allow you to do anything and abuse the system.”

1. Wrong, and unnecessary. It is entirely possible to do foreground-plus sort of software model and make it clear to the user that running more things in the background will slow the device down. You “task swap” by closing one app and opening another, and you “stop” background processes by uninstalling them. Maybe some of them can have “on off” switches. It doesn’t matter; either way this is an easy problem to fix.
2. Even the least tech-savvy are capable of realizing “after I installed Widget.app, my battery life went down like crazy.” This is simple, simple stuff that can be (and is) put in help files.
3. AHHHH! HERE’S THE RUB, ISN’T IT! :) Finally we admit that the American cell phone cartel is fundamentally anti-consumer and anti-user in general. Their agenda is to milk the customer by any means possible, because they have no real regulation and are able to do any damn thing they please despite running a network which was partially paid for by tax dollars and upon which life or death situations depend.

Here’s my counter-bet for you, friend: I will wage a bet that software on Android will be 10 times more USEFUL than software on the iPhone, and that there will be much more free (and Free) software available for Android than there is for the iPhone. Why? It’s already extant: look at the software available for jailbroken iPhones right now. Most of that is ported free OS X and *NIX software, and it’s all tremendously useful.

One thing is for certain: the next few months after Android is released will be verrrrry interesting.

109 gus2000 { 03.18.08 at 1:23 am }

Nobody praised Apple for their iPhone web craplets (I certainly did not). But I do understand why Apple wanted to proceed slowly. I respect that they were willing to admit this. And I love that the iPhone shipped with 95% of the features I wanted with 5% of the hassle. No 3rd-party crap needed!

That’s not to say that there isn’t a market. Heck, there might be a killer app that none of us have thought of yet. But I did jailbreak my phone and load up every app in sight, and was ambivalent. I look forward to seeing the community creativity poured into this platform, I’m simply not chomping at the bit for it.

110 iPhone SDK: How Signed Certificates Work — RoughlyDrafted Magazine { 03.18.08 at 1:41 am }

[...] on the iPhone 2.0 SDK iPhone 2.0 SDK: The No Multitasking Myth iPhone 2.0 SDK: Java on the [...]

111 Apple’s iPhone vs Smartphone Software Makers — RoughlyDrafted Magazine { 03.18.08 at 1:45 am }

[...] on the iPhone 2.0 SDK iPhone 2.0 SDK: The No Multitasking Myth iPhone 2.0 SDK: Java on the iPhone? iPhone 2.0 SDK: How Signed Certificates Work I really like to [...]

112 mc77 { 03.21.08 at 5:30 pm }

iPhone platform can’t be compared to Android, because currently there aren’t any phones with Android OS. It doesn’t matter what apps are technically feasible with Android, if the carrier refuses to let users install them. Don’t be fooled by Google’s promises of openess. Just take a look at OpenSocial, each instance of OpenSocial is only as good as the underlying Social Network allows it to be.

113 Jeff56 { 03.22.08 at 9:08 am }

This article really doesn’t address the hardware. What we know of as preemptive multitasking on a computer with a Unix or NT kernel doesn’t appear to be possible on the ARM platforms because that type of feature requires hardware that doesn’t seem to be there. It looks like it’s a cooperative multitasking system at best, even if it is Unix-based. I’m not saying the other handheld platforms do have this sort of feature either, but I think that’s part of why Apple isn’t allowing devs to do multitasking.

114 starkruzr { 03.22.08 at 5:33 pm }

@Jeff56: If you’re referring to the MMU, you’ve got bad information. The ARM11 in the iPhone has an MMU and there are other OSes running on similar chips (including Debian Linux!) that do pre-emptive multitasking. It is not a hardware limitation. The main limitation of the ARM family of chips (most of them, anyway) is that they lack a floating-point unit. This is made up for, of course, on jailbroken iPhones with the armfp library.

115 iPhone 2.0 SDK: The No Multitasking Myth » General » Apple, iphone { 03.22.08 at 5:53 pm }

[...] iPhone 2.0 SDK: The No Multitasking Myth General | Respond Apple has a responsibility to iPhone users to develop guidelines that ensure that the system continues to work as expected, doesn’t overheat, and doesn’t plunge in battery life as new applications are installed. Not allowing third party developers to install background processes is part of that plan. It would be irresponsible for Apple to kick open the floodgates for developers and then blame users for not understanding how to manage their own process allocation within the iPhone’s thermal envelope and resource constraints. # [...]

116 countach { 03.28.08 at 2:57 am }

And of course, you don’t need an MMU to preemptively multitask. Even the crappy 8086 chip could preemptively multitask.

117 pecos.bill { 03.31.08 at 2:42 pm }

Very well written.

I also agree with another commenter that at some point Apple might open up task specific threads such as an AIM listener. Those would be required to be vetted by Apple before release. I would presume those will run as child processes to a babysitter task that could throttle them as needed. To my knowledge, such a thing does not exist in Mac OS X, and coupled with the huge effort to get the SDK, wasn’t even considered.

Unless AIM currently supports some flavor of message queuing, I’m not sure what would happen with the messages when the AIM client isn’t running. Currently, AIM doesn’t allow queuing messages while users are offline.

118 eraser’s blog » Blog Archive » iPhone 2.0 SDK: The No Multitasking Myth { 04.11.08 at 10:01 pm }

[...] inability to run multiple applications at once. The suggestion is that the iPhone is a … http://www.roughlydrafted.com/2008/03/13/iphone-20-sdk-the-no-multitasking-myth/ RoughlyDrafted Magazine [...]

119 Mobile EEE PC, UMPC, and Internet Tablets vs the iPhone — RoughlyDrafted Magazine { 05.20.08 at 1:34 pm }

[...] Jobs Ends iPhone SDK Panic iPhone 2.0 SDK: The No Multitasking Myth iPhone 2.0 SDK: How Signing Certificates Work iPhone 2.0 SDK: Video Games to Rival Nintendo DS, [...]

120 Interesting Launch to the New iphone - Page 9 - Nokia N95Users { 07.14.08 at 7:29 am }

[...] Also I don’t know where you guys are getting information that the iPhone can’t multitask: iPhone 2.0 SDK: The No Multitasking Myth — RoughlyDrafted Magazine __________________ If you find my (or anybody else’s) help please use the Thanks button! [...]

121 Why Apple Plays God with the iPhone SDK — RoughlyDrafted Magazine { 08.28.08 at 2:36 am }

[...] iPhone 2.0 SDK: How Signing Certificates Work iPhone 2.0 SDK: The No Multitasking Myth [...]

122 Why I will not be getting an iPhone : The Brits Blog { 10.11.08 at 2:22 pm }

[...] lack of multi-tasking on the iPhone, which isn’t strictly true as both The iPod Observer and RoughlyDrafted Magazine point out in illuminating articles. (By the way the iPod Obeserver Article is shorter, for those of [...]

123 Push To The Background: Will "iPhone 3.0" FINALLY Support True Multitasking? | iPhone 3G Tricks { 02.07.09 at 6:13 am }

[...] (And here’s a great article on why the iPhone, in its current incarnation, CAN multitask &#8212…) [...]

124 2 anos depois, conseguimos definir o que é o iPhone? « Indistinguível da Magia { 02.19.09 at 2:24 pm }

[...] é uma crítica mais complexa. Não é que o iPhone não suporte esses recursos, o fato é que os desenvolvedores não têm acesso a eles no momento de desenvolver seus [...]

125 The big 3.0: How iPhone will shift peripheral devices — RoughlyDrafted Magazine { 03.20.09 at 12:35 am }

[...] iPhone 2.0 SDK: The No Multitasking Myth Gone in a Flash: More on Apple’s iPhone Web Plans Flash Wars: Adobe in the History and Future of Flash SCO, Linux, and Microsoft in the History of OS: 1970s SCO, Linux, and Microsoft in the History of OS: 1980s [...]

126 The Palm Pre/iPhone Multitasking Myth — RoughlyDrafted Magazine { 07.28.09 at 7:44 pm }

[...] iPhone 2.0 SDK: The No Multitasking Myth Real Multitasking After successfully delivering the premise of an intuitive graphical computing environment in a commercial product, Steve Jobs wanted Apple to aggressively move the Mac environment on top of a more sophisticated foundation. A new “Super Mac” operating system was explored, as was a partnership with both AT&T (then the owner of commercial Unix) and a joint engineering project with Apollo, a workstation vendor that produced a Unix-like, sophisticated operating system called Domain/OS. [...]

You must log in to post a comment.