

Apple Relaxes iOS Restrictions On Development Tools, Publishes Review Guidelines - jakewalker
http://www.apple.com/pr/library/2010/09/09statement.html
More details:<p>http://developer.apple.com/appstore/guidelines.html
======
jacquesm
So, how about all those people that were supporting apples' right to run their
app store the way they see fit and who said that there is no point complaining
about it?

I think this proves that complaining about stuff like this is well worth the
effort, assuming that that - and not some backroom pressure - is what caused
them to back off. They mention it in their release so I figure it must have
been a major factor.

edit:

the plaintext version of the appstore guidelines:

<http://ww.com/appstore.html>

I've been reading through the guidelines while fixing the markup and it seems
to me that it's very reasonable the way it is worded and those terms that are
left.

I'd feel pretty good developing under these terms.

~~~
lurch_mojoff
The thing is most of the complaining about this was not the constructive "hey,
Apple have you considered so-and-so", but rather the whiny "waaaa... Apple are
Nazis" kind.

And as you point out there is no evidence that it is the complaining that made
Apple reconsider. It could very well be something entirely different, e.g. the
FTC probe.

~~~
jacquesm
Plenty of it was _very_ constructive, it pointed out why the choice of tools
should be left to the developer and how not relaxing this restriction would
make it easier for people to develop for android than for the Iphone.

If the FTC probe (or the rise of android) has anything to do with it then I
doubt we'll ever know, but I'm all for taking this on face value and believing
them when they publicly admit to listening to their devs. It's a nice thing to
be able to hold them to at a future date.

~~~
lurch_mojoff
Well, it looked plenty for very small values of plenty, from where I stand.
There were some _very_ well reasoned arguments against the restriction -
arguments like the fact that many libraries and game engines require the
flexibility that scripting allows; or like the fact that there are languages
and environments that are more conducive of tackling certain types of
problems. Those, however were drowned in a sea of petty complaints like "I
know language XYZ and now Apple are making me learn their sucky ObjC" or
"Apple just want to prevent you from porting your app to a competing platform,
them Nazis", or dramatic pronouncements that Apple have turned their back on
the hacker crowd and thus are stifling innovation.

And I'm not saying we shouldn't believe Apple when they say they've listened
to the developer community. I am saying that such decisions usually factor in
a broader spectrum of reasons. At the very least, there are may examples of
Apple not budging on issues, regardless of the huge ruckus.

I'm also not saying we shouldn't complain. I am saying we should cut on the
drama, try to understand Apple's rationale for their decisions, and figure out
a way to meet them midway. Or as Apple say in the intro to the App Store
Review Guidelines - "If it sounds like we're control freaks, well, maybe it's
because we're so committed to our users and making sure they have a quality
experience with our products. Just like almost all of you are too."

~~~
jacquesm
> "I know language XYZ and now Apple are making me learn their sucky ObjC"

That's a very valid complaint imo, except for the 'sucky', was that present in
the original?

> "Apple just want to prevent you from porting your app to a competing
> platform, them Nazis"

Are you sure about the 'them Nazis' bit in this one ? Otherwise, again, that's
a valid complaint.

> I'm also not saying we shouldn't complain. I am saying we should cut on the
> drama,

Indeed.

~~~
chc
"Sucky" isn't very descriptive, but I wouldn't blame somebody used to a more
advanced or coherent language for feeling frustrated with Objective-C. It is a
backwards language in many ways, and I say that as somebody who's been writing
it for the better part of a decade.

It doesn't even have _namespaces_ — something that has been standard in every
language since the '90s. Instead, you must stick a two- or three-character
prefix on all your class and function names (some people even recommend
prefixing _method names_ ) and hope that nobody else happened to pick the same
two or three characters for theirs.

For another example, it has a strongly dynamic OO model, but a singularly
unhelpful static type system that is shackled with C compatibility, leaving
the language in this awkward limbo between static and dynamic, where you're
offered all these tantalizing paths that turn out to be blocked by walls.

Yet another: It has monkey-patching like Ruby, but it lacks the language or
library support to do it anywhere near as cleanly (which is saying something
if you know how messy Ruby monkey patches can be), to the point where some
parts are almost necessary and others are almost unusable and it's not obvious
at first where the pitfalls lie.

(On the other hand, a lot of people hate Objective-C for pretty bad reasons
too. There seems to be a legion of PHP converts who really want to write PHP
in Objective-C.)

~~~
tjr
I've been doing a lot of Objective-C coding the past few months, and have
found it surprisingly pleasant, once I got used to the syntax. Maybe I had low
usability expectations for a language based on C. :-)

~~~
chc
It's not unusable, and overall I actually prefer it to, say, C or Java. But
compared to modern languages it has some glaring weaknesses.

Also, you have to be careful to distinguish between the framework and the
language. Cocoa is an excellent framework that does a great job playing to
Objective-C's strengths. It's the language that I'm criticizing here.

------
dgallagher
Engadget.com posted an excellent summary regarding Apple's new App Store
review guidelines:

 _"We have lots of kids downloading lots of apps, and parental controls don't
