iPhone's Development Limitations Could Hurt It In the Long Run

ZDOne writes "Apple might have finally come around to allowing third party developers to create applications for the iPhone, but only up to a point. ZDNet UK claims Apple is leaving itself vulnerable to the competition and to a loss of lustre by blocking background tasks on the device. The author notes, 'Perhaps it doesn't trust application designers or users very much. Perhaps it wants the best software for itself, where it can limit what it can do in order not to upset its telco friends. Whatever the reason, it reflects badly on Apple. The iPhone is not an iPod; it's a smartphone connecting to a universe of fast-changing data on behalf of innovation-hungry users. The sooner it stops pretending to be a 1981 IBM PC, the better it will be for everyone.'"

Comments

Re:Where is the competition?

[jrumney]

I wouldn't even know where to start if I wanted to develop an application for my Sony Ericsson W910,

developer.sonyericsson.com would be a good start, which is linked directly on the front page of www.sonyericsson.com, so you can't have looked very hard in your rush to defend the iPhone.

Re:Where is the competition?

[Aldric]

Microsoft. It's easy to create a program for Windows Mobile without Visual Studio, and stupidly easy with it.

Re:Symbian 3rd signed is the same

[Eunuchswear]

You can run unsigned apps on s60v3.

Unsigned apps can access the network (see for example putty), play run stuff on the screen (see for example quake, dooom), run in the background, read & write files and so on.

I can't seem to find this famous list of things an unsigned app can't do.

Re:Um... phone network != internet

[teh kurisu]

Banning uncertified code?

The way J2ME operates is far more sensible than a total ban. Every time an unsigned program wants to make use of a 'restricted' API, the user is prompted. This stops anything malicious from happening.

Banning background processes?

If you're doing the above, then this additional step is completely pointless and only serves to limit the usefulness of your platform. It's not like the backgrounding abilities of Symbian phones have brought down the phone networks yet.

Re:ZDNet Writers Lack Technical Expertise

[DavidShor]

Dude, my jailbroken iphone runs background processes on third party software right now. I can run a good number of programs before the thing slows down. Programmers are pretty good at satisfying space constraints.

Re:Where is the competition?

[nguy]

Among the mobile phone makers, who hands out SDKs for creating applications on the phones?

Almost every manufacturer, actually: there are SDKs for Symbian (Nokia, Motorola, Samsung), Windows Mobile (Motorola, Samsung, HTC, ...), Palm OS (Palm), etc. Symbian is a multitasking OS with Linux-like APIs. And almost all modern phones other than the iPhone can be programmed in MIDP.

I wouldn't even know where to start if I wanted to develop an application for my Sony Ericsson W910,

The W910 runs J2ME and MIPD, just like most phones these days. There are thousands of applications for that and it's easy to develop for.

call me clueless but I don't see anything comparable to the iPhone SDK for any other phone.

Yup, you're clueless. In terms of SDK, the iPhone is about the worst there is among modern phone platforms.

not true

[nguy]

Symbian 3rd edition, hava also limitations to developers, for certain type of capabilities the program must be signed by nokia. And there is a license 10.000$ for developers

That's pure fiction. I have half a dozen unsigned apps on my phone, several of them free and open source.

Re:not true

[SteveAyre]

Unless it's like the Blackberry. They allow anyone to use most of the API calls, but require the developers to pay a fee for access to some of the API calls and sign the applications so that the Blackberry knows which programs to allow to access the licensed API calls.

In their case it's more to control the riskier functions, so you can make a free unsigned game which only really needs graphics and the keypad without signing the code but anything that runs a risk of doing something like making a call, eavesdropping or deleting your data needs to be signed.

http://na.blackberry.com/eng/developers/downloads/api.jsp
The fee's tiny ($20) for access, but that's tiny really so it's more about being able to control the programs using those API calls.

Symbian might be similar since the GP said for "certain type of capabilities". The fee's huge by comparison though, so perhaps they want the revenue more than the security benefits.

stupidity

[nguy]

Banning uncertified code? Banning background processes? That sounds pretty damned prudent to me.

