Apple Relaxes iOS Restrictions On Development Tools, Publishes Review Guidelines
apple.com
More details:
http://developer.apple.com/appstore/guidelines.html
apple.com
http://developer.apple.com/appstore/guidelines.html
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:
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.
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.
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."
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.
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.
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.
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?
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.
So, how about all those people... who said that there is no
point complaining about it?
"We have lots of kids downloading lots of apps, and parental controls don't work unless the parents set them up (many don't). So know that we're keeping an eye out for the kids."
"We have over 250,000 apps in the App Store. We don't need any more Fart apps."
"We have lots of serious developers who don't want their quality Apps to be surrounded by amateur hour."
"If your app is rejected, we have a Review Board that you can appeal to. If you run to the press and trash us, it never helps."
"This is a living document, and new apps presenting new questions may result in new rules at any time. Perhaps your app will trigger this."
"If it sounds like we're control freaks, well, maybe it's because we're so committed to our users and making sure they have a quality experience with our products."
More here: http://www.engadget.com/2010/09/09/apples-app-store-review-g...
"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.
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.
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".
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)
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).
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.
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.
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.
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.
("Use Pastie for good, not evil." - I think this is for good)
Still too many rules for my taste. (Google also has too many rules, FWIW.)
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.)
You mean the ptrace() flag that's trivial to bypass? Been a while since I dealt with it, but ISTR it's as simple as:
br ptrace
commands
ret
cont
endUproar 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.
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.
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.
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.
They're not limited to rejecting you for only the things that are in the guidelines. The guidelines say this.
12.3 Apps that are simply web clippings, content aggregators, or a
collection of links, may be rejected
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
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.
Apps larger than 20MB in size will not download over cellular networks (this is automatically prohibited by the App Store)
Don't many games cross this threshold?
Apps that browse the web must use the iOS WebKit framework and WebKit Javascript
Opera Mini - which was accepted by the App Store - would seem to fail this rule.
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.
Presumably this is in place to try to keep AT&T from falling even more over under the load.
Also, does this mean you can't download JavaScript from an external web page in your app?
Assuming this[1] is it, what exactly counts as a "private API" per section 3.3.1. Isn't any code I write a private API, thus calls to it a are violation? And how is that compatible with the allowance in 3.3.2 to package an interpreter into the app?
[1]http://developer.apple.com/programs/terms/ios/standard/ios_s...
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.
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.
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.
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...?
http://stadium.weblogsinc.com/engadget/files/app-store-guide...
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.
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?
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?
It actually got approved today too!
http://itunes.apple.com/au/app/square-there/id367085960?mt=8
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 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.
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.
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.
It almost paints a Flash-compiled app as being "legacy" when a company opens it up after demonstrating it's case against alternatives.
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.
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++.
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.
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 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.
Objective-C isn't bad, as I like both C and Smalltalk, it seemed quite normal to me.
I will say the lack of a persistent ORM that isn't as complicated as removing an internal organ is a bit of a liability (simple, core data is not).
And yeah yeah, persistent object graph blah blah.
And I say that as someone who's been developing Flash content for the web for quite some time.
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).
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 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.
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.
This will continue to happen. And just because the tools are allowed doesn't mean that their output is allowed to be below standards.
> Time to get Java installed on the iPhone.
You mean, a static Java to arm-apple-darwin compiler? It's not possible to run a JIT interpreter (HotSpot+Zero) on iOS.
"New" as in "new to me" but actually created in 1986, no, not so much.
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?
If so, well done jakewalker. Makes me wonder if HN can become a primary source for news in addition to an aggregator.
Go get a light sweater.