work unless the parents set them up (many don't). So know that we're keeping
an eye out for the kids."

"We have over 250,000 apps in the App Store. We don't need any more Fart
apps."

"We have lots of serious developers who don't want their quality Apps to be
surrounded by amateur hour."

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

"This is a living document, and new apps presenting new questions may result
in new rules at any time. Perhaps your app will trigger this."

"If it sounds like we're control freaks, well, maybe it's because we're so
committed to our users and making sure they have a quality experience with our
products."_

More here: [http://www.engadget.com/2010/09/09/apples-app-store-
review-g...](http://www.engadget.com/2010/09/09/apples-app-store-review-
guidelines-we-dont-need-any-more-far/)

------
woodrow
No one has mentioned what seems to be one of other most seemingly positive
developments of this -- the App Review Board [1]:

"We’ve created the App Review Board to provide you the opportunity to appeal
the rejection of an application if you believe that the functionality or
technical implementation was misunderstood. You will be able to submit details
that the App Review Board will use to determine if the rejection of your app
should be reconsidered."

Of course it's unclear if this will actually work, but at least there's a
seeming opportunity to make an argument compared to the previous "just
resubmit it to the App Store" approach. Hopefully these
decisions/adjudications won't be under NDA so we can see if this process
actually works.

[1] <http://developer.apple.com/appstore/guidelines.html>

~~~
elai
Sending emails also work rarely. You don't even have to resubmit!

~~~
jlongster
Yes, I've asked Apple to fast-track the review of my app several times (for
good, although selfish, reasons), and 50% of the time they've obliged! They
are actually quite friendly.

------
kylechafin
Now that MonoTouch appears to be in the clear on iOS...

It sounds like C# is going to be a viable language for 3 major mobile
platforms this Fall. Windows Phone 7 supports C# by default. MonoTouch brings
it to iOS and MonoDroid takes it to Android.

It sounds like there will be some really neat opportunities to reuse C#
libraries across all three platforms, while dropping a native platform UI on
top of them.

~~~
sourc3
Having programmed in C, C++, C#, Java and JS (if scripting counts) I applaud
this. I have tried to get used to Objective-C but after using C# for the past
4 years or so, it just seems uncomfortable with me (probably a personal bias
that cannot be generalized). I was considering developing my startup's first
mobile app in Android since I did not want to touch Objective-C and go with an
iPhone Web Page.

Considering the number of developers on the .NET/C# bandwagon I think we will
be seeing another Gold Rush to the app-store. I really hope the app-review
board can filter out the ugly, form and buttons type of applications that will
come as part of this rush. Otherwise, AppStore will be the next Tucows.

~~~
swilliams
Keep in mind that using C# to program iOS apps is still very different than
traditional .NET apps. The language is familiar, but the framework is
definitely not.

~~~
MartinCron
I was a little disappointed to see that using Monotouch doesn't work my Visual
Studio + ReSharper + nUnit development trifecta. C# as a language is nice, but
the tools are where it's at.

------
jakewalker
Will be interesting to see if Adobe's program to port flash-to-iOS 5, which
was to be included in CS5, is a go again.

~~~
TrentBrown
Exactly. This is potentially hugely important news.

------
mcobrien
If you're a registered developer, you can read the just-published App Store
Guidelines here:

