Slashdot Mirror


Apple Relaxes iOS Development Tool Restrictions

An anonymous reader writes "Earlier this year Apple caused major upset among developers by updating the iPhone developer program license with clause 3.3.1. It basically stopped the use of cross-platform compilers, meaning Adobe Flash could not be used to develop an app for the App Store. The move also put into doubt which other development platforms could be used and generally caused a lot of confusion. Apple has just significantly relaxed that policy and allowed for the use of development tools, as long as 'the resulting apps do not download any code.'"

62 of 347 comments (clear)

  1. Problem by Anonymous Coward · · Score: 3, Insightful

    There are still interesting problems in not allowing to download or update any code. With the rise of jailbreaking iPhones and them running unsigned and modified applications (cracked and/or otherwise), there is no way for an anticheat system to update itself. All anticheat systems like Valve's VAC, PunkBuster and Blizzard's Warden rely on downloading updated code from the internet.

    What this means for online iPhone games is that when someone releases a hack for the jailbroken iPhones, their users can completely ruin the games and legit players cannot do anything. And since Apple is a control freak, they check every update to your application slowly and ineffectely. All while the hacking is rampant and ruins everyones game.

    There certainly are need for updating code and Apple needs to remove that clause too. We don't want walled gardens controlled by mega corporations, we want systems we can use the way we want.

    1. Re:Problem by Kjella · · Score: 3, Insightful

      And how is the situation you describe any different than every console? If you live in a signed sandbox, you live on the good graces of the signee. Doesn't seem like that's a dealbreaker to anyone.

      --
      Live today, because you never know what tomorrow brings
    2. Re:Problem by tlhIngan · · Score: 4, Interesting

      There are still interesting problems in not allowing to download or update any code. With the rise of jailbreaking iPhones and them running unsigned and modified applications (cracked and/or otherwise), there is no way for an anticheat system to update itself. All anticheat systems like Valve's VAC, PunkBuster and Blizzard's Warden rely on downloading updated code from the internet.

      What this means for online iPhone games is that when someone releases a hack for the jailbroken iPhones, their users can completely ruin the games and legit players cannot do anything. And since Apple is a control freak, they check every update to your application slowly and ineffectely. All while the hacking is rampant and ruins everyones game.

      There certainly are need for updating code and Apple needs to remove that clause too. We don't want walled gardens controlled by mega corporations, we want systems we can use the way we want.

      Jailbroken and/or pirated apps are easily detected. So easily detected, that Apple doesn't really bother, because apps can do it themselves.

      Firstly, an app downloaded from the App Store has DRM on it, which consists mostly of encrypted portions of the binary. That binary is then signed. On running the app, the kernel loads the app, validates the signature, then in-memory decrypts the binary, and finally runs it.

      A cracked app can't be re-encrypted for a specific device, so they're shipped decrypted. The kernel, however, cannot load unsigned binaries unless a special flag is set to indicate that it's a decrypted binary that's OK.

      An app just needs to check for that flag which exists in its info.plist file. It can do several checks - first, is info.plist in text format (it should be binary XML)? Second, do those keys exist in the file?

      The apps that do the obvious checks are quickly re-patched to disable those checks, but there's nothing to say that an app has to pop up an "I'm pirated!" notice - it can silently report its pirated status to the server, for example, but otherwise run normally. Most crackers don't check, and most pirates won't bother. Even the ones running Firewall IP (a really nice firewall alert). You need someone to actually go and sniff the WiFi transmissions to ensure it's sending the same data to the server. Use SSL and you're golden. (Sure the pirate could disable all network access, but then who cares about single-player cheating?).

      Also, assets are signed as well, so replacing all the textures with transparent ones also have the exact same issue - you have to go and decrypt the binary, make your mods and set the flag. There are also tests for jailbroken phones as well.

      Online multiplayer is not a huge thing on iPhones, iPads and iPod Touches - at least, the ones where you can't do server-side validation of inputs (which you should do anyways). Local multiplayer may be a bigger deal, but there are probably social pressures against that behavior as well.

    3. Re:Problem by Hatta · · Score: 2, Insightful

      Why do you assume that's not a deal breaker for anyone? Every console ever has been hacked, people wouldn't do that if they didn't object to being restricted.

      --
      Give me Classic Slashdot or give me death!
    4. Re:Problem by IKnwThePiecesFt · · Score: 2, Insightful

      Or if they didn't object to paying for their games. One of the two.

    5. Re:Problem by afabbro · · Score: 2, Informative

      I find anti-cheating software an unnecessary evil. It is very basic software engineering: "never trust input from a user". As the client software of game is in the hands of the user this extends to the client itself. In fact this also extends to the anti-cheating software itself. Like DRM, anti-cheating software is a mathematical impossibility.

      Much as I hate to step on a good pompous rant, you're oversimplifying and missing quite a bit. For example, there's rendering information the server has to send the client. If the client is altered to make some of the rendering transparent, the ability to look through walls is gained, which is cheating. No "trusting user input" is needed here. It would not be practical to render on the server and send the frames to the client, yet the client needs info that the user can't necessarily see to render correctly and maintain a decent frame rate.

      Likewise, imagine there is a weapon that when fired blinds the opponent. If the opponent's client is modified to remove that effect, the server may never know if it's just a visual effect. Or perhaps some bad guys are hidden among the good guys...a modified client could change their color or highlight them. Or maybe I have a couple friends over and our modified clients all share information - we can then see what others see, look around walls, etc.

      It is far easier to just design your game so that you do not trust the client code, run the simulation/game on the server and let the client be a dumb terminal. Dumb being a relative term, as you do want to implement some sort of prediction in the game to what the game server will do, to make it a smooth user experience.

      And therein lies many opportunities to cheat. Once the client has any information that should not be available to the player, there is an opportunity to cheat. Yet this information may be vital to having a smooth, high frame rate user experience. I suppose the ideal anti-cheat would be a system where the entire GUI was rendered on the server and the client just received frames, but that is not practical from a performance viewpoint. Heck, I still see a little lag when typing in a terminal window connected to an SSH session on the other side of the country...playing an FPS via RDP over the Internet would not work.

      I'm just picking random examples off the top of my head, but the problem is not as simple as you imply

      --
      Advice: on VPS providers
  2. Yea by mrsteveman1 · · Score: 2, Interesting

    It's refreshing to see Apple wrong so many times in a row. Watching them backpedal is amusing.

    1. Re:Yea by Tom · · Score: 3, Insightful

      At least they are. We all know companies that'd rather die than admit they were wrong.

      --
      Assorted stuff I do sometimes: Lemuria.org
    2. Re:Yea by Zelgadiss · · Score: 2, Insightful

      No significantly complex system comes out right the first time.
      Apple has a goal, I believe it's to give as much freedom to 3rd party developers without losing control of the platform.

      It's like how Blizzard balances WoW, they have "back-pedalled" countless times.

    3. Re:Yea by Anonymous Coward · · Score: 5, Funny

      It's refreshing to see Apple wrong so many times in a row. Watching them backpedal is amusing.

      When was Apple wrong? Apple was never wrong. Apple knew this was right all along. There is no evidence of the old license. The old license never existed. It is dead now. Apple never endorsed it. It was a lie made by Apple's enemies to discredit Apple's name. Apple is good. Apple would never hurt you. Apple is your friend. Apple is magic. Apple has never backpedaled. Apple is at war with Google. Apple has never been at war with Microsoft. Why do you hate Apple? Apple only wants to help you. You are clearly disturbed. Apple wants to assure you this is not your fault. Please report to your nearest iThoughtCorrection facility. Apple is your friend. Trust in Apple. Apple is your friend.

    4. Re:Yea by Mongoose+Disciple · · Score: 2, Interesting

      At least they are. We all know companies that'd rather die than admit they were wrong.

      Such as? I suspect that if you name a company or companies, people can point out similar things they backpedaled on.

    5. Re:Yea by Anonymous Coward · · Score: 2, Funny

      I read this over 15 times and I really felt a warm fuzzy feeling towards Apple.
      Someone should mod parent disturbing.

    6. Re:Yea by 0xdeadbeef · · Score: 5, Insightful

      We all know companies that'd rather die than admit they were wrong.

      Yes, Apple. Does this sound like a mea culpa?

      The App Store is perhaps the most important milestone in the history of mobile software. Working together with our developers, we will continue to surprise and delight our users with innovative mobile apps.

      They didn't admit that their critics were right, the said that they "listened to their developers". As one of those developers, I assure you that what they really listened to was negative press and Android's rising numbers.

    7. Re:Yea by thetoadwarrior · · Score: 3, Insightful

      It must upset you that they were spot on about Flash.

    8. Re:Yea by abhi_beckert · · Score: 4, Insightful

      Get off your high horse.

      Just because Apple doesn't carry out the wishes of every individual developer doesn't mean they don't listen. The ENTIRE POINT of the app store is to allow developers to create and distribute great software.

      Do you seriously think apple doesn't give a shit about developers? If that was true, there would be no app store at all.

  3. Google Voice by esocid · · Score: 2, Insightful

    So...when will they be approving Google Voice?

    --
    Absolute power corrupts absolutely. indymedia
    1. Re:Google Voice by SimonTheSoundMan · · Score: 2, Interesting

      Sure, so how does Skype get through. In fact, how do most apps get around points 2.11-2.13?

      2.11 Apps that duplicate apps already in the App Store may be rejected, particularly if there are many of them
      2.12 Apps that are not very useful or do not provide any lasting entertainment value may be rejected
      2.13 Apps that are primarily marketing materials or advertisements will be rejected

      I would say the vast majority of apps in the store fall under these points.

    2. Re:Google Voice by abhi_beckert · · Score: 2, Insightful

      2.12 Apps that are not very useful or do not provide any lasting entertainment value may be rejected

      I would say the vast majority of apps in the store fall under these points.

      The keyword there is "may". There are categories where you have to choose through 10 different free applications with not a single feature do differentiate between them. That's annoying for users, and completely pointless for everyone else.

      If you can't do something better or cheaper than anyone else in the store, then you shouldn't bother in the first place. 2.12 simply enforces that.

      If they didn't enforce it, no developer would make any money at all in those categories (because the revenue would be spread too thinly, so individual apps would have low sales), and users would struggle to find the gems among the garbage.

  4. what about writing apps *on* the device by line-bundle · · Score: 2, Interesting

    Does that count as downloading?

    I am looking at this in the context of scriptability.

    1. Re:what about writing apps *on* the device by Lunix+Nutcase · · Score: 3, Informative

      That's because the rules against interpreted code are part of the SDK rules not the app approval guidelines.

  5. More importantly by BasilBrush · · Score: 4, Informative

    More importantly, developers will no longer have to second guess the reasons why apps may or may not be accepted. From the statement:

    "In addition, for the first time we are publishing the App Store Review Guidelines to help developers understand how we review submitted apps. We hope it will make us more transparent and help our developers create even more successful apps for the App Store."

    1. Re:More importantly by Sarten-X · · Score: 4, Interesting

      It's to prevent/reduce the lawyer-like arguments. The moment a set of guidelines becomes public, people start trying to find loopholes. Arguments about terminology, implementation, and technicalities ensue. Then the rules get updated to account for what's been argued already, which brings in a new set of loopholes. Soon, a whole new industry springs up around just knowing the rules, and the whole process grinds to an inefficient halt.

      It's much easier to keep guidelines internal, and only release very general suggestions.

      --
      You do not have a moral or legal right to do absolutely anything you want.
    2. Re:More importantly by Mongoose+Disciple · · Score: 2, Insightful

      However, simplicity/efficiency is often the enemy of fairness. It certainly was in this case.

      I mean, I can drastically simplify the American legal system if we toss the laws and move to a system of laws only I know. We'll get rid of all the lawyering and costly trials, and I'll just let the secret police know who they should quietly execute.

    3. Re:More importantly by Bigjeff5 · · Score: 2, Insightful

      How can you change the guidelines to justify removing any app you want if everybody knows what the guidelines are?

      Duh.

      The only reason they are doing this now is because they've gotten too much pressure not too.

      Any reasonable company would have released them from the very beginning. Most companies tell you what their criteria are for rejection specifically so you can avoid and correct any potential issues.

      --
      Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
    4. Re:More importantly by bill_mcgonigle · · Score: 2, Interesting

      The only reason they are doing this now is because they've gotten too much pressure not too.

      Naw, the iPhone is, literally, the textbook example from The Innovator's Solution.

      Apple's best profit maximization came from keeping everything proprietary for as long as they didn't have significant competition. That they're doing this is likely an indication of a sales slump vs. competition from Android. Now they'll begin the process of competing in a commoditized market.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  6. Re:browsers by line-bundle · · Score: 3, Informative

    webkit is exempt.

    Written like a true slashdotter who didn't read the article.

  7. Applause by Superken7 · · Score: 2, Interesting

    Its good to see big companies backpedal and fix their mistakes, even more if the company is Apple/Ms/Google

    Don't get me wrong, I think it made sense for *them* to ban things like Adobe CS5, but I don't think it was good for everyone involved (especially users and developers), and its great to see them do that, for whatever reason it must be.

  8. Re:browsers by wherethewoolzewasnt · · Score: 2, Informative

    The WebKit JavaScript implementation is essentially the one exception to the downloadable code rule. I imagine that you could still be rejected for implementing core functionality in downloadable JavaScript, as that would open up a potential security hole.

  9. Clarification by mr100percent · · Score: 3, Informative

    Let's clarify, since the description isn't that great. Apple will now allow Adobe's Flash to export in iPhone app format

    Also, Apple released their App Store Review Guidelines (PDF). Worth a read.

    1. Re:Clarification by BasilBrush · · Score: 3, Insightful

      I suggest actual developers access that list on Apple's site. It'll change quite often.

  10. Unity by Xest · · Score: 4, Insightful

    This was all about Unity, which basically does exactly what Adobe's Flash packaging tool did for the most part. The Unity game tools have been used to develop some fairly popular iPhone games, and Apple knew it couldn't continue to authorise Unity based apps whilst denying apps created with Adobe's tools without falling foul of competition laws. Similarly, by kicking Unity off too they'd be throwing away from of the iPhone's most popular games.

    So the question now is, does this mean if Adobe tries to release it's tools again that Apple is going to let it, or are they now going to try and find another excuse to deny Adobe access to the platform?

    Apple stood to lose far more if it continued to stand by this policy, and if it stood by the policy whilst letting some apps through it also stood to face the DoJ, so it had to decide one way or the other.

    1. Re:Unity by BasilBrush · · Score: 4, Insightful

      So the question now is, does this mean if Adobe tries to release it's tools again that Apple is going to let it, or are they now going to try and find another excuse to deny Adobe access to the platform?

      That's probably the reason they've released App Review Guidelines at the same time. Apple can probably deny most Flash apps based on other rules that already exist. e.g.
      "Apps that rapidly drain the device's battery or generate excessive heat will be rejected." and
      "Apps must comply with all terms and conditions explained in the Apple iPhone Human Interface Guidelines and the Apple iPad Human Interface Guidelines"

    2. Re:Unity by Rossman · · Score: 2, Interesting

      "does this mean if Adobe tries to release it's tools again "

      The tools are already released, they are still included with Flash CS5 (Packager for iPhone). Developers can start using them today if they want.

  11. Apple's Statement by amolapacificapaloma · · Score: 5, Interesting

    This is the actual statement by Apple.

    Also, I've read some rumors about the next iLife '11 having a new program for creating iOS apps in a similar way to the Android's AppInventor. This new statement seems a like a pointer in that direction, otherwise they would have a hard time arguing about antitrust issues on the App Store...

    --
    exp(i*pi)+1=0
    1. Re:Apple's Statement by amolapacificapaloma · · Score: 3, Interesting

      All this is highly speculative, but I'd expect it to be like Automator on OS X, and the "apps" not being submitted to the store, but used but executed inside an apple made app. Easy way for power users to scratch their own itches, and a nice mousehole in the walled garden... Pure speculation though.

      --
      exp(i*pi)+1=0
  12. What's wrong with issuing an update? by SuperKendall · · Score: 3, Informative

    there is no way for an anticheat system to update itself.

    What's to prevent the game maker from simply issuing a software update, and having software issue challenges to each other related to versions before accepting games?

    Online cheating is not as great a problem as with the PC's or consoles.

    It only takes a few seconds to update a new version on the device.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:What's wrong with issuing an update? by BasilBrush · · Score: 2, Informative

      These days it typically takes a couple of days for approval. Sometimes it can be as short as a few hours.

  13. Antivirus or any update. by leuk_he · · Score: 2, Informative

    Most of the time these worries are about anti virus instead. There the updates also contain exe updates.

    But the same update mechanism used for an normal application can apply to a any application. Let it bet antivirus, anti-cheat or a simple game. If you want to update it you do it via a the app-store, and don't come up with a own update system. If that is not good enough, that should be updated, not implement it on yourself.

    The fact that windows does not have a central update system and every app has to do their own update mechanism is a bad thing of windows. And it is a sad fact that user have come accustomed to that.

  14. Flash, java, interpreted languages by codepunk · · Score: 2, Interesting

    What I would like to see apple do is to add performance to it's application review process. Say for instance you app does not boot to a stable runnable state in 10 seconds it gets disapproved. Same goes for memory usage and and processor load. That would solve the whole "user experience" goal that they claim to have. Of course it would keep most of the interpreted apps, flash, java etc off of the phone but I have no problem with that. On one hand I would like to have to option to use interpreted languages on the device on the other hand I know that for performance reasons it is not the way to go.

    --


    Got Code?
  15. Re:Flash on android by rjstanford · · Score: 4, Insightful

    But most people wouldn't have blamed Flash - especially if there wasn't an easy example of a non-flash version to point to. They'd have blamed the iPhone. Most people, even most iPhone users, don't read /. or related sites - that's one of the reasons that the iPhone has been a smashing commercial success, you don't need to be a geek to use it (N70, I'm looking at you here). Keeping Flash off the platform was exactly the right business decision to make.

    Even if Adobe would release a version that wasn't a battery killing unstable one - which would be a great start - the usability experience isn't close to being there for multitouch devices. And the iPhone is all about user experience.

    --
    You're special forces then? That's great! I just love your olympics!
  16. Kind of, but more about control of app quality by SuperKendall · · Score: 2, Insightful

    This was all about Unity, which basically does exactly what Adobe's Flash packaging tool did for the most part.

    Actually I thought Unity was more intermediate, producing an XCode project you would compile - the flash tool produced a binary directly.

    Apple knew it couldn't continue to authorise Unity based apps whilst denying apps created with Adobe's tools without falling foul of competition laws

    Actually it could do that forever because there are no such laws. Anti-Trust doesn't enter into the picture in any way.

    The real reason the relaxed the restrictions is, I think twofold:

    1) Developer outcry - Apple does respect and listen to developers, and they were having too many people come up with too many perfectly valid edge cases (like using Mono or Scheme for development). Apple had actually pulled back on this restriction a few months earlier letting people submit things developed using alternative languages on a case by case basis, that was probably a lot of work to review.

    2) Control of app quality. This I think is key - what Apple is really worried about with Flash developed apps coming out is that a ton a crappy stuff would flood the store and the review process. So what has changed? The fact that they have a stated review policy now, which says in part "we will not allow a ton of crappy small applications that do nothing". The whole limitation made no sense before because Apple benefits from having quality applications on the platform, so now its more clear that wider spectrum of development tools will not be allowed to destroy the level of quality the application pool enjoys, so someone CAN use Flash to compile an iPhone binary but they had better be producing something good. A formal app store review policy allows Apple to be more relaxed in other regards, because it keeps control over the final quality of applications.

    Whats really odd is that it took this long to come up with any kind of review policy document!

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Kind of, but more about control of app quality by delinear · · Score: 2, Insightful

      Whats really odd is that it took this long to come up with any kind of review policy document!

      Well I guess the reason for that is primarily twofold. Firstly, it benefit Apple to grow the App store massively in a short space of time - if they'd rejected all those fart apps and similar early on, there'd likely be nowhere near the 250,000+ apps there are in there now. Secondly, I guess there's also the question of what the guidelines actually are. As has been said elsewhere, they've probably been largely making these up as they went along. Oh sure they would have had some foundation stones to build on, but really there was nothing exactly like the App store with anything like that kind of success before the iDevices came along. Who could have predicted in the early days exactly how people would use this service, and more importantly how people would develop for it? If they'd released this list on day 1 you could have undoubtedly expected several hundred revisions to it in the interim, that would have angered developers even more ("moving the goalposts"). Now they've had time to test the guidelines and ensure that they produce a desirable mix in terms of quality and quantity (although I'd still expect more finessing, but nothing on the same level).

    2. Re:Kind of, but more about control of app quality by SuperKendall · · Score: 2, Insightful

      Well I guess the reason for that is primarily twofold. Firstly, it benefit Apple to grow the App store massively in a short space of time - if they'd rejected all those fart apps and similar early on, there'd likely be nowhere near the 250,000+ apps there are in there now.

      Right, but that aspect did not have to be in an initial version of the document.

      Secondly, I guess there's also the question of what the guidelines actually are. As has been said elsewhere, they've probably been largely making these up as they went along.

      As an application developer, I don't think that's really true. All of use knew what the rules were, the basic outline of them. They were just never officially listed. Having a list before wouldn't have stopped them from modifying it often...

      But you are probably right that Apple thought the situation was too fluid to bother maintaining a document until now, where they have a really crafted set of rules.

      --
      "There is more worth loving than we have strength to love." - Brian Jay Stanley
  17. Re:MonoTouch? by rjstanford · · Score: 2, Insightful

    Does this mean that I can use C# to generate a Silverlight app that will run on Windows, Windows Mobile, Linux, Android and iPhone?

    Can I write in Java an app that will run on every desktop and mobile?

    Well, considering that a good app experience on a desktop (with a mouse and keyboard) is by definition very different than a good app experience on a multi-touch device, probably not, no. You might be able to share some code internals, but you could do that anyway.

    --
    You're special forces then? That's great! I just love your olympics!
  18. Meaningless by Andy+Smith · · Score: 3, Insightful

    Apple seem terribly random and unpredictable. It would be senseless for any developer to begin work on a project that has become permitted by this clause, because tomorrow the terms could change again.

    I'm an Android developer, releasing my first game in the next 4-6 weeks. Then I need to consider whether or not to produce an iPhone version. The decision will only slightly be based on forecasted sales, market share of competing products, and demand for my product. For the most part I will need to decide if I can afford to invest the time developing for a platform that may, at any point, "ban" my product for some obscure reason. (For example, all of my graphics are produced in 3D Studio and rendered as 2D sprites. Suppose Apple takes a dislike to Autodesk...?)

    1. Re:Meaningless by BasilBrush · · Score: 4, Insightful

      (For example, all of my graphics are produced in 3D Studio and rendered as 2D sprites. Suppose Apple takes a dislike to Autodesk...?)

      It's always wise to do a risk analysis before embarking on a new project. Don't forget to factor in the possibility that you'll spend so much time posting ridiculous scenarios to slashdot that you never get round to doing the work.

  19. Because they don't replace contacts by SuperKendall · · Score: 3, Informative

    Sure, so how does Skype get through.

    Because it doesn't duplicte existing functionality. There is no built in VOIP client, and it uses the Apple contacts. GV linked back to Google contacts...

    In fact, how do most apps get around points 2.11-2.13?

    2.11 Apps that duplicate apps already in the App Store may be rejected, particularly if there are many of them

    At this point that might be a problem for some applications but there's always a new idea without many apps in the store.

    2.12 Apps that are not very useful or do not provide any lasting entertainment value may be rejected

    I think you might just be able to work around that by writing an app that is useful or entertaining.

    2.13 Apps that are primarily marketing materials or advertisements will be rejected

    To me that simply repeats point 2.12 since an application that is primarily marketing is also not useful (though I suppose it could be entertaining, and thus possibly accepted).

    I would say the vast majority of apps in the store fall under these points.

    Like what? Very few of the applications I have seen fall under these points, except possibly for point 2.11 - but that's the thing, the avoidance of replication is more a point going forward than it has been (though Apple has been starting to reject some applications in crowded categories).

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  20. Re:What other company even backpedals... by Bigjeff5 · · Score: 3, Insightful

    Are you serious?

    Wow man, you are a true fanboy.

    There are mistakes, and then there is an attitude that the whole world should bow to their wishes. It's only when they realize they don't have quite that much clout that Apple backs down.

    A good company that did not believe customers owed their happiness to the company, developers owed their very existence to the company, would not have locked down the tools in the first place.

    Apple treats its customers as though it's only because of Apple's great kindness that those customers get to use Apple products. They treat their developers like a necessary evil, and it's only by Apple's grace and mercy that developers are permitted to write code for Apple products.

    That's how you get things like the ridiculous hoops needed to write apps for the App store, or the ridiculous policy of no flash when flash is ubiquitous on the internet. That's a "you get what we give you" attitude if there ever was one. The only reason Apple is backpedaling now is because they pushed it too far and received some backlash. That's it. And they are only going to change the policy far enough to reduce the backlash to an acceptable level - they are not going to change their attitude, and if they see an opportunity to lock things down again they will jump on it.

    --
    Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
  21. Re:Flash on android by Bigjeff5 · · Score: 2, Informative

    Flash is a failure on Android? Since when?

    It works great on my phone.

    --
    Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
  22. Re:What other company even backpedals... by Mongoose+Disciple · · Score: 2, Funny

    What's refreshing to see is a company that actually admits it was wrong, how often does that happen?

    If you think Apple does so more than other companies in its industry, you are drowning in the Kool-Aid.

    Obligatory Penny Arcade. Except probably swap from to to.

  23. Re:Qt for the iPad? by gbjbaanb · · Score: 2, Informative

    since Nokia started the Lighthouse project, nicely hosted on code.google.com :)

    See: http://tamss60.tamoggemon.com/2010/03/18/qt-on-android-the-bogdan-vatra-interview/

    and instructions for how to do it.

  24. My favorite new guideline: Don't snitch by mliu · · Score: 4, Informative

    I think this line from the guidelines is pretty funny:
    "If your app is rejected, we have a Review Board that you can appeal to. If you run to the press and trash us, it never helps."

    So basically, don't snitch.

    To the contrary, however, in the past, it seems like running to the press and trashing them can really help get your app approved.

    See, e.g. http://apple.slashdot.org/story/10/04/16/2327219/Bad-PR-Forces-Apple-To-Reconsider-Banning-Mark-Fiores-App

  25. Opening it up will just prove Apples point by grapeape · · Score: 3, Interesting

    After the disaster that has been flash on Andoid so far, perhaps this is just Apples way of saying "see we told you". I expect a plethora of sub-par apps flooding the app store soon, in the end this will probably help HTML5's cause much more than Adobe.

  26. Re:What other company even backpedals... by Dhalka226 · · Score: 3, Insightful

    What's refreshing to see is a company that actually admits it was wrong, how often does that happen?

    I'm trying in vain to find where they admitted they were wrong. All I see is "we listened to our developers," which is nothing more than a nice way of saying "we think this is beginning to hurt our bottom line" and is something MOST companies do if they get to that point.

    Didn't Steve Jobs make a big hullabaloo about how "intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform"[1] when asked about the rule? So is that magically no longer true, or do they just no longer care? Or is it, perhaps, that their transparently self-serving reasoning for instituting the rule in the first place has started to cost them more than it gains?

    The about-face is good, don't get me wrong. But trying to frame it as some sort of benevolence instead of ANOTHER self-serving action to mitigate problems caused by the first is misguided at best.

    Apple wanted to control everything, and thought they had the clout to get it done. Apparently enough developers made them nervous about it that they changed their mind. Good, but hardly some sign of a great corporate system.

    [1] http://www.taoeffect.com/blog/2010/04/steve-jobs-response-on-section-3-3-1/

  27. Re:What other company even backpedals... by s73v3r · · Score: 2, Insightful

    Would you rather they not, "Listen to their developers"? Every free-market libertarian on this site says that the way companies learn what to do is to, get this, piss off customers so that it affects their bottom line.

    Seriously, everybody (myself included) bitched about the restriction clause. Now its lifted. And you fucks still want to bitch?

  28. All platforms have negative aspects by SuperKendall · · Score: 2, Interesting

    Wouldn't it be better to prefer to work with another platform that does not have to receive negative feedback in the first place?

    Sure it would. And I'd love to ride a Unicorn through the sky!

    Too bad I can't do either. All platforms have some negative feedback from the user community. The question is, do the curators of the platform you are developing to listen to you?

    I'm not even saying Google does not, I think they do as well. But Apple is very good about taking in suggestions for enhancements and eventually coming out with really good API's around them, or as in this case responding to something Developers saw as pointless and removing it (and in reality they had backed down on it months ago with a slight revision to the alternate platform clause).

    It's not like Google is perfect either after all, like only allowing Skype to be used with Verizon, or allowing really crapping phone company specific UI to be added to Android.

    Has there been any fundamental policy shift before today?

    Yes, for example they had a no screen-scriping rule in place for camera use (because that was the only way to read the camera data realtime was a private API call) and they specifically allowed use of that private call so that basically every barcode scanner and AR app could function.

    They've also backed of policy choices like not allowing free apps to change to paid apps (or something along those lines, I forget the exact details since I wasn't affected). Or they have also changed policy around in-app purchases to change some restrictions.

    Basically there are a lot of examples of where Apple came out with some initial policy that had issues, and they fixed it is response to developer feedback.

    If not, what were you saying prior to today on why you prefer to work with iOS development?

    I'm saying it because I have found it to be a consistent pattern over the past few years. I was a Java developer for many years, I could do Android development just as easily - but I like more what Apple is doing around the iOS platform, and currently I see a ton more potential (and it's much easier to make a living at it).

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  29. Re:Flash on android by mr100percent · · Score: 2, Insightful

    The problem is that Apple can't trust a third party development environment to take over too much of the app share. In the past stuff like that has wrecked OSes as a vital update breaks the third party APIs that are used in bestseller apps. Apple wants to be able to release iOS 5 and 6 without worrying if they break Flash's internal APIs

  30. Re:What the...I don't...I..I'm flabbergasted by sglewis100 · · Score: 3, Informative

    Also, you say, "That's why I prefer to work with iOS development, because they do listen to developers and take into account feedback or concerns, and really change fundamental policy instead of continuing said policy just because it exists as so many other companies would do..." Has there been any fundamental policy shift before today? If not, what were you saying prior to today on why you prefer to work with iOS development?

    They listened to developer demand and introduced an SDK and stopped allowing only HTML5 web apps. They allowed turn by turn navigation products. And neither of those were really influenced by the rising success of Android, at the time. I could probably think of a few more, but you asked for "ANY", of which two satisfies.

  31. Re:browsers by shutdown+-p+now · · Score: 2, Interesting

    Makes me wonder... WebKit is embeddable in iOS apps, right? Is it possible to embed it in such a way that it is not visible - e.g. just hide it, or overlay it with something - and use it solely as a JS scripting engine?

  32. Re:Are you sure? I see iPhone contacts in screen s by Just+Some+Guy · · Score: 2, Insightful

    It uses them alongside their own contact list. A given contact can be in either or both lists. If that were the distinguishing characteristic, it seems like that would be easy enough to handle in a Google Voice app.

    --
    Dewey, what part of this looks like authorities should be involved?
  33. Re:Not seeing the attitude you see by WNight · · Score: 2, Insightful

    As I said they listen to feedback, and have done things like making all WWDC (Apple developer conference) videos free for every registered iPhone developer.

    Wow, free access to developer resources. Well, to registered and paid-up developers. Amazing.

    There really are no "hoops" at all in application development, and honestly how can you claim there are with 250k approved apps?

    Yeah, except for anyone who wanted to code one in LISP or Ruby. Or oh, I don't know, whatever keeps a huge number of apps from being approved or rejected.

    It's a great platform to develop for as long as you don't step on a land-mine and for some reason be unable to sell your hard work. If you like running a business with a huge uncertainty like "Will I even be able to show this to customers, let alone sell it" hanging in the air, it's for you.

    The only reason Apple is backpedaling now is because they pushed it too far and received some backlash.

    Isn't that the reason most people back down from a bad position? People tell them they are wrong, and eventually they see the light...

    Do they see the light, or just stop doing the thing that got pressure while someone's watching? One's right, the other is the behavior of a sociopath.

    They still don't promise to reject an app quickly with a good reason. They'll still let unpleasant (for them) apps linger forever while their developers' businesses die.

    but often not, especially with companies. That's my point, that to me it seems rare that customer complaints change anything about how a company works.

    What's really changed? Apple is changing what they're doing here only because with the rise of android they've got less control over app developers. Next time they've got this much lock-in they'll do the same sort of thing - use it to stifle competition right up until they'd lose market share by doing so.

    Beyond enabling them by developing for their devices you're also showing you'll work with the Microsoft of the moment. Damn the industry, and open competition, I'm making money attaching myself to their locked-in users!

  34. Re:Not seeing the attitude you see by WNight · · Score: 2, Interesting

    Not in the slightest. What's an argument to you kid? Shaking your user IDs at each other while shouting "Nuh uh"? Points are raised, answered, dissected. Claims are made, and tested. He can be the illustrious whatever he wants but if he dodges the issue he's proven nothing.

    I'm not challenging him on the iOS build environment, or his UI design skills. I'm discussing issues other developers have that he, by his very admission, has never seen and has heard very little about.

    I'm bringing up questions from the news: "this uncertainty, what if it happened to you?"

    He on the other hand is saying quite plainly that that never happened and besides, stopped sometime last year, but that reports are largely fabricated.

    I see risk. A company I worked for recently was building a PBX and one of the risks they had to disclose to investors, and they weren't even publicly traded yet, was that the whole system simply wouldn't get through regulatory testing despite otherwise working. And this is government regulatory testing at an independent lab, not Apple's totally opaque approval process.

    I see that risk here. If you wrote an app, and as a programmer about half of what I write is small dev tweaks - I assume others are similar, that DID step on Apple's toes, what then? I don't see any clear guidelines on exactly what is not allowed. What I do see is Apple sitting on things for months, refusing to say anything, threatening and punishing those who speak out (though being swayed back again by intense PR), but never actually giving a firm reason that you can work with because they don't want to appear to everyone else to be hostile to development.

    Instead of talking about the risk and how to avoid it he sidestepped the issue and talked about all the apps that do get approved - as if the trivial approval process for yet another pedometer, or calculator, is in any way related to what goes on when Apple plays rough. It's as if I asked a question about how many people get mugged and the city PR person says "Over a million people safely enjoy our city every day." A total non-answer.

    And as for the dev sessions, I simply disagree. They charge to see the presentation in person because seats are limited because of your chance to see people but the video of the presentations are never comparatively useful. Once you get past the extra time spent on introductions and chatter you've still got to slog along at their pace. Far more useful at that point, in a strict sense, is if they've summarized the talk and given the demo code. The video is more about seeing other developers, "meeting" the personalities, and community building. Not useless, but not something the developer should be paying for - it's Apple's community - dev's already bought in with their phones. And especially since it could reach a wider audience if it were open.

    But then there's the thing... Charge for something, keep some people out, and you've made it more precious to some others. They could make the dev tools free, to support kids who want to get into it, as I myself started coding on an Apple 2+ long before I could have afforded dev tools. But they don't. It costs them more to host the video with access controls rather than simply make it available, but they feel that barrier is necessary. Why?