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.
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.
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.
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.
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.
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.
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'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.
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 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.
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.
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?
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?
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?
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.
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."
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).
>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.
"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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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?
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).
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.
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.
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.
239 comments
[ 3.7 ms ] story [ 261 ms ] threadUproar 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.
They won't go back on it. Not now.
EDIT: As explained below, my point isn't that Android isn't open today but that it's their (or the carrier's) platform.
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.
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.
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.
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.
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.
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.
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...).
Which just goes to prove my point - I don't fit very well into the Apple box.
If so, well done jakewalker. Makes me wonder if HN can become a primary source for news in addition to an aggregator.
Also, does this mean you can't download JavaScript from an external web page in your app?
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.
http://developer.apple.com/appstore/resources/approval/guide...
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"
http://stadium.weblogsinc.com/engadget/files/app-store-guide...
I wonder how quality of the current apps vs quality of the new app applies here.
But still, it's an improvement.
I wish Apple would learn how to use the word "different".
They're not limited to rejecting you for only the things that are in the guidelines. The guidelines say this.
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.
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.
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.
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."
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?
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.
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.
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.)
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.
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.
It's not like there is some equal subtle list of pros and cons that need to be weighed, here.
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)
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.
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. :)
From my personal experience, people "in the trenches" use feedback from their constituents to add weight to their messages to their superiors.
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.
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.
> Apps that do not use the MediaPlayer framework to access media in the Music Library will be rejected
That sounds like apps that don't access the Music Library at all will be rejected.
Apps that access media in the Music Library, without using the MediaPlayer framework to do so, will be rejected.
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.
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.
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.
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.
This mostly affects registered developers anyway (and I'd say there are a fair few on HN), for whom the rules are just a click away.
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."
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.
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.
They may have a non-commanding share of mobiles, but they have a total monopoly on iPhone apps.
Fortunately, this simply isn't how antitrust law works.
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.
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.
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.
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?
http://www.justice.gov/atr/public/reports/236681.pdf
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.
"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.
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.
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).
I mean, this case was sustained past summary judgement: http://www.wired.com/images_blogs/gadgetlab/2010/07/iphone-A...
And people in Washington were talking about investigating (although not necessarily on AT basis).http://www.nypost.com/p/news/business/an_antitrust_app_buvCW...
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.
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 :)
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.
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).
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.
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.
Damn iPhone.
Go get a light sweater.
http://www.youtube.com/watch?v=p2H8hmi8yrQ
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.