[http://developer.apple.com/appstore/resources/approval/guide...](http://developer.apple.com/appstore/resources/approval/guidelines.html)

For those who aren't registered developers, it's basically a list of 189
rules, most in the form of "Apps that ... will be rejected"

~~~
johnthedebs
Any chance someone can make that available to non-developers?

~~~
Tichy
Probably not, NDA and all that.

------
greendestiny
I just had a quick read of the new sections of the agreement. As far as I can
see all restrictions on the languages and tools have been removed. No scripts
or executable code can be downloaded by the app (ie it all has to be packaged)
with the exception of javascript in a web component. Really I guess the press
release says all that, but there is no equivocation in the terms of the actual
agreement which is nice. Great move Apple!

------
wallflower
I applaud this. Yes, it might have been in reaction to the potential US
Government anti-trust type probe. Yes, it effectively lowers the billable rate
and billable hours of many iPhone developers. Yes, it makes it possible for
almost anyone (using Titanium and tools-yet-to-come [wake up, Adobe!]) to make
mobile apps.

However, I think its good because it allows developers to further
differentiate themselves from the pack. What apps get featured? People bemoan
the fact there is so many apps competing. But I believe that if you write a
compelling app that stands out from the hum-drum tab-bar apps and, yes, glut
of physics-based games, your reviewer at Apple will notice. They probably even
get some kind of bonus for identifying the diamonds in the coal.

Thank you and muchos gracias, Apple. I believe that apps that push the limit
of what an iPhone current generation can do - and do it beautifully - that is
what will win in the marketplace. Uzu, that addictive slice a shape in half
game, the render a photo like an oil painting. All require secret sauce - in
development time, graphics, rendering.

Titanium mobile won't for a very long time be able to make a Uzu-type game. Or
even a well-designed app. I hope...

Prepare to be flooded with ports of Flash games (I assume this makes Adobe's
compile to Flash in CS5 feature a go, now)

------
thibaut_barrere
Now I seriously hope it means we'll be able to use MacRuby on iPhone/iPad in
the next few weeks/months.

~~~
annon
Exactly what I was thinking. I'd love to do some small things on iPhone, but I
don't really want to commit the time to become pro at Objective-C. It's not a
bad language, just not my thing.

~~~
mike_h
If you've used C or Java before, you can become "pro enough" in ObjC in a
matter of hours, maybe even 1 hour. The real work of designing an iOS app is
getting the interface right, and any complex logic you might have. Nothing
esoteric about day-to-day expressing yourself in ObjC -- plus Cocoa provides
so many nice features that the verbosity you may gain coming from Ruby is
offset by the amount of coding Apple took care of for you.

~~~
zekel
Yeah, it's really Cocoa you have to learn, not ObjC.

------
ohhmaagawd
my guess is the FTC investigation into Apple's practices got them nervous.
better to just cave than deal with anti-trust issues:
[http://voices.allthingsd.com/20100611/ftc-to-investigate-
app...](http://voices.allthingsd.com/20100611/ftc-to-investigate-apples-
conduct-in-mobile-app-market/)

~~~
tptacek
My guess is that only Apple knows why it changed the rules, but that anyone
who can do a Google search can (a) read up on what antitrust means and (b)
observe Apple's non-commanding share of the mobile market.

~~~
mattmanser
True, but we're starting to live in a slightly weird world where once you buy
a particular product which is a gateway to other products and services, the
manufacturer is dictating in a very megalomaniac way on how you spend your
money. And commanding huge sums from utterly controlling that marketplace.
Like the XBox and iPhone.

They may have a non-commanding share of mobiles, but they have a total
monopoly on iPhone apps.

~~~
tptacek
Under that theory of law, every platform company in the world is subject to
antitrust suits as the "monopoly provider of access to that platform". Twitter
could be sued. 37signals could be sued.

Fortunately, this simply isn't how antitrust law works.

~~~
notahacker
Microsoft's monopoly was only on Windows, which just happened to be the only
viable option for most PC OEMs and browser developers.

If owning 99.4% of the mobile app sales market (Gartner figure for 2009) and
imposing restrictions which hinder the development of cross-platform apps
doesn't deserve antitrust scrutiny, I'm really not sure what does.

~~~
tptacek
No, it was the _only_ option for most PC OEMs, because Microsoft adopted
anticompetitive licensing practices that explicitly punished OEMs financially
for distributing anything but Windows with prominently-placed IE.

Apple cannot control 99.4% of the mobile app market, regardless of what their
current revenue share is, because they still control less than 30% of the
market for app platforms. If Apple attempted to abuse their position in the
market to the detriment of customers, customers would switch to other phones,
which is easy because there are multiple vendors with approximately the same
or greater market penetration.

There is just no way to get around the fact that Apple does not control the
mobile app market (yet). Coming up with the market model that maximizes
revenue and one random Gartner stat does not make them a monopoly. Read the
document I posted earlier; it's written for laypeople.

Think of it this way: imagine Apple invented 3D animated wallpaper technology,
and allowed people to create and sell wallpapers in a special wallpaper store.
A year later, Samsung releases a phone that also has a 3D animated wallpaper
store. By your logic, Apple would have nearly 100% share of the 3D animated
wallpaper market, and would be subject to antitrust regulation.

~~~
notahacker
OEMs wanting to offer a non-IE default browser had the unattractive options of
switching Linux or incurring the financial penalties; iPhone developers barred
from using "cross platform" tools had the unattractive option of switching to
platforms that have shown relatively little potential to generate revenue or
higher development costs.

Because of their store cornering the market for paid apps, Apple is in the
enviable position of being potentially able to reduce development on their
competitors' platforms, thereby making customers less likely to switch as well
as worse off overall. Irrespective of the letter of US antitrust law, that is
something I feel _ought_ to be kept under scrutiny.

------
hopeless
Just in time for me to start coding my first iPhone app!

I'd wanted to use Appcelerator's Titanium to avoid learning Objective-C and to
keep my options open with respect to Android phones. I've sat on the
development on this idea for a few months now wondering if Apple would finally
reveal their hand. I'm glad they did but I'm honestly surprised that they've
done "the right thing" and moved away from monopolistic tactics.

Wahoo! Coding starts on Monday :)

~~~
jacquesm
Just too late for me, bought an android on Monday!. Too bad, I figured I'd
waited long enough and had decided they were not going to budge.

~~~
stoney
Would you change your mind now? I decided on Monday to buy an Android phone
(HTC Desire), but haven't got around to going to the store yet.

~~~
jacquesm
Funny, I bought an HTC desire as well.

Would I change my mind?

That's a tough one. I have a Mac (borrowed it to a friend because of lack of
use), so I could develop for an iPhone as well. I like the android ecosystem a
bit better because it has more variety, it reminds me more of the PC platform
in terms of hardware than the iphone gear.

The increased variety means that you'll have to write more flexible software,
but that's only a good thing.

Most - if not all - of my objections to the iphone platform have fallen by the
wayside with this terms of service change, and the fact that _if_ you develop
something useful you can immediately market it to a large number of people is
a neat thing, however I think that the number of apps in the app store make it
hard for new applications to still gain sufficient traction. Your app would
have to be pretty original to make a go of it today I think.

Then there is the fact that I don't like that they did this stuff in the first
place. I'm apparently not the most forgiving person and it appears to me that
if you pull this sort of stunt you need to do a bit more than just change your
terms and say you'll listen better in the future.

It would certainly be a much harder decision to make, I won't be making the
choice again but I think it is a toss-up at this point. Probably I'd still go
for the android, but I'm really not 100% sure.

~~~
stoney
Android vs iPhone definitely reminds me of PC vs Mac. It will be interesting
to see if things play out the same way in the long term.

