iPhone SDK And Restrictions: Some Of The Details Aren’t Great.

Trackbacks/Pings (Trackback URL)

1. 113.com
   

   March 7th, 2008 at 3:58 am

   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!

2. Technoq.blogspot.com
   

   March 7th, 2008 at 4:02 am

   Very informative.I will try to add it to my site.

   http://technoq.blogspot.com

3. Webreaper
   

   March 7th, 2008 at 4:07 am

   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?

4. John Doerr
   

   March 7th, 2008 at 4:10 am

   Anti-trust anyone?

   Apple is the new Microsoft…

5. 113.com
   

   March 7th, 2008 at 4:15 am

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

6. John John
   

   March 7th, 2008 at 4:19 am

   the biggest limitation is that its from apple.

7. Ken Adair
   

   March 7th, 2008 at 4:27 am

   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.

8. Darren Stuart
   

   March 7th, 2008 at 4:29 am

   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.

9. 113.com
   

   March 7th, 2008 at 4:32 am

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

10. John Willis
    

    March 7th, 2008 at 4:33 am

    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/sil.....leywagcom/

11. Rajeev
    

    March 7th, 2008 at 4:35 am

    Delays are part of lives to be accepted.

    http://tekno-world.blogspot.com

12. Ken Adair
    

    March 7th, 2008 at 4:55 am

    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

13. jon bradford
    

    March 7th, 2008 at 5:31 am

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

14. David Welton
    

    March 7th, 2008 at 6:11 am

    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/art.....not-for-me

    BTW, what’s up with this “you’re posting too fast” junk?!

15. LouN
    

    March 7th, 2008 at 7:57 am

    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

16. bozzy
    

    March 7th, 2008 at 7:58 am

    Even a Razr can run apps in the background. This type of limitation seems pretty strange to me.

17. johny
    

    March 7th, 2008 at 9:06 am

    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.

18. jerome
    

    March 7th, 2008 at 9:32 am

    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.

19. Markus
    

    March 7th, 2008 at 9:37 am

    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.

20. Tony Smith
    

    March 7th, 2008 at 10:37 am

    Developer has to have a Mac to write an application. This sounds a problem to me

21. Kevin
    

    March 7th, 2008 at 11:14 am

    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

22. JavaGuy
    

    March 7th, 2008 at 11:16 am

    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.

23. Sam Jackson
    

    March 7th, 2008 at 11:20 am

    Wait, something good that Windows Mobile can do that the iPhone doesn’t? Everyone watch your heads for falling pieces of sky…

24. Zach Weisman
    

    March 7th, 2008 at 11:24 am

    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!

25. Cesar Cardoso
    

    March 7th, 2008 at 11:37 am

    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!

26. Mike Rundle
    

    March 7th, 2008 at 12:04 pm

    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.

27. thunk
    

    March 7th, 2008 at 12:16 pm

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

28. n2
    

    March 7th, 2008 at 12:20 pm

    Read this: http://code.google.com/android.....cycle.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.
    ..
    “

29. Rajiv Singh
    

    March 7th, 2008 at 12:26 pm

    “thunk” is a dumbass Mactard.

30. David Gonzales
    

    March 7th, 2008 at 12:28 pm

    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!

31. Nick Dalton
    

    March 7th, 2008 at 12:48 pm

    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

32. thunk
    

    March 7th, 2008 at 1:23 pm

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

33. mimi
    

    March 7th, 2008 at 1:35 pm

    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.

34. Bob
    

    March 7th, 2008 at 1:51 pm

    Hard to believe that a high end device like iPhone has such a limitation, hope they fix it soon.

35. jws
    

    March 7th, 2008 at 1:59 pm

    Those are not the only restrictions / problems with the SDK:
    iPhone SDK: 5 Reasons to Love, 5 Reasons to Hate
    http://gonnected.blogspot.com/.....asons.html

36. Marcelo Rodriguez
    

    March 7th, 2008 at 3:51 pm

    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.

37. Mike Cane
    

    March 7th, 2008 at 4:21 pm

    http://mikecane2008.wordpress......-question/

38. A non-mouse
    

    March 7th, 2008 at 5:41 pm

    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.

39. Sid
    

    March 7th, 2008 at 7:04 pm

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

