Steve Jobs’ response on Section 3.3.1(taoeffect.com)
taoeffect.com
Steve Jobs’ response on Section 3.3.1
http://www.taoeffect.com/blog/2010/04/steve-jobs-response-on-section-3-3-1/
35 comments
> I think Apple feared that more third-party toolkits are on the way, and that they'll become more popular.
I guess Apple has been surprised by apps popularity. Their original policy was that 3rd party applications ought to be web apps (initially, it was the only way to go).
Embedded applications make sense:
* for super-tightly integrated user experience: but then, you don't want any lowest common denominator middleware on the way, as they guarantee a crappy experience (typically way worse than a decent and portable web app, see below).
* for driver-like stuff that do magic (but Apple always hated the idea of 3rd parties writing such sensitive code, which is one of the reasons why OSX is way more stable than Windows)
* because in some countries, users are stuck with a not-so-reliable 3G carrier, so being able to run offline is valuable. Hopefully that's a temporary situation, and I understand that HTML5 allows to write offline-compatible web apps anyway.
* because it's culturally accepted to pay a couple of dollars for a fart simulator app, but most people won't pay a dime to access the New York Times content in a web site. That's the reason why most apps are apps rather than web sites, but that's a problem with the web, not Apple's business.
This last point is at the core of most issues with Apple's tight control on iPhone apps: most of them should have been web app. They've been written as apps not to benefit from the iPhoneOS platform, but to benefit from the AppStore's easy monetization and publicity. It's about the AppStore, not about the iPhone!
I guess Apple has been surprised by apps popularity. Their original policy was that 3rd party applications ought to be web apps (initially, it was the only way to go).
Embedded applications make sense:
* for super-tightly integrated user experience: but then, you don't want any lowest common denominator middleware on the way, as they guarantee a crappy experience (typically way worse than a decent and portable web app, see below).
* for driver-like stuff that do magic (but Apple always hated the idea of 3rd parties writing such sensitive code, which is one of the reasons why OSX is way more stable than Windows)
* because in some countries, users are stuck with a not-so-reliable 3G carrier, so being able to run offline is valuable. Hopefully that's a temporary situation, and I understand that HTML5 allows to write offline-compatible web apps anyway.
* because it's culturally accepted to pay a couple of dollars for a fart simulator app, but most people won't pay a dime to access the New York Times content in a web site. That's the reason why most apps are apps rather than web sites, but that's a problem with the web, not Apple's business.
This last point is at the core of most issues with Apple's tight control on iPhone apps: most of them should have been web app. They've been written as apps not to benefit from the iPhoneOS platform, but to benefit from the AppStore's easy monetization and publicity. It's about the AppStore, not about the iPhone!
> it's culturally accepted to pay a couple of dollars for a fart simulator app, but most people won't pay a dime to access the New York Times content in a web site. That's the reason why most apps are apps rather than web sites, but that's a problem with the web, not Apple's business
Brill!
The funny thing is, the price of 'software' has often really been driven by the price of distributing it, not the value it delivers or how much it cost to create it.
(Joel Spolsky has pointed out this is why Enterprise Software costs so much: because it costs so much to sell software to Enterprises).
The App Store really takes the friction out of the business of distributing binaries, including the friction out of marketing it. So it should come as no surprise that a lot of really good software is cheap in the app store.
It won't be long before you won't be able to charge for the NYT in the app store either.
Brill!
The funny thing is, the price of 'software' has often really been driven by the price of distributing it, not the value it delivers or how much it cost to create it.
(Joel Spolsky has pointed out this is why Enterprise Software costs so much: because it costs so much to sell software to Enterprises).
The App Store really takes the friction out of the business of distributing binaries, including the friction out of marketing it. So it should come as no surprise that a lot of really good software is cheap in the app store.
It won't be long before you won't be able to charge for the NYT in the app store either.
Nit, but he pointed out there isn't much in the way of software that's priced between $1,000 and $75,000:
"There's no software priced between $1000 and $75,000. I'll tell you why. The minute you charge more than $1000 you need to get serious corporate signoffs. [Etc. And to get that you need a salesforce and so on.] And with all this, the cost of making one successful sale is going to average about $50,000. If you're sending salespeople out to customers and charging less than $75,000, you're losing money."
(http://www.joelonsoftware.com/articles/CamelsandRubberDuckie...)
"There's no software priced between $1000 and $75,000. I'll tell you why. The minute you charge more than $1000 you need to get serious corporate signoffs. [Etc. And to get that you need a salesforce and so on.] And with all this, the cost of making one successful sale is going to average about $50,000. If you're sending salespeople out to customers and charging less than $75,000, you're losing money."
(http://www.joelonsoftware.com/articles/CamelsandRubberDuckie...)
Are we in violent agreement? The cost of sales is part of the cost of distribution. Part of why the App store lowers prices is reducing the cost of spitting bits, but most of why it lowers prices is by reducing the cost of marketing software to users.
Cordial agreement, more like it.
Joel was talking almost entirely about the sales effort, not so much about marketing (although you need a much more expensive marketing effort if you're playing the big sales force/big ticket sales game at the upper end, if only to establish your company and/or brand).
And I really wonder about lowering the cost of marketing. I don't know at all how this Apple App ecosystem works, but it seems to me that rising above the crowd and noise of 100,000? 1 million (if not now, soon enough) apps means you need serious marketing of some sort, or a stroke of luck where your app goes viral without much connected effort on your side.
The generally greater interconnectedness of today probably has a lot more to do with lowering the cost of marketing than anything having to do with the App store ... although that'll e.g. depend on its search function and how and if people use it. I note that Amazon gets by with what is by far the worst search engine of any site I've used in years.
Joel was talking almost entirely about the sales effort, not so much about marketing (although you need a much more expensive marketing effort if you're playing the big sales force/big ticket sales game at the upper end, if only to establish your company and/or brand).
And I really wonder about lowering the cost of marketing. I don't know at all how this Apple App ecosystem works, but it seems to me that rising above the crowd and noise of 100,000? 1 million (if not now, soon enough) apps means you need serious marketing of some sort, or a stroke of luck where your app goes viral without much connected effort on your side.
The generally greater interconnectedness of today probably has a lot more to do with lowering the cost of marketing than anything having to do with the App store ... although that'll e.g. depend on its search function and how and if people use it. I note that Amazon gets by with what is by far the worst search engine of any site I've used in years.
I can think of a lot of software that's priced in the $1000-10000 range.
I've wondered about that and wondered how much of that is due to a total sale adding up to much more than $10K?
And of course that's not a hard rule, there can be software priced in the middle where a less strenuous effort on the part of the corporate buyer gets the job done on his side (and many think that a major reason for corporate software piracy is not that the corporation can't afford it, but that it's so hard to get a purchase order through that borrowing a disk from someone across the hall is by far the path of least resistance).
And maybe this help explains some major failures, like Centerline's Code and ObjectCenter (interpretive environments (with interpreters, but you often just load compiled code on the fly) for C and C++ that are as close to a Lisp Machine as you could get for those languages).
Also, the $1,000 limit is undoubtedly too low, it's whatever your corporation allows you to spend without too much effort (e.g. CxO signoff). A few thousand dollars are OK, e.g. that's how PCs slipped into a lot of companies, on departmental but not corporate budgets. (Heck, that's how a few Z-80 CP/M machines slipped into LMI when we had at most 3 CADRs operational at a time and a strong bias against doing anything outside of a Lisp Machine.)
And of course that's not a hard rule, there can be software priced in the middle where a less strenuous effort on the part of the corporate buyer gets the job done on his side (and many think that a major reason for corporate software piracy is not that the corporation can't afford it, but that it's so hard to get a purchase order through that borrowing a disk from someone across the hall is by far the path of least resistance).
And maybe this help explains some major failures, like Centerline's Code and ObjectCenter (interpretive environments (with interpreters, but you often just load compiled code on the fly) for C and C++ that are as close to a Lisp Machine as you could get for those languages).
Also, the $1,000 limit is undoubtedly too low, it's whatever your corporation allows you to spend without too much effort (e.g. CxO signoff). A few thousand dollars are OK, e.g. that's how PCs slipped into a lot of companies, on departmental but not corporate budgets. (Heck, that's how a few Z-80 CP/M machines slipped into LMI when we had at most 3 CADRs operational at a time and a strong bias against doing anything outside of a Lisp Machine.)
I would be surprised if they did go back on 3.3.1. They're hurting themselves with the backlash, yes, but they're hurting other mobile platforms far more, further securing their position as the #1 mobile platform to develop for.
That said, I'd be surprised if Apple spends too much effort policing the rule. The fact that it exists in the first place will probably be enough FUD to prevent third party toolkits from taking off at all. They'll probably do some kind of automated signature testing for Flash, Unity etc and leave it at that. The upside of that is you'd probably be able to sneak a Clojure or whatever app in and nobody would probably care too much.
That said, I'd be surprised if Apple spends too much effort policing the rule. The fact that it exists in the first place will probably be enough FUD to prevent third party toolkits from taking off at all. They'll probably do some kind of automated signature testing for Flash, Unity etc and leave it at that. The upside of that is you'd probably be able to sneak a Clojure or whatever app in and nobody would probably care too much.
It took me a few days to figure out why Apple would risk driving away developers like this, until I realized: That's the whole point.
Apple wants to drive away developers who are spreading their apps thin over multiple platforms. I think you're right that it's quite unlikely they will relent on this, at least on paper.
As for policing, I think you're also right that it won't be particularly onerous. I see enforcement less to the letter and more to the intention of 3.3.1: If your submitted app feels like a rough port, they'll probably check for cross-compiler evidence and reject it on those grounds, but if it fits right into the iPhone experience, they probably aren't going to go hunting for traces of Lisp.
Apple wants to drive away developers who are spreading their apps thin over multiple platforms. I think you're right that it's quite unlikely they will relent on this, at least on paper.
As for policing, I think you're also right that it won't be particularly onerous. I see enforcement less to the letter and more to the intention of 3.3.1: If your submitted app feels like a rough port, they'll probably check for cross-compiler evidence and reject it on those grounds, but if it fits right into the iPhone experience, they probably aren't going to go hunting for traces of Lisp.
I don't think it has to do with the quality of the applications at all. Apple hasn't taken many steps to control quality in their app store, and there's not much difference between having an app that's bad because it's a port and an app that's bad because it's a badly made original.
What is has to do is with lock in. Right now, there's a decent barrier to porting an application from iPhone to Android, and in most cases the port will cost more than the profit it makes, so it won't be done.
If people start using multi platform engines, the ports will be very cheap, and the iPhone will have far fewer exclusive apps, which is a huge threat to their platform. Each multiplatform app reduces the costs of a user switching away from the iPhone to an Android phone or similar.
Apple's been on the losing end of lock in with Mac OS for a long time. I think now they're experiencing the effect in their favour and want to keep it going for as long as they can.
What is has to do is with lock in. Right now, there's a decent barrier to porting an application from iPhone to Android, and in most cases the port will cost more than the profit it makes, so it won't be done.
If people start using multi platform engines, the ports will be very cheap, and the iPhone will have far fewer exclusive apps, which is a huge threat to their platform. Each multiplatform app reduces the costs of a user switching away from the iPhone to an Android phone or similar.
Apple's been on the losing end of lock in with Mac OS for a long time. I think now they're experiencing the effect in their favour and want to keep it going for as long as they can.
I think there is also another dynamic at play: Apple makes high-end, high-margin 'lifestyle' computing devices. Every time Steve Jobs gets up and announces a new whiz-bang hardware or software capability in one of these devices, that whiz-bang capability needs to be deployed as widely and quickly as possible into the consumer ecosystem. This rapid deployment lets Apple keep ahead of the Joneses and continue to own the high-end space. If there is a lag while least-common-denominator, cross-platform tools incorporate the new whiz-bang features, Apple loses its temporal edge and gives time to competitors to catch up. The last decade has built up the "Apple == newest" identity in consumers' minds, and they don't want to lose that, it is one of the keys to their hold on the high end (another being incredible design and polish, at scale).
If everyone is writing in Cocoa on XCode, Apple's latest & greatest will be deployed that much more quickly.
I think this interpretation is consistent with Jobs' terse emails here, particularly the line, "intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform" (emphasis mine).
If everyone is writing in Cocoa on XCode, Apple's latest & greatest will be deployed that much more quickly.
I think this interpretation is consistent with Jobs' terse emails here, particularly the line, "intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform" (emphasis mine).
At first I was thinking that Apple wasn't targeting the game engines with this, but they're releasing a social "Game Center" API to compete with Xbox live and Facebook.
Suddenly it matters very much indeed that lots of games start calling new platform-native APIs, right fucking now.
Suddenly it matters very much indeed that lots of games start calling new platform-native APIs, right fucking now.
I completely agree. Also this push more people to learn and write Cocoa, that will ultimately push those developers to build awesome desktop apps as well, increasing the value of the OS X platform.
After some reflection, I think you're definitely right that it's a factor. But I'd still be surprised if it were the primary one, despite what they claim. The developer base is just so huge, any new platform feature is going to have dozens of apps to show it off right away.
Saying that they're doing it to further their platform sounds a hell of a lot better than saying that they're doing it to hurt their competition!
Saying that they're doing it to further their platform sounds a hell of a lot better than saying that they're doing it to hurt their competition!
I agree this temporal aspect isn't the only dynamic, but I don't see people talking about it much (at all?). I think it's worth thinking about as an angle on the whole thing. Market tempo matters. Doesn't make what they're doing any more palatable, mind you -- but it does make it more comprehensible (to me, anyway).
I'm not sure how valid this point is...there is already going to be a lag since all of the current app developers are going to have to update their apps to support the new APIs anyway.
At best you could say that there won't be an intermediary platform delaying the process...but I'm not sure if that really is a compelling reason to justify this decision.
At best you could say that there won't be an intermediary platform delaying the process...but I'm not sure if that really is a compelling reason to justify this decision.
there is already going to be a lag
Without cross-compilers, the lag is as you say: developers update their apps. With cross-compilers, the lag balloons: the makers of the cross-compiler toolset need to incorporate the latest Apple features (if they choose to do so given the rest of their market), roll out their tools to developers, then developers have to use the new tools to update their apps. Slow!
Without cross-compilers, the lag is as you say: developers update their apps. With cross-compilers, the lag balloons: the makers of the cross-compiler toolset need to incorporate the latest Apple features (if they choose to do so given the rest of their market), roll out their tools to developers, then developers have to use the new tools to update their apps. Slow!
The problem with cross-development tools is that the people using them tend to focus on the app working on all the supported platforms, making it effectively using the lowest common denominator. If Apple releases a new API not available in the cross-platform tool, cross-developers are far more likely to ignore it than developers targeting Apple's platform specifically.
I would agree with you that Apple's been doing the same lock-in with Mac OS for a long time, but I'm not so sure they've been on the losing end of anything. I remember that when Jobs came back to Apple, they had free WWDC videos online, and attendance was very much in decline. Since he came back, they removed the Java bridge stuff, Carbon and at the same time they're charging good money for a WWDC that tends to sell out really quickly. Lock-in on the Apple way seems to me to be a fairly successful strategy.
I would agree with you that Apple's been doing the same lock-in with Mac OS for a long time, but I'm not so sure they've been on the losing end of anything. I remember that when Jobs came back to Apple, they had free WWDC videos online, and attendance was very much in decline. Since he came back, they removed the Java bridge stuff, Carbon and at the same time they're charging good money for a WWDC that tends to sell out really quickly. Lock-in on the Apple way seems to me to be a fairly successful strategy.
> They're hurting themselves (...) but they're hurting other mobile platforms far more.
That's true today because they're the main platform. This might change if, say, Android becomes much more widespread than iPhoneOS. When this happens, they might concede on things like 3.3.1.
Then again, Apple is quite comfortable with having minority share but huge profit margins in a market: I'd guess that 90% of laptops sold over $1000 are Apple, and that their margin is something like 5 times Dell's...
That's true today because they're the main platform. This might change if, say, Android becomes much more widespread than iPhoneOS. When this happens, they might concede on things like 3.3.1.
Then again, Apple is quite comfortable with having minority share but huge profit margins in a market: I'd guess that 90% of laptops sold over $1000 are Apple, and that their margin is something like 5 times Dell's...
That's true. I should clarify that I meant in the short term - definitely they'll change their position the minute it benefits them. But right now, it certainly doesn't.
If multi platform engines take off, we are a few short years away from a situation where the choice of mobile platforms is like the choice between browsers is now - no lock in, low switching costs - and I think they want to avoid that at all costs.
If multi platform engines take off, we are a few short years away from a situation where the choice of mobile platforms is like the choice between browsers is now - no lock in, low switching costs - and I think they want to avoid that at all costs.
Once 3G will be reliable and truly unlimited, what would cross-platform apps offer that web app don't anyway?
There is already a cross-platform, 100% uncensored dev framework, with excellent distribution channels, and it's called HTML5. I'm not sure there is a niche for a 2nd one, especially if Apple is unhelpful.
There is already a cross-platform, 100% uncensored dev framework, with excellent distribution channels, and it's called HTML5. I'm not sure there is a niche for a 2nd one, especially if Apple is unhelpful.
Native apps still enjoy a pretty hefty UI advantage over web apps. I don't see that changing in the next few years.
And it appears Apple won't be the one pushing it forward, despite all their work on webkit. Which is enough for me to jump ship when the time to get a new phone arrives.
Actually, I would prefer to put it the other way around: Once 3G will be reliable and truly unlimited, what would web apps offer that cross-platform app don't anyway? Give it some thought before answering.
Apple doesn't have to take web apps into consideration when they're considering changing the platform or the API however they see fit. They're committed to upholding open web standards, but have no similar commitment to their own API. HTML standards are slow to evolve by design, and Apple is okay with that, however that is the last thing they want with their own software stack.
Apple isn't focused on developing a smart phone operating system. They're focused on redefining what a computer IS, and how we interact with them. That's why they've been so careful about copy+paste, and later multi-tasking. They are taking this as a chance for a clean slate approach to computing and don't want to be hampered (or their customers to be hampered) by slow-moving third party compatibility layers. How much as Window's development hampered by the fear to break legacy apps compatibility moving forward? Apple isn't afraid to make their developers jump through hoops and make changes if they think it will benefit the platform in the end (a la the Intel switch). They'll provide tools to make that as painless as possible when the time comes (e.x. iPhone app compatibility on the iPad, Rosetta) but having another layer in between only slows this process down.
Whether you view Apple's actions as that momentous and revolutionary is largely irrelevant. I think THEY do.
Not that I'm not upset by this as well, but I'm trying to make sense of it.
Apple isn't focused on developing a smart phone operating system. They're focused on redefining what a computer IS, and how we interact with them. That's why they've been so careful about copy+paste, and later multi-tasking. They are taking this as a chance for a clean slate approach to computing and don't want to be hampered (or their customers to be hampered) by slow-moving third party compatibility layers. How much as Window's development hampered by the fear to break legacy apps compatibility moving forward? Apple isn't afraid to make their developers jump through hoops and make changes if they think it will benefit the platform in the end (a la the Intel switch). They'll provide tools to make that as painless as possible when the time comes (e.x. iPhone app compatibility on the iPad, Rosetta) but having another layer in between only slows this process down.
Whether you view Apple's actions as that momentous and revolutionary is largely irrelevant. I think THEY do.
Not that I'm not upset by this as well, but I'm trying to make sense of it.
Er, I wasn't talking about Apple, but software development in general.
As I see it, there are two elements that define the modern software: end-user experience (not only GUI, but things like local storage, geolocation etc), and communication with the Internet. With low bandwidth, Web apps have all the advantage with the latter and are good enough with the former; with ubiquitous broadband, the latter advantage is meling away, and the former just being "good enough" might not be, well, good enough anymore.
As I see it, there are two elements that define the modern software: end-user experience (not only GUI, but things like local storage, geolocation etc), and communication with the Internet. With low bandwidth, Web apps have all the advantage with the latter and are good enough with the former; with ubiquitous broadband, the latter advantage is meling away, and the former just being "good enough" might not be, well, good enough anymore.
As a developer, I might prefer to write local apps. As a user, the zero install + security guarantees make web apps much preferable. Plus, given that cross-platform toolkits only offer the lowest common denominator, the resulting applications typically don't look better than a good web app.
Moreover, repeated installations and deinstallations degrade a computer's performances and security. It's much more obvious under Windows than under correctly designed OSes, but always remains true.
I expect a 95% web-based slate/phone to be mostly stateless, and to remain functional indefinitely without requiring administration, as opposed to a computer.
Moreover, repeated installations and deinstallations degrade a computer's performances and security. It's much more obvious under Windows than under correctly designed OSes, but always remains true.
I expect a 95% web-based slate/phone to be mostly stateless, and to remain functional indefinitely without requiring administration, as opposed to a computer.
I think Apple feared that more third-party toolkits are on the way, and that they'll become more popular.
I don't think is it. I remember when Metrowerks PowerPlant was the main framework. Apple had let their own MacApp and MPW languish. Arguably Metrowerks CodeWarrior saved the Mac as a development platform.
I don't think is it. I remember when Metrowerks PowerPlant was the main framework. Apple had let their own MacApp and MPW languish. Arguably Metrowerks CodeWarrior saved the Mac as a development platform.
It's funny, his main example of a "high quality cross platform app" was Mozilla Firefox. In my opinion, Mozilla Firefox is a prime example of why the intermediate layers (if Firefox uses one, I'm not sure) and the cross platform stuff is a bad idea. It uses its own weird certificate store instead of using the operating system's, its interface does not have a Cocoa feel in any sense of the term, etc.
But we're talking about whether cross platform apps are of such a low quality that banning that outright is a good thing, how can anyone suggest Firefox isn't a counter example to that?! Compare Firefox to the average App Store offering and I think its obvious that this Section 3.1.1 is bullshit. This move by Apple is just an attack on Adobe that is catching innocent developers in the crossfire.
I doubt we'll see Firefox using Grand Central Dispatch, OpenCL, Core Data or any other of a number of APIs available for the Mac platform anytime soon. Because even if Firefox pretends to really well, first-class citizen of Mac OS X it ain't.
Firefox may not have a Cocoa feel but he prefers it over Safari anyway since it serves him better. So apparently native look 'n feel isn't all that for some people in their choice of applications.
I feel the same way about Safari on my iPhone. I quickly ditched that for a better browser.
I feel the same way about Safari on my iPhone. I quickly ditched that for a better browser.
XUL+Javascript is the UI intermediary.
There are a great number of application that does not have a native look and feel, does not use built-in resources from the operating systems that I use and yet I think they are great (Firefox, Vim, Apache Directory Studio), even WebKit (and WebKit2) is a cross platform layer on top of WebCore[1][2].
[1]: http://trac.webkit.org/wiki/HighLevelOverview
[2]: http://trac.webkit.org/wiki/WebKit2
[1]: http://trac.webkit.org/wiki/HighLevelOverview
[2]: http://trac.webkit.org/wiki/WebKit2
No, if anything, Firefox is proof that you can write a bad 'native application' in C directly with the APIs provided by the OS. It's entirely possible to write something that is more native than Firefox but is based on another language, like Ruby, a Lisp, ML, etc.
Firefox isn't written directly on top of the OS APIs. It's written on top of NSPR (Netscape Portable Runtime) on the bottom, with layers of more compat piled on top.
It's more accurate to say that Firefox 3.6 is written on top of the Mozilla 1.9.1 platform, which includes technologies such as NSPR or XPCOM for some low level system interaction. I don't think anything at the UI rendering level uses those technologies.
And NSPR is written in C as a thin layer over the OS APIs. Just because it's C doesn't magically imbue whatever uses it with super-awesome-native qualities.
When Steve Jobs got a demo of the graphical user interface and object-oriented software at Xerox PARC, he saw a computer that could be interactively programmed. In Smalltalk.
When Steve Jobs started with NeXT in the mid 80s he got a demo of a novel program that can be used to interactively design general user interfaces - the first program of its kind.
It was written in Lisp by Jean-Marie Hullot. It was called SOS Interface, marketed also as Action! by the company Expertelligence.
Steve Jobs hired him and Jean-Marie created the Interface Builder - which became one of the most important tool on NeXT OS. Then for Mac OS X and now for iPhone OS.
This innovation is now hindered by Apple. The innovative software may not be written in Lisp anymore, but it is not necessarily Objective-C either.
With the Mac everybody got a copy of HyperCard - everybody could write and design programs in a simple way - using the built-in HyperTalk. Xerox had such a software years before - called NoteCards and written in InterLisp-D.
With the iPad, which is much more capable than the Mac where SOS Interface and HyperCard were developed, everybody is degraded to be a consumer. The goal is no longer to be a maker, a creator, a programmer. You can't even use a shell to connect to your own iPad.
There is huge domain of visual programming and end user programming to be explored on touch screen devices. Maybe Apple is working on that and hiding this (like Jobs claimed that 'nobody reads anymore' and some time later Apple now sells iBooks) - from what we see now Apple hinders innovation and innovators in these areas.
I want a 'DynaBook' and not a media player.
Steve Jobs did not really understand what he saw at Xerox PARC when he got the demos of the Smalltalk system. He got the idea of the graphical user interface. But what he overlooked was the concept of object-oriented programming. He later with NeXT understood that. But what he never really got was the importance of interactive programming, end-user programming - the role of the user being able to program his computer in a straight-forward way. The cultural importance of being able to write, understand and change software.
When Steve Jobs started with NeXT in the mid 80s he got a demo of a novel program that can be used to interactively design general user interfaces - the first program of its kind.
It was written in Lisp by Jean-Marie Hullot. It was called SOS Interface, marketed also as Action! by the company Expertelligence.
Steve Jobs hired him and Jean-Marie created the Interface Builder - which became one of the most important tool on NeXT OS. Then for Mac OS X and now for iPhone OS.
This innovation is now hindered by Apple. The innovative software may not be written in Lisp anymore, but it is not necessarily Objective-C either.
With the Mac everybody got a copy of HyperCard - everybody could write and design programs in a simple way - using the built-in HyperTalk. Xerox had such a software years before - called NoteCards and written in InterLisp-D.
With the iPad, which is much more capable than the Mac where SOS Interface and HyperCard were developed, everybody is degraded to be a consumer. The goal is no longer to be a maker, a creator, a programmer. You can't even use a shell to connect to your own iPad.
There is huge domain of visual programming and end user programming to be explored on touch screen devices. Maybe Apple is working on that and hiding this (like Jobs claimed that 'nobody reads anymore' and some time later Apple now sells iBooks) - from what we see now Apple hinders innovation and innovators in these areas.
I want a 'DynaBook' and not a media player.
Steve Jobs did not really understand what he saw at Xerox PARC when he got the demos of the Smalltalk system. He got the idea of the graphical user interface. But what he overlooked was the concept of object-oriented programming. He later with NeXT understood that. But what he never really got was the importance of interactive programming, end-user programming - the role of the user being able to program his computer in a straight-forward way. The cultural importance of being able to write, understand and change software.
With the Mac everybody got a copy of HyperCard
Existence of iPad (and iPhone) does not hinder innovation — it fosters it. Three years ago there was no iPhone, no iPhone OS, no App Store. Now we have a new platform with not far from 200 000 (just think about it) applications written for it. iPad gives an opportunity truly explore what's possible on multitouch device with dedicated UI.
I am a web developer, but I do not complain that I cannot easily write my code in the browser itself. Nor do I want to.
Just think about it: if there were no iPad you could not code for it even in Obj-C.
I'm not talking about programming on the Mac, I'm talking about the iPhone OS and devices like the iPad.
I need a Mac to program the iPad? Why?
We needed a LISA to program the Mac in 1984. The Mac had 128kbyte of RAM and couldn't do much.
The iPad has 256MB RAM, a multitasking OS based on Unix - I want to see end-user programming on the touch screen. Not a generation of link clickers.
We have 2010.
I want a better EMAIL program for my iPhone (or something like the iPad). I don't get it. Apple does not allow that. WHY? It can't even filter mails. We had that twenty years ago.
I need a Mac to program the iPad? Why?
We needed a LISA to program the Mac in 1984. The Mac had 128kbyte of RAM and couldn't do much.
The iPad has 256MB RAM, a multitasking OS based on Unix - I want to see end-user programming on the touch screen. Not a generation of link clickers.
We have 2010.
I want a better EMAIL program for my iPhone (or something like the iPad). I don't get it. Apple does not allow that. WHY? It can't even filter mails. We had that twenty years ago.
"I need a Mac to program th iPad. Why?"
Holy moly! Are you mad because a TV isn't a video camera? Are you mad because a plate isn't a frying pan?
The iPad is a consumption device. It's a new thing. I've had it for a week now. I know that it's not going to replace a real computer. But it is absoulutely great for what it is. I wouldn't want to program on it (as things stand). It's acceptable for writing short texts, that's about it for now.
And this has nothing to do with the 3.3.1 controversy. There are a number of things that you can take Apple to task for, but this isn't one of them.
Holy moly! Are you mad because a TV isn't a video camera? Are you mad because a plate isn't a frying pan?
The iPad is a consumption device. It's a new thing. I've had it for a week now. I know that it's not going to replace a real computer. But it is absoulutely great for what it is. I wouldn't want to program on it (as things stand). It's acceptable for writing short texts, that's about it for now.
And this has nothing to do with the 3.3.1 controversy. There are a number of things that you can take Apple to task for, but this isn't one of them.
Making a traditional TV in to a video camera would require adding hardware (capture, storage) at significant cost. Incidentally, Apple did turn the TV in to a video camera[0].
Turning the iPad in to a platform where children could explore programming with Squeak, eToys or some as-yet unreleased environment would only require that Apple not actively prevent it.
[0] http://www.apple.com/ipodnano/
Turning the iPad in to a platform where children could explore programming with Squeak, eToys or some as-yet unreleased environment would only require that Apple not actively prevent it.
[0] http://www.apple.com/ipodnano/
"I wouldn't want to program on it (as things stand). It's acceptable for writing short texts, that's about it for now."
There seems to be an presupposition there that programming must involve lots of typing. If so, it is a false one.
There seems to be an presupposition there that programming must involve lots of typing. If so, it is a false one.
I haven't seen a good 5th generation language that does visual programming well yet. Even the wonderful morphic libraries on Squeak or the ALICE virtual world still require lots of typing.
Why did the goal posts for my point in the conversation suddenly get moved to 5GL? That feels like a bit of a disingenuous reply.
Technically, yes you can have a better mail program. You just might not be approved to sell it once you create it using XCode. If you are serious about this, start with reMail. reMail has implemented a lot of features and solved a lot of thorny email client implementation issues.
"As someone who is passionate about mobile email, my hope is that developers interested in making email-related apps can use reMail code as a starting point. Part of the reason email apps are hard is because you have to pay the tax of figuring out how to download email via IMAP, parse MIME messages, handle attachments, and store data. reMail has already solved these problems. If you have a great mobile email idea, I hope you will find reMail's source code helpful in your quest."
http://www.remail.com/blog/
http://code.google.com/p/remail-iphone
"As someone who is passionate about mobile email, my hope is that developers interested in making email-related apps can use reMail code as a starting point. Part of the reason email apps are hard is because you have to pay the tax of figuring out how to download email via IMAP, parse MIME messages, handle attachments, and store data. reMail has already solved these problems. If you have a great mobile email idea, I hope you will find reMail's source code helpful in your quest."
http://www.remail.com/blog/
http://code.google.com/p/remail-iphone
http://gizmodo.com/5053232/apple-rejects-mailwrangler-app-fo...
'… Your application duplicates the functionality of the built-in iPhone application Mail without providing sufficient differentiation or added functionality, which will lead to user confusion. …'
'… Your application duplicates the functionality of the built-in iPhone application Mail without providing sufficient differentiation or added functionality, which will lead to user confusion. …'
Twenty years ago you did not have a handheld device that read your emails.
Depends what you call a handheld device. The Osborne-1 from 1981, one of the first portable computers had an email program. Handheld computers started in the early 90s and some had email capabilities. For Apple's own Newton there was a bunch of email clients.
"I need a Mac to program the iPad? Why?"
You need a computer to transfer data to it, so why not to program it? Yes, the toolchain is not available for windows, but that's at least understandable. The iPad is not currently marketed as a stand-alone device.
You need a computer to transfer data to it, so why not to program it? Yes, the toolchain is not available for windows, but that's at least understandable. The iPad is not currently marketed as a stand-alone device.
From what I can tell, you MUST connect it to iTunes before it even allows you pass the "Connect me to iTunes on your computer" screen. I thought it was unneeded and should have had a "remind me later" at the very least (I didn't buy one, just set one up). Regardless, almost anyone that wants an iPad will have a computer - and the benefit of having a "import everything" option is huge.
You are a very small minority.
You are in a very small minority... of people who get it.
I have nothing against consumer electronics devices, but they're about consuming. The promise of computers is in creation.
Steve Jobs took Alan Kay's work, but not his ideas. The promise of the Dynabook isn't about hardware, but a change in how we create software. That change is coming, and that's the change to get excited about.
I have nothing against consumer electronics devices, but they're about consuming. The promise of computers is in creation.
Steve Jobs took Alan Kay's work, but not his ideas. The promise of the Dynabook isn't about hardware, but a change in how we create software. That change is coming, and that's the change to get excited about.
You're not presenting any amount of believable evidence here to prove your point. Your quip of "You don't get it!" doesn't pass the muster.
Yes, computers promise creation. But this creation isn't always developing software. A device can simply create entertainment.
I hate to break it to you, buddy, but you've become saturated in your community. It's very hard from that point to see how very small your pool is.
Yes, computers promise creation. But this creation isn't always developing software. A device can simply create entertainment.
I hate to break it to you, buddy, but you've become saturated in your community. It's very hard from that point to see how very small your pool is.
A device can simply create entertainment.
No, a device shows entertainment. And people consume it. Creation means that the end user has something new when they're done. Not that they've just passed the time.
And you're ad hominem attack on being saturated in your community was most likely a projection, buddy.
And you're ad hominem attack on being saturated in your community was most likely a projection, buddy.
You don't need a Mac. You can write web apps for it on any platform.
And this is exactly what Apple wants us to think; be in awe of the favor that they are doing developers. This is an abusive relationship to say the least.
The false dichotomy is the assumption that since Apple makes two portable devices, one that creates content (Macbook) and another that consumes it (iPhone/iPad), that there must be two kinds of people, content creators and content consumers.
There is no reason not to own a laptop and a tablet for much teh same reason that many people own an iPod and an iPhone and a laptop.
In my own case, I own a laptop for development, a mini for displaying media on my 37" display at home, an iPhone for calls and portable content consumption, and an iPod Classic for music in my car.
All of these together cost less than my first development system. I think that people who want to create content and programs will do so, and the iPad does nothing to hinder them.
There is no reason not to own a laptop and a tablet for much teh same reason that many people own an iPod and an iPhone and a laptop.
In my own case, I own a laptop for development, a mini for displaying media on my 37" display at home, an iPhone for calls and portable content consumption, and an iPod Classic for music in my car.
All of these together cost less than my first development system. I think that people who want to create content and programs will do so, and the iPad does nothing to hinder them.
Don't you think the fact that iPad SDKs and programming tutorials are readily available from Apple, plus the fact that Apple still sell Macs which interface with the iPad (but which they obviously don't want the iPad to render obsolete), contradicts your vision of the present trend? I mean the iPhone surely spurned a HUGE number of people to become (in your terms) 'creators' - and that was before non-Apple developer tools were even on the table.
The effect is that people are divided into developers/content providers/media providers and consumers.
It is not (D),(C); it is (C (D)).
We are all consumers, just some happen to be developers.
No, consumers are not developers on the iPad.
You can't program filters for the Email program. The Email program is neither open source nor scriptable. You can't program formulas for the calculator. The people who program for iPhone OS are doing it in a completely different stage and environment. I can't just log into MY iPhone and change a program.
You can't program filters for the Email program. The Email program is neither open source nor scriptable. You can't program formulas for the calculator. The people who program for iPhone OS are doing it in a completely different stage and environment. I can't just log into MY iPhone and change a program.
I just don't see the iPad as replacement for anything. And I was not talking about it specifically in my comment.
My personal and work accounts are both using GMail. I don't have the source of it, I cannot just login and change id, but I do not care. You can get a bunch of programmable calculators in App Store, or just get Numbers and use all the formulas it offers. My car probably has a couple dozens of CPU which I have no interest to program for. My TV probably runs linux, but I am not going to hack it. Most likely I will program for iPad, but I'd hate to do it on iPad. I love to eat soup with a spoon, but I'd hate to carve spoon with a spoon.
My personal and work accounts are both using GMail. I don't have the source of it, I cannot just login and change id, but I do not care. You can get a bunch of programmable calculators in App Store, or just get Numbers and use all the formulas it offers. My car probably has a couple dozens of CPU which I have no interest to program for. My TV probably runs linux, but I am not going to hack it. Most likely I will program for iPad, but I'd hate to do it on iPad. I love to eat soup with a spoon, but I'd hate to carve spoon with a spoon.
That you don't want to program on the iPad does not mean others don't want that too. It does not even mean that you won't want it in the future.
But there is no choice. You are at the merci of Apple.
Other people want a different entertainment system in their car.
With Apple you can't - you can't replace iTunes on your phone.
But there is no choice. You are at the merci of Apple.
Other people want a different entertainment system in their car.
With Apple you can't - you can't replace iTunes on your phone.
I think you are confusing developers (for the platform) and tinkerers
Stop thinking of the iPhone/iPad as if they're just small Macs. They are neither general purpose computers, nor are they RAD platforms. They're consumer devices with restricted capabilities and resources.
No innovation has been hindered, in fact it has been enabled. Smalltalk, SOS and others are tools that make certain kinds of experiment easier.
I remember when RAD tools were only meant for building prototypes, with the assumption that the program would be rewritten in a conventional language afterwards. They only became the delivery environment after consumer machines gained so much RAM and CPU power that the benefits of optimization became negligible.
Well, these are cell phones, batteries with CPUs. We're back in the 80s again. Section 3.3.1 does not prohibit anyone from developing iPhone software with whatever cross-compiler or funky toolkit they like, it only prevents them from deploying the output to consumers through the App Store.
No innovation has been hindered, in fact it has been enabled. Smalltalk, SOS and others are tools that make certain kinds of experiment easier.
I remember when RAD tools were only meant for building prototypes, with the assumption that the program would be rewritten in a conventional language afterwards. They only became the delivery environment after consumer machines gained so much RAM and CPU power that the benefits of optimization became negligible.
Well, these are cell phones, batteries with CPUs. We're back in the 80s again. Section 3.3.1 does not prohibit anyone from developing iPhone software with whatever cross-compiler or funky toolkit they like, it only prevents them from deploying the output to consumers through the App Store.
>like Jobs claimed that 'nobody reads anymore' and some time later Apple now sells iBooks
The point Jobs was making was that a device used exclusively for reading would never be successful. He wasn't suggesting that it would be pointless to participate in the ebook market, just that it would need to be on a general purpose mobile platform.
The point Jobs was making was that a device used exclusively for reading would never be successful. He wasn't suggesting that it would be pointless to participate in the ebook market, just that it would need to be on a general purpose mobile platform.
Jobs on why the Kindle will fail:
“It doesn’t matter how good or bad the product is, the fact is that people don’t read anymore,” he said. “Forty percent of the people in the U.S. read one book or less last year. The whole conception is flawed at the top because people don’t read anymore.”
I'm not sure I can read your interpretation into it.
From what I read, Jobs says that 'people' don't read anymore - even books on paper. So it is useless to bring books in any new ebook form, because the market is not there. Books in general is an outdated concept according to Jobs at that time.
“It doesn’t matter how good or bad the product is, the fact is that people don’t read anymore,” he said. “Forty percent of the people in the U.S. read one book or less last year. The whole conception is flawed at the top because people don’t read anymore.”
I'm not sure I can read your interpretation into it.
From what I read, Jobs says that 'people' don't read anymore - even books on paper. So it is useless to bring books in any new ebook form, because the market is not there. Books in general is an outdated concept according to Jobs at that time.
In addition to up voting you I would like to add that this is a pattern. Steve Jobs dishes some use then provides for it. Perhaps the interpretations are:
1. Misdirection or
2. Change of mind (being wrong).
So, I can understand why developers dislike and hackers despise the new 3.3.1 rules. What programmer, in their right mind, wants to have the language they develop in dictated to them?
But, for just a moment, I'm hoping that some of you can appreciate how miserable an experience Apple users have had with the couple decades of various levels of cross-platform development that Microsoft has done.
At times, those applications have been _so_ bad as to be an advertisement for windows. I'm an Apple fanboy, and own three generations of Apple MBPs, three iPhones, and, of course, an iPad - but to this day, at work, I still keep a 2003 class Windows XP system with Microsoft Excel on it to get work done - The painful experience that is Office 2008, (and don't get me started on "NeoOffice") single handedly make me appreciate the fact that Apple is dictating that people write dedicated, high quality applications, directly for the iPhoneOS, rather than trying to do some crufty translation to that platform.
When I read Jobs's response, I could only imagine that he was having bad flashbacks to some of the x-platform disasters of years past.
I appreciate and respect that developers don't want to be told how to develop, but if the end result is that the few development shops out there capable of putting out a AAA title like Microsoft Excel, have to pony up a few more developer resources and put out a world class app directly for the iPhone OS, rather than just creating some half-baked x-platform experience, I'm in favor of 3.3.1.
But, for just a moment, I'm hoping that some of you can appreciate how miserable an experience Apple users have had with the couple decades of various levels of cross-platform development that Microsoft has done.
At times, those applications have been _so_ bad as to be an advertisement for windows. I'm an Apple fanboy, and own three generations of Apple MBPs, three iPhones, and, of course, an iPad - but to this day, at work, I still keep a 2003 class Windows XP system with Microsoft Excel on it to get work done - The painful experience that is Office 2008, (and don't get me started on "NeoOffice") single handedly make me appreciate the fact that Apple is dictating that people write dedicated, high quality applications, directly for the iPhoneOS, rather than trying to do some crufty translation to that platform.
When I read Jobs's response, I could only imagine that he was having bad flashbacks to some of the x-platform disasters of years past.
I appreciate and respect that developers don't want to be told how to develop, but if the end result is that the few development shops out there capable of putting out a AAA title like Microsoft Excel, have to pony up a few more developer resources and put out a world class app directly for the iPhone OS, rather than just creating some half-baked x-platform experience, I'm in favor of 3.3.1.
> I appreciate and respect that developers don't want to be told how to develop, but if the end result is that the few development shops out there capable of putting out a AAA title like Microsoft Excel, have to pony up a few more developer resources and put out a world class app directly for the iPhone OS, rather than just creating some half-baked x-platform experience, I'm in favor of 3.3.1.
Well, OK, but the other possibility is that the executives at the few development shops out there capable of putting out a AAA title take one look at Apple's terms, observe that their entire investment could be arbitrarily yanked by another commercial organisation without compensation, kill the iPhone/iPad development before it starts, and target more open platforms that don't come with the same absurd levels of risk instead.
In the long run, the developers will always win, because someone will always make a platform where good developers can write good software, and then people will buy that platform to get that software. On the other hand, no-one cares about the platform, even if it's Apple, once the initial "Oh, shiny!" moment wears off and you actually have to get stuff done.
Well, OK, but the other possibility is that the executives at the few development shops out there capable of putting out a AAA title take one look at Apple's terms, observe that their entire investment could be arbitrarily yanked by another commercial organisation without compensation, kill the iPhone/iPad development before it starts, and target more open platforms that don't come with the same absurd levels of risk instead.
In the long run, the developers will always win, because someone will always make a platform where good developers can write good software, and then people will buy that platform to get that software. On the other hand, no-one cares about the platform, even if it's Apple, once the initial "Oh, shiny!" moment wears off and you actually have to get stuff done.
Aren't there just as many, if not more, that will stay on iPhone (since it's where the money is) and use only approved tools? AAA-capable shops will build where the money is. There's been a LOT of controversy about Apple's terms in the last two years and I don't know of a single example of a AAA moving off the platform and onto a competing one.
What's more likely is that they'll build a native iPhone version and use a cross-platform toolkit or HTML to build for the other mobile platforms.
What's more likely is that they'll build a native iPhone version and use a cross-platform toolkit or HTML to build for the other mobile platforms.
> Aren't there just as many, if not more, that will stay on iPhone [...] AAA-capable shops will build where the money is.
Well, that's the question, isn't it? I would argue that the AAA shops will ultimately define where the money goes in the long term. Early adopters buy based on platform hype, but what really attracts users is good applications.
> There's been a LOT of controversy about Apple's terms in the last two years and I don't know of a single example of a AAA moving off the platform and onto a competing one.
I'm not sure any mobile applications have reached AAA level yet. It takes time, research and evolution to achieve that kind of status. But it also takes the right development team seizing the opportunity, and that in turn requires that team to be looking in the first place.
Well, that's the question, isn't it? I would argue that the AAA shops will ultimately define where the money goes in the long term. Early adopters buy based on platform hype, but what really attracts users is good applications.
> There's been a LOT of controversy about Apple's terms in the last two years and I don't know of a single example of a AAA moving off the platform and onto a competing one.
I'm not sure any mobile applications have reached AAA level yet. It takes time, research and evolution to achieve that kind of status. But it also takes the right development team seizing the opportunity, and that in turn requires that team to be looking in the first place.
> an experience Apple users have had with the couple decades of various levels of cross-platform development that Microsoft has done.
I'm not sure that proves your point here. Microsoft has had a Mac development team since the very first Macintosh. They write native software that is not a port of the Windows versions. In the past, IE for the Mac actually had more features (and was more standards compliant) than the Windows version. All this proves is that, yes, native apps can be crap. Which is exactly why this rule is entirely pointless. It's the not the development tool that matters, it's the developer.
> single handedly make me appreciate the fact that Apple is dictating that people write dedicated, high quality applications, directly for the iPhoneOS, rather than trying to do some crufty translation to that platform.
They're also eliminating any other tool or language which can also be written directly for the iPhone OS. Something like MonoTouch uses the iPhone API directly, it just happens to allow developers to use C# instead of Objective-C. No translation necessary.
Even Adobe Flash apps being recompiled for the iPhone isn't a big deal. A high quality Flash game like Bejeweled, for example, is going work great on the iPhone if Adobe did their job right. That is an opportunity for you to have apps you wouldn't otherwise have and it's not wasting programmer resources rewriting it to achieve the same result for nothing.
Rule 3.3.1 does not mandate high quality applications. If you want that, make Apple use their approval process for that instead of their own selfish interests. This rule does nothing to give you want you want.
I'm not sure that proves your point here. Microsoft has had a Mac development team since the very first Macintosh. They write native software that is not a port of the Windows versions. In the past, IE for the Mac actually had more features (and was more standards compliant) than the Windows version. All this proves is that, yes, native apps can be crap. Which is exactly why this rule is entirely pointless. It's the not the development tool that matters, it's the developer.
> single handedly make me appreciate the fact that Apple is dictating that people write dedicated, high quality applications, directly for the iPhoneOS, rather than trying to do some crufty translation to that platform.
They're also eliminating any other tool or language which can also be written directly for the iPhone OS. Something like MonoTouch uses the iPhone API directly, it just happens to allow developers to use C# instead of Objective-C. No translation necessary.
Even Adobe Flash apps being recompiled for the iPhone isn't a big deal. A high quality Flash game like Bejeweled, for example, is going work great on the iPhone if Adobe did their job right. That is an opportunity for you to have apps you wouldn't otherwise have and it's not wasting programmer resources rewriting it to achieve the same result for nothing.
Rule 3.3.1 does not mandate high quality applications. If you want that, make Apple use their approval process for that instead of their own selfish interests. This rule does nothing to give you want you want.
"Microsoft has had a Mac development team since the very first Macintosh. They write native software that is not a port of the Windows versions."
Minor nit: these two statements are true separately, but misleading together. Many of MS's early Mac programs were written to a bytecoded abstraction layer. The results were distinctly non-Mac-like, which is why MS eventually switched to fully native apps.
IIRC, this was true from the very beginning, while Jobs was still in charge the first time. Here's an anecdote from Andy Hertzfeld that mentions the abstraction layer in passing:
http://www.folklore.org/StoryView.py?project=Macintosh&s...
Minor nit: these two statements are true separately, but misleading together. Many of MS's early Mac programs were written to a bytecoded abstraction layer. The results were distinctly non-Mac-like, which is why MS eventually switched to fully native apps.
IIRC, this was true from the very beginning, while Jobs was still in charge the first time. Here's an anecdote from Andy Hertzfeld that mentions the abstraction layer in passing:
http://www.folklore.org/StoryView.py?project=Macintosh&s...
I would not consider Firefox to be a "top-notch" Mac app. Every time I used it it felt slow, awkward, and clunky. I'd even find myself using non-native keyboard shortcuts (despite the native ones being available; e.g. F5 vs. Cmd+R) simply because it took me out of the "Mac native" world. No matter how close its emulation came there was always something to throw me off, mostly little GUI idiosyncrasies.
It's not good on Windows either. It still better than IE though, but way behind Google Chrome. Chrome is fast and when I browse, I want to quickly scan pages and run JavaScript.
FireFox exists in my desk only because it has FireBug and a couple of other web dev. tools.
FireFox exists in my desk only because it has FireBug and a couple of other web dev. tools.
Actually, the web development tools and the JavaScript debugger in recent Chrome betas are starting to get really good, almost as good as FireBug and even better in some respects. You should definitely give it a try.
Actually, I only use FireBug for debugging JavaScript. For CSS, there is nothing like Stylizer. Just give it a try and you'll never use another tool.
Firefox was my default browser on Windows since v. 0.6 when it wasn't a Firefox yet but Phoenix.
It was still my default when I switched to Mac, but with the
release of Safari 3 Firefox was relegated to development/tools role. I'd say the only area it beats Safari is extensions. Alas, Chrome also has those now. When Web Inspector matches Firebug, my usage of FF will be for testing only :(
Strange,
I use Firefox but rely on Safari for debugging web apps because I find the web inspector more practical to use, especially for CSS issues.
And yet, I'm writing this from FF on OS X right now because the awesomebar is just that damn good.
I've actually seen the benefits of the cross-platform approach first-hand, too. I've copied my same profile from mac to linux to windows and it Just Worked every time, extensions and all.
I've actually seen the benefits of the cross-platform approach first-hand, too. I've copied my same profile from mac to linux to windows and it Just Worked every time, extensions and all.
Well, at least we know he's listening and is concerned enough to respond to the criticism. Where this leads will be interesting to see, it's only been two days after all.
Thanks for emailing him.
Thanks for emailing him.
You know they are worried when they are using their PR backchannel. (But damn, what a great tool from a PR perspective.)
(I don’t really know whether Firefox is such a good example. It’s a great program because it first challenged IE, not because it’s anything close to a native feeling app. There must be better examples out there, right?)
(I don’t really know whether Firefox is such a good example. It’s a great program because it first challenged IE, not because it’s anything close to a native feeling app. There must be better examples out there, right?)
I don't think they're "worried". They may be a generally secretive company, but Steve has been replying to a lot of emails in the last few months. I'm not surprised to hear about someone else hearing from him, although I can't recall the last time someone emailed Steve about a developer issue specifically.
The only time I remember them reaching out to developers was a while back when app rejections were getting out of hand, and Phil Schiller (SVP of Worldwide Product Marketing) started making the press rounds to say that Apple was working to improve the situation (e.g., http://daringfireball.net/2009/08/phil_schiller_app_store)
The only time I remember them reaching out to developers was a while back when app rejections were getting out of hand, and Phil Schiller (SVP of Worldwide Product Marketing) started making the press rounds to say that Apple was working to improve the situation (e.g., http://daringfireball.net/2009/08/phil_schiller_app_store)
Everyone fears The Ignorant Boss
For developers, this is the person who knows nothing about programming yet insists that you use X tool and write it in Y language.
The author seems to imply that either Steve Jobs or Apple itself "knows nothing about programming". That seems wholly unfair, especially for Apple, and even for Steve. Obviously Apple employs some very talented programmers, or else we wouldn't be here talking about the iPhone. But surely Steve has a working understanding of the issue? Compared to Wozniak, he may have been the less technical of the two, but reviewing his history at Apple, Pixar, and NeXT, I think we can agree that he has a much better understanding of his products than many CEOs.
Apple knows what they're doing. As usual, they are just very conservative and arrogant, which I'm personally OK with (in general) because they make great products.
For developers, this is the person who knows nothing about programming yet insists that you use X tool and write it in Y language.
The author seems to imply that either Steve Jobs or Apple itself "knows nothing about programming". That seems wholly unfair, especially for Apple, and even for Steve. Obviously Apple employs some very talented programmers, or else we wouldn't be here talking about the iPhone. But surely Steve has a working understanding of the issue? Compared to Wozniak, he may have been the less technical of the two, but reviewing his history at Apple, Pixar, and NeXT, I think we can agree that he has a much better understanding of his products than many CEOs.
Apple knows what they're doing. As usual, they are just very conservative and arrogant, which I'm personally OK with (in general) because they make great products.
The author seems to imply that either Steve Jobs or Apple itself "knows nothing about programming". That seems wholly unfair, especially for Apple, and even for Steve.
It is, however, fair to say that Jobs is overlooking some very basic computer science. There is no reason why a tool like Flash can't emit Objective C, and there is no guaranteed way for an app reviewer to tell the difference.
It is, however, fair to say that Jobs is overlooking some very basic computer science. There is no reason why a tool like Flash can't emit Objective C, and there is no guaranteed way for an app reviewer to tell the difference.
Just a cursory look at what's going on with the new virtual memory system seems to indicate that writing apps that follow the rules enough to work correctly will be an interesting enough problem even _using_ Apple's tools and libraries.
But this issue is mostly about control, both of developer promiscuity and usage of system resources. Blocking developers' cross-platform plans is probably just a bonus. Apple could certainly solve any technical issues if it felt it was worth the effort and in its best interests.
Apple does not feel it is in its best interests... And for now, they are probably right.
But this issue is mostly about control, both of developer promiscuity and usage of system resources. Blocking developers' cross-platform plans is probably just a bonus. Apple could certainly solve any technical issues if it felt it was worth the effort and in its best interests.
Apple does not feel it is in its best interests... And for now, they are probably right.
[deleted]
The quality argument is bunk, in a very obvious way. Apple reviews each individual app anyway before it can enter the App Store. In other words, given a review of an individual app, the original platform and the app's quality are d-separated (in the Bayes Net sense).
Agreed, Apple doesn't need any reasons to kill an app. Conversely, they have the ability to "save" an app that doesn't respect TOS.
Yet the TOS are useful, as a good set of guidelines: TOS compliance is very strongly correlated with chances of having your app accepted.
Yet the TOS are useful, as a good set of guidelines: TOS compliance is very strongly correlated with chances of having your app accepted.
I think it's their way of getting the word out.
You can look at it this way: Apple will have less apps to review :)
Simply because it's against the agreement doesn't mean people won't attempt to submit offending applications (especially considering we don't yet know what the limits are). Using private APIs is against the agreement too, but that hasn't stopped a lot of developers from using them and submitting to the store. Some have even made it by the App Store reviewers.
And, obviously, such a meta-platform would be out of Apple’s control. Consider a world where some other company’s cross-platform toolkit proved wildly popular. Then Apple releases major new features to iPhone OS, and that other company’s toolkit is slow to adopt them. At that point, it’s the other company that controls when third-party apps can make use of these features.
This has happened before. It's called the web, and it's beautiful. Slow to adopt? Hells yes. But I love it because it runs everywhere.
This has happened before. It's called the web, and it's beautiful. Slow to adopt? Hells yes. But I love it because it runs everywhere.
The web is many things, but it is _not_ beautiful. It is a mess. It happened by accident, evolved beyond anyone's control and is now a beast loose upon the world. Unlovely in the extreme.
And it does _not_ run everywhere. With lots of work, you can make it run a lot of places; enough to be worth the effort. It is certainly useful, but not _nearly_ as useful as it could be.
Ted Nelson, who created the term hypertext, famously said, "HTML is precisely what we were trying to PREVENT-- ever-breaking links, links going outward only, quotes you can't follow to their origins, no version management, no rights management."
While politically I myself am very much in favor of open standards, for reasons I shouldn't have to explain _here_, I'm also vastly disappointed in the quality of most of the results, if from no other viewpoint than a human factors one. Like the talking dog, proponents seem happy that it talks (works) at all, and don't seem nearly concerned enough about what it's saying...
And it does _not_ run everywhere. With lots of work, you can make it run a lot of places; enough to be worth the effort. It is certainly useful, but not _nearly_ as useful as it could be.
Ted Nelson, who created the term hypertext, famously said, "HTML is precisely what we were trying to PREVENT-- ever-breaking links, links going outward only, quotes you can't follow to their origins, no version management, no rights management."
While politically I myself am very much in favor of open standards, for reasons I shouldn't have to explain _here_, I'm also vastly disappointed in the quality of most of the results, if from no other viewpoint than a human factors one. Like the talking dog, proponents seem happy that it talks (works) at all, and don't seem nearly concerned enough about what it's saying...
If I may: The salient difference between the web and a meta-platform like Flash is that while Adobe controls flash, nobody controls the web.
If Apple wants to build hardware acceleration for CSS animations on iPhone, it does so. If Apple wants to fix a bug in Javascript, it does so. If Apple wants to close a security hole in Safari, it does so.
Whereas if Adobe feels like making Flash slow as shit on OS X, it does so. If Adobe doesn't feel like fixing a bug on OS X, it doesn't fix a bug on OS X. If Adobe can't be bothered to fix a security bug on OS X, Adobe leaves a huge security hole open on OS X.
The web is a "worse is better" alternative to native iPhone apps, but at least it's open and offers opportunities as well as dangers for Apple.
If Apple wants to build hardware acceleration for CSS animations on iPhone, it does so. If Apple wants to fix a bug in Javascript, it does so. If Apple wants to close a security hole in Safari, it does so.
Whereas if Adobe feels like making Flash slow as shit on OS X, it does so. If Adobe doesn't feel like fixing a bug on OS X, it doesn't fix a bug on OS X. If Adobe can't be bothered to fix a security bug on OS X, Adobe leaves a huge security hole open on OS X.
The web is a "worse is better" alternative to native iPhone apps, but at least it's open and offers opportunities as well as dangers for Apple.
If Apple wants to write 200,000 applications and post them to it's app store it does so... no wait.
Regardless of the content of Jobs' response, and regardless of the merits or flaws of Section 3.3.1 for Apple, developers and consumers: It is interesting to see that Jobs is aware of the dissatisfaction with this clause. The man isn't stupid, and maybe he will pay attention as more developers look for other platforms with more open developer licenses.
I've always seen Jobs as being highly principled and opinionated about the technology he helps create, but not particularly greedy (it is perhaps fortuitous that his principles have contributed to Apple's financial success).
I get the impression that Section 3.3.1 was changed as-is because Jobs honestly believes that restricting use of cross-platform toolkits and compatibility layers will help keep the iPhone platform and AppStore true to his vision of what those platforms "should be" (whether or not this is actually the case). I also don't think Jobs is explicitly trying to lock developers into the Objective-C/Cocoa development platform (though this might be a welcome side-effect of this decision from Apple's POV).
Philosophically I don't agree with Section 3.3.1. However I can see, on the one hand, how it fits in with what I understand of Jobs' character and motivations about his technology. And on the other hand I can see how it makes good business sense for Apple in the short-term. In the long-term it may not work out as well if it induces a developer-exodus. But since Jobs is paying attention, we'll see what happens when that time comes.
I've always seen Jobs as being highly principled and opinionated about the technology he helps create, but not particularly greedy (it is perhaps fortuitous that his principles have contributed to Apple's financial success).
I get the impression that Section 3.3.1 was changed as-is because Jobs honestly believes that restricting use of cross-platform toolkits and compatibility layers will help keep the iPhone platform and AppStore true to his vision of what those platforms "should be" (whether or not this is actually the case). I also don't think Jobs is explicitly trying to lock developers into the Objective-C/Cocoa development platform (though this might be a welcome side-effect of this decision from Apple's POV).
Philosophically I don't agree with Section 3.3.1. However I can see, on the one hand, how it fits in with what I understand of Jobs' character and motivations about his technology. And on the other hand I can see how it makes good business sense for Apple in the short-term. In the long-term it may not work out as well if it induces a developer-exodus. But since Jobs is paying attention, we'll see what happens when that time comes.
Ugh. That's an awfully distasteful response.
"Intermediary layers" are what make modern programming productive. We don't all write in processor-specific assembler because it's not (developer-time) efficient, and because we can accomplish a given task without having to resort to such a low level. For example, it's far more efficient to write in higher-level C and compile for the platform as necessary. The entirety of the software development ecosystem is "intermediary layers". C compiled to a platform target with GCC is sure as hell an "intermediary layer".
I can't help but think that what Jobs means here is "intermediary layers that aren't ours automatically produce inferior products". What an arrogant line to feed to developers. At least he's being direct (if not honest) with Apple's intent to fully lock developers into the Apple-blessed toolchain, from the initial concept to the final product. Ugh.
"Intermediary layers" are what make modern programming productive. We don't all write in processor-specific assembler because it's not (developer-time) efficient, and because we can accomplish a given task without having to resort to such a low level. For example, it's far more efficient to write in higher-level C and compile for the platform as necessary. The entirety of the software development ecosystem is "intermediary layers". C compiled to a platform target with GCC is sure as hell an "intermediary layer".
I can't help but think that what Jobs means here is "intermediary layers that aren't ours automatically produce inferior products". What an arrogant line to feed to developers. At least he's being direct (if not honest) with Apple's intent to fully lock developers into the Apple-blessed toolchain, from the initial concept to the final product. Ugh.
>I can't help but think that what Jobs means here is "intermediary layers that aren't ours automatically produce inferior products".
Is that not true though? In most cases, apps that use an intermediary layer will not be as polished or usable as an app developed using the native tools.
Is that not true though? In most cases, apps that use an intermediary layer will not be as polished or usable as an app developed using the native tools.
I don't think that's true at all. Layers of abstraction can improve the quality of a product by letting the developer focus on polish, rather than fighting a lower-level language. We see vast quantities of applications written in high-level languages on high-level frameworks that behave marvelously.
Well, Steve Jobs said it so of course it's true dear.
Whether throwing mud at cross-compiled apps is valid or not (personally I'd say its validity fades in light of the voluminous bad apps already available... although i do remember Apple already taking some measures against those), I think it's merely a footnote to a sensible business decision. Apple need to preserve their lead, build a wall of incompatibility (now that it's necessary), and avoid this 'de facto cross-platform standard' which would greatly benefit Adobe and others but greatly hinder iPhone. If the iPhone ever loses its strong position you can bet Apple will embrace Flash, Java and cross-compilers in a heartbeat.
This is exactly right. Until they see real damage from the decisions they're making in the form of lost revenue and non-record quarterly performances, why not take the strongest "negotiating" position possible. You can always back down later.
From what I've seen of the CS5 packaging for iPhone, there are no native UI controls. Adobe claims to have a project to port Flex to iPhone, and I can't assume that it will use native UI controls. Since the iPhone is all about the rich user experience, perhaps by limiting access to the AppStore for prior-life Flash 2D games, Apple is protecting the dilution of the quality of the games.
As for the other build an iPhone app application frameworks, the quality of the finished product varies from lackluster to average. At the worst, the finished app looks like one of the RSS reader apps that Apple is now trying to filter out of its AppStore. At the best, it's something like Location Scout. I believe by limiting access to third-party application builders, Apple is going to continue to increase the quality of iPhone apps. Titanium, Adobe et al will never generate anything like Tweetie 2. And, I believe Apple wants more Tweetie 2-caliber applications. To increase the S/N ratio. I believe Apple wants less crap and cookie cutter applications, even though some of the top 25 Free and Paid lists may from time to time have those types of 'Fart' type apps.
Apple is a premium brand. Even for developers. There are barriers to developer entry. It is kind of a privilege to write iPhone apps as you need $99/yr and an Intel Mac. The Cocoa/UIKit framework and CoreData persistence are tools that Apple engineers have invested centuries of programmer years in developing. There aren't many private APIs in Apple land; almost all of the standard iPhone apps could be recreated by third-party developers. And now with OS 4.0, I believe only a small fraction could not be recreated. As another example, Titanium et al. are not using CoreData - CoreData is designed to make managing and persisting an object graph easier. Which is what you need for non-cookie cutter applications. I have yet to find one application built on RhoMobile, Titanium, Ascena etc that leverages CoreData.
And, I wouldn't be surprised if they start rejecting apps for quality (as in what does this app provide that is of value).
"He downloaded Titanium on a Saturday morning, and by Sunday night he had a functional prototype of his Location Scout app..."
http://www.appcelerator.com/partners/case-studies/locationsc...
http://labs.adobe.com/wiki/index.php/Applications_for_iPhone...
As for the other build an iPhone app application frameworks, the quality of the finished product varies from lackluster to average. At the worst, the finished app looks like one of the RSS reader apps that Apple is now trying to filter out of its AppStore. At the best, it's something like Location Scout. I believe by limiting access to third-party application builders, Apple is going to continue to increase the quality of iPhone apps. Titanium, Adobe et al will never generate anything like Tweetie 2. And, I believe Apple wants more Tweetie 2-caliber applications. To increase the S/N ratio. I believe Apple wants less crap and cookie cutter applications, even though some of the top 25 Free and Paid lists may from time to time have those types of 'Fart' type apps.
Apple is a premium brand. Even for developers. There are barriers to developer entry. It is kind of a privilege to write iPhone apps as you need $99/yr and an Intel Mac. The Cocoa/UIKit framework and CoreData persistence are tools that Apple engineers have invested centuries of programmer years in developing. There aren't many private APIs in Apple land; almost all of the standard iPhone apps could be recreated by third-party developers. And now with OS 4.0, I believe only a small fraction could not be recreated. As another example, Titanium et al. are not using CoreData - CoreData is designed to make managing and persisting an object graph easier. Which is what you need for non-cookie cutter applications. I have yet to find one application built on RhoMobile, Titanium, Ascena etc that leverages CoreData.
And, I wouldn't be surprised if they start rejecting apps for quality (as in what does this app provide that is of value).
"He downloaded Titanium on a Saturday morning, and by Sunday night he had a functional prototype of his Location Scout app..."
http://www.appcelerator.com/partners/case-studies/locationsc...
http://labs.adobe.com/wiki/index.php/Applications_for_iPhone...
From what I've seen of the CS5 packaging for iPhone,
there are no native UI controls. Adobe claims to have
a project to port Flex to iPhone, and I can't assume
that it will use native UI controls.
A couple of telling examples: http://adobegripes.tumblr.com/post/296745150/photoshop-why-i...
http://adobegripes.tumblr.com/post/236090781/the-many-slider...
I hope you're not implying that the speed of development is an indicator of bad quality.
Any environment where you're working with JavaScript (or Ruby, or Python...) is going to have faster dev time than working with a compiled language. It's not just having to type way less, but less brainless typing leads to better flow.
I'm doing both right now, and I love Titanium because it gets me in the zone, whereas with ObjC, so often I have to turn on autopilot to get through the boring stuff when I create a new model or class or something.
Any environment where you're working with JavaScript (or Ruby, or Python...) is going to have faster dev time than working with a compiled language. It's not just having to type way less, but less brainless typing leads to better flow.
I'm doing both right now, and I love Titanium because it gets me in the zone, whereas with ObjC, so often I have to turn on autopilot to get through the boring stuff when I create a new model or class or something.
Reading all the comments posted on this thread, I'm
starting to change my mind. It's not the quality (Titanium mobile apps are nearly indistinguishable from most iPhone apps), the speed of development (like you said, not having to use Objective-C). Unfortunately it is probably protectionism. To protect the dominance of the AppStore. If you can simultaneously write an Android and iPhone app using the same Titanium/Kroll codebase, you're helping to weaken the AppStore (which is arguably the main tent pole of Apple's strategy to dominate computing in this century).
"When Apple’s SDK was introduced in July 2008, the company tried over a period of several months to get a basic app up and running. Notes Bart Johnston, Director of Interactive, “I thought that my web development experience would have prepared me for developing on the iPhone, but it felt like I was starting completely from scratch. The learning curve was very high."
Does Apple really want to officially allow Titanium to lower the barrier to entry? Premium brands cannot be premium if everyone has access.
http://www.appcelerator.com/partners/case-studies/lone-star-...
"When Apple’s SDK was introduced in July 2008, the company tried over a period of several months to get a basic app up and running. Notes Bart Johnston, Director of Interactive, “I thought that my web development experience would have prepared me for developing on the iPhone, but it felt like I was starting completely from scratch. The learning curve was very high."
Does Apple really want to officially allow Titanium to lower the barrier to entry? Premium brands cannot be premium if everyone has access.
http://www.appcelerator.com/partners/case-studies/lone-star-...
> "He downloaded Titanium on a Saturday morning, and by Sunday night he had a functional prototype of his Location Scout app..."
Getting a functional prototype to work should be simple and fast. (There's a big difference between a functional prototype and a finished product!) The fact that it's not fast using the Apple toolchain is exactly what's wrong with them. Developer time/effort is limited. A good dev environment should make the common stuff easy; since Apple seems disinclined to provide tools that do this themselves, our big hope for improvement in that regard was that third parties would get in there and fix the problem with products like Corona or Titanium.
Getting a functional prototype to work should be simple and fast. (There's a big difference between a functional prototype and a finished product!) The fact that it's not fast using the Apple toolchain is exactly what's wrong with them. Developer time/effort is limited. A good dev environment should make the common stuff easy; since Apple seems disinclined to provide tools that do this themselves, our big hope for improvement in that regard was that third parties would get in there and fix the problem with products like Corona or Titanium.
Is there an alternative way for Apple to meet its goal of prohibiting extra layers of cross platform toolkits, without mandating the choice of programming language?
Could they somehow say that programs must use native CocoaTouch widgets, while still allowing for people who want to compile from Scheme into Objective C or C?
Could they somehow say that programs must use native CocoaTouch widgets, while still allowing for people who want to compile from Scheme into Objective C or C?
If they did this 'native UI widgets' only restriction for non-game apps, it would help. However, as other commenters have pointed out, there are a lot of crappy applications that are built with the native tab bar control.
Maybe some people don't want polish, they just want a momentary diversion (hence the proliferation of silly trivia type games and gag apps). I even saw the developer of a top-50 paid iPhone app be wow'd recently by a simple iPad game. Fun is fun, no matter how it is coded.
Maybe some people don't want polish, they just want a momentary diversion (hence the proliferation of silly trivia type games and gag apps). I even saw the developer of a top-50 paid iPhone app be wow'd recently by a simple iPad game. Fun is fun, no matter how it is coded.
This makes an interesting thought experiment: what if Adobe decides to take on Apple directly by throwing their weight behind Apple's main competitor, Android. CS5.1 is shipped as a free upgrade to CS5 and replaces the iPhone-compiler with an Android-compiler. Organizations with existing Flash content decide that they had might as well do a quick/dirty port of their apps using CS5.1.
What will the results of this be?
* Lots of Flash content gets released on Android. This expands Android's software market considerably, though with a cost in performance/platform-integration (both in terms of UI and in terms of taking advantage of low-level capabilities).
* Many of the best/most popular and money-making Flash apps will get an iPhone OS-native port. The cost to write an iPhone app is relatively low; if you're talking about a game, the vast majority of the cost is usually in the assets. The iPhone developer tools are very good, there are lots of developers: finding an iPhone developer willing to make a native port of your game engine isn't difficult or expensive relative to the number of users you open up your investment to. Thus iPhone potentially gets the best version of many originally-Flash apps.
Thus, Android continues to have more possibilities (theoretical and, in some cases, actual), but a lower overall level of quality, integration, and performance... an issue its apps are already widely accused of. And iPhone, which has a tremendous lead in number of apps, loses out on a few — again, a fairly unpopular set which would have generally not fit in on the platform as well and would have slowed Apple's ability to require adoption of new platform capabilities.
It's hard to see the downside to Apple here. And it's hard to see how this does anything but make Android less attractive and iPhone more attractive for most mainstream (the overwhelming majority) users.
What will the results of this be?
* Lots of Flash content gets released on Android. This expands Android's software market considerably, though with a cost in performance/platform-integration (both in terms of UI and in terms of taking advantage of low-level capabilities).
* Many of the best/most popular and money-making Flash apps will get an iPhone OS-native port. The cost to write an iPhone app is relatively low; if you're talking about a game, the vast majority of the cost is usually in the assets. The iPhone developer tools are very good, there are lots of developers: finding an iPhone developer willing to make a native port of your game engine isn't difficult or expensive relative to the number of users you open up your investment to. Thus iPhone potentially gets the best version of many originally-Flash apps.
Thus, Android continues to have more possibilities (theoretical and, in some cases, actual), but a lower overall level of quality, integration, and performance... an issue its apps are already widely accused of. And iPhone, which has a tremendous lead in number of apps, loses out on a few — again, a fairly unpopular set which would have generally not fit in on the platform as well and would have slowed Apple's ability to require adoption of new platform capabilities.
It's hard to see the downside to Apple here. And it's hard to see how this does anything but make Android less attractive and iPhone more attractive for most mainstream (the overwhelming majority) users.
It depends. Lets say that Adobe's compiler allows Zynga to quickly port FarmVille to Android as a native app. There are 82.4 million FarmVille users who, like crack addicts, always need their fix. They might just buy an Android phone for FarmVille and all the other games they play daily.
Now Zyngna does as you said and hires someone to build an iPhone OS native version. It'll come out 6 months to a year later -- but it's there. Then what happens? FarmVille is always being updated. It's easy to update the Android version but iPhone version always requires more work. So inevitably it falls behind or stops working entirely. Is that really more attractive for mainstream users?
Now Zyngna does as you said and hires someone to build an iPhone OS native version. It'll come out 6 months to a year later -- but it's there. Then what happens? FarmVille is always being updated. It's easy to update the Android version but iPhone version always requires more work. So inevitably it falls behind or stops working entirely. Is that really more attractive for mainstream users?
I agree that it makes android a lot larger; however, I feel you underestimate the cost to make an iPhone app.
Also, I feel you are underestimating the 'theoertical possibilities'. I have a custom keyboard (swype) that allows me to "type" extremely fast. On my computer, I use Chrome; it integrates poorly with KDE's UI, but since it is so damn fast compared to firefox, I use it.
Finally, a quality loss is very debatable for cross-compiled apps. Polarbit (http://polarbit.com/) cross compiles to iphone, android and Symbian and their apps are quite good.
Performance might not be such a big deal either - high-end Android phones spec-wise are significantly better than the 3GS; this advantage should make up for slower apps.
Also, I feel you are underestimating the 'theoertical possibilities'. I have a custom keyboard (swype) that allows me to "type" extremely fast. On my computer, I use Chrome; it integrates poorly with KDE's UI, but since it is so damn fast compared to firefox, I use it.
Finally, a quality loss is very debatable for cross-compiled apps. Polarbit (http://polarbit.com/) cross compiles to iphone, android and Symbian and their apps are quite good.
Performance might not be such a big deal either - high-end Android phones spec-wise are significantly better than the 3GS; this advantage should make up for slower apps.
iTunes is cross platform. Is Steve saying that iTunes is crap?
It certainly is on Windows. Same goes for Safari on Windows.
The difference is that Windows users are used to using primarily shoddy, poorly designed software. Most PCs even come with some preinstalled.
Microsoft should ban it from Windows then.
Apple would probably like that. They don't have to spend money on support and can point their finger at Microsoft when customers come to complain.
Also, a small fraction of complaining customers might actually purchase a Mac. Cha ching!
Also, a small fraction of complaining customers might actually purchase a Mac. Cha ching!
"Also, a small fraction of complaining customers might actually purchase a Mac."
While the rest can't use their IPods anymore? I don't think Apple would be too happy with that.
While the rest can't use their IPods anymore? I don't think Apple would be too happy with that.
The majority of the functions that used to require a computer-to-iPhone sync can be done over the air now.
And they'd finally make their devices useful without being synced to a computer!
iTunes runs on machines with RAM measured in the gigabytes, hard-drives in the terabytes, cooling fans and continuously or frequently connected power adaptors.
When you have those kinds of resources to slop around, then sure, you can spend them on abstractions that only serve the programmer's convenience.
When you have those kinds of resources to slop around, then sure, you can spend them on abstractions that only serve the programmer's convenience.
I think 3.3.1 is a smart choice from apple's perspective. They need to raise the barrier of entry into the app market and make developing apps more difficult, because there is currently an oversupply. Even if the clause turns away a ridiculous 70% of would-be app developers, I don't think apple will suffer.
Monotouch has been out since November 2009, Adobe CS5 isn't out for the iPhone yet, and as for Titanium I don't know the exact time period but it's not been long.
The only platform producing apps for a longer period of time has been Unity3D, which now advertises itself as having over 600 appstore games.
So your argument about raising the barrier to entry is weak, as these tools have only just emerged in the last 6 months. Prior to that we've seen thousands of poorly written, leaking objective-C applications on the AppStore. I've seen 2 RSS readers and the official digg.com app crash straight to springboard in the last 2 weeks, all written in objective-C.
Just because the language is closer to C and enforces memory management doesn't make its barrier any higher or require any greater skills - it means you'll get a tonne of apps that aren't releasing or reference counting and crash. I'm sure all this was hotly debated 10 years ago and garbage collection won.
The only platform producing apps for a longer period of time has been Unity3D, which now advertises itself as having over 600 appstore games.
So your argument about raising the barrier to entry is weak, as these tools have only just emerged in the last 6 months. Prior to that we've seen thousands of poorly written, leaking objective-C applications on the AppStore. I've seen 2 RSS readers and the official digg.com app crash straight to springboard in the last 2 weeks, all written in objective-C.
Just because the language is closer to C and enforces memory management doesn't make its barrier any higher or require any greater skills - it means you'll get a tonne of apps that aren't releasing or reference counting and crash. I'm sure all this was hotly debated 10 years ago and garbage collection won.
I think perhaps what the parent meant is that Apple wants to maintain the current barrier to entry. I think perhaps they're worried about the shitload of crap apps that will end up being submitted for approval once Flash CS5 is released.
If apple allows cross-compilation like that from titanium and adobe, then guess which platform gets the apps first? That's right - all the others!
Because apple is so slow and nitpicky with their approval process, if they allow this to happen their own policies will make sure they lose out to the less moderated platforms.
I think this is a good reason why apple is doing what it is. They want to maintain the app advantage as long as possible.
Seems to me there is an easier way - make your approval process better!
Because apple is so slow and nitpicky with their approval process, if they allow this to happen their own policies will make sure they lose out to the less moderated platforms.
I think this is a good reason why apple is doing what it is. They want to maintain the app advantage as long as possible.
Seems to me there is an easier way - make your approval process better!
Apple may have other motives, but the effect of this is still positive; encouraging a higher standard of quality is a good thing for a massive platform.
Remember, Microsoft didn't do this with Windows. Where did we end up? For years, an incredibly bad user interface became the norm, with shaky programming APIs to match. Most 3rd party developers simply copied whatever Microsoft was doing (out of laziness?), causing other applications and APIs to also be horrible.
Remember, Microsoft didn't do this with Windows. Where did we end up? For years, an incredibly bad user interface became the norm, with shaky programming APIs to match. Most 3rd party developers simply copied whatever Microsoft was doing (out of laziness?), causing other applications and APIs to also be horrible.
Jobs' second response is the most interesting.
We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.
So it seems, at least from his comment and the context it was in, the intention of the clause is to remove layers that are other people's products.
There are two sides to the "hinders progress" claim. One is that, with an intermediary layer, new features added by Apple cannot be used by anyone relying on an intermediary layer to build iPhone apps until the maintainers of the intermediary layer add support for it. From what few comments we've gotten out of Apple, it seems they are trying to avoid a situation in which there is a large ecosystem of developers who are unable to directly exploit Apple's newest innovations on the platform, and instead work with least-common-denominator that their layer provides.
I think this is a totally reasonable thing to want.
The other side to this is that there is probably not a good technical way to make people obey. Innovation directly on top of a platform can involve abstraction into layers. For example, most of the best games all involve multiple layers of abstraction, in the form of a managed runtime for the game, some sort of scripting engine (or template/meta-language for specifying behavior), dynamic compiler (for shaders, AI and other tasks), etc.
The first thing a good programmer does when faced with a complex and uncertain problem is to build a grammar to express their ideas in on top of the foundation you're given. In C, this usually involves writing sets of routines that form a second (usually ad-hoc) 'language' that can be composed together to form complex ideas without having to hand-code everything over and over.
I see tons of bad and dumb Objective-C iPhone, iPad and Mac apps. It's completely possible to write first-class stuff in something other than Objective-C or C. ML variants, such as OCaml, SML and now even Haskell are speed demons in comparison to Objective-C. (The thing that makes Objective-C 'fast' is that when you need it to be fast, you just write the routines only in C, without message dispatching. Want to know how much fun it is to write GUI glue in C? Not very.)
I hope this means Apple is not going to start rejecting apps that are polished, fast, and innovative simply because they are built or expressed with tools other than C. I realize a lot of Flash->Objective-C compiled stuff would be crap. A lot of Objective-C stuff is crap, too. But some guy with his own hand-rolled Scheme runtime with message passing mapped onto the UIKit classes implemented with closures? If you reject that, you're going to piss off the very best developers, and dig yourself into the kind of hole that no technology company in history has been able to maintain mindshare once inside.
Addendum: if it's true that Apple's primary intention of removing layers is to keep their APIs and ecosystem nimble, then I would expect them to not reject games made with intermediary software, such as Unity3D. Games usually play outside of the main OS framework kits and are not as beholden to new UI features as normal application kit programs.
We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.
So it seems, at least from his comment and the context it was in, the intention of the clause is to remove layers that are other people's products.
There are two sides to the "hinders progress" claim. One is that, with an intermediary layer, new features added by Apple cannot be used by anyone relying on an intermediary layer to build iPhone apps until the maintainers of the intermediary layer add support for it. From what few comments we've gotten out of Apple, it seems they are trying to avoid a situation in which there is a large ecosystem of developers who are unable to directly exploit Apple's newest innovations on the platform, and instead work with least-common-denominator that their layer provides.
I think this is a totally reasonable thing to want.
The other side to this is that there is probably not a good technical way to make people obey. Innovation directly on top of a platform can involve abstraction into layers. For example, most of the best games all involve multiple layers of abstraction, in the form of a managed runtime for the game, some sort of scripting engine (or template/meta-language for specifying behavior), dynamic compiler (for shaders, AI and other tasks), etc.
The first thing a good programmer does when faced with a complex and uncertain problem is to build a grammar to express their ideas in on top of the foundation you're given. In C, this usually involves writing sets of routines that form a second (usually ad-hoc) 'language' that can be composed together to form complex ideas without having to hand-code everything over and over.
I see tons of bad and dumb Objective-C iPhone, iPad and Mac apps. It's completely possible to write first-class stuff in something other than Objective-C or C. ML variants, such as OCaml, SML and now even Haskell are speed demons in comparison to Objective-C. (The thing that makes Objective-C 'fast' is that when you need it to be fast, you just write the routines only in C, without message dispatching. Want to know how much fun it is to write GUI glue in C? Not very.)
I hope this means Apple is not going to start rejecting apps that are polished, fast, and innovative simply because they are built or expressed with tools other than C. I realize a lot of Flash->Objective-C compiled stuff would be crap. A lot of Objective-C stuff is crap, too. But some guy with his own hand-rolled Scheme runtime with message passing mapped onto the UIKit classes implemented with closures? If you reject that, you're going to piss off the very best developers, and dig yourself into the kind of hole that no technology company in history has been able to maintain mindshare once inside.
Addendum: if it's true that Apple's primary intention of removing layers is to keep their APIs and ecosystem nimble, then I would expect them to not reject games made with intermediary software, such as Unity3D. Games usually play outside of the main OS framework kits and are not as beholden to new UI features as normal application kit programs.
> So it seems, at least from his comment and the context it was in, the intention of the clause is to remove layers that are other people's products.
Exactly. It's not about forbidding other languages, they just don't want to be beholden to things like CS5. Gruber was right.
Exactly. It's not about forbidding other languages, they just don't want to be beholden to things like CS5. Gruber was right.
I wouldn't be utterly surprised if Apple took Titanium Mobile:
http://github.com/appcelerator/titanium_mobile
or bought Appcelerator and made a play for it to be the environment to develop mobile apps in.
If the future says we'll be able to cross-compile our apps for the 2 or 3 most popular mobile platforms, why not do have people do it on Macs, in Apple's environment, and have the paid apps end up appearing in an Apple controlled app store?
(side note: i've mentioned Appcelerator a few times in previous comments. I have no connection to them other than thinking it's a pretty neat product and have been looking forward to diving in to it properly. I'll be annoyed if Apple removes that as an option from me. FWIW, Appcelerator is the reason i've already paid $99 to register as an iPhone developer.)
http://github.com/appcelerator/titanium_mobile
or bought Appcelerator and made a play for it to be the environment to develop mobile apps in.
If the future says we'll be able to cross-compile our apps for the 2 or 3 most popular mobile platforms, why not do have people do it on Macs, in Apple's environment, and have the paid apps end up appearing in an Apple controlled app store?
(side note: i've mentioned Appcelerator a few times in previous comments. I have no connection to them other than thinking it's a pretty neat product and have been looking forward to diving in to it properly. I'll be annoyed if Apple removes that as an option from me. FWIW, Appcelerator is the reason i've already paid $99 to register as an iPhone developer.)
> If the future says we'll be able to cross-compile our apps...
Apple wants to prevent that future, not embrace it. They'd rather sell millions of iPhones to consumers than sell hundreds of Macs to developers.
Apple wants to prevent that future, not embrace it. They'd rather sell millions of iPhones to consumers than sell hundreds of Macs to developers.
[deleted]
For people who think that this will increase quality in the app store:
No, you are completely wrong! There will be always sh!t games and apps, because sh!t developers exist either on Mac or Pc or Linux. So the solution is either to tighten the app store approval process or make a user voting system that select the best.
I do believe that Flash will bring loads of crappy game to the iPhone, however the couple exciting games it will bring are worth it.
No, you are completely wrong! There will be always sh!t games and apps, because sh!t developers exist either on Mac or Pc or Linux. So the solution is either to tighten the app store approval process or make a user voting system that select the best.
I do believe that Flash will bring loads of crappy game to the iPhone, however the couple exciting games it will bring are worth it.
No matter how clever Steve's rhetoric - he's trying to restrict freedom and moderate the behaviour of developers.
Steve; if you were really worried about quality, you could examine the end product and make a judgement based on the final quality of each app in question.
This is a strategic business decision and you're treating developers like pawns. Potentially this move has the ability to stifle innovation.
Steve; if you were really worried about quality, you could examine the end product and make a judgement based on the final quality of each app in question.
This is a strategic business decision and you're treating developers like pawns. Potentially this move has the ability to stifle innovation.
Developers, like all scientists, want to have choices to tinker with stuff. Especially the smartest. As a consequence the number of smart iPhone developers will decrease and we'll have a higher number of sub-standard iPhone apps. But at least they will all have a consistent look and feel.
So much for "Here's to the crazy ones." I feel more like a sheep that's being told a priori what to do.
So much for "Here's to the crazy ones." I feel more like a sheep that's being told a priori what to do.
[deleted]
Steve's second response tells us that he's well aware of what they're doing. The platform is going to be heavily guarded. If you make something for the iPhone or iPad you're going to have to hire fan-boys or developers who are very, very willing to bow to the Apple.
And if you want to make something that runs on airplanes, you're going to have to play by the FAA rules, which also severely limit what nifty computer science techniques (and, in practice, what languages) you can use.
Not every development environment is going to be a free-for-all. If a particular environment is too restrictive for our tastes, we don't have to develop there... though if our desire to support the users on the other side of the development environment is strong enough, then we might decide to put up with what may feel like are rather perplexing, pointless rules.
Not every development environment is going to be a free-for-all. If a particular environment is too restrictive for our tastes, we don't have to develop there... though if our desire to support the users on the other side of the development environment is strong enough, then we might decide to put up with what may feel like are rather perplexing, pointless rules.
The difference being that you have to play by the FAA rules for all airplane software development.
But you have a choice when it comes to mobile development. Android, WebOs, Symbian,... All allow you to do mobile development. The IPhone is not the only game in town. Which is why a move like this could be considered risky by some.
But you have a choice when it comes to mobile development. Android, WebOs, Symbian,... All allow you to do mobile development. The IPhone is not the only game in town. Which is why a move like this could be considered risky by some.
As an iPhone/iPad user one of the things I like most about it is the UI consistency and being able to install third party apps without a huge amount of paranoia that it will steal my data or crash my phone. I like that I can always get a phone call even when playing a fairly intense 3D game. I accept the restrictions to achieve those goals. That's my choice -- it's also Apple's choice. So I don't really understand why people who have a problem with it don't just go develop for Android, WebOS, BlackBerry, etc. You'll be happier, I'll be happier. We'll have more competition in the SmartPhone market. It's a win-win-win situation. This obsession over the iPhone platform is not healthy. It's not like we don't have choices. Use them.
So let me get this straight, you are a fanboy per definition if you're an iPhone developer? Holy fundamentalism, Batman!
No. Repeating myself now, a fanboy or just willing to work within Apple's tools and nothing else.
Very close to 100% of iPhone developers are using Apple's tools.
Does that mean that all of these developers are either fanboys or willing to "bow down" to Apple, or is there even a smidgeon of a chance that they actually think it's a pretty decent platform to work with?
I've heard a lot of complaints about developing for the iPhone, but none about the quality of the development environment.
Does that mean that all of these developers are either fanboys or willing to "bow down" to Apple, or is there even a smidgeon of a chance that they actually think it's a pretty decent platform to work with?
I've heard a lot of complaints about developing for the iPhone, but none about the quality of the development environment.
Dude, I'm not complaining or saying it's a bad platform. Just that if you're going to develop on it you're going to be guided by Apple's choices and platform. As opposed to being able to hack something that in the end runs on the iPhone. That's no longer the case as you're not even allowed to choose the language or tools.
Right, but since everybody (close to 100%) is already using Apple's platform by choice that means there's no difference from how they were developing apps before.
That doesn't suddenly make them "fanboys", or "willing to bow", it just means they like the platform.
That doesn't suddenly make them "fanboys", or "willing to bow", it just means they like the platform.
> I've heard a lot of complaints about developing for the iPhone, but none about the quality of the development environment.
Consider this your first, then: the iPhone development environment sucks. People are using it despite the suckage or because they don't know any better. I do have an app in the app store, but the experience of making it was so painful - the cruftiness of Objective C, the gawdawful poorly-integrated mess of the Interface Builder, and various DRM issues - that I just couldn't take it anymore. I had a long list of apps I wanted to build next and features I wanted to add to the one I had, but programming for the iPhone turned out to be so unpleasant that I couldn't stand doing it.
The same sense of aesthetics that makes me really like using the iPhone makes me dislike using Objective C or the iPhone dev environment in general.
By way of reference, I really enjoyed programming for the Newton using the Newton Toolkit and NewtonScript, and I really enjoy using Ruby. Ruby and NTK were discoverable in ways that the iPhone toolchain is not.
My chief hope, if I ever wanted to develop more iPhone or iPad apps, was that third parties would jump in and fill the gap with more mac-like development tools that I could stand to use on a regular basis. Maybe something like Corona. I could even hope that competition from third party development environments might lead Apple to improve theirs. But no, these hopes have been dashed. So I guess I'll have to continue not developing iPhone apps.
Oh, and consider the posts on this blog your second-through-tenth complaints:
http://www.iphonerant.com/
Consider this your first, then: the iPhone development environment sucks. People are using it despite the suckage or because they don't know any better. I do have an app in the app store, but the experience of making it was so painful - the cruftiness of Objective C, the gawdawful poorly-integrated mess of the Interface Builder, and various DRM issues - that I just couldn't take it anymore. I had a long list of apps I wanted to build next and features I wanted to add to the one I had, but programming for the iPhone turned out to be so unpleasant that I couldn't stand doing it.
The same sense of aesthetics that makes me really like using the iPhone makes me dislike using Objective C or the iPhone dev environment in general.
By way of reference, I really enjoyed programming for the Newton using the Newton Toolkit and NewtonScript, and I really enjoy using Ruby. Ruby and NTK were discoverable in ways that the iPhone toolchain is not.
My chief hope, if I ever wanted to develop more iPhone or iPad apps, was that third parties would jump in and fill the gap with more mac-like development tools that I could stand to use on a regular basis. Maybe something like Corona. I could even hope that competition from third party development environments might lead Apple to improve theirs. But no, these hopes have been dashed. So I guess I'll have to continue not developing iPhone apps.
Oh, and consider the posts on this blog your second-through-tenth complaints:
http://www.iphonerant.com/
This was my take/biased-C++ guess on it a couple of days ago, fwiw.
http://tmsh.posterous.com/section-331
http://tmsh.posterous.com/section-331
Read your post. Problem is, there isn't that much code you can write without allocating something on the heap. When you are allocating stuff on the heap, manually using malloc() can be very inefficient. Not to mention recent versions of the JVM can perform escape analysis and convert un-needed heap allocation to stack allocation.
From my own experiences, bigger problems occur with extra large heaps (>32gb). That's where the dreaded Java GC pauses and CMS failures come in. In these cases custom memory allocators (such as memcached's) are what people turn to.
I'd also wager the iPhone/iPad are not low-memory devices by any stretch of the imagination. The amount of memory is orders of magnitude higher than the original machines on which Smalltalk, Common Lisp and Java were developed. Erlang (with the BEAM VM) is meant to run extremely reliable on very limited telecommunications switch equipment.
That being said, well written, profiled and optimized code in C is always going to beat code written in a JIT-compiled, garbage collected language. 3d graphics and gaming is one such place and I'd hesitate using anything other than C for these domains (at least for now).
From my own experiences, bigger problems occur with extra large heaps (>32gb). That's where the dreaded Java GC pauses and CMS failures come in. In these cases custom memory allocators (such as memcached's) are what people turn to.
I'd also wager the iPhone/iPad are not low-memory devices by any stretch of the imagination. The amount of memory is orders of magnitude higher than the original machines on which Smalltalk, Common Lisp and Java were developed. Erlang (with the BEAM VM) is meant to run extremely reliable on very limited telecommunications switch equipment.
That being said, well written, profiled and optimized code in C is always going to beat code written in a JIT-compiled, garbage collected language. 3d graphics and gaming is one such place and I'd hesitate using anything other than C for these domains (at least for now).
Good point. I don't regret my time spent writing in Java. I think in many ways it improved on previous languages and clarified a lot of things that are pretty murky in C++ (like how objects have both a 'dynamic' and 'static' type). And it's nice to hear they're still innovating things.
It's just that small things add up. Take class members. In C++, all non-pointer class members are allocated together (like a struct). In Java, each non-array member is basically a pointer. That small little thing spread across say a UI/widget hierarchy adds up and creates a lot less memory locality, etc. Doesn't quite fold as nicely into the caching layers of the von Neumann model.
I totally agree with you about there being orders of magnitude more memory than the original machines that these languages were developed on. Actually, just googling 'ipad ram' (and filtering by last week -- man, I love that feature):
http://bit.ly/dioAjU
It looks like there's only 256MB or so. No idea why they didn't include more. That makes no sense to me. It's almost like they're squeezing VMs on purpose. Not sure if Jobs is that much of an evil genius, but yeah. I mean when you're paying $600 for a device made in bulk, RAM is cheap. Odd.
It's just that small things add up. Take class members. In C++, all non-pointer class members are allocated together (like a struct). In Java, each non-array member is basically a pointer. That small little thing spread across say a UI/widget hierarchy adds up and creates a lot less memory locality, etc. Doesn't quite fold as nicely into the caching layers of the von Neumann model.
I totally agree with you about there being orders of magnitude more memory than the original machines that these languages were developed on. Actually, just googling 'ipad ram' (and filtering by last week -- man, I love that feature):
http://bit.ly/dioAjU
It looks like there's only 256MB or so. No idea why they didn't include more. That makes no sense to me. It's almost like they're squeezing VMs on purpose. Not sure if Jobs is that much of an evil genius, but yeah. I mean when you're paying $600 for a device made in bulk, RAM is cheap. Odd.
I'd argue 256 mb is more than plenty to run a VM. I recall running much slower and memory-hogging VMs (earlier versions of Flash, Bochs, Blackdown JDK 1.3 under Linux emulation in FreeBSD, how's that for layering?), running much heavier applications (Netbeans, Tomcat under Blackdown) in 256 mb of ram on a machine with a slow PATA disk and a Pentium-III processor. It wasn't pretty (this experience is what turned me away from JVM until recently), but it was tolerable.
I am not saying the JVM (at least HotSpot) is actually best for the iPhone/iPad, there are better VMs out there. Erlang's VM is better (and again, runs in a much more restricted space), there are also register based VMs (e.g., Dalvik and -- best example -- how Apple themselves emulated m68k on PowerPC based Macs).
I'll definitely trust you in regards to UI programming: last UI programming I did for a salary was GTK+- in C, having played a bit with OS X SDKs / IB -- even prior to iPhone -- I found that to be a much better experience. The only Java desktop apps I use extensively are the IDEs (and both Eclipse with SWT and IntelliJ IDEA with its JNA/JNI libraries make heavy use of native APIs).
I am not saying the JVM (at least HotSpot) is actually best for the iPhone/iPad, there are better VMs out there. Erlang's VM is better (and again, runs in a much more restricted space), there are also register based VMs (e.g., Dalvik and -- best example -- how Apple themselves emulated m68k on PowerPC based Macs).
I'll definitely trust you in regards to UI programming: last UI programming I did for a salary was GTK+- in C, having played a bit with OS X SDKs / IB -- even prior to iPhone -- I found that to be a much better experience. The only Java desktop apps I use extensively are the IDEs (and both Eclipse with SWT and IntelliJ IDEA with its JNA/JNI libraries make heavy use of native APIs).
I think companies would cooperate more with each other and with developers if patent law wasn't creating incentives to do the opposite.
Cooperation would happen a lot more if cooperation were mutually beneficial instead of just benefitting the patent holder.
The creation of web was really a fluke, but the sort of thing that would be happening all the time if patents weren't discouraging them.
Cooperation would happen a lot more if cooperation were mutually beneficial instead of just benefitting the patent holder.
The creation of web was really a fluke, but the sort of thing that would be happening all the time if patents weren't discouraging them.
I look forward to Steve not allowing any software other than those developed in XCode and solely for the Mac OS to be run on my Macbook Pro. Put an end to all software piracy and buginess and one place to run all OS apps.
// I was just being sarcastic but given Apple's behavior I wouldn't be surprised if this happens.
// I was just being sarcastic but given Apple's behavior I wouldn't be surprised if this happens.
Does Android support flash or AIR apps? If so, are there a lot of developers using this to build applications?
There are a few phones with Flash Lite, and plans announced for full Flash 10.1 in the browser. But as far as I know there is no AIR for Android, and no shipping phones with the full Flash runtime. There's no Android equivalent to the Adobe CS5's iPhone app compiler.
[deleted]
I really don't get this argument. It seems that his point is that section 3.3.1 is going to scare developers away and ruin the platform.
Ok. So let the developers go elsewhere.
The only party hurt here is Apple. If they want to shoot themselves in the foot, then let them do so. It's one thing to have an intervention for a friend that is an addict, quite another to save a company from itself.
As a friend put it, section 3.3.1 pisses off an extremely small subset of iPhone users... namely, the developers themselves. No one else cares. If they app ecosystem dies because of it, then people will jump to another smartphone. But until that actually happens (if ever), Apple can get away with whatever it wants, and trying to argue about it is not going to get you anywhere.
Ok. So let the developers go elsewhere.
The only party hurt here is Apple. If they want to shoot themselves in the foot, then let them do so. It's one thing to have an intervention for a friend that is an addict, quite another to save a company from itself.
As a friend put it, section 3.3.1 pisses off an extremely small subset of iPhone users... namely, the developers themselves. No one else cares. If they app ecosystem dies because of it, then people will jump to another smartphone. But until that actually happens (if ever), Apple can get away with whatever it wants, and trying to argue about it is not going to get you anywhere.
Does Steve Jobs know how to program, and if so, what languages does he know?
Quoting Steve Wozniak's description of Jobs' job back when he worked for Atari: "... Steve would examine their design and make changes, like adding sounds, etc. It's like modifying a program to do different things, just barely a step under designing them yourself, and a step that all design engineers go through." http://www.woz.org/letters/general/91.html
If that gives you any sense.
If that gives you any sense.
[deleted]
[deleted]
Apparently nobody at Apple has the guts to tell Steve that Adobe will just modify their tool to emit Objective C code instead of ARM bytecode. Performance really will suffer when they do that, and Apple won't be able to do anything about it because they won't be able to prove that the Objective C source was generated.
They absolutely will be able to tell. When you auto generate code it is going to have a very distinct signature, not to mention common runtime code. All they have to do is get a competent programmer to compile a Flash for iPhone app, disassemble it and build a program that looks for the signature that's run over submitted apps. A few days of work at most every time Adobe releases an update to their iPhone compiler.
When you auto generate code it is going to have a very distinct signature, not to mention common runtime code
A couple thousand Russian worm authors would beg to differ.
This is a classic arms-versus-armor battle. Arms will always win.
A couple thousand Russian worm authors would beg to differ.
This is a classic arms-versus-armor battle. Arms will always win.
I'm talking specifically about Flash generated iPhone apps above, and there is no way Adobe would win that war. Even if they spend millions of dollars changing the generators in an arms race, it'll cost Apple orders of magnitude less to dissect their updates and write a program to flag the apps.
Don't forget that Apple has full access to the Flash IDE - they can generate as many Flash iPhone apps as they want, and test out their signature analysis programs until they fit - where as Adobe has absolutely no knowledge of what Apple is doing to detect their generator.
Apple has every advantage here. Adobe could put their best guys on it and Apple could defeat them with a single (smart) intern.
As for the long tail of code generators, which I wasn't talking about, I just don't think Apple will bother. They know they can't win there, but they don't need to. As soon as one of them gains any sort of popularity (like Unity), they'll cut them down, but until then, a few apps breaking the rules means nothing to them in the big picture.
Don't forget that Apple has full access to the Flash IDE - they can generate as many Flash iPhone apps as they want, and test out their signature analysis programs until they fit - where as Adobe has absolutely no knowledge of what Apple is doing to detect their generator.
Apple has every advantage here. Adobe could put their best guys on it and Apple could defeat them with a single (smart) intern.
As for the long tail of code generators, which I wasn't talking about, I just don't think Apple will bother. They know they can't win there, but they don't need to. As soon as one of them gains any sort of popularity (like Unity), they'll cut them down, but until then, a few apps breaking the rules means nothing to them in the big picture.
Objective-C, when compiled down (with the Apple toolchain, at least), remains a very expressive language. It won't be all that difficult to programmatically detect signs of an Adobe library in the binary. It's how Apple presently checks for use of private APIs (and that has led to the sorts of false positives we've seen in that detection).
It won't be all that difficult to programmatically detect signs of an Adobe library in the binary
There doesn't have to be an Adobe library in the binary. To the extent Adobe would want or need to include standard library code as part of a Flash-generated iPhone app, they'd just compile it as C. Absolutely 100% of the binary code would come from Apple's compiler.
There are a dozen trivial workarounds for 3.3.1, and the fact that Jobs apparently doesn't see that is unnerving. Somebody at Apple is feeding him BS.
There doesn't have to be an Adobe library in the binary. To the extent Adobe would want or need to include standard library code as part of a Flash-generated iPhone app, they'd just compile it as C. Absolutely 100% of the binary code would come from Apple's compiler.
There are a dozen trivial workarounds for 3.3.1, and the fact that Jobs apparently doesn't see that is unnerving. Somebody at Apple is feeding him BS.
More proof that Gruber is a tool.
Anyway, the puzzling thing here is that as Greg says, most iPhone OS apps are written in one of the whitelisted languages already. Couple that with what I think is the likely fact that Apple is being honest about its motives (namely that it doesn't want its roadmap to have to consider third-party toolkits in any way), and it's confusing. Why would they go to the trouble of pissing everyone off to bring about a result that had largely brought itself about?
Two answers. One, I think Apple feared that more third-party toolkits are on the way, and that they'll become more popular. Two (and I think this is a huge part of it), Apple seems to have simply underestimated how mad this would make developers.
I wouldn't be surprised if the company went back on 3.3.1, or at least moderated it. Apple's only willing to be a jerk when it and the public agree about the level of jerkitude at hand. If Apple gets more ire than it was expecting, there's precedent for it backing down.