How do they work for the trackpad? The only thing I can imagine there is some kind of multi-touch technology letting you do those things.
Yep.
It lets you use up to four fingers.
Normally that kind of action will run you at least $250/hr.
Nice.
EDIT: Also not really what I'd class as gesture recognition because its not recognizing mouse input its recognizing a difference I as the user make to the device i.e. using two fingers rather then one.
The gestures I'm against is stuff where you draw some pattern with the mouse and it does a thing.
I've never understood mouse gestures. To me they basically seem like an opportunity for my normal mouse inputs to, under specific circumstances, do something I did not intend.
I have to say, the magic mouse for all its revolutionary technology is kind of a problem looking for a solution. Yes, it's lighter and smoother than using a standard 2-button+wheel mouse, but they could have left it at that and we'd all be happy.
The gestures for the MacBook trackpad are infinitely more necessary. Zooming, tilting, right-clicking without an extra button or key, moving windows and tabs around . . . . pretty neat and useful.
I thought the Magic Mouse supported the exact same gestures as the MacBook trackpad, i.e. pinch-to-zoom etc.
Am I wrong?
enc0re on
0
syndalisGetting ClassyOn the WallRegistered User, Loves Apple Productsregular
I've never understood mouse gestures. To me they basically seem like an opportunity for my normal mouse inputs to, under specific circumstances, do something I did not intend.
I have to say, the magic mouse for all its revolutionary technology is kind of a problem looking for a solution. Yes, it's lighter and smoother than using a standard 2-button+wheel mouse, but they could have left it at that and we'd all be happy.
The gestures for the MacBook trackpad are infinitely more necessary. Zooming, tilting, right-clicking without an extra button or key, moving windows and tabs around . . . . pretty neat and useful.
I thought the Magic Mouse supported the exact same gestures as the MacBook trackpad, i.e. pinch-to-zoom etc.
Am I wrong?
It CAN; it has the same tech on the inside.
Apple limited it to only allow for scrolling, and swiping back and forth between pages.
With a little app called MagicPrefs, you can enable as many of the iPhone gestures as you are comfortable with. My only warning is that it is a lot harder to pull them off on a moving thing like a mouse than it is a stationary input like a trackpad or iPhone screen. So I generally only have about 5-6 functions bound at any time that I know work (4 finger tap for instance).
syndalis on
SW-4158-3990-6116
Let's play Mario Kart or something...
What a difference two weeks and a few words of legalese can make to the future of a widely used programming technology.
In that span of time, Adobe Systems has gone from touting its technology for building Flash applications that run on the iPhone to canceling future development of that technology.
When Apple changed the terms of its iPhone 4.0 software developer kit license, it effectively blocked Adobe's move. But in his Tuesday announcement that Adobe will cease future development of the Flash-apps-on-iPhone technology, Mike Chambers, Adobe's principal product manager for the Flash platform, let loose a tirade that indicates the battle between the two companies isn't over yet.
"As developers for the iPhone have learned, if you want to develop for the iPhone you have to be prepared for Apple to reject or restrict your development at any time, and for seemingly any reason," Chambers said. "The primary goal of Flash has always been to enable cross browser, platform and device development. The cool Web game that you build can easily be targeted and deployed to multiple platforms and devices. However, this is the exact opposite of what Apple wants. They want to tie developers down to their platform, and restrict their options to make it difficult for developers to target other platforms."
Adobe takes the matter seriously. It disclosed in a regulatory filing that its business could be harmed if the iPhone and iPad don't support Adobe technology. And Adobe could be considering legal action against Apple, too, according to one report.
In a response, Apple indicated its preference for a variety of up-and-coming standards that collectively compete with what Flash can do.
"Someone has it backwards--it is HTML5, CSS, JavaScript, and H.264 (all supported by the iPhone and iPad) that are open and standard, while Adobe's Flash is closed and proprietary," said spokeswoman Trudy Muller in a statement.
HTML5 is a revision to Hypertext Markup Language used to describe Web pages; CSS (Cascading Style Sheets) are used to format Web pages; and H.264 is a video compression technology used in streaming video among other areas. Adobe isn't totally removed from these technologies, however: its Flash Player includes H.264 support, and its AIR technology has built-in HTML and CSS support through inclusion of the WebKit browser on which Apple's Safari is based.
Adobe isn't limited to lashing out on blogs. It's got a big ally in any competition against Apple: Google.
"Fortunately, the iPhone isn't the only game in town. Android based phones have been doing well behind the success of the Motorola Droid and Nexus One, and there are a number of Android based tablets slated to be released this year. We are working closely with Google to bring both Flash Player 10.1 and Adobe AIR 2.0 to these devices, and thus far, the results have been very promising," Chambers said.
Google is a willing ally, too, as evidenced by a Wednesday blog post from Andy Rubin, vice president of engineering for the Android effort, on Adobe's Web site.
"Google believes that developers should have their choice of tools and technologies to create applications. By supporting Adobe AIR on Android we hope that millions of creative designers and developers will be able to express themselves more freely when they create applications for Android devices. More broadly, AIR will foster rapid and continuous innovation across the mobile ecosystem. Google is happy to be partnering with Adobe to bring the full Web, great applications, and developer choice to the Android platform."
The alliance fits a common pattern of convenience in the technology industry, with challengers working together to take on an incumbent. Apple, with tens of thousands of iPhone applications available and strong sales of the phone, the iPod Touch, and now the iPad, holds a lot of power over developers. Even those who feel Apple is riding roughshod over them likely will think twice before choosing not to participate in a market that is vibrant and in many cases lucrative.
In a synchronized move, Adobe's Flash platform evangelist, Lee Brimelow, lauded Rubin's post and spotlighted demonstrations of 13 Flash and AIR applications running on Android.
The upcoming Flash Player 10.1 and related AIR 2.0 programming foundations are in private beta testing for Android now. The software, scheduled to arrive this quarter, will work on a variety of other phone operating systems, including Windows Phone 7, the BlackBerry OS, Symbian OS, and Palm's WebOS.
Rhetoric can have teeth, and Adobe clearly hopes to give Apple a bad reputation among programmers. Chambers, a programmer himself, is directing his own attention toward Android.
"I think that the closed system that Apple is trying to create is bad for the industry, developers, and ultimately consumers, and that is not something that I want to actively promote," Chambers said. "We are at the beginning of a significant change in the industry, and I believe that ultimately open platforms will win out over the type of closed, locked-down platform that Apple is trying to create."
The Adobe technology for bringing Flash-derived applications to the iPhone is now effectively irrelevant at the very moment when Adobe is bringing it to market in its CS5 product line. Chambers, though, argues it wasn't a waste of effort.
The work proved, he said, "There is no technical reason that Flash can't run on the iPhone."
By blocking Flash, though, Apple, has proved that there is more to programming than technology.
Updated 9:04 a.m. PDT to add Apple comment and 1:26 p.m. PDT to add Google comment and correct Muller's name spelling.
Blocking the use of Adobe's flash to iPhone converter is CLEARLY anti-competitive by Apple. They want to lock in developers to only writing for iPhone, whereas the existance of a flash to iPhone converter would let you make all your apps in flash, and then sell them on any platform. This would be good for consumers and producers, but bad for apple since the reason the iPhone does so well is its many apps, if other phones had the same number of apps then iPhone sales would collapse.
edit - And honestly with the existance of the iPad this is going to become a bigger and bigger deal. If Apple doesn't change its tune (ie, allow third party app stores on the iPad and iPhone) I could see them running into numerous anti-trust problems espescially in europe.
Can someone explain to me again exactly how Disallowing flash development tools for the iPhone = Developers prevented from doing multiplatform development?
Can someone explain to me again exactly how Disallowing flash development tools for the iPhone = Developers prevented from doing multiplatform development?
Developers can do multiplatform development. Apple's move however has prevented anyone developing a middleware solution which allows portability of a code-base.
What Adobe were doing was creating a system which ran Flash on the iPhone in a bundled app solution. This means that whatever ran on the iPhone would also run on any other device which could run flash, or for which Adobe wrote a compatibility layer.
Without the ability to use anything like that, trying to make apps designed to run on portable devices, well, portable, is going to be nigh impossible (i.e. pretty much equivalent to rewriting from scratch most of the time).
Can someone explain to me again exactly how Disallowing flash development tools for the iPhone = Developers prevented from doing multiplatform development?
Developers can do multiplatform development. Apple's move however has prevented anyone developing a middleware solution which allows portability of a code-base.
What Adobe were doing was creating a system which ran Flash on the iPhone in a bundled app solution. This means that whatever ran on the iPhone would also run on any other device which could run flash, or for which Adobe wrote a compatibility layer.
Without the ability to use anything like that, trying to make apps designed to run on portable devices, well, portable, is going to be nigh impossible (i.e. pretty much equivalent to rewriting from scratch most of the time).
And what about things like PhoneGap which are reported to still be supported?
Blocking the use of Adobe's flash to iPhone converter is CLEARLY anti-competitive by Apple.
It is their platform.
Is Nintendo being anti-competitive by only allowing licensed games to run on their hardware?
I'm not really familiar enough with Nintendo's game development process to determine if that's a legitimate argument. I would GUESS the answer is yes, though. Just like Microsoft or Sony. But this is why there's such a big deal about "exclusive" titles. A good example of this would be Castle Crashers for 360. It's a relatively simple game, but has had to be almost completely redone for its release on PS3.
With app development, the developers have no such agreements that they'll develop SOLELY for Apple. However, by forcing devs to write using Apple's code means that they can't just make an easy port to say... a Palm Pre. If it were a flash-based code (as an example), it would be relatively easy to make that app available to all mobile devices that support Flash.
This is Apple's way of keeping all the players in their court.
If you develop a nintendo DS game and submit it to nintendo and nintendo decides they don't like it (for any reason) then they have every right to prevent you from distributing that game up to and including technological barriers built into the wii hardware and software
If you develop a nintendo DS game and submit it to nintendo and nintendo decides they don't like it (for any reason) then they have every right to prevent you from distributing that game up to and including technological barriers built into the wii hardware and software
But they don't have the right to make it so you can't develop for anyone else (a lesson that Nintendo found out the hard way, mind you.) That's what makes Apple's actions anti-competitive - it's not about controlling the App Store, it's about raising the barriers to cross-platform development.
But they don't have the right to make it so you can't develop for anyone else (
Sure they do, they could say "we won't license this game because you used some API we don't like" and that would be the end of it, regardless of whether that API makes it easier for you to develop for multiple platforms
If you develop a nintendo DS game and submit it to nintendo and nintendo decides they don't like it (for any reason) then they have every right to prevent you from distributing that game up to and including technological barriers built into the wii hardware and software
But they don't have the right to make it so you can't develop for anyone else (a lesson that Nintendo found out the hard way, mind you.) That's what makes Apple's actions anti-competitive - it's not about controlling the App Store, it's about raising the barriers to cross-platform development.
you do realize that Nintendo's method of "You can't develop for anyone else" was entirely different from what Apple's doing, right?
Apple isn't saying "you can only develop for iPhone OS if you want to develop for it.," they're saying you can't use certain kinds of middleware (again, certain kinds; PhoneGap is still fine), but developing on other platforms is fine.
Everyone else is interpreting it to be rooted in anticompetitive behavior.
I mean, it's not like they're banning developers who make android versions of their apps, they're just imposing shitty guidelines to make that more difficult to accomplish and it's their platform so what can you do
If you develop a nintendo DS game and submit it to nintendo and nintendo decides they don't like it (for any reason) then they have every right to prevent you from distributing that game up to and including technological barriers built into the wii hardware and software
But they don't have the right to make it so you can't develop for anyone else (a lesson that Nintendo found out the hard way, mind you.) That's what makes Apple's actions anti-competitive - it's not about controlling the App Store, it's about raising the barriers to cross-platform development.
you do realize that Nintendo's method of "You can't develop for anyone else" was entirely different from what Apple's doing, right?
Apple isn't saying "you can only developing for iPhone OS," they're saying you can't use certain kinds of middleware (again, certain kinds; PhoneGap is still fine), but developing on other platforms is fine.
Everyone else is interpreting it to be rooted in anticompetitive behavior.
Because what they're saying is "sure, you can develop for other platforms - we're just going to make it really hard to do so and develop for us." And you keep on bringing up PhoneGap, while failing to realize that by itself, PhoneGap is a very lightweight framework that doesn't give you access to the internals like frameworks like MonoTouch do.
And the only difference between Apple and Nintendo's approach is the level of blatancy - Nintendo came out and actually said it, Apple's just throwing every roadblock they can without stating what everyone knows.
Right, nobody denied any of this, what I am saying is this is not, strictly speaking, anti-competitive
I mean apple have a pretty clear track record of anti-competitive behaviour but this is far from the worst thing they have done
iphone devs are just as free to develop for other handhelds now as they were before
No, they're not.
And yes, Apple's just skirting the edge of the letter of the law - that's what they pay their lawyers for. But remember, these are the same lawyers who tried to wipe their ass with the First Amendment.
besides, the availability of cheap multiplatform middleware would result in a deluge of terrible apps on all platforms
This is true, but I don't think it's very relevant. I mean, there's really no shortage of shitty fucking shovelware if you go looking, and no doubt Adobe's tools would in fact provide us with even more shitty fucking shovelware, but that is true of literally anything which makes it easier to bring a product to market; there will always be more shit than gold, and while it's easy to imagine that Flash in particular would be responsible for some awful shit, it's probable that it would also account for at least a little bit of gold.
Mind you, I hate Flash and the best thing about any of this is that Apple apparently agrees with me. Their calculus, as I imagine it, is probably more along the lines of having dealt with umpteen-million Safari bugs (that were actually Flash bugs) and watching Adobe Reader constantly vulnerable to not less than three unpatched exploits, and they just threw their hands up in the air and said "fuck it, we are sick of Adobe's shit." The thin tolerances of the iPad's processor for the sort of Flash-enabled bullshit that keeps even multicore desktops from handling too many tabs in Firefox probably sealed the deal.
Apple sees this as an issue relating to their product's quality, and so long as Flash-addled websites can bring a quad-core to its knees, there's a bit of truth in that. It's possible Apple did include the shovelware question into their considerations; perhaps the shit/gold ratio they ended up predicting was out of line with their vision for the App store. But Apple is an unusual company and this is a pretty unusual move even by their standards. Generally speaking, more applications on your platform is a good thing even if those applications are mostly terrible. After all, if a glut of terrible apps could change a beacon of excellence into an embarrassment, nobody would be hailing the wonders of the app store.
Any developer wanting to "port" their iphone app to android will simply have to start from scratch, and when I say from scratch what I actually mean is they have all their requirements, data structures, test cases, and vital program logic in hand so they're pretty much halfway there already. All that remains is to learn the Android platform and classes and figure out how to get the XML layouts working and then write the code in Java. It's inconvenient and costly, sure, but nobody is telling them they are not allowed to do it. And from the stakeholder's point of view, this means both versions of the app were made by someone who knew what he was doing. So I don't see what the problem is here, really.
Mind you, I hate Flash and the best thing about any of this is that Apple apparently agrees with me. Their calculus, as I imagine it, is probably more along the lines of having dealt with umpteen-million Safari bugs (that were actually Flash bugs) and watching Adobe Reader constantly vulnerable to not less than three unpatched exploits, and they just threw their hands up in the air and said "fuck it, we are sick of Adobe's shit." The thin tolerances of the iPad's processor for the sort of Flash-enabled bullshit that keeps even multicore desktops from handling too many tabs in Firefox probably sealed the deal.
I'd find that argument more persuasive if Safari didn't go down on day one of Pwn2Own three years running.
I like flash, it's a great toolkit for making little games and cartoons and stuff. It's a shame it had to become a vehicle for inexperienced people to make professional-looking "applications"
Any developer wanting to "port" their iphone app to android will simply have to start from scratch, and when I say from scratch what I actually mean is they have all their requirements, data structures, test cases, and vital program logic in hand so they're pretty much halfway there already. All that remains is to learn the Android platform and classes and figure out how to get the XML layouts working and then write the code in Java. It's inconvenient and costly, sure, but nobody is telling them they are not allowed to do it. And from the stakeholder's point of view, this means both versions of the app were made by someone who knew what he was doing. So I don't see what the problem is here, really.
Yeah, pretty much. The actual "coding" part isn't too much of a hassle once you have all the implementation details already figured out. In fact the Android app will probably turn out better since at that point you already have fixed a lot of bugs and improved your design thanks to user feedback and data from the apple platform.
I think the best part is people assuming phones are all easy to cross-develop on in the first place, and Apple is suddenly throwing a wrench in the works.
That's probably the biggest "L" "O" "L" ever. Especially when Adobe's idea of cross platform still requires you to make special versions of your project for each device.
Any developer wanting to "port" their iphone app to android will simply have to start from scratch, and when I say from scratch what I actually mean is they have all their requirements, data structures, test cases, and vital program logic in hand so they're pretty much halfway there already. All that remains is to learn the Android platform and classes and figure out how to get the XML layouts working and then write the code in Java. It's inconvenient, sure, but nobody is telling them they are not allowed to do it.
And if you really think "they're halfway there"...I really don't know what to say to that. First off, even if you have all the technical documents, test cases, etc. written, rebuilding your app in a new language is a significant task in of itself - look at how much time it took to create the 360 port of FFXIII. Second, there's the issue of keeping the code bases in sync - if you add a feature in one, you have to add it to the other - meaning you're maintaining two programs.
These are not little hiccups, these are major issues to be worked out, and for a lot of smaller developers, they may feel forced by Apple's decision and basic economics to abandon cross-platform development.
iPhone OS is fundamentally different from android in many ways. I don't doubt that some clever person would eventually have managed to write some tool for cross-platform development but let's not kid ourselves here. It would be inredibly obtuse, it would be ugly as sin, it would probably generate awful code that is next to impossible to debug manually, there would be a sickening multitude of bugs, and trying to maintain consistency between the two versions would probably represent as much, if not more work in the long run than just having two separate projects on two separate platforms
how is a complete monopoly on development tools for a platform not a monopoly?
Because they also developed the platform?
Nintendo does the same thing. This is a silly question.
No, they don't. Please show me where they tell their developers what tools they are allowed to use to develop games?
In the licensing agreement? You can only use approved middleware and toolchains on the Wii. And you can't use any open source code at all, which disqualifies a bunch of middleware.
how is a complete monopoly on development tools for a platform not a monopoly?
Because they also developed the platform?
Nintendo does the same thing. This is a silly question.
No, they don't. Please show me where they tell their developers what tools they are allowed to use to develop games?
In the licensing agreement? You can only use approved middleware and toolchains on the Wii. And you can't use any open source code at all, which disqualifies a bunch of middleware.
Well, then Nintendo's in the wrong as well. And you'd think they would know better.
iPhone OS is fundamentally different from android in many ways. I don't doubt that some clever person would eventually have managed to write some tool for cross-platform development but let's not kid ourselves here. It would be inredibly obtuse, it would be ugly as sin, there would be a sickening multitude of bugs, and trying to maintain consistency between the two versions (and I don't mean trivial things like "I want to add this feature and I only want to do the work once" I mean horrible nightmares like "this text label is misaligned on android but it looks right in my cross platform toolkit I don't know what's going on") would probably represent as much, if not more work in the long run than just having two separate projects on two separate platforms
How about the idea that it's okay for bad programs to exist? It'd be excellent if every single program out there was unique, beautiful, bug-free, and did amazingly amazing things native to the OS it was written for, but I don't think that is a necessity and I don't think it's something that should necessarily be pushed toward.
To me, this is equivalent to censorship. If developers and publishers want to make and release substandard ports, so be it. The market will invariably reject those anyway.
I'm really not seeing the harm in the existence of "tons" of shitty programs. If they suck, don't buy them. Is the main argument here really against a bloated menu of purchasable apps? Because I'd rather that the alternative. I think that even one potentially good program lost to something like this is a tragedy.
Posts
Nice.
EDIT: Also not really what I'd class as gesture recognition because its not recognizing mouse input its recognizing a difference I as the user make to the device i.e. using two fingers rather then one.
The gestures I'm against is stuff where you draw some pattern with the mouse and it does a thing.
I thought the Magic Mouse supported the exact same gestures as the MacBook trackpad, i.e. pinch-to-zoom etc.
Am I wrong?
Apple limited it to only allow for scrolling, and swiping back and forth between pages.
With a little app called MagicPrefs, you can enable as many of the iPhone gestures as you are comfortable with. My only warning is that it is a lot harder to pull them off on a moving thing like a mouse than it is a stationary input like a trackpad or iPhone screen. So I generally only have about 5-6 functions bound at any time that I know work (4 finger tap for instance).
Let's play Mario Kart or something...
http://news.cnet.com/8301-30685_3-20003006-264.html
edit - And honestly with the existance of the iPad this is going to become a bigger and bigger deal. If Apple doesn't change its tune (ie, allow third party app stores on the iPad and iPhone) I could see them running into numerous anti-trust problems espescially in europe.
Developers can do multiplatform development. Apple's move however has prevented anyone developing a middleware solution which allows portability of a code-base.
What Adobe were doing was creating a system which ran Flash on the iPhone in a bundled app solution. This means that whatever ran on the iPhone would also run on any other device which could run flash, or for which Adobe wrote a compatibility layer.
Without the ability to use anything like that, trying to make apps designed to run on portable devices, well, portable, is going to be nigh impossible (i.e. pretty much equivalent to rewriting from scratch most of the time).
That's what I think is so funny about all of this.
If Apple actually takes over one of these markets fully (phone/slate) then they really are liable to end up in a breach of anti-trust laws.
Imagine if the iPod ONLY allowed you load music purchased via iTunes. We'd have seen the lawsuits already.
And what about things like PhoneGap which are reported to still be supported?
Is Nintendo being anti-competitive by only allowing licensed games to run on their hardware?
I'm not really familiar enough with Nintendo's game development process to determine if that's a legitimate argument. I would GUESS the answer is yes, though. Just like Microsoft or Sony. But this is why there's such a big deal about "exclusive" titles. A good example of this would be Castle Crashers for 360. It's a relatively simple game, but has had to be almost completely redone for its release on PS3.
With app development, the developers have no such agreements that they'll develop SOLELY for Apple. However, by forcing devs to write using Apple's code means that they can't just make an easy port to say... a Palm Pre. If it were a flash-based code (as an example), it would be relatively easy to make that app available to all mobile devices that support Flash.
This is Apple's way of keeping all the players in their court.
What does that have to do with development?
But they don't have the right to make it so you can't develop for anyone else (a lesson that Nintendo found out the hard way, mind you.) That's what makes Apple's actions anti-competitive - it's not about controlling the App Store, it's about raising the barriers to cross-platform development.
you do realize that Nintendo's method of "You can't develop for anyone else" was entirely different from what Apple's doing, right?
Apple isn't saying "you can only develop for iPhone OS if you want to develop for it.," they're saying you can't use certain kinds of middleware (again, certain kinds; PhoneGap is still fine), but developing on other platforms is fine.
Everyone else is interpreting it to be rooted in anticompetitive behavior.
And the only difference between Apple and Nintendo's approach is the level of blatancy - Nintendo came out and actually said it, Apple's just throwing every roadblock they can without stating what everyone knows.
I mean apple have a pretty clear track record of anti-competitive behaviour but this is far from the worst thing they have done
iphone devs are just as free to develop for other handhelds now as they were before
No, they're not.
And yes, Apple's just skirting the edge of the letter of the law - that's what they pay their lawyers for. But remember, these are the same lawyers who tried to wipe their ass with the First Amendment.
This is true, but I don't think it's very relevant. I mean, there's really no shortage of shitty fucking shovelware if you go looking, and no doubt Adobe's tools would in fact provide us with even more shitty fucking shovelware, but that is true of literally anything which makes it easier to bring a product to market; there will always be more shit than gold, and while it's easy to imagine that Flash in particular would be responsible for some awful shit, it's probable that it would also account for at least a little bit of gold.
Mind you, I hate Flash and the best thing about any of this is that Apple apparently agrees with me. Their calculus, as I imagine it, is probably more along the lines of having dealt with umpteen-million Safari bugs (that were actually Flash bugs) and watching Adobe Reader constantly vulnerable to not less than three unpatched exploits, and they just threw their hands up in the air and said "fuck it, we are sick of Adobe's shit." The thin tolerances of the iPad's processor for the sort of Flash-enabled bullshit that keeps even multicore desktops from handling too many tabs in Firefox probably sealed the deal.
Apple sees this as an issue relating to their product's quality, and so long as Flash-addled websites can bring a quad-core to its knees, there's a bit of truth in that. It's possible Apple did include the shovelware question into their considerations; perhaps the shit/gold ratio they ended up predicting was out of line with their vision for the App store. But Apple is an unusual company and this is a pretty unusual move even by their standards. Generally speaking, more applications on your platform is a good thing even if those applications are mostly terrible. After all, if a glut of terrible apps could change a beacon of excellence into an embarrassment, nobody would be hailing the wonders of the app store.
Any developer wanting to "port" their iphone app to android will simply have to start from scratch, and when I say from scratch what I actually mean is they have all their requirements, data structures, test cases, and vital program logic in hand so they're pretty much halfway there already. All that remains is to learn the Android platform and classes and figure out how to get the XML layouts working and then write the code in Java. It's inconvenient and costly, sure, but nobody is telling them they are not allowed to do it. And from the stakeholder's point of view, this means both versions of the app were made by someone who knew what he was doing. So I don't see what the problem is here, really.
I'd find that argument more persuasive if Safari didn't go down on day one of Pwn2Own three years running.
Because they also developed the platform?
Nintendo does the same thing. This is a silly question.
Yeah, pretty much. The actual "coding" part isn't too much of a hassle once you have all the implementation details already figured out. In fact the Android app will probably turn out better since at that point you already have fixed a lot of bugs and improved your design thanks to user feedback and data from the apple platform.
That's probably the biggest "L" "O" "L" ever. Especially when Adobe's idea of cross platform still requires you to make special versions of your project for each device.
And if you really think "they're halfway there"...I really don't know what to say to that. First off, even if you have all the technical documents, test cases, etc. written, rebuilding your app in a new language is a significant task in of itself - look at how much time it took to create the 360 port of FFXIII. Second, there's the issue of keeping the code bases in sync - if you add a feature in one, you have to add it to the other - meaning you're maintaining two programs.
These are not little hiccups, these are major issues to be worked out, and for a lot of smaller developers, they may feel forced by Apple's decision and basic economics to abandon cross-platform development.
Then why did it matter what Microsoft did with their own operating system?
No, they don't. Please show me where they tell their developers what tools they are allowed to use to develop games?
In the licensing agreement? You can only use approved middleware and toolchains on the Wii. And you can't use any open source code at all, which disqualifies a bunch of middleware.
Well, then Nintendo's in the wrong as well. And you'd think they would know better.
Their house, their rules.
How about the idea that it's okay for bad programs to exist? It'd be excellent if every single program out there was unique, beautiful, bug-free, and did amazingly amazing things native to the OS it was written for, but I don't think that is a necessity and I don't think it's something that should necessarily be pushed toward.
To me, this is equivalent to censorship. If developers and publishers want to make and release substandard ports, so be it. The market will invariably reject those anyway.
I'm really not seeing the harm in the existence of "tons" of shitty programs. If they suck, don't buy them. Is the main argument here really against a bloated menu of purchasable apps? Because I'd rather that the alternative. I think that even one potentially good program lost to something like this is a tragedy.