Smart phones have had background processes and uncertified code for many years, and there have been almost no problems with it in practice. Half of Nokia's phone lineup are fully programmable, multi-tasking machines, capable of running ssh, BitTorrent, Python, VNC client and server, Apache web server, and anything else you can think of. There's even software for turning Symbian phones into WiFi access points for sharing the 3G connection.

Anybody who claims that one needs to ban uncertified code and background processes to avert disaster simply doesn't know the mobile phone business... or is lying through their teeth.

bullshit

[S3D]

Symbian 3rd edition (v 9.x) is not capable of running unsigned native application. Period.
Some application, restricted in functionality could be signed by developer without developer certificate(LocalServices, UserEnvironment, NetworkServices,ReadUserData ,WriteUserData). User can allow application which use only those capabilities to run on his device. The rest - Network control, Multimedia driver, Communication driver, disk admi, PowerMgmt, Location, ProtServ, ReadDeviceData, Surroundings driver, SwEvent, TrustedUI, WriteDeviceData - should be signed online through Symbian website or offline by other certified body.
The situation is quite heated right now, after Symbian introduced some more restrictions recently (removed free developer certificates, which allow sign application for single phone - IMEI numebr). Symbian signed forum turning to flamefeast between moderator interventions. http://developer.symbian.com/forum/forum.jspa?forumID=2&start=0
Of cause all this only from legal point of view. Many devices (all FP1 and Nokia N95-1, not 8GB) have their platform security hacked already.

Re:Symbian 3rd signed is the same

[eggz128]

I can't seem to find this famous list of things an unsigned app can't do.

There are a few references here:

1.5 Why can I not get a certificate to sign Freeware, there is no other way to install Freeware? Contact your freeware developer and request him/her to re-release the application such that Developer Certificates are not required. a) Approx 60% of APIs do not require any Capabilities and applications using only those APIs do not need to use Symbian Signed services. b) The Capabilities; LocalServices, Location*, NetworkServices,ReadUserData ,UserEnvironment, WriteUserData: are user-grantable on the device. Applications using these Capabilities are not required to be Symbian Signed; an end-user can grant the permissions on their device. This allows people to do application development with a large amount of functionality for interesting apps. At least 25% of commercial apps are released without needing to use any Symbian Signed services. c) The Capabilities; PowerMgmt, Location*, ProtServ, ReadDeviceData, SurroundingsDD, SwEvent, TrustedUI, WriteDeviceData: are grantable by Open Signed Online, as well as all the user grantable permissions described in (2) .There is a requirement (as requested by the developer community) that you must own the applications UID, or you may use a test UID (i.e. in the range 0xE0000000 to 0xEFFFFFFF). This protects the integrity of UID allocation process and prevents developers signing applications with UIDs which have been reserved by other developers. Note: Location* depends on device type

There seems to be a further capability level that can only be granted by manufaturers (I would guess for APIs that could break DRM on the phones, or work at a low level on the cell network):

Symbian Signed allows access to all but the seven most resticted capabilities on the phone (these capabilities can only be accessed with an extra level of manufacturer approval). Self-signing allows application access to a more limited set of capabilities than Symbian Signed. General capabilities that are not considered a major security risk can be access via self signed applications. Where there is a small security risk (such as the use of Bluetooth or use of the Network to retrieve data) self signed application must gain user permission to access these capabilities (in the form of a dialog that asks user the grant these capabilities to an application).

Not without their reasons

[countach]

Background tasks, especially networking ones (which frankly, are the most useful type), would flatten the battery really quickly. Even more so with several of them waking up at different times and connecting the network.

On the other hand, making the rule hard and fast is a bit tough. And Apple could provide some means of minimizing drain (waking every task up every few hours for example), but don't damn Apple totally on this one.

Re:Not without their reasons

[Achromatic1978]

Bah. No they won't. On my phone, this is as simple as a setting "Allow network data usage: Never, Home, Roaming, Always" - selecting certain options will result in a "May incur higher costs" confirmation message. Simply solved. People are just too keen to excuse these kind of things.

Re:Bad analogy

[tweak13]

That's the worst analogy in history. For someone talking about history, you don't know too much of it. It took reverse engineering to make the first "IBM compatible" computers. It was only later that IBM became more open.