40. Kevin Leong
    

    March 7th, 2008 at 7:36 pm

    Actually… according to industry veteran, Apple got it right. I have to agree with Michael Mace. Here more about it here. http://mobileopportunity.blogs.....right.html

41. physio
    

    March 7th, 2008 at 8:16 pm

    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.

42. George
    

    March 7th, 2008 at 8:30 pm

    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?

43. Christian
    

    March 7th, 2008 at 8:54 pm

    The GUI might quit but, say, the network layer is still running to fetch, eg. emails, stay within Wifi etc…

44. James Gillmore
    

    March 7th, 2008 at 9:14 pm

    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

45. Sav
    

    March 7th, 2008 at 10:58 pm

    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.

46. AdamC
    

    March 7th, 2008 at 11:09 pm

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

47. Satinderbir Singh
    

    March 8th, 2008 at 12:35 am

    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!

48. Brau
    

    March 8th, 2008 at 3:51 am

    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.

49. Dean
    

    March 8th, 2008 at 8:40 am

    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.

50. Bill&Ted
    

    March 8th, 2008 at 8:41 am

    Apple iPhone is just like MS Windows 3.11…still a single tasking DOS with a nice GUI.

51. Quentin
    

    March 8th, 2008 at 9:26 am

    For those of you complaining for the last 8 months about the lack of copy&paste capability, have you actually used the phone? You do realize that it’s impossible for an application to read your mind and figure out if you want to pan the screen, or select text. In text input areas, it could not read your mind to see if you wanted to select text or just move the cursor. With the touch interface, there are just some things you won’t be able to do. You can choose to either zoom in/out, pan/scroll using the touch interface, or select chunks of text. You cannot do both. Apple could possibly add in some sort of right-click like functionality, but with the current touch interface, selecting text is not possible.

    For the Java/Android fans, Java may be solid, and Android has potential, but the argument comes up everytime anyone talks about Flash/Flex, PHP, and now Objective C for the iphone. Java is not the only capable programming language. It is bloated and slow in a lot of applications, and there is not one programming language for everything. Why does it have to be Java or nothing? Plenty other languages are very capable for what they do, and they are hardly inferior to your beloved bloated Java.

52. hiro protagonist
    

    March 8th, 2008 at 10:28 am

    If you have done ANY kind of development for mobile devices, period - you would know that these ‘restrictions’ are basically the exact same set of restrictions that every other mobile device has for applications.

    This is nothing surprising, unless you are expecting to be able to port any random application to the iphone and expect it to function the same as it did on ‘x’ platform before.

    It’s a celphone, albeit a fancy looking one that can do some cool stuff. But when you get down to it, it’s a celphone, and as such expect the normal celphone restrictions to be in place.

    The major difference, which apple really needs to be congratulated on, is the fact that it is an OPEN celphone platform - meaning that anyone will be able to put apps onto the iphone without going through the very rigorous and expensive ‘certification’ process that normal mobile development requires. Not to mention the process of simply getting permission to roll out your application on ‘x’ providers mobile network.

    This ability for anyone to make mobile applications should be a HUGE boon to the mobile developer market - and add in the fact that the iPhone is a single hardware device, very similar to the Nintendo DS (which is basically a fancy celphone as well) or the Ngage - simplifies what is currently a nightmare development process.

    Current mobile development market:
    1) try to get permission to launch on ‘x’ providers network (typically such a convoluted process you MUST go through a major publisher or partner to even get the time of day from the providers)
    2) create mobile game (say in j2me). J2me is probably the most broken ’standard’ ever. Every single mobile device implements the standard slightly differently and not only that, but different firmware versions can completely break your application, so you have to test and patch applications for specific firmware versions
    3) once you have the game created, you need to test it for ALL of the potential configurations of phones / j2me runtimes / firmware versions that the provider / publisher wants you to support - this can literally run into hundreds of UNIQUE handsets that need to be supported - each with a custom build of your game.
    4) all of this has to be done on ridiculously small budgets because the business model for actually getting paid for your application is remote, and the pricing model forces you to sell the app for a pittance. In order to make any kind of money on an app you have to sell tens of thousands of copies - a questionable prospect for all but the most successful applications.

    The iPhone SDK changes almost all of these barriers to mobile development and should be welcomed as the paradigm shift that it has the potential to become.

    ps. no i don’t currently own an iphone or have anything to do with apple, just thoughts based on our own prior experience developing mobile games.

