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.johnmwillis.com/silicon-valley/valleywagcom/
Delays are part of lives to be accepted.
http://tekno-world.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.dedasys.com/articles/2008/03/07/iphone-nice-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.google.com/android/intro/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!