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.
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.
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.
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.
It's hard to resist the temptation to follow that line of thinking, but given a complete absence of evidence and a very public acknowledgement that they listened to their developers I think that's the prudent option for now.
It certainly looks like they are sincere about it, and if they are not this will hollow out their position in the future quite a bit and they did not have to give any reason at all.
Listening to your developers is not such a bad thing, after all.
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."
"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.)
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. :-)
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.
>That's a very valid complaint imo, except for the 'sucky', was that present in the original?
While 'sucky' isn't up to HN's style standards, and a more reasoned response is always preferable, I personally don't think the prohibition Apple put in place was sufficiently reasonable to merit a reasonable response.
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"
Uh, what? These seem like perfectly legitimate complaints to me. Why shouldn't you be allowed to use the tools you already know how to use? Why shouldn't you be allowed to write once and run anywhere?
I've got nothing against your point on using the tools you know, but I can at least see where Apple is coming from with disallowing write once, run everywhere, especially regarding UI (think Java apps on OS X).
What kind of constructive arguments, exactly, need to be marshaled against it? "Hey, Apple, have you considered that a blanket ban on third-party development tools fucks over developers who use third-party tools?" Why, yes, I suspect that they did consider that.
It's not like there is some equal subtle list of pros and cons that need to be weighed, here.
My guess is that Apple thought they saw a problem on the horizon, threw out some very restrictive language to be sure they had as many known AND UNKNOWN bases covered, then after some more thoughtful consideration decided that they didn't need to be so strict after all, and relaxed the terms. This sort of pattern happens a lot: go overboard at first, then pull back as you get more comfortable with things.
Complaining is always useful. It conveys information.
It's even better if you convey a suggestion on how specifically to improve things. But often the complaint itself contains that, implied.
For example, a what-you-would-call whiny complaint of "waaaaa... don't touch my arm with that torch, it burns!" contains the rather useful suggestion (implied) to stop touching my arm with that torch. To be more relevant, if Apple suddenly says you can't use any language but XYZ, and we go "waaaa...." what we are saying is "let us use XYZ". I hope that is obvious and implicit in all such cases. :)
I completely agree that it's always good for a customer to complain about the product if there are problems. Gosh: read all the Mac faithful complains when a new MacOS comes out! Similarly if your phone doesn't work, or your car is not comfortable you go and complain.
BUT, the crucial word there is customer. People who would never buy an Apple product out of principle, or unless Apple becomes totally completely open source/open market/whatever, then those complains are pointless.
It all goes back to "vote with your wallet". Apple may listen to the first ones because their behaviour may change: the latter won't, they'll just complain, and Apple couldn't care less.
That said Apple is also a pretty stubborn company, and often even when it is in their best interest and their customers are complaining (AND voting with their wallet) they may keep their believes. It's one of their problems, though it's of course their right, and it may even make sense.
(for example a luxury brand is more interested in maintaining their recognisable features rather than adapt... but it's their choice: they judge how many customers they lose in the short run vs. how many customers they will retain in the long run)
The argument has been made that for every iphone developer that would quit making apps another (or two) would take their place. And that may be true. But a developer that has quit is not going to sit around and do nothing.
He's going to use his expertise gained on the one platform to make a go of it on the other. So an exodus of frustrated developers is really a very big problem.
Of course the customers will never know of anything like that happening behind the scenes. But they'll see their buddies with their shiny non-apple phones do stuff that they'd like to be able to do.
Where developers go, customers follow, you ignore them at your peril.
At the same time developers follow customers. ;) It goes both ways.
But yeah, I agree with you. Do it at your peril, and they tried, kept going probably thinking the pros. out-weighted the cons, and eventually after 2 years pushing it, they relented.
That's all I am saying. And yes, I admit Apple would have sticked to its guns for a little bit longer (basically until, like in today's mac, users were so familiar with the mac UI, that any rougue developer would change it at his peril ;) ).
But anyway, customers feedback or developers feedback (as you point out) is very very different from the trolls and haters you see populating internet forums. :)
Periodically Apple sends a survey out to iPhone developers asking for feedback on various aspects of the developer program and App Store. This latest move by Apple gives me some hope that they aren't just round-filing the feedback.
As someone who works for a large software company. I can assure you that feedback from developers is not only hard to obtain, but highly valued and used to shape future decisions.
From my personal experience, people "in the trenches" use feedback from their constituents to add weight to their messages to their superiors.
Not sure about statement 2.9: "Apps that are "beta", "demo", "trial", or "test" versions will be rejected"
Does this mean no "lite" versions of games? That would affect tons of apps... unless Apple is about to come out with a way to bundle a lite version with your app.
That's a tricky one, you're right about that. Maybe there is a way to get some clarification on that one without having to go through a whole round of developing an app and then having it rejected or accepted. I think what they mean to say is that it should be a 'finished product' (no beta, no test), it should be fully functional (no demo or trial), so self contained.
If there is a more fully featured version of the game available for another platform I can't really see how that could lead to trouble, but it may be worth a bit of investigation beforehand.
I think trial software has the connotation of being time limited. This whole section of the rules is just saying that they should be able to use the software as much as they want without having a "dead" app in the phone after the software expires. Lite just means less features/levels so that is permissible.
They also don't like software that looks like some feature should work, but just pops up a "buy me" dialog. Lites are OK as long as they are internally consistant.
I think this may be because of in-app purchases. So you can distribute a free "full but locked" app, and then just add functionality with in-app purchases. Maybe they're trying to promote that?
Not really, you can bundle music in your app and call it however you like. If you are playing music from the music that you loaded from itunes then yes they want you to use that framework.
Currently any app can just get raw read access to the Media Library SQLite database file — the current MediaPlayer framework just implements an unprivileged API on top of that.
My guess would be that it had more to do with the number of apps submitted since the policy was enacted than the number of complaints on internet forums.
I also believe the original policy had less to do with security and more to do with selling more MBPs (their higher margin product). So if their research showed that those mobile developers without a Mac chose to develop for other platforms instead of buying a Mac it would've only made sense to reverse their policy.
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.
Their mentioning it is nothing but a PR excuse. This had nothing to do with you or me and everything to do with Adobe's lawyers.
So, how about all those people... who said that there is no
point complaining about it?
I don't think I was one of those people, but I don't think the complaints have had much practical effect, here. The real impetus is more likely that they are feeling the heat from the Android platform.
Complaining does not work. Competition does. Apple finally has some so they are making developers happy before they all leave for android. Android is getting damn well polished.
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."
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.
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.
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.
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.
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.
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.
Yeah this is just awesome news for MonoTouch - I'd been on the fence about spending the money on the license thinking it might end up being a waste of money, but now, hell yeah full speed ahead. Hopefully the mono-Droid update is as well done and available soon, I really need it.
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!
You have to make it a bit better/different and then they can't argue it's duplicate. You can say, oh we can't compete now. Only 3 car manufacturers are allowed?
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.
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.
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)
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.
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.
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.
What theory of law? Notice the words 'weird' and 'starting to live', I am saying that this is new territory and as such the law hasn't even been tested yet. It may even result in new legislation.
There is a huge gap between the monopolistic marketplaces that Apple and MS have setup and service providers like Twitter or 37signals who give api keys to anyone who asks.
And why fortunately? Do you like having your freedoms curtailed? Do you like being vastly overcharged for things you know would be a lot less if competition was allowed?
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.
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.
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.
Read the intro to section 2, then skip to section 2 and read the first couple pages.
Long story short: the acid test for "monopoly power" is, "if Apple jacked the prices up on iPhones, would its customers be unable to acquire reasonable substitutes." Since Apple has something less than 30% of the smart-phone market (note: that same DoJ doc says that market shares under 55% are probably prima facie excluded from antitrust enforcement), it's unreasonable to argue that consumers have no substitutes for iPhones.
Apple also has a huge share of games involving catapulting birds and falling refrigerators and cars, but, well, read above.
There is another store for which normal people can buy software for iOS devices?
"would its customers be unable to acquire reasonable substitutes."
If you look at the class "iOS software" which is only legitimately sold by one vendor, the very definition of a monopoly. If Apple raised the price of all iPhone apps to 200k tomorrow, there would be no reasonable substitute for software for the device.
They do not have a monopoly of "mobile phones", they have a monopoly on "iOS software". Which is all sold by them (nonwithstanding tiny jailbroken stores). They do not have a monopoly on "Games about birds", as you can develop a substitute for that on other platforms which they do not control. You cannot however say they do not have a monopoly on the distribution of games about birds which run on iOS devices, because they clearly do.
As iOS software makes up 85% or more of all paid sales, this IS a legitimate issue for Anti-trust legal system, at least good enough to get in front of a judge.
You are hopping between two arguments to avoid having to deal with the weaknesses of either of them.
On the one hand, you point out that Apple has a 100% monopoly on iOS applications. Of course, Twitter also has a 100% monopoly on Twitter apps. Surely nobody thinks Twitter has a monopoly.
On the other hand, you point to profit share in the wider market of smartphone apps. But of course the problem there is that Apple has less than 30% of the market for smart phones, and so clearly can't monopolize the market for smartphone apps.
I'm not hopping between 2 arguments, I'm explaining how they meet the 55% bar, (85% of all paid app sales for all mobile phones are sold on the Apple AppStore, so they clearly are meeting marketshare requirements if the government wants to prosecute), and how they do actually have pricing power, which is merely responding to your arguments.
So you're saying if Toyota only ran on gas with a certain additive, and 85% of all gas sales were for Toyota cars, the company who had control of the additive wouldn't be possibly considered a monopoly?
The cost of the phone and the contract which locks you into a carrier makes this a much bigger deal then you think it is, and very possibly does give the FTC pause (among restraint of trade arguments as well).
You're trying to argue they're not a monopoly, and I'm saying it's at least close enough that could become a finding of fact for the judge/jury in a court case to decide, which is likely close enough to make the company back off its more onerous behaviors to avoid the expense of that sort of case.
I honestly think the restraint of trade issues are much bigger than the AT ones, but that wasn't what this thread was about.
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.
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.
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).
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.
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.
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!
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.
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.
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.
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?
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?
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.
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!
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?
"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/
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.
I guess he changed his mind when Epic showed him the Unreal Engine 3 running on an iPhone. He was so impressed by it that he presented it as the only third party app on their iPod press conference, that says a lot.
According to John Carmack (http://twitter.com/ID_AA_Carmack, search for Apple), Apple asked him to also be at the conference, and he turned them down because of the conditions they wanted to put on him to do it.
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.
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.)
I think the number of rules reflects the ultimate simplicity of it. Rather than referencing 9 things to see if it's legal, simply go down it as you would a checklist.
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.
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.
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.
Agreed. You give a mouse a cookie, and then he'll want a glass of water. By giving up this ground it would be near impossible and close to PR-suicide to commit any future retraction. About time for sure.
The fact remains that releasing an app for iOS has its risks. Sure, the chance that Apple will reject your app are slim, but that chance is still there. There are real developers out there who have found themselves quite screwed because this very slim risk happened to him them.
Releasing a Windows, OSX, Un*x or webapp does not have this risk at all. At the expense of losing out the benefits the app store gives a developer.
I'm putting the finishing touches on an iPad game right now. Do I want to make the leap from here and do this full time? Possibly. But if I do, I have to weigh the risk of Apple fully controlling the app store and what it could possibly mean to me. To not do so is simply naive.
My comment was based on the assumption that the OP thought the picture was different on Android. I know there are platforms where you can release without being so dependent on others (e.g. the web).
What are you talking about? Target the Dalvik VM and Google doesn't care what you do, what language you do it in, or what tools you use to build it. Sure there are some parts of the system that you can't access without root privileges, but that's an entirely different issue.
But it's their platform. Maybe they don't care today but how do you know they, or the carriers wont care tomorrow? That risk seems at least as big as Apple going back on today's announcement (for the record, I would view both small).
What if the world ends tomorrow and you spent your last hours doing nothing but debating hypotheticals? That would be a shame, so you should just stop now.
The difference is that Apple has enacted many policies that limit developers while Google has, to my knowledge, never done anything of the sort. In fact, it seems like they go out of their way to be fair to developers (for instance: every app they built for Android uses only the APIs that are available to everyone).
Edit: My point is that Google has never shown an inclination towards policies like these, and I think it's reasonable to expect that not to change.
Google doesn't let you release an app that allows wifi tethering without rooting your phone. I'm sure there are other examples. Google/Apple = the same. They all bow before the carrier gods.
Edit: I can't reply to the child for some reason (too deep), but I just wanted to let you know that you're wrong: 2.2 as distributed by Verizon does not have tethering unless you use their carrier replaced version which bills your account for additional fees.
And how is that Google's fault? Are you going to blame the locked NAND and signed bootloader on Google too? Carriers locking down Android is just as bad a reason to blame Google as faulting iOS for not having tethering is (considering that the OS has been capable for a long time but ATT drug their feet).
What? It is Google's fault that they allow carrier lockdown. It's their platform. They could say if you do X, no Google Android apps allowed. They have already done that, for certain values of X; extending X to include carrier lockdown is certainly a possibility.
That Apple didn't make allowing tethering a deal breaker in their negotiations with ATT was Apple's decision and goes to what Mr. Jobs views/ed as a market requirement. The iPhone seems to have done alright without tethering.
It's built into Android 2.2. Additionally, if you can think of a way of exposing the ability to wifi tether, without requiring root that doesn't fundamentally compromise the security of the underlying Linux system... well I think there would be a lot of Linux gurus who would be quite intrigued.
What's the point of such a comment. It reminds me of the pundits talking about how it was "About time" copy & paste was devised. Be glad that Apple isn't so prideful that they aren't able to make changes like this. A lot of people and companies wouldn't be able to admit things like thing to make the right decision.
Whether it was fast enough for you is entirely besides the point. They couldn't have just opened up the whole deal could they? They make careful decisions. They started out with high restrictions and have become continually more open. How often is the opposite the case?
Every "death knell" for the App Store and the iPhone is being chipped away; not by Android, but Apple itself.
The point was that Apple could have avoided much pain and suffering for all concerned if they had done the right thing in the first place.
Now we just need to be able to run programs not purchased through the Apple store and access my iPod without having to use Windows, and I will have to take Apple of my "somewhat evil" list.
I disagree. Apple's stubbornness has its problems, and sometimes it's a pain. At the same time this uncompromising stances are common among those with strong believes and vision. And Apple has those (if you agree with their believes and vision is another story though ;) ).
Case in point: the original Mac had no arrow keys to FORCE the developers and the users to change their frame of mind and make heavier use of the mouse. Had they compromised maybe people would have gone for the path of lowest resistance, and people wouldn't have accepted the advantages.
Other cases:
- USB (how long did it take in the PC world to get rid of serial ports?)
- 64-bit cocoa (or rather 64-bit carbon)
etc...
It may seem madness, but there is logic in the madness. And usually if after many months if not year they are still proved wrong, Apple relents (e.g. fat Nano, Cube, DVD>CD-RW, tabs on top in Safari, etc...).
Hmm, I just don't believe in people telling me what to do - if it really is better, I will come around to it eventually (emacs, dvorak) but except for getting more usb ports, I don't really see any of the things you listed as being a good thing.
Which just goes to prove my point - I don't fit very well into the Apple box.
My point is that it's not nearly so simple as just enabling it. They're trying to reach a compromise between security/control and giving freedom to the developer. Not fast enough is sour grapes. I'm not saying it could have happened faster, but it's sort of pointless to count the days.
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.
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?
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
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.
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.
Yep, and they don't download over cellular networks - you have to do it over wi-fi.
> Opera Mini - which was accepted by the App Store - would seem to fail this rule.
It seems to get round it on a slight technicality. It goes via the Opera proxy server and isn't actually reading HTML (the stream is compressed and encoded) so you could argue that it's not strictly a web browser. In a sense it's closer to something like Instapaper - it takes a chunk of the web, encodes it and passes it to the app to use.
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.
Also, the 20MB limit applies to everything in iTunes, not just the app store. If you purchase a video in iTunes that is larger than 20MB, it will refuse to download it on cellular connections.
They've always done this since the App Store was first launched - in fact, the cap was initially 10MB, not 20MB. And as someone with a metered data plan, I'm glad that I can't accidentally use a huge chunk of my bandwidth downloading a super large game or app, but I'd also prefer a way to override this restriction if I'm OK with downloading a 25MB app or podcast over the cell network.
A lot of games put a lot of work into reducing their size below the 20MB threshold. The big games out there are probably over 20MB, but a lot of games are able to get below 20MB as long as they use compressed resources.
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?
I found it interesting that the exception was not for Javascript, but rather for WebKit in general. "The only exception to the foregoing [ban on downloading and interpreting code] is scripts and code downloaded and run by Apple’s built-in WebKit framework." [from section 3.3.2]. Perhaps Apple wants to keep their options open for other scripting languages in WebKit. I would love to see python and ruby scripting on the client side, personally.
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?
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.
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.
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.
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.
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.
I imagine Apple and AT&T don't want their consumer device to become part of the infrastructure of a major and potentially critical business. Same with the EMS thing. Just too many potential legal risks.
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...?
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?
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.
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?
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.
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.
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?
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?
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.
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.
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?
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.
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++.
I generally agree, but: verbosity is mostly due to Cocoa naming conventions, not Objective-C. PyObjC (Cocoa bridge for Python) is — aside from few classes mapped to Python types — equally verbose and even more annoying to use, because you can't mix method name with arguments.
Reference-counted memory management might be step back, but I don't agree about inconsistent object lifetimes. Cocoa has simple rules: you're responsible for releasing objects returned by methods with `init`, `new` or `copy` in name. delegates are not retained. Everything else is retained and autoreleased for you. It's pretty consistent and even clang's static analyzer can catch common mistakes.
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.
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.
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).
Guidelines or not, they can always ban crappy apps ... that's why those restrictions (like developing with other languages) seemed so out of place and more like a political move meant to take shots at its competition.
It's quite simple ... if an app consumes lots of resources (measurable) or is violating the design guidelines or is another fart-app ... then ban it. If Flash-based apps are indeed crappy, you don't need to explicitly ban Flash ... and who knows ... maybe a skilled developer can make something usable that doesn't fuck up your battery life.
I don't think it's that positive a move for Flash.
I think there will be some instances where people will port existing Flash content but it's not going to be the platform of choice for most people starting from scratch.
I suspect we'll see an increase in iPhone IDEs for different platforms and Flash will be one of many picking up a small share of the market with XCode holding onto the bulk of it.
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.
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.
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.
Actually it would properly affect those who are considering becomming developers for Apple more - after all, if you already learned the APIs, then you already made your choice.
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.
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?
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.
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.