Uh, I guess you've never read much about Steve Jobs.
LTMP said (paraphrasing) "Apple is an astute company," and you replied with the above. Either you have some major personal issues with SJ here, or you are unable to process basic English language.
I just read a comment to an article on the same subject over on Ars. The commenter is doormat. I do not have his permission to quote, but what the heck, its a great comment.
"I think you're missing Gruber's point - not that cross platform apps are bad, its that they underutilize the platform to its fullest potential. [...]
The point is that Apple isn't going to wait for others (Monotouch, Adobe) to catch up with its OS releases. If they become the predominant tools in developing mobile apps, any innovation Apple puts into the OS isn't utilized unless its supported by Adobe or Monotouch. Kinda like Flash, Apple doesn't like relying on third parties in what it considers its "critical path" to the customer. If a link in the chain is outside of Apple's control its a liability for them. [...]"
Although Gruber did actually say that cross-platform apps pretty much suck, or at least that they historically have on Apple platforms, because they don't really support the features of the platform, this is pretty much what this is about. It's about preventing their platform from being commoditized by Adobe or Google or anyone else and turned into just a generic smartphone platform that isn't any different from, where apps and services are indistinguishable from, everything else.
And not only does Apple have every right to take whatever steps they deem necessary to prevent this commoditization, they would be fools not to. The idea that Apple must, or ought to, just sit by and allow other companies to define the user experience on the iPhone is simply ludicrous. But, that's exactly what those of you demanding you be allowed to develop for the iPhone using Flash or some other toolkit are saying. Well, Apple isn't in business for your benefit, or to be a host organism for Adobe or Google.
To developers depending on, or intending to depend on Flash or other non-Objective-C/Xcode solutions, I would say, get with the Objective-C program now if you want to develop for iPhone OS. Apple isn't going to back down on this issue because it's too important to the continued success of the iPhone and the iPad, and Apple. So, you can either whine about how unfair it is or you get to work in Objective-C, or you can not develop for iPhone. But, the bottom line is, it's Objective-C or nothing from here on out.
Agreed, better wait till you get something right. The new 4.0 looks awesome. Can't wait for the same abilities on iPad too. I was surprised Steve didn't mention that the iPad would also receive the same new features soon. I have to assume it will though.
Steve mentioned in the 4.0 keynote that Ipad will get the 4.0 update in the fall.
The primary reason for the change, say sources familiar with Apple's plans, is to support sophisticated new multitasking APIs in iPhone 4.0. The system will now be evaluating apps as they run in order to implement smart multitasking. It can't do this if apps are running within a runtime or are cross compiled with a foreign structure that doesn't behave identically to a native C/C++/Obj-C app.
Technically this makes no sense. There is no reason why a C program written by hand will be different with regard to multi-tasking than a C program generated by, say, a Scheme-to-C translator. And even if there were a runtime library, such as with Flash-to-iPhone compiler, there is no technical reason why such a runtime could not be multi-tasked.
I have worked with the innards of four different operating systems targetting eight different CPU architectures over the past 20 years, and this seems to me like a technical snowjob.
Apple does appear to have valid business reasons (i.e., protecting its platform franchise) to stifle competitors, but there are no good technical reasons that I can see, based on the arm-waving explanation provided in the blog post.
Aha ... So when people were bitching that iPhone OS didn't have multitasking they meant to say that it didn't have A shitty, poorly implemented, battery draining form of multitasking.
Well, that type of multitasking isn't poorly implemented or battery draining if you're willing to throw a big battery, fast CPU and a slug of RAM at the problem. The Nexus has 2X the RAM of the 3GS, half again as much battery and CPU speed, so it has more headroom to deal with the issues. Versus the 3G, it's even starker, and Apple doesn't even try to implement its non-shitty, well-implemented, battery-sipping multi-tasking ON A CURRENT MODEL.
A simple engineering/business choice. Having programmed for Macs since the very first model, I see a long history of minimized hardware; even so, the company has had to deal with low volumes and so necessarily higher prices. And I can cite other firms, like Sun, that bet the company on a gold-plated lineup just as the DotBomb exploded, showing that Apple is not simply being neurotic.
Still, Apple's implementation choices don't have to be the right ones for everybody. Multi-tasking on the Google phone is pretty sweet, as long as you don't tax it too hard and/or are willing to pace yourself on the number of apps, the same way that iPhone users have to pace themselves on the number of hours of surfing & talking between charges.
And even if there were a runtime library, such as with Flash-to-iPhone compiler, there is no technical reason why such a runtime could not be multi-tasked.
Somehow I doubt Adobe could make a Flash to iPhone compiler in such a short period of time.
Sounds more like a Flash + iPhone compatible Flash runtime bundled together.
Otherwise Adobe won't be so freaked out about it, because there is no way Apple can tell.
I find it hilarious that the same people who are bawling for Flash are also weeping that Apple is exerting proprietary control over the App Store platform it created. Of fucking course it doesn't want to enrich its competitors. Apple did all the work here.
There are some exceptions, but for the most part, I think the point being made by most people here isn't about addressing fairness / morality / competitiveness / whatever with regards to Apple's decision to do this; rather, issue is being taken with the given reason for the decision, as quoted by AI in TFA. In the article, it is suggested that this decision is for technical rather than business reasons. We (I) simply don't accept that as technically valid.
Having said that, I do think it would be nice to hear the reasoning direct from Apple. Then we could get into the philosophical discussion without all the need for speculation.
Just stop stepping outside the bounds of your expertise or intelligence in order to awkwardly invent ridiculous justifications for Apple's bullshit. Face it, every company both fails and makes profit driven choices that are wrong by standards of decency.
Apple can pick any number of options for dealing with such technical issues if they even exist. Here are a few no-brainers
a) Not all apps can multitask until upgraded to compatibility requirements. Having some ice cream is always better than none. This is typical with software, and how the real OSX handles OS updates. It works and everyone is happy.
b) Adapt license agreement to include agreement for officially sanctioned 3rd party developer tools. To stay in the club Flash, Unity3D, Corona, Mono, have to keep up with .ipa standards. Apps that fall behind the standard eventually get removed from storefront & iphone during critical upgrades like OS4
c) Copy Backgrounder with apps that arent up to standards & give users a simple popup setting to notify user that its a battery killer app and ask if they want to allow background access or not.
Any good software firm especially Apple, could implement an elegant solution. This article is wrong, reading a few fanboy comments one can barely stand to use the same OS as the people making suh douche-ridden comments.
When was the last time Adobe, Microsoft, Apple released open source on their key software?
Well with both Adobe and Microsoft you can get other tools to compile into there run times. Both of them even give away a command line compiler that could be used by the third party IDE to do it with. So I don't really know what your getting at.
Quote:
Originally Posted by lowededwookie
But isn't Objective-C available to ALL the major platforms? If you want to take the least amount of time to get apps running on all platforms you choose the language that is available to all platforms and work around the ugly bits within the language.
To be honest I don't really know. But speaking as someone thats a .NET developer, I wouldn't want to go back to the version of .NET languages from 5 years ago due to the amount thats changed in that time. Then there's lot's of arguments that writing in Xcode also takes a lot longer.
End of the day in the arguments of what's better, when you work with these languages that have 1000s of components it takes a few years to get really good and know them all. Being forced to use one particular tool just takes you backwards and to a large extent really goes against the development community. Developers like to create, not be restricted.
Quote:
Originally Posted by Alfiejr
The answer is many developers and users have simply become addicted to it. like cheap drugs. when it was new it was the first good solution to a huge problem - a great high! - so it was widely embraced. ok. eventually it achieved near monopoly status in its category. but now there is a rival, Silveright/MS, and a new kid in town, HTML5/Apple. but the Flash mob won't switch, they're hooked. (and some make their living from it, of course, so you can understand their alarm.)
but nobody owes Adobe anything. their stewardship of Flash when it had to the market to itself was poor. stay addicted to it or kick the habit, but please drop the moral posturing.
This isn't an argument about Flash as you see in your browser, it's about flash the development tool or not even that, its about using any development environment. It would be like if the iPhone was actually running on HTML5 and Apple suddenly said that apps had to be made in their HTML5 IDE rather than using anyone elses.
Just stop stepping outside the bounds of your expertise or intelligence in order to awkwardly invent ridiculous justifications for Apple's bullshit. Face it, every company both fails and makes profit driven choices that are wrong by standards of decency.
Nice first post to AI forums... It appears you joined within the last 9 days... possibly just now, to post this message.
After reading through a series of posts by people who regularly visit these forums, most of us can discern the poster's demeanor, morality, expertise and intelligence.
Since you have no established track record, please enlighten us with your qualifications in these areas... so we can better determine the soundness of your reasoning.
Quote:
Apple can pick any number of options for dealing with such technical issues if they even exist. Here are a few no-brainers
a) Not all apps can multitask until upgraded to compatibility requirements. Having some ice cream is always better than none. This is typical with software, and how the real OSX handles OS updates. It works and everyone is happy.
Not sure I understand this. Are you implying that a poorly-performing program is better than having no program at all?
If so, I agree, that this may be true for some audiences. But, consider, who is the target audience of the iPhone: The non-technical person who just wants to get in; do something; get out. Ideally, each program will perform and behave in an expected way... like all the other apps, they just work
If an end user buys an app from Apple and runs it on an Apple device, he has reason to expect that it will behave like other apps. If it does not, he is likely to blame Apple as well as the provider of the app.
Quote:
b) Adapt license agreement to include agreement for officially sanctioned 3rd party developer tools. To stay in the club Flash, Unity3D, Corona, Mono, have to keep up with .ipa standards. Apps that fall behind the standard eventually get removed from storefront & iphone during critical upgrades like OS4
This is one valid way to assure that apps comply with standards. However, there are several difficulties:
1) Apple has to spend valuable resources to train themselves, evaluate, monitor and negotiate solutions to problems with any 3rd-party tools.
2) Allowing a 3rd party tool, then, later, disallowing it (even for valid reasons) puts the burden of proof (and the effort entailed) on Apple-- for a tool that is out of their control.
3) Should 2 occur, where does that leave customers who have purchased that app? Will they no longer receive updates because Apple has disapproved a previously approved tool?
4) What are the legal ramifications of this?
Quote:
c) Copy Backgrounder with apps that arent up to standards & give users a simple popup setting to notify user that its a battery killer app and ask if they want to allow background access or not.
If I understand it, you are suggesting that Apple should sell and distribute apps that are known to be "not up to standard", or at best, "unknown if up to standard".
Then, after the user has bought, downloaded and installed the app, he gets a "popup" that suggests he may have made a bad decision.
That is exactly the last thing you want to do, if you are Apple (or any other company).
First, the fact a store carries a product implies that the store thinks it meets their standards (or they wouldn't be selling it).
If the store has a problem, they pull the product and resolve the issue with the vendor... without involving their customer.
If the vendor has a history of supplying products that are "not up to standard" the burden is placed on the vendor to correct this before the store agrees to sell the vendors products.
Quote:
Any good software firm especially Apple, could implement an elegant solution.
Yes, they can provide an elegant solution. That appears to be what Apple is trying to do. It appears that they have decided that 3rd-party cross-compiler/generator tools may not meet their minimum standard at this time.
Say, Apple has some analysis tools and 50 people talented enough to use them and interpret the results. Apple is not accepting programs that were created by tools which are out of Apple's control (and by definition, are out of date).
By doing this, Apple is focusing their talents on apps created known tools which are under Apple's control and understood by Apple's evaluation team. Its a matter of efficiency, allocation of resources, and ROI.
Those are technical reasons.
Quote:
This article is wrong, reading a few fanboy comments one can barely stand to use the same OS as the people making suh douche-ridden comments.
A final reason, that many have suggested (including me), is that it does not make good business sense for Apple to support development tools which allow developers to create a single, one-size-fits-all, app that will run on competitors ' platforms, rather than exploit the specific advantages of Apple's platforms.
That's a pure business decision. As a user, customer, and stockholder... I support it!
Well, that type of multitasking isn't poorly implemented or battery draining if you're willing to throw a big battery, fast CPU and a slug of RAM at the problem. The Nexus has 2X the RAM of the 3GS, half again as much battery and CPU speed, so it has more headroom to deal with the issues. Versus the 3G, it's even starker, and Apple doesn't even try to implement its non-shitty, well-implemented, battery-sipping multi-tasking ON A CURRENT MODEL.
A simple engineering/business choice. Having programmed for Macs since the very first model, I see a long history of minimized hardware; even so, the company has had to deal with low volumes and so necessarily higher prices. And I can cite other firms, like Sun, that bet the company on a gold-plated lineup just as the DotBomb exploded, showing that Apple is not simply being neurotic.
Still, Apple's implementation choices don't have to be the right ones for everybody. Multi-tasking on the Google phone is pretty sweet, as long as you don't tax it too hard and/or are willing to pace yourself on the number of apps, the same way that iPhone users have to pace themselves on the number of hours of surfing & talking between charges.
And the way Android do multitasking is exactly the same that Apple has implemented on 4.0.
Daniel Eran doesn't know it, it's a waste of time trying to do a bit of research if the reality collides with his own view of reality.
And the way Android do multitasking is exactly the same that Apple has implemented on 4.0.
Daniel Eran doesn't know it, it's a waste of time trying to do a bit of research if the reality collides with his own view of reality.
No it's not. Android has true multi-tasking. (ie. the ability to run any app in the background continuously, not just an Apple approved small sub set of functions)
Those "anti-competitive business reasons" have changed the computer industry from the stagnant crap hole it has always been into a forward moving computer manufacturer changing the way we work with computers and mobile devices. It's all been for the good of the consumer even if they did step on some people's toes to do it.
They controlled the hardware so were in a position to jump from 68000 to PPC and later from PPC to Intel. Yes it annoyed a lot of developers but the ones who did well were the ones who changed as soon as possible. It also mean the latest developments in computing had a platform that could be progress their technology. Apple killed off ADB, Serial, and Parallel in favour of USB, it killed off VGA in favour of DVI and DVI in favour of DisplayPort because it makes sense in the long run.
You can all complain as much as you want now but in the future you will look back and realise that this was the turning point in computing where developers moved forward instead of using old worthless technology.
Could this be a key reason Apple product hold their value for so long? Apple uses new concepts that when they eventually become mainstream have already been found to have been on the Apple product for years.
Android, continuously eating up limited power reserves and wasting CPU cycles on a resource limited mobile platform.
Is any Android mobile device permanently hooked up to the Hoover Dam?
Battery life on a Nexus One is pretty similar to a 3GS, and miles better than my iPhone 3G.
You can achieve good results simply through good software engineering you know. Have you considered the possibility that Android is just a more efficient, better engineered OS than the iPhone OS?
Additionally, that fact that Apple introduced its Push Notifications service first means that most iPhone apps are already designed to respond to outside events efficiently. On the BlackBerry OS, for example, apps that run in the background often inefficiently poll their servers, a big tax on battery life. This is somewhat ironic because Blackberry is renowned for running its own push services, it just didn't open these to developers until third party software had largely already rolled their own solutions.
When was the last time that you heard Blackberry users complain about battery life? RIM didn't need to implement push notifications for apps and so didn't.
... To developers depending on, or intending to depend on Flash or other non-Objective-C/Xcode solutions, I would say, get with the Objective-C program now if you want to develop for iPhone OS. Apple isn't going to back down on this issue because it's too important to the continued success of the iPhone and the iPad, and Apple. ....
Another problem which is kind of an "Elephant in the room" no one is speaking about is the very idea that someone who is good at Flash scripting is someone we should be calling a "developer," at least in the context of this discussion.
I am very good at several different scripting languages myself, but I wouldn't equate this knowledge to "being a developer" (of apps). The two different software packages I primarily work with, can both also create executable files that are indistinguishable from an "app" (for Mac not iPhone OS) to the end user, but I still wouldn't label myself a "developer" as a result.
The more I look at it, the more I think that the whole idea that there are application "developers" who want to use Flash as their "coding language" of choice is just a total boondoggle. There are no such "developers" in this context. If you are using Flash, it doesn't mean you are dumber or less capable than someone who knows C, C++, etc., but it doesn't make you a "developer" either IMO.
.. It's a completely different equation if the entire codebase has to be ported to ObjC. Yah, so for us it's going to take a lot longer to get onto the platform if Monotouch is out of the equation. It's not the inability from a technical perspective but the inability from a business/resource perspective.
Interesting real-world examples. Something typically missing from these kinds of debates.
It seems to me that if you are not already using XCode for the "desktop" part of your business though, that your desktop apps are already cross-platform, so perhaps Apple's decision here will have a side effect of pushing shops like yours to either go full-on Mac, or leave it altogether.
At the very least it seems like if a developer is using "foreign" (non-XCode) tools it will only be efficient to target *either* the Mac desktop (as a port), *or* the iPhone in addition to the non-Mac stuff. If you are doing iPhone OS and Desktop OS-X integration or apps that run in both, then Apple is very strongly pushing you into XCode I suppose.
Interesting real-world examples. Something typically missing from these kinds of debates.
It seems to me that if you are not already using XCode for the "desktop" part of your business though, that your desktop apps are already cross-platform, so perhaps Apple's decision here will have a side effect of pushing shops like yours to either go full-on Mac, or leave it altogether.
At the very least it seems like if a developer is using "foreign" (non-XCode) tools it will only be efficient to target *either* the Mac desktop (as a port), *or* the iPhone in addition to the non-Mac stuff. If you are doing iPhone OS and Desktop OS-X integration or apps that run in both, then Apple is very strongly pushing you into XCode I suppose.
It could mean going all XCode or leaving the platform. Historically, with the Mac side of things, it meant the Mac versions languished behind the Windows versions. In our company, we do primarily Windows software, with Mac, Linux and Netware ports of some products or components. Unfortunately, what this means is that the Mac code sits generally idle until someone decides to fire up XCode on one of the Macs and does a build to see what code has broken. Since we do mainly C and C++, much of the code itself if generally pretty portable. The Mac port has some Mac specific work, but generally it is just a matter of building it on the Mac. There is always the chance that something has broken between builds, though. In those cases we have to spend time and resources making changes to fix the Mac build without breaking the Windows build. It was worse when we used Metroworks.
This decision won't affect us much, since we don't really use ObjC at all. There have been some informal discussions recently about doing a new mobile app as part of our other desktop/server suites, but it isn't really even on the radar yet. One way that this decision might impact the execs in their planning is that we are in the heart of RIM land and even share office space with them. If were were to do a mobile app, we would have to include BB, in fact it would at first be the primary platform, given the product lines. Google Canada's dev office is very close as well, where they mainly do mobile platform work. Networking with devs and managers from these companies is frequent, so of course running on those platforms would be on the table in any case. If we had to have to completely different code bases for the mobile apps, there is a good chance the iPhone version would be delayed and would end up behind the other versions.
As I said, this decision won't impact us very much for now. In the end, the market decides for us. If our clients need the iPhone app, it will happen. There are undeniable repercussions, however.
Edit: The above had nothing to do with the prohibition against Flash or similarly ported code. Only the apparent requirement "that all iPhone apps begin as native development using its own Xcode tools".
Edit2: Does anyone remember the OpenStep days, where write once run anywhere was an objective and not a taboo?
Comments
Uh, I guess you've never read much about Steve Jobs.
LTMP said (paraphrasing) "Apple is an astute company," and you replied with the above. Either you have some major personal issues with SJ here, or you are unable to process basic English language.
I just read a comment to an article on the same subject over on Ars. The commenter is doormat. I do not have his permission to quote, but what the heck, its a great comment.
"I think you're missing Gruber's point - not that cross platform apps are bad, its that they underutilize the platform to its fullest potential. [...]
The point is that Apple isn't going to wait for others (Monotouch, Adobe) to catch up with its OS releases. If they become the predominant tools in developing mobile apps, any innovation Apple puts into the OS isn't utilized unless its supported by Adobe or Monotouch. Kinda like Flash, Apple doesn't like relying on third parties in what it considers its "critical path" to the customer. If a link in the chain is outside of Apple's control its a liability for them. [...]"
Although Gruber did actually say that cross-platform apps pretty much suck, or at least that they historically have on Apple platforms, because they don't really support the features of the platform, this is pretty much what this is about. It's about preventing their platform from being commoditized by Adobe or Google or anyone else and turned into just a generic smartphone platform that isn't any different from, where apps and services are indistinguishable from, everything else.
And not only does Apple have every right to take whatever steps they deem necessary to prevent this commoditization, they would be fools not to. The idea that Apple must, or ought to, just sit by and allow other companies to define the user experience on the iPhone is simply ludicrous. But, that's exactly what those of you demanding you be allowed to develop for the iPhone using Flash or some other toolkit are saying. Well, Apple isn't in business for your benefit, or to be a host organism for Adobe or Google.
To developers depending on, or intending to depend on Flash or other non-Objective-C/Xcode solutions, I would say, get with the Objective-C program now if you want to develop for iPhone OS. Apple isn't going to back down on this issue because it's too important to the continued success of the iPhone and the iPad, and Apple. So, you can either whine about how unfair it is or you get to work in Objective-C, or you can not develop for iPhone. But, the bottom line is, it's Objective-C or nothing from here on out.
Agreed, better wait till you get something right. The new 4.0 looks awesome. Can't wait for the same abilities on iPad too. I was surprised Steve didn't mention that the iPad would also receive the same new features soon. I have to assume it will though.
Steve mentioned in the 4.0 keynote that Ipad will get the 4.0 update in the fall.
The primary reason for the change, say sources familiar with Apple's plans, is to support sophisticated new multitasking APIs in iPhone 4.0. The system will now be evaluating apps as they run in order to implement smart multitasking. It can't do this if apps are running within a runtime or are cross compiled with a foreign structure that doesn't behave identically to a native C/C++/Obj-C app.
Technically this makes no sense. There is no reason why a C program written by hand will be different with regard to multi-tasking than a C program generated by, say, a Scheme-to-C translator. And even if there were a runtime library, such as with Flash-to-iPhone compiler, there is no technical reason why such a runtime could not be multi-tasked.
I have worked with the innards of four different operating systems targetting eight different CPU architectures over the past 20 years, and this seems to me like a technical snowjob.
Apple does appear to have valid business reasons (i.e., protecting its platform franchise) to stifle competitors, but there are no good technical reasons that I can see, based on the arm-waving explanation provided in the blog post.
Aha ... So when people were bitching that iPhone OS didn't have multitasking they meant to say that it didn't have A shitty, poorly implemented, battery draining form of multitasking.
Well, that type of multitasking isn't poorly implemented or battery draining if you're willing to throw a big battery, fast CPU and a slug of RAM at the problem. The Nexus has 2X the RAM of the 3GS, half again as much battery and CPU speed, so it has more headroom to deal with the issues. Versus the 3G, it's even starker, and Apple doesn't even try to implement its non-shitty, well-implemented, battery-sipping multi-tasking ON A CURRENT MODEL.
A simple engineering/business choice. Having programmed for Macs since the very first model, I see a long history of minimized hardware; even so, the company has had to deal with low volumes and so necessarily higher prices. And I can cite other firms, like Sun, that bet the company on a gold-plated lineup just as the DotBomb exploded, showing that Apple is not simply being neurotic.
Still, Apple's implementation choices don't have to be the right ones for everybody. Multi-tasking on the Google phone is pretty sweet, as long as you don't tax it too hard and/or are willing to pace yourself on the number of apps, the same way that iPhone users have to pace themselves on the number of hours of surfing & talking between charges.
And even if there were a runtime library, such as with Flash-to-iPhone compiler, there is no technical reason why such a runtime could not be multi-tasked.
Somehow I doubt Adobe could make a Flash to iPhone compiler in such a short period of time.
Sounds more like a Flash + iPhone compatible Flash runtime bundled together.
Otherwise Adobe won't be so freaked out about it, because there is no way Apple can tell.
I find it hilarious that the same people who are bawling for Flash are also weeping that Apple is exerting proprietary control over the App Store platform it created. Of fucking course it doesn't want to enrich its competitors. Apple did all the work here.
There are some exceptions, but for the most part, I think the point being made by most people here isn't about addressing fairness / morality / competitiveness / whatever with regards to Apple's decision to do this; rather, issue is being taken with the given reason for the decision, as quoted by AI in TFA. In the article, it is suggested that this decision is for technical rather than business reasons. We (I) simply don't accept that as technically valid.
Having said that, I do think it would be nice to hear the reasoning direct from Apple. Then we could get into the philosophical discussion without all the need for speculation.
Apple can pick any number of options for dealing with such technical issues if they even exist. Here are a few no-brainers
a) Not all apps can multitask until upgraded to compatibility requirements. Having some ice cream is always better than none. This is typical with software, and how the real OSX handles OS updates. It works and everyone is happy.
b) Adapt license agreement to include agreement for officially sanctioned 3rd party developer tools. To stay in the club Flash, Unity3D, Corona, Mono, have to keep up with .ipa standards. Apps that fall behind the standard eventually get removed from storefront & iphone during critical upgrades like OS4
c) Copy Backgrounder with apps that arent up to standards & give users a simple popup setting to notify user that its a battery killer app and ask if they want to allow background access or not.
Any good software firm especially Apple, could implement an elegant solution. This article is wrong, reading a few fanboy comments one can barely stand to use the same OS as the people making suh douche-ridden comments.
Come on!
Daniel Eran Dilger (aka: prince@appleinsider.com) is the author and you are surprised? that the article seems slanted?
How long have you been around?
it's the same email address, but aren't Daniel Eran Dilger and Prince McLean two different people?
When was the last time Adobe, Microsoft, Apple released open source on their key software?
Well with both Adobe and Microsoft you can get other tools to compile into there run times. Both of them even give away a command line compiler that could be used by the third party IDE to do it with. So I don't really know what your getting at.
But isn't Objective-C available to ALL the major platforms? If you want to take the least amount of time to get apps running on all platforms you choose the language that is available to all platforms and work around the ugly bits within the language.
To be honest I don't really know. But speaking as someone thats a .NET developer, I wouldn't want to go back to the version of .NET languages from 5 years ago due to the amount thats changed in that time. Then there's lot's of arguments that writing in Xcode also takes a lot longer.
End of the day in the arguments of what's better, when you work with these languages that have 1000s of components it takes a few years to get really good and know them all. Being forced to use one particular tool just takes you backwards and to a large extent really goes against the development community. Developers like to create, not be restricted.
The answer is many developers and users have simply become addicted to it. like cheap drugs. when it was new it was the first good solution to a huge problem - a great high! - so it was widely embraced. ok. eventually it achieved near monopoly status in its category. but now there is a rival, Silveright/MS, and a new kid in town, HTML5/Apple. but the Flash mob won't switch, they're hooked. (and some make their living from it, of course, so you can understand their alarm.)
but nobody owes Adobe anything. their stewardship of Flash when it had to the market to itself was poor. stay addicted to it or kick the habit, but please drop the moral posturing.
This isn't an argument about Flash as you see in your browser, it's about flash the development tool or not even that, its about using any development environment. It would be like if the iPhone was actually running on HTML5 and Apple suddenly said that apps had to be made in their HTML5 IDE rather than using anyone elses.
Just stop stepping outside the bounds of your expertise or intelligence in order to awkwardly invent ridiculous justifications for Apple's bullshit. Face it, every company both fails and makes profit driven choices that are wrong by standards of decency.
Nice first post to AI forums... It appears you joined within the last 9 days... possibly just now, to post this message.
After reading through a series of posts by people who regularly visit these forums, most of us can discern the poster's demeanor, morality, expertise and intelligence.
Since you have no established track record, please enlighten us with your qualifications in these areas... so we can better determine the soundness of your reasoning.
Apple can pick any number of options for dealing with such technical issues if they even exist. Here are a few no-brainers
a) Not all apps can multitask until upgraded to compatibility requirements. Having some ice cream is always better than none. This is typical with software, and how the real OSX handles OS updates. It works and everyone is happy.
Not sure I understand this. Are you implying that a poorly-performing program is better than having no program at all?
If so, I agree, that this may be true for some audiences. But, consider, who is the target audience of the iPhone: The non-technical person who just wants to get in; do something; get out. Ideally, each program will perform and behave in an expected way... like all the other apps, they just work
If an end user buys an app from Apple and runs it on an Apple device, he has reason to expect that it will behave like other apps. If it does not, he is likely to blame Apple as well as the provider of the app.
b) Adapt license agreement to include agreement for officially sanctioned 3rd party developer tools. To stay in the club Flash, Unity3D, Corona, Mono, have to keep up with .ipa standards. Apps that fall behind the standard eventually get removed from storefront & iphone during critical upgrades like OS4
This is one valid way to assure that apps comply with standards. However, there are several difficulties:
1) Apple has to spend valuable resources to train themselves, evaluate, monitor and negotiate solutions to problems with any 3rd-party tools.
2) Allowing a 3rd party tool, then, later, disallowing it (even for valid reasons) puts the burden of proof (and the effort entailed) on Apple-- for a tool that is out of their control.
3) Should 2 occur, where does that leave customers who have purchased that app? Will they no longer receive updates because Apple has disapproved a previously approved tool?
4) What are the legal ramifications of this?
c) Copy Backgrounder with apps that arent up to standards & give users a simple popup setting to notify user that its a battery killer app and ask if they want to allow background access or not.
If I understand it, you are suggesting that Apple should sell and distribute apps that are known to be "not up to standard", or at best, "unknown if up to standard".
Then, after the user has bought, downloaded and installed the app, he gets a "popup" that suggests he may have made a bad decision.
That is exactly the last thing you want to do, if you are Apple (or any other company).
First, the fact a store carries a product implies that the store thinks it meets their standards (or they wouldn't be selling it).
If the store has a problem, they pull the product and resolve the issue with the vendor... without involving their customer.
If the vendor has a history of supplying products that are "not up to standard" the burden is placed on the vendor to correct this before the store agrees to sell the vendors products.
Any good software firm especially Apple, could implement an elegant solution.
Yes, they can provide an elegant solution. That appears to be what Apple is trying to do. It appears that they have decided that 3rd-party cross-compiler/generator tools may not meet their minimum standard at this time.
Say, Apple has some analysis tools and 50 people talented enough to use them and interpret the results. Apple is not accepting programs that were created by tools which are out of Apple's control (and by definition, are out of date).
By doing this, Apple is focusing their talents on apps created known tools which are under Apple's control and understood by Apple's evaluation team. Its a matter of efficiency, allocation of resources, and ROI.
Those are technical reasons.
This article is wrong, reading a few fanboy comments one can barely stand to use the same OS as the people making suh douche-ridden comments.
A final reason, that many have suggested (including me), is that it does not make good business sense for Apple to support development tools which allow developers to create a single, one-size-fits-all, app that will run on competitors ' platforms, rather than exploit the specific advantages of Apple's platforms.
That's a pure business decision. As a user, customer, and stockholder... I support it!
.
Well, that type of multitasking isn't poorly implemented or battery draining if you're willing to throw a big battery, fast CPU and a slug of RAM at the problem. The Nexus has 2X the RAM of the 3GS, half again as much battery and CPU speed, so it has more headroom to deal with the issues. Versus the 3G, it's even starker, and Apple doesn't even try to implement its non-shitty, well-implemented, battery-sipping multi-tasking ON A CURRENT MODEL.
A simple engineering/business choice. Having programmed for Macs since the very first model, I see a long history of minimized hardware; even so, the company has had to deal with low volumes and so necessarily higher prices. And I can cite other firms, like Sun, that bet the company on a gold-plated lineup just as the DotBomb exploded, showing that Apple is not simply being neurotic.
Still, Apple's implementation choices don't have to be the right ones for everybody. Multi-tasking on the Google phone is pretty sweet, as long as you don't tax it too hard and/or are willing to pace yourself on the number of apps, the same way that iPhone users have to pace themselves on the number of hours of surfing & talking between charges.
And the way Android do multitasking is exactly the same that Apple has implemented on 4.0.
Daniel Eran doesn't know it, it's a waste of time trying to do a bit of research if the reality collides with his own view of reality.
And the way Android do multitasking is exactly the same that Apple has implemented on 4.0.
Daniel Eran doesn't know it, it's a waste of time trying to do a bit of research if the reality collides with his own view of reality.
No it's not. Android has true multi-tasking. (ie. the ability to run any app in the background continuously, not just an Apple approved small sub set of functions)
Those "anti-competitive business reasons" have changed the computer industry from the stagnant crap hole it has always been into a forward moving computer manufacturer changing the way we work with computers and mobile devices. It's all been for the good of the consumer even if they did step on some people's toes to do it.
They controlled the hardware so were in a position to jump from 68000 to PPC and later from PPC to Intel. Yes it annoyed a lot of developers but the ones who did well were the ones who changed as soon as possible. It also mean the latest developments in computing had a platform that could be progress their technology. Apple killed off ADB, Serial, and Parallel in favour of USB, it killed off VGA in favour of DVI and DVI in favour of DisplayPort because it makes sense in the long run.
You can all complain as much as you want now but in the future you will look back and realise that this was the turning point in computing where developers moved forward instead of using old worthless technology.
Could this be a key reason Apple product hold their value for so long? Apple uses new concepts that when they eventually become mainstream have already been found to have been on the Apple product for years.
No it's not. Android has true multi-tasking. (ie. the ability to run any app in the background continuously )
Android, continuously eating up limited power reserves and wasting CPU cycles on a resource limited mobile platform.
Is any Android mobile device permanently hooked up to the Hoover Dam?
Android, continuously eating up limited power reserves and wasting CPU cycles on a resource limited mobile platform.
Is any Android mobile device permanently hooked up to the Hoover Dam?
Battery life on a Nexus One is pretty similar to a 3GS, and miles better than my iPhone 3G.
You can achieve good results simply through good software engineering you know. Have you considered the possibility that Android is just a more efficient, better engineered OS than the iPhone OS?
Additionally, that fact that Apple introduced its Push Notifications service first means that most iPhone apps are already designed to respond to outside events efficiently. On the BlackBerry OS, for example, apps that run in the background often inefficiently poll their servers, a big tax on battery life. This is somewhat ironic because Blackberry is renowned for running its own push services, it just didn't open these to developers until third party software had largely already rolled their own solutions.
When was the last time that you heard Blackberry users complain about battery life? RIM didn't need to implement push notifications for apps and so didn't.
... To developers depending on, or intending to depend on Flash or other non-Objective-C/Xcode solutions, I would say, get with the Objective-C program now if you want to develop for iPhone OS. Apple isn't going to back down on this issue because it's too important to the continued success of the iPhone and the iPad, and Apple. ....
Another problem which is kind of an "Elephant in the room" no one is speaking about is the very idea that someone who is good at Flash scripting is someone we should be calling a "developer," at least in the context of this discussion.
I am very good at several different scripting languages myself, but I wouldn't equate this knowledge to "being a developer" (of apps). The two different software packages I primarily work with, can both also create executable files that are indistinguishable from an "app" (for Mac not iPhone OS) to the end user, but I still wouldn't label myself a "developer" as a result.
The more I look at it, the more I think that the whole idea that there are application "developers" who want to use Flash as their "coding language" of choice is just a total boondoggle. There are no such "developers" in this context. If you are using Flash, it doesn't mean you are dumber or less capable than someone who knows C, C++, etc., but it doesn't make you a "developer" either IMO.
.. It's a completely different equation if the entire codebase has to be ported to ObjC. Yah, so for us it's going to take a lot longer to get onto the platform if Monotouch is out of the equation. It's not the inability from a technical perspective but the inability from a business/resource perspective.
Interesting real-world examples. Something typically missing from these kinds of debates.
It seems to me that if you are not already using XCode for the "desktop" part of your business though, that your desktop apps are already cross-platform, so perhaps Apple's decision here will have a side effect of pushing shops like yours to either go full-on Mac, or leave it altogether.
At the very least it seems like if a developer is using "foreign" (non-XCode) tools it will only be efficient to target *either* the Mac desktop (as a port), *or* the iPhone in addition to the non-Mac stuff. If you are doing iPhone OS and Desktop OS-X integration or apps that run in both, then Apple is very strongly pushing you into XCode I suppose.
Interesting real-world examples. Something typically missing from these kinds of debates.
It seems to me that if you are not already using XCode for the "desktop" part of your business though, that your desktop apps are already cross-platform, so perhaps Apple's decision here will have a side effect of pushing shops like yours to either go full-on Mac, or leave it altogether.
At the very least it seems like if a developer is using "foreign" (non-XCode) tools it will only be efficient to target *either* the Mac desktop (as a port), *or* the iPhone in addition to the non-Mac stuff. If you are doing iPhone OS and Desktop OS-X integration or apps that run in both, then Apple is very strongly pushing you into XCode I suppose.
It could mean going all XCode or leaving the platform. Historically, with the Mac side of things, it meant the Mac versions languished behind the Windows versions. In our company, we do primarily Windows software, with Mac, Linux and Netware ports of some products or components. Unfortunately, what this means is that the Mac code sits generally idle until someone decides to fire up XCode on one of the Macs and does a build to see what code has broken. Since we do mainly C and C++, much of the code itself if generally pretty portable. The Mac port has some Mac specific work, but generally it is just a matter of building it on the Mac. There is always the chance that something has broken between builds, though. In those cases we have to spend time and resources making changes to fix the Mac build without breaking the Windows build. It was worse when we used Metroworks.
This decision won't affect us much, since we don't really use ObjC at all. There have been some informal discussions recently about doing a new mobile app as part of our other desktop/server suites, but it isn't really even on the radar yet. One way that this decision might impact the execs in their planning is that we are in the heart of RIM land and even share office space with them. If were were to do a mobile app, we would have to include BB, in fact it would at first be the primary platform, given the product lines. Google Canada's dev office is very close as well, where they mainly do mobile platform work. Networking with devs and managers from these companies is frequent, so of course running on those platforms would be on the table in any case. If we had to have to completely different code bases for the mobile apps, there is a good chance the iPhone version would be delayed and would end up behind the other versions.
As I said, this decision won't impact us very much for now. In the end, the market decides for us. If our clients need the iPhone app, it will happen. There are undeniable repercussions, however.
Edit: The above had nothing to do with the prohibition against Flash or similarly ported code. Only the apparent requirement "that all iPhone apps begin as native development using its own Xcode tools".
Edit2: Does anyone remember the OpenStep days, where write once run anywhere was an objective and not a taboo?