Apple Relaxes iOS Development Tool Restrictions 347
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.'"
More importantly (Score:5, 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."
Re:browsers (Score:4, Informative)
webkit is exempt.
Written like a true slashdotter who didn't read the article.
Re:browsers (Score:2, Informative)
Re:Google Voice (Score:1, Informative)
Clarification (Score:4, 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) [bit.ly]. Worth a read.
What's wrong with issuing an update? (Score:4, 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.
Antivirus or any update. (Score:3, 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.
Re:Problem (Score:1, Informative)
Yes, but what you describe is intrinsically insecure and while a PC game can submit that score through code modification means, the consoles can only currently do it by intercepting and editing network packets sent from the device. It seems like what the OP wants is magical DRM hardware, not an anti-cheat system. VAC and PB get *constantly* bypassed, and they would do absolutely nothing to revert illegitimate scores. VAC/PB/Warden like anti-virus are reactionary, they exist to provide a stable and fun gaming experience, not a 100% secure one.
Re:What's wrong with issuing an update? (Score:2, Informative)
Not when each of those versions has to go through another round of approval.
Re:what about writing apps *on* the device (Score:4, Informative)
That's because the rules against interpreted code are part of the SDK rules not the app approval guidelines.
Because they don't replace contacts (Score:4, 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).
Re:Flash on android (Score:3, Informative)
Flash is a failure on Android? Since when?
It works great on my phone.
Re:Qt for the iPad? (Score:3, Informative)
since Nokia started the Lighthouse project [google.com], nicely hosted on code.google.com :)
See: http://tamss60.tamoggemon.com/2010/03/18/qt-on-android-the-bogdan-vatra-interview/ [tamoggemon.com]
and instructions for how to do it [google.com].
My favorite new guideline: Don't snitch (Score:5, 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 [slashdot.org]
Re:What's wrong with issuing an update? (Score:3, Informative)
These days it typically takes a couple of days for approval. Sometimes it can be as short as a few hours.
Re:What the...I don't...I..I'm flabbergasted (Score:4, 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.
Re:Problem (Score:3, 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 [wikipedia.org]