Who modded this insightful?

Re:Even funnier

[Anonymous Coward]

1)- the iphone sdk DOES NOT ban background processes. it disables them by default, but people have been compiling iphone apps that run in the background for months. it's actually ridiculously easy; this is how im apps let you stay signed on while your iphone is off (or you're talking on it).
2)- the official iphone os may ban uncertified code, but people have been running uncertified code on iphones for months. since the number of "hacked" iphones is almost as great as the number of "boring" iphones, this is rather significant.

i'm not a fanboy- personally, i don't like iphones, or people who like iphones. i just don't like misinformation.

Re:Even funnier

[catwh0re]

Better yet, if they actually read the T&C's they'll see that you can still run background apps, it's just not advised. Otherwise applications like AIM won't be able to run.

It's a sane request, and not a requirement.

[FellowConspirator]

Two things: first, the human interface guidelines (HIG) stipulation that a process not background itself is perfectly reasonable. The phone form-factor has limited battery, memory, and processor resources. It wouldn't take much to make resource contention an issue or to torpedo battery-life and phone performance. This isn't a laptop with a big battery, multi-gigabytes of RAM, and a 3GHz dual-core CPU.

It should also be noted that while the HIG asks you not to make your app run in the background, neither the phone nor the SDK enforce it. You can, in fact, do it.

If you want to sell your app through Apple's service, you probably need to communicate to them that there's a good reason for it (for example, implementing hands-free voice-dialing might require it). Apple reserves the right to not carry applications that don't meet the HIG, but there's no reason to think that they won't make exceptions when a reasonable request is made to do so. Certainly, a good hands-free voice-dialing app would be a good candidate for such a thing.

The old term was "road apple".

[reiisi]

See lowendmac and (for instance) wikipedia

Re:Bad apple tag?

[slawo]

The SDK is crippled. Not function wise but legally. It is forbidden for example to use the WAN interface of the iPhone for VoIP applications. This makes it basically impossible to introduce applications like Skype or SIP softphones on the iPhone when you are outside of a usable WiFi zone. Also the Apple guidelines state that it is forbidden to leave your application running during voice communications and while your application is out of scope. This again makes any messaging application impossible on the iPhone.

These restrictions are here to artificially limit competition between advanced communication applications and the telcos. It keeps you dependent on the old phone voice communications and the old SMS system which are obsolete and extremely expensive comparing to any IM and SIP solution.

This way you are banned from using any innovative communication technology while paying for the (artificially) crippled internet connection plus the expensive call rates.

Re:Umm...Mod parent down?

[toleraen]

Few of them will last 5 days while doing anything other than waiting for an occasional ring. When did I say that it lasted that long on a single charge? I was responding to their comment that having several programs open kills the OS. It doesn't. The 163 hours number was just how long the phone has been connected without interruption, ie not soft reset. I know I synced my phone last week, which I have set to disable any data connection (otherwise my VPN connection freaks out on my laptop). I know it's been running without a soft reset longer than 163 hours, but I don't recall exactly when. I just know it's been longer than 163 hours.

Battery life sucks for any smartphone, not just WinMo though. I charge my phone every night, otherwise it lasts maybe 36 hours through regular use. A bit more if I turn off data to disable the 3 email accounts, weather info, web browsing, etc, that I do normally.

But if you are actually using any programs on it, that battery is toast with all that junk open (Windows Media Player? Is it actually playing music? Why leave it open?). This is like the file copy troll all over again. Why leave programs open? Is that a serious question? If it's loaded into RAM then I don't have to wait for it to load from ROM. Reading from RAM is faster than reading from flash memory, in case you were wondering. To answer your question though, no, it isn't playing songs 24/7. However, I can just do a start - WMP and hit play to start playing any random song I've got on there. Same with every other app I've got open. I can either wait for Live Search to load to view a map, or see the map instantly.

This is like the file copy troll all over again. Are you sure it's not you who is the troll? I'm sitting here using the device, and posting my experience from using it. You are posting feedback based on stuff you've heard from clients. Anecdotal, sure, but head over to XDA-Developers some time and ask them about using it. Feel free to message me when you get there, I'm under the same username.