iPhone 2.0 SDK: The No Multitasking Myth

March 13th, 2008

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

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

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: Apple, Bloggers, Development, iPhone, the Media

kusmi

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)
pinion

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

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

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

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.
http://wimleers.com Wim Leers

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

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. :)
http://johnsessays.blogspot.com John Muir

@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. ;)
OlivierL

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

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

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 !
Rich

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

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
duckie

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

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

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

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 ]
http://www.jphotog.com ewelch

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.
http://johnsessays.blogspot.com John Muir

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

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

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

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

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

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

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!
addicted44

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

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
http://johnsessays.blogspot.com John Muir

@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? ;)
punkassjim

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

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

@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
http://johnsessays.blogspot.com John Muir

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

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?
http://johnsessays.blogspot.com John Muir

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

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

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

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.
Pingback: Generation 5 » The Wisdom of a Closed Platform()
http://euc.cx/ jshell

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).
http://www.kimhill.com kimhill

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.
http://www.roughlydrafted.com danieleran

@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.
http://www.kimhill.com kimhill

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.
http://www.whydoeseverythingsuck.com hank777

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
http://www.roughlydrafted.com danieleran

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

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

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

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

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.
Pingback: iPhone 2.0 SDK: The No Multitasking Myth via RoughlyDrafted | Just Another iPhone Blog()
thgd

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

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)

iPhone 2.0 SDK: The No Multitasking Myth

Navigation

Search this site

Recent Articles

Search This Site

Categories