I'm planning to do some app development stuff and my thoughts were that maybe
in the long term Android will be the bigger market simply because of the
variety in Android phones from cutting edge to mid-priced (and eventually I
expect to see some cheap low-end Anroid phones).

------
magicseth
An important Caveat is Section 1 and 10.1: The Human Interface Guidelines.
This is large document that describes in general the "look and feel" of apps
that run on the iPhone. If you make something that doesn't fit with their
long-term vision, or irks them in some other way, it is extremely easy for
them to say "You are violating the Human Interface Guidelines," and leave it
at that. This has prevented me from delivering innovative UI experiences on
iOS, stifling creativity, and again, frustrating developers with wasted
research and development time.

~~~
gte910h
However it also lets them smash the Flash developers who don't actually port
their apps to the platform, which is one of the issues they cited this spring.

------
doki_pen
What I find really funny is that a certain breed of fanboy applauded the
restrictions in the first place, saying that they were needed. Yet I don't see
anyone complaining now that the restriction is removed!

~~~
nanairo
_raises small hand sheepishly_ :)

I didn't like the old system at all: I'm very happy that Apple has finally
deemed a good idea to release the review policies.

However I would have much rather seen Apple giving users another way to
install their apps, and turned the store into a nice, curated, deal.

In particular I am a bit worried about floods of badly designed apps, maybe
because they used some cross-platform framework.

Sure, I can ignore those, but the point is that it will still increase the
noise/signal ratio. Mmm... maybe Apple should have a tiered system in the App
store. Hence why I thought that if they allowed anyone to install any app they
want some other way (even though with big signs saying "DANGER DANGER") then
they could keep curating the app store without risking anyone's anger.

But, oh well... _shrugs_

edit: actually as jdz2 said above, as long as they keep curating the new apps,
I don't really care if they were built from CS5 or brainfuck... but the first
point is important.

------
bigfudge
I think this is a big mistake from apple's perspective. Despite the noise, and
the possible exception of a few games dev tools for which they could have made
exceptions, there has been no serious evidence of people avoiding ios because
of the toolchain. This will inevitably result in cross-mobile-platform apps
which have non ios-like interfaces. At the very least it will give succour to
developers who don't want to fully engage with the ios ui conventions and
fully utilise the platform specific features.

Obviously, as on the mac, the market will ultimately decide. But remember
these sort of cross-platform efforts are what has given us the UI abomination
that is CS3 through 5.

~~~
wtracy
Section 10.3 of the new rules specifically bans apps that incorrectly use or
fail to use the native widgets.

------
DeusExMachina
This puzzles me. Why did they change them after a couple of months? I'm really
wondering.

Maybe now they will raise the bar for quality rejecting apps that do not
follow guidelines or do not provide enough functionality? Sounds strange, but
I cannot think about any other reason.

EDIT: reading through the just published guidelines, it is exactly like this.

~~~
meelash
hmm... haven't I read somewhere about building something people want and
releasing quickly, and then iterating on it when you hear from people what
they want differently?

------
Legion
I'm skimming the guidelines, and I don't see a restriction on one of the most
well-known app rejections: duplicating functionality of built-in apps.

I noticed that guideline 2.11 states, "Apps that duplicate apps already in the
App Store may be rejected, particularly if there are many of them", but that
seems intended for preventing a bunch of near-duplicate 3rd party apps, not
the "Thou Shalt Not Write a New Mail Client" commandment.

I wonder, does this "relaxation" include relaxing that restriction?

~~~
trjordan

        10.2 Apps that look similar to apps bundled on the iPhone, including the App Store, iTunes Store, and iBookstore, will be rejected.
    

This may be as simple as thinking their users don't know how to tell the real
Mail.app from your 3rd-party Mail.app. If they can't tell the difference after
installing yours, they may be confused or otherwise left behind when Apple
updates Mail.app with some shiny new feature you don't have. If they're not
sophisticated, they'll blame Apple, not the developer, for a lousy core
functionality.

~~~
Legion
Good eye. I was skimming for things like "duplicate functionality".
Interesting that this just seems to restrict _looking_ like the built-in apps.

------
technomancy
So now instead of developing for a platform run by a megalomaniac dictator who
never listens, you can develop for a platform run by a megalomaniac dictator
who rarely listens to the demands of developers. Sign me up!

------
appie
Here they are: <http://pastie.org/1148102>

("Use Pastie for good, not evil." - I think this is for good)

~~~
jrockway
Thanks for posting these.

Still too many rules for my taste. (Google also has too many rules, FWIW.)

~~~
cardinal23
Instead of just saying too many rules, do you have points in the list that you
object to? One of the problems with rejection until now was the lack of
specific guidelines about what would be rejected. It seems to me that a
comprehensive document would unavoidably have many rules, and the prohibitions
that I read seemed reasonable.

~~~
jrockway
The tipping point was "no card counting". While card counting may be against
the rules at a particular casino, it's not illegal in general and does not
belong in the "legal" section.

Whenever Apple is confronted with a situation where the user could use a
feature or tool for something that's "against the rules", they tend to disable
the feature. See, for example, iTunes' inability to import music from an iPod.
It could be 100% legal for me to do that, but Apple doesn't provide that
feature, even though iTunes "knows" how to do it.

(I stopped using Apple products about 5 years ago when they added
PT_DENY_ATTACH.)

