Daniel Eran Dilger
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: , , , ,

  • Scott

    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”…

  • beanie

    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?

  • yuhong

    “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]

  • starkruzr

    “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?

  • dssstrkl

    @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.

  • dicklacara

    @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

  • Rich

    “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.

  • demallien

    @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…

  • David Dennis

    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

  • http://www.nyceducated.info/ Michael P

    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.

  • starkruzr

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

  • starkruzr

    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.

  • Mr. X

    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.

  • starkruzr

    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.

  • yuhong

    “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.

  • Rich

    “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.

  • Mr. X

    ” 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.

  • Pingback: iPhone 2.0 SDK: Java on the iPhone? — RoughlyDrafted Magazine()

  • Mr. X

    “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.

  • Mr. X

    “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.

  • yuhong

    >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.

  • http://johnsessays.blogspot.com John Muir

    @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.

  • harrywolf

    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.

  • starkruzr

    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?

  • countach

    “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.

  • Mr. X

    “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!”

  • Mr. X

    “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.

  • countach

    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.

  • Mr. X

    “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?

  • duckie

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

  • starkruzr

    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.

  • http://www.kimhill.com kimhill

    @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…

  • gus2000

    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.

  • http://www.kimhill.com kimhill

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

  • yuhong

    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.

  • gus2000

    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.

  • Mr. X

    “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.

  • Mr. X

    “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.

  • starkruzr

    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.

  • Mr. X

    “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.

  • countach

    “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.

  • demallien

    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…

  • countach

    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.

  • http://www.kimhill.com kimhill

    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.”

  • starkruzr

    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.

  • demallien

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

    Twit.

  • Pingback: rambo's ramblings()

  • Mr. X

    “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.

  • Mr. X

    “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.” :-)

  • mmbossman

    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.