Obviously Steve Jobs and team didn’t go through all the details today when they announced the availability of the iPhone SDK. It was more of a high level pass. But details are what third party developers need to think about before jumping into the iPhone with both feet.
Last year when Facebook announced Facebook Platform, developers had to decide to ignore it, build for it along with a standard web site, or build exclusively for Facebook. Venture capitalist Josh Kopelman laid out an argument that some developers should immediately build on Facebook v. developing for MySpace, despite the fact that it was (and is) proprietary.
Facebook Platform has its own venture funds to support new startups. As of today, so does the iPhone.
The decision to build an iPhone application is very similar. Some developers will add one to their existing products. Others will go iPhone only.
Should we expect Kopelman to write a new post, urging developers to build an iPhone application as soon as possible? Maybe. But a number of bloggers and developers did some digging today into the fine print, and there are some troubling details.
Some of the limitations were announced at the event today. VOIP services, for example, are basically out of luck. They can access the Internet only via wifi, not the cell networks. That’s a signal of a larger issue, though – that Apple isn’t going to allow applications to threaten any of their revenue streams from the iPhone. Likewise, SIM unlocking is forbidden. But what about other, less black and white applications? John Gruber asks if Amazon would be able to launch an iPhone application that allowed users to buy songs from the Amazon MP3 store. That’s a great question, currently without an answer.
Other limitations can be found in the developer agreement. Developers can only use the published APIs and only in the way Apple says they can use them. Ok, that helps with stability. Applications also cannot write data anywhere except in their designated area, meaning developers can’t modify data from any other applications.
But the single biggest issue we’ve found is in the 100 page iPhone Human Interface Guidelines. It’s a public document, but you must be a registered iPhone developer to see it. We’ve embedded it below via docstoc.
Users can only run one application at a time, and if they leave an application it quits. That doesn’t seem like a big deal, but it means that you can’t switch away from an application and have it continue to do things. That’s a big issue with the current support for websites on the iPhone – as soon as you leave the browser the connection is broken. With the iPhone, the hope was that an installed application could continue to run in the background and, most usefully, gather and send information from and to the web.
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. (p. 16)
This will be a serious problem for some developers. For example, say a developer wanted to take location information from the iPhone (created via the iPhones cellular triangulation feature) and dump it into FireEagle to keep track of where you’ve been. Well, that won’t work unless you keep the application open at all times, and don’t use the iPhone for anything other than that. Another example: instant messaging applications (we saw a demo of an AIM version at the event today), can’t run in the background and collect messages while you are doing something else. Leave the application to take a phone call, and it shows you offline. The bottom line is – any application that wants to periodically interact with the web to do stuff, won’t be able to on a continual basis.
Perhaps future versions of the iPhone, with additional CPU and memory resources, won’t have this limitation. But for now, whole classes of applications are useless, or are significantly less useful than they otherwise would be.
If you know of or find other significant limitations, let us know in the comments with a link or text and we’ll add them here.
iPhones Human Interface Guidelines – Get more free documents
Thank you for the doc. The guidelines (for the few highlighted paragraphs here on TC) aren’t too unreasonable. Reliability is king for mobile apps!
I agree, there’s nothing worse for mobile applications. Surely it’s not unreasonable to expect an “app” to work the way it was designed to! Frank Sullivan legal forms Website Owner
Very informative.I will try to add it to my site.
http://technoq.blogspot.com
The GPS tracker app is a good example of an app that wouldn’t want to be frontmost. The other example that springs to mind is an IM client, which sits in the background until somebody sends a message.
Silly Apple. Why impose daft restrictions which serve no purpose?
Anti-trust anyone?
Apple is the new Microsoft…
Allowing things to run in the background on a cellphone (a device so private) is worrysome.. sniffing data (if technically feasible).. eavesdropping calls.. (if technically feasible).. routing to different nets (if technically feasible)…..
Don’t be stupid. Just because its running in the background doesn’t mean its sniffing around. It cant do anything in the background that it cant do when you run it.
You shouldn’t be loading it if you don’t trust it to run.
the biggest limitation is that its from apple.
It’s unfortunate that Apple didn’t put more forethought into this solution. I think you’ll see much more innovation on Google Android’s platform. Yes there are some security concerns, but you should think of these next generation devices more like personal computers. Users will just have to do a little research or download applications from only approved sites.
those limitations are not show stoppers it just sad it does not seem to have much of a multi tasking facility which is odd. I guess it could be down to stopping the device from being killed by to many apps running at the same time.
The developer can just use a system to keep the applications state saved at all times so when its kiled for a phone call and restarted it starts at the same place unless it was closed via the user interface etc.
The biggest problem I have is actaully getting the thing to download. Been trying since yesterday and getting errors. poor show from apple not having planned for this.
Apple did great (and responsibly) to protect its users (at least at this stage, from earlier on) from this “new pc” getting viruses too easily.. for obviously users aren’t going to listen [to download apps from "approved" sites]..
Probably not the right place for this however …
These guys are always hammering on you and here is what I have to say about them…
http://www.john...y/valleywagcom/
Delays are part of lives to be accepted.
http://tekno-wo...ld.blogspot.com
I agree that users will probably not going to download from approved sites. But, users want to make their own decisions. If they didn’t, you would see the proliferation of hacked applications.
I can understand why Apple would want to limit the execution of background services and/or applications given the limited resources of even the best mobile phone devices. The battery life is one of the biggest problems here. However, this doesn’t mean that there aren’t good use cases where you would want or need to execute something in the background.
Regards,
Ken Adair
http://www.appsocial.com
this all plays into google’s efforts with android. much less restrictive and not that far away and much lower entry cost to “have a play”.
I am the creator of Hecl ( http://www.hecl.org ), a Java-based scripting language that runs on Java ME and Android. One of the strengths of that approach, whatever particular language you happen to be using, is that you can download and run new components ‘on the fly’. That is apparently verboten, according to early reports of the developer license agreement. Yuck. I’d be curious to hear more about the details of this and what it means in practice.
Here are my very subjective thoughts on iphone vs android:
http://journal....-but-not-for-me
BTW, what’s up with this “you’re posting too fast” junk?!
It would be an unlevel playing field, and contrary to what Apple has previously said, if you were not able to run apps in the background.
As an example, how can exchange “push” events to the device if something is not running in the background waiting to handle them…
Apple said you get access to all of the same SDK tools that they do, which would imply that there is some way to do this.
Reason why I say all this is that we make our own sync app for the iPhone that syncs with Oracle and other SyncML servers. If we wanted to add a “push” capability, or even just automatic sync every X hours, I do not know how we would do that without some access to run in the background.
It would seem as if Apple kept some toys to themselves if Apple’s sync app was allowed to run in the background, but not others.
Lou
http://nexthaus.com/iphone
Even a Razr can run apps in the background. This type of limitation seems pretty strange to me.
Im very much excited for all new gadgets which will come on my iPod Touch but I think that the main problem is the battery life.
With all this push services, messengers, locators and if you leave your WiFi on all the time, and bit of browsing, you will be searching for charging cable every night. Without listening music or watching videos.
Now I have my WiFi off most of the time trying to spar my battery and still I have to charge it every second day.
I hope this will be fixed on next generation.
Any hope that with this SDK somebody could develop microphone for iPod Touch? That would be awsome!!
Than with proper voip client and WiFi access I would have SIP phone with ridiculously small call prices.
Another big problem for now is the fact that Interface Builder does not yet support the iPhone. No way to start it from within a Cocoa Touch project, and even if you start it directly, none of the iphone components are available.
All of the UI has to be done programmatically which is not the way of doing things in Cocoa or OSX.
If you watch the Developments Tools Getting Started video, around the 11:00 marker it says it’s coming soon.
The question is, why start developing now a full blown UI and have to redo it when they release the actual tool to do it. Might be worth it for games and other graphical applications that will do most of the job programmatically anyway but for other applications doesn’t make any sense.
Other limitations are the lack of answer on how will the approval process work. Sure there is the $99 gate to get the certificates but how long will it take to be approved and all. We’ve all seen what happened on Facebook with the approval process.
For background execution, the key phrase here is “third party applications”. That is, one could probably expect Apple themselves to develop and market background-executing applications. Not totally unreasonable when you consider the security and performance implications as outlined above.
As for the VOIP issue, I’d blame that one on the telcoms. Disallowing VOIP traffic is probably one of the first and foremost things any phone company would insist on before even considering working with Apple. That’s an anti-trust issue IMHO, but it’s not like regulators will do anything about it.
Developer has to have a Mac to write an application. This sounds a problem to me
Michael – We (Mo’Blast) have been thinking about this for a while now. We started with local apps (on Windows Mobile and Nokia S60 using Java), and then we shifted to mobile Web (using the iPhone as a reference platform). We considered staying just in mobile Web. In the end, we decided that we are going to build local apps.
Why? The first reason is a go-to-market reason. We can’t get on the carriers’ decks and now iTune’s deck without a local app. I was hoping that the Apple SDK announcement might change the playing field. Now that Apple is also managing the deck like other carriers, I have decided that I will create local-app versions of our Fon11, OpenLandmark, and other future apps.
There is also a second reason. A European carrier has been telling me that by not shipping local apps, I’m leaving money on the table. People are willing to pay 5 Euros per download for useful applications, such as with location support and a faster user interface. If you do the numbers (given the huge carrier subscriber base), the revenue can be quite substantial for developers.
Actually, it’s not that bad to create separate local apps for the iPhone, Windows Mobile, Nokia, and Andrioid (not available yet) because of the interface builders. Forget about having a common local app code base. It’s not possible to create a user experience that is consistent with all devices. We already experienced the pain with Java 2 ME fragmentation. A common Java code for games is possible. There’s no way for social or business applications. Games have their own navigation. Apps must conform to the device’s navigation.
To play in both, developers must create a robust Web-based backend that can service both local apps and mobile Web platforms. This is very important. Carrier-grade scalability is key, especially on the carrier’s deck.
Regarding only one local app at a time, it’s not a big issue. The app can invoke an API on startup. Presence state can be managed with a time-out feature. It would be nice if we could update the inbox numbers on the Face page (like on the top right corner of Phone, Mail and SMS icons). I have not gone thru’ the API doc in detail. Does anyone know?
Kevin Leong @ Mo’Blast
Not only a Mac, but they have to know Objective C. WTF? This is one the biggest things that is getting overlooked on TC and other websites. NOBODY uses Objective C or even C really anymore, cept for game developers. (Notice how apple has a unusual amount of them during their keynote, their they only ones who keep C/C++ alive). Not sure how it works, but if you have to manage memory then all these “web” script kiddies will be assed out. Sorry PHPer’s but Objective C requires real programming.
Android has a much better chance cause it uses JAVA like almost every other mobile platform on earth. Now every mobile dev has to port their crap to Objective C. What a pain in the ass. Why not just write a JRE for the iPhone. Everyone talks about flash likes it a real dev enviroment on the mobile phone. Its not and hasn’t been tested or proven like java has.
Wait, something good that Windows Mobile can do that the iPhone doesn’t? Everyone watch your heads for falling pieces of sky…
Here’s how to avoid the VOIP problem. Its not that hard to txt a phone number to call and wait for your phone to ring….
When a service allows you to SMS, E-mail, or use a widget to initiate a JAJAH style call where the server calls both parties the problem will be fixed.
I mentioned this to Jahjah employees as well as other Voip people at TC40 but still no one has developed this service.
Think about how much this could disrupt!
About the multitasking stuff:
“Perhaps future versions of the iPhone, with additional CPU and memory resources, won’t have this limitation.”
Hm. Most, if not all, Symbian (S60 and UIQ) phones have less CPU power and less memory than the iPhone. There’s still a hell of a lot of Windows Mobile phones with less CPU power and less memory than the iPhone. And Symbian and Windows Mobile can multitask. Oh, even the crippled LJ OS of the Motorola RAZR² V8 permits apps in the background!
There are many interesting comments on this thread, and I say interesting to mean “wrong”, so let me correct some points:
“Not only a Mac, but they have to know Objective C. WTF? This is one the biggest things that is getting overlooked on TC and other websites. NOBODY uses Objective C or even C really anymore, cept for game developers. (Notice how apple has a unusual amount of them during their keynote, their they only ones who keep C/C++ alive). Not sure how it works, but if you have to manage memory then all these “web” script kiddies will be assed out. Sorry PHPer’s but Objective C requires real programming.”
You don’t have to use Objective C, you have to use Cocoa. There are Cocoa bindings available for Python (PyObjc) and Ruby included with xCode. Once you figure out how the frameworks work (there are hundreds of pages of tutorials and guides at Apple.com, not to mention books…) then it’s a matter of applying them to the language you choose. Most Mac developers choose to use Objective-C because it’s elegant and ubiquitous across Mac OS X development. The language has an odd syntax (remind you of anything, say, Ruby? Nobody uses that right?) but once you spend a few hours figuring it out and writing some sample code, it makes sense and the roadblocks disappear. I know this because last night I downloaded the SDK, installed it, read about Cocoa and Obj-C for a few hours, and then started writing my first iPhone app immediately thereafter. I have OO experience with Java and have been programming with PHP recently, and the transition is not complicated, it just takes a little bit of learning, like any new programming effort.
No, Interface Builder is not currently available. From a previous comment:
“Another big problem for now is the fact that Interface Builder does not yet support the iPhone. No way to start it from within a Cocoa Touch project, and even if you start it directly, none of the iphone components are available.”
All the code that Interface Builder generates for you is available to copy/paste from the myriad iPhone sample projects that come with the SDK. Once Interface Builder ships, then you can hop in there and drag-and-drop your way to recreating the interface code you wrote. Or not. You don’t have to use Interface Builder to define your UI, all of the sample code and applications that come with the SDK don’t use NIBs so what’s the big deal? Java programmers should learn Swing code before they use drag-and-drop layout editors, CSS coders should learn how to position elements on a page by hand, so what’s wrong with iPhone programmers spending a little bit more time learning how to code layouts by hand? Is this really a stumbling point or just a nitpicking issue that you think programmers will actually care about?
To everyone who believes Android is going to eat the iPhone for lunch, we’ll have to wait and see. The prototype Android phones that have been previewed look horrible and we’re not even scheduled to have any working phones running Android for many months. The iPhone SDK is out now, iPhones are out now, and Apple’s Developer site was crashed from the load yesterday for many hours which should give some indication to developers’ reactions to it.
Geeks like myself and the commenters on this thread need to understand that the iPhone’s popularity is not because of some feature chart somewhere where it has everything under the sun and stacks up directly against Nokia’s offerings. The iPhone is the total package. Now, developing for the iPhone is the total package. For free I can download the SDK and start developing for the iPhone right at this minute. In a few months and for $99, the applications I develop will be for sale to all iPhone users via an application that sits on every person’s home screen. There is nowhere near the type of response or anticipation for Android as there is for the iPhone SDK, and the iPhone’s marketshare is only going to climb.
@javaguy
Boohoo, cry me a river. Objective-C is the reason why the apps on the iphone will be better performing, less memory hungry and less power hungry than your beloved java apps. If you can’t program, stick to your watered down language and lousy phone, and leave the heavy lifting to real programmers.
@Tony Smith
If this a problem, don’t develop for the iphone. Check the logo on the iphone if you don’t understand.
Read this: http://code.goo.../lifecycle.html
“Life Cycle of an Android Application
..
3. A service process is one holding a Service that has been started with the startService() method. Though these processes are not directly visible to the user, they are generally doing things that the user cares about (such as background mp3 playback or background network data upload or download), so the system will always keep such processes running unless there is not enough memory to retain all foreground and visible process.
..
“
“thunk” is a dumbass Mactard.
Wow! This just killed all the light in my eyes… The combined power of Steve Jobs and FSJ was enough to hypnotize me into considering an iPhone once again. But now? Well, I’m more well informed. Thanks for the tip. Keep ‘em coming!
Another “limitation” is the lack of integration points with the phone portion of the iPhone. About the only thing you seem to be able to do is initiate an outbound tall to a specified phone number.
- Nick
@Rajiv Singh
You have no idea about my background. But you sound REAL mature. My tone was intentionally trollish because of the whining from those two commenters. My point is that if you don’t like what Apple has put out, don’t use it, don’t program for it, and stop whining.
Apple doesn’t own any mobile services, so I’m pretty sure the mentioned “revenue streams from the iPhone” – in terms of the mobile contract was argued in favor of AT&T and their exclusivity contract, not for Apple. Same for the unlocking of the iPhone for SIM usage.
I don’t mind if applications quit when I’m not using them. Seriously, leave 8 apps running, and there goes the battery life, when I may not even remember I’ve been using an application. I’d rather it quit in the background and save the processor and the battery some work.
That said, there are some limitations that could be annoying for a so-called “power-user” (whatever the hell that’s supposed to mean). I can’t imagine what they are at this point, but I guess I haven’t come across anything that I need the iPhone to do that it can’t do (other than copy/paste text, maybe into an email? which is just annoying) I’m sure there are some who will have a problem with anything, given enough time to scrutinize it.
Hard to believe that a high end device like iPhone has such a limitation, hope they fix it soon.
Those are not the only restrictions / problems with the SDK:
iPhone SDK: 5 Reasons to Love, 5 Reasons to Hate
http://gonnecte...-5-reasons.html
There really isn’t a way today in the US to use a cellular network’s data connection (Edge or 3G) to transmit the voice portion of a VoIP call in an acceptable manner. While 3G bandwidth (though not Edge) would seem OK for VoIP, the latency in these networks makes it difficult o hold a sustained conversation. It is the same limitation those who attempt to use VoIP over a satellite Internet access hookup encounter. So limiting VoIP to WiFi is not that big a deal.
However, the problems you point out developers of a native IM app will encounter, the fact that third-party programs cannot run in the background, WILL cause problems with VoIP. It makes it difficult to keep your phone available for incoming VoIP calls. As soon as you switch to any other application, your iPhone’s registration with the VoIP server would be lost. So a call to your VoIP account (phone number or SIP URI) won’t get to your iPhone.
We’re working on a solution however for when we take RF.COM native.
http://mikecane...e-sdk-question/
One important restriction missed by this article, c.f. iPhone SDK EULA clause 3.3.2.
3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s).
What does this mean? There will be no Flash, Silverlight, JVM, Python, Perl, LUA, unless Apple ships it or otherwise makes an exception.
Also this means Firefox, Opera and other browsers must somehow use IPhone’s built in Javascript interpreter, if possible at all. They must also get rid of the plug-in system.
@thunk : You sound like a Jobsy fanboi apologist. Ease up on the anti-Java rhetoric. Java may be bloated but the concept is solid: write once run anywhere. Performance issues stem from the runtime libraries — the JVM itself is solid — but thee issues are being addressed continuously in Java 6.
What Apple’s done here is create a whole new mobile development ecosystem that’s silo’d from the rest of the J2ME-based world. Windows Mobile did the same, of course, so this is not without precedent. Vendor lock-in is great for the handset makers but bad for the developers and businesses that need to feed off these ecosystems. Java (J2ME) provided the only hope of a shared baseline platform for mobile development. Too bad Apple seems to be shunning it.
Actually… according to industry veteran, Apple got it right. I have to agree with Michael Mace. Here more about it here. http://mobileop...s-it-right.html
BlackBerry’s have no problem running apps in the background. With BlackBerry being hugely successful in enterprise I don’t think you can chalk this ability up as security threat.
I am tired of the limitations of this phone. I’m ready to dump mine and look for something else.
Biggest complaints: (1) can’t copy/paste, (2) can’t look someone up in my contacts by just typing the first few letters of their name (I am so sick of scrolling through my Contacts list and having to select!), (3) can’t send a photo to someone else’s phone (no MMS support), (4) can’t take a picture of yourself because the button is on the touch screen which you can’t see if you turn the phone around, (5) very limited browser cache (I am so sick of waiting for the previous page to load again when I hit the back button in the browser!), (6) you can’t delete a bunch of selected emails at once (you can only delete one at a time!), (7) can’t download photo, video, and music attachments from email to save to playback later, (8) the weather app sucks (it might tell you the temperature and daily forecast, but there’s no way to find out particulars… like what is the chance of rain? when is it going to start and end? how many inches of snow are forecast?), (9) can’t read email in landscape mode, (10) the map application does not always allow you to zoom in enough so you can read the street names, (11) the trash can/delete button for email is placed right next to the Home button! (do you know how many times I’ve accidently deleted emails by going for the Home button and accidently brushing the trash can? ok, you can set an option to have it prompt you before it deletes an email, but this should be unnecessary), (12) no support for internet playlists or internet radio, and (13) no native IM client (one that can alert you of messages when you are doing something else).
And now with the SDK prohibiting apps from running in the background, forget about (12) and (13) being provided by third-parties. I’m so sick of the limitations. Is this what you call minimalist design? LOL
I’m still waiting to be wowed by this thing. The little pinching effect of zooming in and out of web pages is cool, but it does not make up for the other shortcomings. I doubt that I’m the first one to mention these things. If Apple is so design-centric, why haven’t these problems been addressed?
The GUI might quit but, say, the network layer is still running to fetch, eg. emails, stay within Wifi etc…
If you’re looking for Cocoa experts to design you your iPhone App, give us a shout.
James
from
FaceySpacey.com, Your One Stop Social Media Shop
Well the simple truth is that it’s almost impossible to make a developer platform more limiting in the future, but it’s always possible to open up more capabilities with new versions.
Apple wants to make it as limiting as possible and only give out features that people unanimously demand, so they can protect the user experience as much as possible. A good strategy.
I know that smartphone users have an app that lets them get windows-like taskmanager functionality to kill all those apps that aren’t closed properly. Once you’re showing task manager on a cell phone — well, that really sucks.
The iPhone is a mobile computer and not a desktop… runs on a battery and not AC It is meant to be on the go and not tether to AC.
BTW battery power can be depleted….
George,
Switch to Sprint. Why to waste $400 if you can get better expereince in $100-$200 and that too with much affordable plans. With Sprint’s Simply Everything – all you can eat in $99.
I have been using Sprint’s Blackberry 8830 Worldphone and never had a problem. Internet works great and as Sprint doesnt block any third party applications it gives me more freedom to install whatever I like. Give it a try!
As far as other cell makers having the ability to run apps in the back ground … none of their bare-bones operating systems are anywhere near OS X. My sense of Apple’s actions regarding the iPhone is that it must have a lot to do with getting OS X on it. I mean OS X must be hugely stripped down, which could also mean very vulnerable in a fully open software environment, and this may also have something to do with the reason apps can’t run in the background. At first Apple said only sandboxed Web-apps would be allowed, waited, and then said they’d release an SDK … but later in February (more waiting), then they released the SDK and now say devs must wait until June when Iphone2.0 arrives. Their actions have been to delay, delay, delay. Clearly the iPhone has been rushed to market and they still have a ton of work left to do. Perhaps the next version of iPhone processor will have greater capacity and allow more of the basic user features we have come to expect.
The iPhone isn’t perfect but it is just beginning to ramp up. My gosh, what do some people expect? No product will ever please everybody and no product is ever complete at the outset. In fact, products are suppose to evolve and become better products over time. After using a number of smartphones, I am quite pleased with my iPhone and I am happy that it is a platform that can be easily updated via software instead of having to upgrade hardware every year. If someone has the PERFECT product that can do everything that everybody on the planet wants it to do immediately and at all times, invent it instead of whining over why someone else isn’t doing it.
Apple iPhone is just like MS Windows 3.11…still a single tasking DOS with a nice GUI.