~~~
duskwuff
> _I stopped using Apple products about 5 years ago when they added
> PT_DENY_ATTACH._

You mean the ptrace() flag that's trivial to bypass? Been a while since I
dealt with it, but ISTR it's as simple as:

    
    
        br ptrace
        commands
        ret
        cont
        end

------
siglesias
Anybody notice that the cadence and style of the intro to the review policies
sounds like it was written by Jobs himself?

~~~
rimantas
Yes, Gruber did.

------
steilpass
Strange. Didn't Steve Jobs mention he doesn't want another software layer?
Because it leads to bad apps and they can't push API changes as fast, because
these third party layers have to update?

~~~
steilpass
"We know from painful experience that letting a third party layer of software
come between the platform and the developer ultimately results in sub-standard
apps and hinders the enhancement and progress of the platform."
<http://www.apple.com/hotnews/thoughts-on-flash/>

~~~
protomyth
I get the feeling that if the dev tool / framework you are using doesn't
exactly act like the native framework they will reject your app. Particularly
if your app draws its own UI without using the native widgets.

------
sant0sk1
Welcome, but long overdue.

~~~
city41
It still doesn't really matter. They can revoke this stance whenever they
want. It still remains risky to base your livelihood on a format completely
controlled by someone else who ultimately couldn't care less about your needs.

~~~
mcav
There's no way they could go back on this now. The outcry would be ten times
larger than it was when they first restricted it.

~~~
points
10 * 0.00001 is still pretty miniscule.

Uproar from developers is _meh_. End users don't care. Apple can do what they
want with the app store. If a few whiney devs decide to not play any more,
there's an infinite supply of other devs who will.

~~~
mcav
It's more than whiney developers now. It was one thing when Apple never made
clear the guidelines and chose to reject apps; now that they've made
guidelines very explicit, going back on them would very publicly damage other
companies: Large companies, like Adobe and Oracle, who would be very upset as
well if Apple reneged on this change of policy.

They won't go back on it. Not now.

------
JeffJenkins
This is great news! I just bought an iPad yesterday, and I would like to do
some development for it. Since I stopped paying attention to them when Apple
added the restrictions, what are all of the tools which are now usable that
were in a grey zone before? The Adobe one is the only one I remember.

------
wheaties
So does this mean they'll actually follow their own review guidelines or is it
going to mean you can read them but @#$%!, you're still at the whim of
whomever gets your app?

~~~
smackfu
Yes, it will be interesting to see if they restrict themselves to these
guidelines. In theory, rejections now can just say: You violated 2.1 and 2.3.

------
what

        12.3 Apps that are simply web clippings, content aggregators, or a 
             collection of links, may be rejected
    

Does this mean you can't just wrap your website in a native app and try to
charge for it? What about feed readers?

Also interesting, they say the more you charge for an app the more thoroughly
they review it. Maybe you can sneak things through if you make it free. :b

~~~
Tyrannosaurs
There are plenty of feed readers in the store and they do fine.

The key word is simply. If you're providing additional functionality to allow
people to better use or manage web content (the way any halfway decent RSS
feed reader does) then that's fine.

------
statictype
Some of the app review guidelines seem weird:

 _Apps larger than 20MB in size will not download over cellular networks (this
is automatically prohibited by the App Store)_

Don't many games cross this threshold?

 _Apps that browse the web must use the iOS WebKit framework and WebKit
Javascript_

Opera Mini - which was accepted by the App Store - would seem to fail this
rule.

~~~
davidcann
The 20MB size limit over cell networks has been published for a long time. It
used to be 10MB and they raised it last year, so nothing new on that one.

~~~
jokermatt999
Doesn't that also rule out the majority of podcasts? 8/12 on my phone right
now are over 20MB. Seems like a rather harsh restriction.

~~~
msbarnett
It rules out downloading any type of app or media from iTunes that is greater
than 20 Megabytes over the cellular connection.

Presumably this is in place to try to keep AT&T from falling even more over
under the load.

------
jsz0
I'm still concerned about the "look & feel" problem of shoddy ports using
Flash or whatever but rejecting apps with bad UIs on a case-by-case basis
should protect users equally as well.

------
umjames
Wait, so does this mean Apple doesn't have a problem with a 3rd-party
framework becoming the preferred API for iOS development? How does not
allowing apps that download code prevent this?

Also, does this mean you can't download JavaScript from an external web page
in your app?

~~~
ra88it
Apparently Javascript is given an explicit exception.

~~~
jrockway
What about, say, Haskell compiled to JavaScript?

~~~
glhaynes
If it runs on their JavaScript engine outputting to their HTML component, it's
fine.

------
ataggart
It's 2010; is there any valid reason why a web page announcing a change to
another document doesn't link to that document?

Assuming this[1] is it, what exactly counts as a "private API" per section
3.3.1. Isn't any code I write a private API, thus calls to it a are violation?
And how is that compatible with the allowance in 3.3.2 to package an
interpreter into the app?