53. Pete Tenereillo
    

    March 8th, 2008 at 1:08 pm

    hiro what you say is not true - ok it’s partly true, it is difficult to get carrier approval for most of the flip phones, especially anything location based. I think many here have lived that incl me so that’s not news.

    But my apps are released on Nokia / BlackBerry / Windows Mobile with no carrier approval, and those are the iPhone competitors.

    This whole thing about no background apps and one app at a time is a HUGE limitation for any sort of alert based or LBS app.

    This is not good news to me or my users who have been waiting for an iPhone version of Trapter. I’ll still make an app, but will have to re-think it. So much for the radar detector model that beeps the iPhone automatically when you approach speed traps (that is how all the other platforms work with Trapster - now not possible with iPhone).

    Pete
    Trapster.com

54. Mohasin
    

    March 8th, 2008 at 1:28 pm

    The reason why 3rd party applications can only execute ONLY in the foreground, I think, is because of the restriction in the design of the SDK. I basically think that it is a design flaw (and probably Apple engineers never had time to really sort it out).

55. Quentin
    

    March 8th, 2008 at 5:19 pm

    It’s not a “design flaw”
    It’s a strict limitation implemented by Apple to guarantee stability.
    More apps running = higher chance of device crashing, which Apple would get blamed for.

    The “jailbreak” community has already developed and distributed apps that have background execution functionality, so it’s clearly not a design flaw, or an inherent limitation. It is simply a way for Apple to guarantee it’s reputation of stability for the iphone.

56. wizardm
    

    March 10th, 2008 at 12:14 am

    The missing mulitasking feature is no big problem if apps can control their termination, so that it can save its state to memory.

57. Mike Cane
    

    March 10th, 2008 at 3:05 pm

    And to think, when the iPhone was first announced, most everyone screamed “You can’t develop for it!!!”

    Now that you can, there are *still* complaints.

    Make up your frikkin minds!

58. millenomi
    

    March 11th, 2008 at 1:45 am

    Ahem, dudes. If you have taken that HIG from Apple’s web site with your own login, you’re violating Apple’s beta NDA that you agreed to. So Apple may conceivably be pissed you posting it in public.

    Just sayin’.

59. Adam
    

    March 11th, 2008 at 10:30 am

    Is the code language in C?

60. Alex
    

    March 11th, 2008 at 8:05 pm

    oh man, really? You guys never quit do you. Talk about a gigantic exaggeration, your picture is absolutely over the top. Your bagging on something that isn’t even out yet. seriously, you have no cred. none. zero.

    I’ll finish by saying this. Get off the “look at me I’m a smarty pants” band wagon and stop thinking your cool by finding every little imperfection. Bottom line, it’s much more interesting to read articles about what you can do not what you can’t do.

    Oh, btw. Your are breaking the developers agreement by posting the UI guidelines. And here you are bagging on apple, you can’t even follow the agreement you made. Amazing!

61. Alex
    

    March 11th, 2008 at 8:10 pm

    P.S.
    It also appears the first 5 post on this site are completely bogus. Look at the names. lame. When real people started posting your article turned into a joke.

62. Rusty Shackleford
    

    March 13th, 2008 at 9:45 pm

    I’m surprised Apple’s thugs, I mean lawyers haven’t had that document removed from your site y et.

63. Thomas
    

    March 15th, 2008 at 1:02 am

    For the Android less desirable because Java is bloated/slow/… folks. The language is Java and even the first pass of the compiler, but it targets the Dalvik virtual machine, not a Sun JRE. That said, an implementation of Java ME appears to be available for Android from Esmertec, http://www.esmertec.com/, an Open Handset Alliance member.

    http://code.google.com/android.....droid.html

    From the above URL.

    “Every Android application runs in its own process, with its own instance of the Dalvik virtual machine. Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed into the .dex format by the included “dx” tool.”

    And finally intelligent state saving does not satisfy event based requirements, or allow for providing audio while a user views something else.

64. chush.net
    

    March 28th, 2008 at 1:02 am

    Just read the SDK docs. What a shame! One can do SO much more with windows mobile than with an iPhone. Who would think that Apple would be much more closed for developers than MS.