[1][http://developer.apple.com/programs/terms/ios/standard/ios_s...](http://developer.apple.com/programs/terms/ios/standard/ios_standard_agreement_20100909.pdf)

~~~
allwein
This strawman comes up every time we have a discussion about the developer
agreement. The section referencing "private" APIs is talking about Apple
specific APIs which have not been publicly documented. In Apple nomenclature,
Public="class, methods, and properties are documented in the reference library
and exposed for developers to use." Private="undocumented and exposed for
Apple internal purposes only". Basically, if you can find it mentioned in the
documentation, you can freely use it. If you had to do a class dump or use
introspection to even find the method out, it's probably private.

------
rabble
I've got 5 apps which were submitted by not approved by the time this 3.3.1
rule was released. Those apps have been "In Review" for this whole time. I've
got another couple dozen apps, which we have been preparing for android, but
could easily submit for iOS. Most of these are unique games, but we've build a
few on our own from scratch.

This is great news. But that said, we're still all at the mercy of Apple's
changing the contract at any time without notice in future.

~~~
rabble
They all got approved. Yes! Finally getting something for that work, we'd
given up on it.

<http://oneappatatime.com/games/published>

------
togasystems
Hopefully the fulfill this promise of being more open. They accidentally
leaked financial records of many app developers to their competitors. Nothing
has been said about this.

Link to story: <http://togapit.com/apple-leaks-sensitive-developer-data/>

On another note, I believe they are relaxing the rules due to epic's
involvement. A lot of there code uses Lua.

------
wtracy
What's with 4.2 and 4.3?

I can't build an app that lets my app drive a toy car around via GPS? (That
would actually be pretty cool!) I can't build an app that taxi drivers can use
to interact with their dispatchers and report their location via GPS?

I can see that those sorts of apps would be likely to run afoul of some other
problems, but I don't see how that in and of itself should be a reason for
rejection.

~~~
blasdel
Liability is a bitch!

I do notice that they left out the standard clause about operating Nuclear
facilities, but that's probably present in the clickwrap for just using the
device at all.

------
tumult
Awesome. Thank you, Apple. Just throwing my comment into this thread in case
anyone there is reading. Some of us really appreciate this move.

------
sambe
Definitely a positive step, but doesn't make (some of) them any less weird.
The one about not using GPS to control remote planes and following one about
not using for dispatch seems very odd. I'm sure there are plenty of people
that could make use of this, and hardly seems harmful.

Likewise the kids-only attitude - why bother having ratings at all? Do we
really have to confirm 18 years old for a dictionary and yet be forbidden
adult material? But strangest of all that I've read so far:

"Apps utilizing a system other than the In App Purchase API (IAP) to purchase
content, functionality, or services in an app will be rejected

Apps using IAP to purchase physical goods or goods and services used outside
of the application will be rejected"

Doesn't this ban all real-world purchases? Ordering books from Amazon App...?

------
jakewalker
I just submitted this as a separate link, but engadget is hosting a copy of
the new guidelines (opens a PDF):

[http://stadium.weblogsinc.com/engadget/files/app-store-
guide...](http://stadium.weblogsinc.com/engadget/files/app-store-
guidelines.pdf)

------
fierarul
What happened ? Did Adobe poke some government officials and Apple was
starting to get bothered by that ?

It just seems incredibly stupid to first ban all tools -- just to mess with
Adobe basically -- and then do an 180 and remove said restriction.

~~~
jakewalker
There is an active FTC investigation into the terms of the developer
agreement, I believe. No idea if it was a direct influence on the change.

------
gmlk
I don't think this actually changes anything? Apple still bans under section 1
and I think 10.1 any app that don't have a consistent iOS look and feel and
behavior. The requirement to only use native widgets is still enforced.

So, either _the app developer_ gives the app a native user experience; Or _the
middleware developer_ makes it so that any app using his middleware is always
conform the guidelines? As far as I can tell this still rules out any simple
use of the simple and generic cross-platform middleware layers?

~~~
allwein
You are incorrect. You are not required to use native widgets. What it does
enforce, however, is that if you use the native widgets, you have to use them
in a way that's consistent with the HIG. As a quick example, you shouldn't use
a tab bar controller where the tab buttons perform an action on the current
view(like save, or cancel). A tab bar controller is only for switching between
views.

~~~
gmlk
That still doesn't change much to my argument: If the app does not behave
exactly like a proper iOS app should Apple is going to reject it.

So we can forget about a simple cross-platform middleware layer that can
create the same app for multiple platforms, however this is maybe less a
problem for games then other applications?

------
benologist
I make Flash games, about 5 months ago I asked <http://www.oneappatatime.com/>
to port one of my games, just before the shit hit the fan.

It actually got approved today too!

<http://itunes.apple.com/au/app/square-there/id367085960?mt=8>

------
tomjen3
Does anybody have the links to the actual rules, since this press release,
through welcome, is extremely light on details.

If not, can we please not post something this light on content to HN in the
future? Maybe instead wait for somebody who knows something to blog about it?
I would hate for this to become a place to just post press releases.

~~~
jakewalker
[https://developer.apple.com/appstore/resources/approval/guid...](https://developer.apple.com/appstore/resources/approval/guidelines.html)

You need to be an iOS Developer to login. Unclear if it's under NDA or not,
but I'm sure this document will leak out eventually.

There are 22 categories of potential violations, and most rules end in "will
be rejected."

~~~
ben1040
You know, while Apple's rejections seemed to be arbitrary at times, I was
surprised that my reaction to reading this was that the vast majority of these
rules are pretty sensible. A lot of them come down to "your app must not crash
or be full of bugs, it must do what it says it does, and it cannot be
malicious." For all the hoopla, I expected this list would read like a crazy
list of charges handed down by a kangaroo court.

The thing on here which I really strongly disagree with is the ban on making
apps that replicate functionality shipped with the phone. If users want an
alternate mail client that supports IMAP IDLE for example, it should be up to
the user to download that.

~~~
loire280
I expect the idea behind that is for the user experience. A non-Apple mail
client, for example, won't have the level of integration into the system (send
mail from apps/camera/etc., notifications, background process that never
quits) that Apple's will, and they seem unwilling to expose that level of
functionality to developers. There's plenty of things wrong with that kind of
thinking, but it's consistent with Apple's philosophy about core
functionality.

It's also beneficial for things like the browser and email client to be
consistent, so that services targeting iPhone have an easy testing platform.
As a web developer I like knowing that every iPhone is using Safari and
renders HTML email using the mail app. I already have enough platforms (4
versions of IE, Firefox, Safari, Chrome, Opera, iPhone, Android, Blackberry,
WinMo) without the mobile platforms becoming fragmented.

------
danlove
I've seen a lot of messages saying Apple "crumbled" to Adobe (pun intended).
While the initial implementation of the rules may have been a knee jerk
reaction to Flash, I think its more likely Apple relaxed the specific rules to
allow Unreal Engine powered games. Thus allowing themselves to fully compete
against the PSP & DS.

------
elai
I hope they add searchability to in app purchases soon. If you make travel
guides for many countries, it looks like you can't sell them as separate apps
easily anymore. If someone searches for Bali, it's going to get missed if you
make a travel guide for Bali and 50 other regions.

~~~
brownleej
Couldn't you just list all the countries you support in the app description?

~~~
elai
No, app descriptions are not searchable anymore. Instead you have to insert
max 100 characters of keywords and that, and the app title and a few other
small things are what are searched. Thats what you would of done quite a while
ago when they searched the entire app description. It's half the reason why
you see spam apps in the first place. Would you call lonely planet doing the
same as spam apps or not, not taking in consideration they do the same with
their books?

------
gaiusparx
What is the pros for Apple beside being able to fend off FTC probe? If company
starting to look at cross-platforms tools (such as one that develops for iOS,
Android and Windows Mobile), and abandon Obj-C and XCode, will this weaken
Apple strategically?

~~~
Tyrannosaurs
The pros are are happier developer community.

Apple is many things but it's not a developer tools company - I doubt it even
covers costs on the developer programme if you include XCode development and
so on. It produces those so people can write software to allow it to sell it's
other products.

The only way this move weakens it is if, as a result, the quality of apps
declines. I'm guessing that they'll look to head that off by pushing non-XCode
apps that little bit harder, at least in the short term, to ensure that
they're up to spec.

------
tomlin
I wonder if this will have a psychological effect on using other dev.
environments for Apps.

It almost paints a Flash-compiled app as being "legacy" when a company opens
it up after demonstrating it's case against alternatives.

------
butterfi
This may be a move by apple to keep the influx of apps available to iOS, as
developers move into the Android space. Given Androids growth, this may be a
way for Apple to avoid what happened on the PC platform in the 80's/90's.

------
adriand
Is this just a press release that changes are coming later today, or are the
actual changes also published? If the latter, is anyone able to summarize what
they are?

------
new2
The death of Objective-C as far as iOS development goes?

~~~
msbarnett
Seems unlikely. It's always been possible to create Mac apps in, say, C++
using Carbon or Qt, but ObjC/Cocoa has remained very popular despite that.

It's an exceptionally good and low friction framework that people tend to
like. Most of the anti-Objective-C sentiment seems to come from people
offended at the notion that they might be _required to learn something new_
rather than stay forever in their comfort zone.

~~~
mkramlich
I think a lot of the complaints about having to use ObjC come from folks that
(a) find it inferior to one or more languages they already know (Python, Ruby,
etc.) and/or (b) feel it is somewhat of a platform ghetto (effectively only
used on iOS and Mac) and therefore not as efficient use of one's time
investment as another language and stack that you can use on many other
platforms, and for many other types of applications.

The biggest problem with Objective-C, in my opinion, is that the syntax and
philosophy is a step backwards in time in terms of programmer friendliness. It
is so much more verbose and clunky compared to Python, for example. Use
Python's built-in dictionary type a while, then be forced to use Objective-C's
dictionaries. Yikes. Then the memory model is more complex and more prone to
error due to inconsistent lifecyles and naming conventions. The XCode/iOS
project model, build generation and signing crud is just nasty compared to how
you can develop and deliver web apps to production in, say, Python, or even
desktop apps. It's just a nasty and overly complicated rat's nest of special
cases. I counted once and an iPhone app has something like 8+ different names
or identifiers, each used in subtly different ways in different places, just
asking for confusion and conflict. I ship a desktop app or web app and I have
effectively one or two identities to deal with, and no Apple hoop-jumping to
do, no publication delays, no long silly list of things I can and cannot do,
etc.: _heaven_ in comparison.

And no it's not about learning something new. I'm personally on like my 8th
language used professionally, and love learning new things. But sometimes
"new" things are worse than what you already know. In that case, learning that
new thing is bad, and a poor use of your time. I've learned enough Objective-C
to be productive, but also enough to know it's a step backward from some other
tools in my toolbox, so bad use of my time in an ideal world. I'm _thrilled_
about Apple's change today because it raises hope I might be able to use a
sexier language than ObjC/C/C++.

~~~
msbarnett
Eh, a lot of the complaints just strike me as not understanding a tool in
terms of its context; Objective-C is, intentionally, a strict superset of C,
so it carries a lot of baggage in order to not break C code. It predates most
of what we now think of as C++. It managed to bring Smalltalk-style dynamic
messaging to C in a manner that wasn't insanely slow and didn't depend on
heavy-weight virtual machines.

Are Python's dictionaries syntactically a bit cleaner? Sure. But Python is
much newer and had the advantage of not having to maintain compatibility with
a vast corpus of C code, and not having to care about achieving very very very
good native code run-time performance on very resource limited machines.

It's just a tool. One that makes a completely different set of tradeoffs than,
say, Python (Python might win in terms of cleanliness of dictionary syntax,
but it's orders of magnitude less suitable for bringing high-level, dynamic OO
to low-resource programming). The people who whine that these Apples aren't
Oranges and that they refuse to do work in anything that isn't citrus-
flavoured strike me as having come to rely too heavily on familiar crutches to
truly learn to appreciate the other advantages that can be found in tools that
make different trade-offs.

~~~
mkramlich
I understand and agree with much of what you say. However I am -- increasingly
as I get older -- a fan of Getting Things Done, so I prefer tools that let me
do that better. This is the role where ObjC is inferior to alternatives like
Python, among others.

I was doing assembly programming in the mid/late 80's, then was a C programmer
for about 5 years, then C++ for about 2, then Java for many years after that
before switching to Python as my default goto language. Leaving out experience
with several other languages. I am a language geek, not super hardcore as
some, but far above average. So I'm quite confident in saying ObjC is a
needlessly archaic, verbose and complex language compared to alternatives. Is
it totally without merits? Of course not. Was it designed to fit a niche and
context? Yes, and perhaps it achieved those goals well, and some would argue
better than C++. But all of this is irrelevant when it exists as part of a
larger set of choices available to a modern programmer who wants to Get
Something Done and has sufficient freedom to choose his tech mix. Given the
right permutation of constraints any tech can become the Perfect Choice for
those constraints, so saying that alone about ObjC is not a compliment.

------
insulanus
How fitting that the link to the appstore guidelines is not in the press
release!

------
elblanco
Well that was a bunch of unnecessary drama for a whole lotta nothing.

------
mambodog
I _really_ hope this doesn't result in a flood of Flash-based apps.

And I say that as someone who's been developing Flash content for the web for
quite some time.

~~~
jrockway
Yeah. The underlying problem here is not that there are a bunch of Flash apps,
but that Apple forces every user to install every app every developer cranks
out. If you could decide for yourself, then you could let other people use
Flash apps, while you could completely ignore them.

Oh right, that's already how it is. So this will actually affect you in no
way, except that you have more apps to pick from (or ignore).

------
akshayubhat
no more 3.3.1 that's good. Finally sanity prevails over "interface decides
programming paradigm/language argument".

------
binaryfinery
Well, I've spent the last six months learning the shitiest language and
libraries with the most backwards arse tools. What a total waste of my time.

Can't decide whether I'm furious at this loss of time and destruction of my
competitive advantage, or deliriously happy at the thought of being able to
use proper tools like Resharper and IDEA.

I suppose the fact is I still have a competitive advantage. I have one client
purely because they tried middleware and it ran like ass, so they wanted a
native app.

Time to get Java installed on the iPhone. I'd prefer Monotouch, but the
editors on OSX suck compared to Resharper.

~~~
brettbender
If you hate researching new technologies and learning new languages, maybe
developer wasn't the right profession?

~~~
CamperBob
Where did he say that? Is he not allowed to criticize Objective C?

------
drewse
I think this yet another step in Apple's progress in refining the App Store
for both the consumer and the developer. Every thing Apple does with the App
Store is taken one baby step at a time, but their baby steps have added up. If
you look back at how different the App Store was when it came out, you'll
notice how far it's come since then.

These review guidelines that Apple recently posted were not needed by most
developers, and will still only be relevant to those 1% of developers whose
apps are controversial or unlucky enough to get rejected. However, since this
has been covered so much by the publicity (just like the iPhone 4 antennagate
issue and Adobe-Apple war), Apple felt the need to succumb to the media. Sure,
it was not that big of a thing in the first place to just publish their review
guidelines, but isn't it unusual that Apple is having to quiet down the media
more and more often these days? Apple shouldn't have to do this, but with
people taking everything out of proportion (all these issues only affect the
small minority), it's hard for them to ignore it. What do you think?

------
c00p3r
<http://vmkit.llvm.org/> becoming ready? ^_^

------
drivebyacct2
Developers are forced to the Apple's Push Network? Huh.

------
bhjodokast
How fickle are they?

------
Setsuna
VLC

------
portman
Was this story broken here on HN? I can't find any other stories on Google
News.

If so, well done jakewalker. Makes me wonder if HN can become a primary source
for news in addition to an aggregator.

~~~
jakewalker
I saw it on a few tech sites (AppleInsider, Gizmodo, etc.) this morning, but
linked to the source, since most of their articles were just a copy & paste of
the Apple press release.

------
statemachine
In other news, hell freezes over, and Microsoft embraces open source.

~~~
adolfojp
<http://www.microsoft.com/opensource/>

Go get a light sweater.

------
aditya42
Badam bam pshsh!

