Now they're being put on hold because they have to learn to program this aged language instead of just making everything happen with something like Unity.
The best programmers are already using the best software for the IPad. Sorry you backed the wrong horse.
Now you are just being silly. A large portion of the Macs sold go to creative professionals who use Adobe products. Why would Steve want to sell less product?
Because the future of Apple is in Mobile Devices. Apple will never work in the past. Instead, they create the future.
I am really surprised that people are cheering about this horrible, restrictive move on Apple's part.
Let me try to help you understand me.
I know a small bit about technology and it's history. I know what a geek is and I'm sympathetic for them, most of the time.
Since 10 years I'm using a Mac. I check Windows and Linuxes (what's the correct plural?) from time to time in a virtual machine. I'm happy that I've changed to the Mac and I see nothing at the moment which would make me switch back.
If Apple would be run by geeks, I wouldn't have changed to the Mac because there wouldn't be a difference for me, as a non-geek-user, to a Windows box. Obviously, it must have something to do with Steve Jobs.
Ergo: if in doubt, I stay on Steve's side and watch how more and more information comes in (thank you, Gruber and Dilger and all the others) and try to understand it. And you know what? I always agree with Steve If somebody is right 10 years (I'm not closely following Apple for a longer time), that's an excellent track record.
For me, the Mac works. For me, my iPods worked. For me, my iPhone worked (sold it 1 month ago to buy an Android-Phone for the time until the next iPhone will be available contractless here in Europe). My Android-Phone doesn't work as it should.
I find at least Monkey Island, Angry Birds, Zombieville USA. None of will fulfill the new rules.
You obviously don't realize that "engines and code interpreting" aren't outlawed by this latest license terms update.
Engines such as physics engines will already be written in C++ or C, it is the drastic oddity to find one written in something else. So that code is okey doke. Anyway engines as you are using the term are just libraries, not OS APIs so they weren't even part of the conversation to start with.
Interpretation and Just In Time compilation have been verboten on iPhone since the first dev kit betas. Nothing new there, them's been the rules for two years now.
Most of the rest of "translated or cross compiled" into iPhone Apps has a little bit of interpretation to it. If a developer uses code generation to create an Objective-C file, and repeats to generate a fully formed Xcode project which is then built within Xcode that isn't code translation into an iPhone app. This plus library calls is what the majority of those game developers use. There are a few other capabilities which will need tweaking to line up with the new terms, but that's why stuff like this gets announced in the beta. It gives the devs a few months to tweak what's necessary, but still locks the system terms against what it is really aimed at.
Since 10 years I'm using a Mac. I check Windows and Linuxes (what's the correct plural?) from time to time in a virtual machine. I'm happy that I've changed to the Mac and I see nothing at the moment which would make me switch back.
....
For me, the Mac works. For me, my iPods worked. For me, my iPhone worked (sold it 1 month ago to buy an Android-Phone for the time until the next iPhone will be available contractless here in Europe). My Android-Phone doesn't work as it should.
Do I have to write more?
Cheers,
j.
Well, sorry to say, but the only thing you successfully communicated here is your blind religious Steve fanboyism.
You obviously don't realize that "engines and code interpreting" aren't outlawed by this latest license terms update.
Engines such as physics engines will already be written in C++ or C, it is the drastic oddity to find one written in something else. So that code is okey doke. Anyway engines as you are using the term are just libraries, not OS APIs so they weren't even part of the conversation to start with.
Alright, I chose my words wrong, with engines, I perhaps mean more "platforms", such as Unity3D.
Quote:
Interpretation and Just In Time compilation have been verboten on iPhone since the first dev kit betas. Nothing new there, them's been the rules for two years now.
Yes, but as far as I understood, scripting languages are forbidden as well, which would make, for example Monkey Island forbidden. If you have written games, well, ever, you would know that scripting makes things easier and more practical.
Quote:
Most of the rest of "translated or cross compiled" into iPhone Apps has a little bit of interpretation to it. If a developer uses code generation to create an Objective-C file, and repeats to generate a fully formed Xcode project which is then built within Xcode that isn't code translation into an iPhone app. This plus library calls is what the majority of those game developers use. There are a few other capabilities which will need tweaking to line up with the new terms, but that's why stuff like this gets announced in the beta. It gives the devs a few months to tweak what's necessary, but still locks the system terms against what it is really aimed at.
The agreement says that it has to be written originally in Objective-C, you can't make it java first and run it through a code converter. Apple would never know, but you've still broken the agreement.
Well, nobody knows if Unity is allowed until something official is given. But believe me, if you have almost finished a project on Unity, you cannot convert it to native code in a few months, especially most of these people work alone or in very small groups.
John Gruber lists the people affected by Apple's decision to change section 331 in his excellent "Daring Fireball": http://daringfireball.net/2010/04/wh...ed_section_331 - but there are other users affected by this decision not in his list...
As an app developer, we have government clients that want to commission a mobile app, but have to make any investment multi-platform in order to comply with rules requiring tax payers money to be spent on multiple-platform software. By using one of these "cross-platforms" (not the flash or silverlight 'meta-platforms'), we can deliver mobile iPhone, iPad, iPod Touch, Android, Desktop Mac, Desktop Windows and Desktop Linux compatible apps with much reduced development overheads. If we become required to use a different SDK for every platform, then the cost to our client will, at least, double - potentially making the project non viable.
Yes, this is an immense pain today as a result. On the other hand we're starting to see ObjC ports to Android (http://code.google.com/p/android-gcc-objc2-0/) and ObjC kinda sorta works on Linux and Windows and with gnuStep you even get some of the core libraries.
And of course, you can always use C++ or C. Write your core logic (model) in C/C++ and then your view/controller in the target platform language for Android and iPhone.
The issue is with managed langages like Java and C#. Looking at the Java to iPhone solutions it didn't look like a viable government solution given that the code is recompiled on foreign servers. Flexycore and the other one (that the big game devs use) do this.
MonoTouch looked good...until this. On the other hand it's Novell backed. Um, okay. And the future of Java in anything other than J2EE is suspect now that Oracle has it. While Android is Java it isn't J2ME.
I honestly don't see a bulletproof solution moving forward regardless of Apple's new rules. It's just a shame as I can't stand C/C++ anymore after a decade of Java and C#.
Maybe ObjC across all platforms is the lesser of the three evils. It'll depend on how usable the core language will be without libraries. I do like the message passing architecture even if I dislike the syntax. I REALLY am going to miss the Call Hierachy from eclipse though.
Comments
"Forced out" in the sense that you can't or won't take the trouble to learn the native tools?
I can't afford to roll back two months of development and start from scratch.
Yes, I know this was an April Fool's Joke, but I want one!
Credit
I can't afford to roll back two months of development and start from scratch.
So you're abandoning developing for the mobile space altogether? Or just whatever app you had cooking for the iPhone/iPad?
So you're abandoning developing for the mobile space altogether? Or just whatever app you had cooking for the iPhone/iPad?
I was going to target iPhone-iPad/Android/Facebook, so my Android plans are unaffected.
Any future plans to support iPhone OS are uncertain.
I was going to target iPhone-iPad/Android/Facebook, so my Android plans are unaffected.
Any future plans to support iPhone OS are uncertain.
Understood.
http://unity3d.com/ can't use the iPhone? Come on!!!
Apple has suffered from Hubris in the past but this is really tyranny. Apple is EVIL!
Now they're being put on hold because they have to learn to program this aged language instead of just making everything happen with something like Unity.
The best programmers are already using the best software for the IPad. Sorry you backed the wrong horse.
Now you are just being silly. A large portion of the Macs sold go to creative professionals who use Adobe products. Why would Steve want to sell less product?
Because the future of Apple is in Mobile Devices. Apple will never work in the past. Instead, they create the future.
I agree that Apple could and should do more for the pro film and audio markets,
Those markets are dwarfed by the consumer market. Apple cannot be in every market. They choose to put resources where they yield the highest return.
I am really surprised that people are cheering about this horrible, restrictive move on Apple's part.
Let me try to help you understand me.
I know a small bit about technology and it's history. I know what a geek is and I'm sympathetic for them, most of the time.
Since 10 years I'm using a Mac. I check Windows and Linuxes (what's the correct plural?) from time to time in a virtual machine. I'm happy that I've changed to the Mac and I see nothing at the moment which would make me switch back.
If Apple would be run by geeks, I wouldn't have changed to the Mac because there wouldn't be a difference for me, as a non-geek-user, to a Windows box. Obviously, it must have something to do with Steve Jobs.
Ergo: if in doubt, I stay on Steve's side and watch how more and more information comes in (thank you, Gruber and Dilger and all the others) and try to understand it. And you know what? I always agree with Steve
For me, the Mac works. For me, my iPods worked. For me, my iPhone worked (sold it 1 month ago to buy an Android-Phone for the time until the next iPhone will be available contractless here in Europe). My Android-Phone doesn't work as it should.
Do I have to write more?
Cheers,
j.
http://www.devwhy.com/blog/2010/4/12...framework.html
That said, I really don't care to run Flash. I'm just fine without it.
Care to still claim that using engines and code interpreting creates BAD games and that this change is only good for the iPhone and iPad?
https://spreadsheets.google.com/ccc?...zV1hwVnc&hl=en
I find at least Monkey Island, Angry Birds, Zombieville USA. None of will fulfill the new rules.
Well.. Seems like a lot of Top list apple games are no longer eligible for AppStore..
Care to still claim that using engines and code interpreting creates BAD games and that this change is only good for the iPhone and iPad?
https://spreadsheets.google.com/ccc?...zV1hwVnc&hl=en
I find at least Monkey Island, Angry Birds, Zombieville USA. None of will fulfill the new rules.
You obviously don't realize that "engines and code interpreting" aren't outlawed by this latest license terms update.
Engines such as physics engines will already be written in C++ or C, it is the drastic oddity to find one written in something else. So that code is okey doke. Anyway engines as you are using the term are just libraries, not OS APIs so they weren't even part of the conversation to start with.
Interpretation and Just In Time compilation have been verboten on iPhone since the first dev kit betas. Nothing new there, them's been the rules for two years now.
Most of the rest of "translated or cross compiled" into iPhone Apps has a little bit of interpretation to it. If a developer uses code generation to create an Objective-C file, and repeats to generate a fully formed Xcode project which is then built within Xcode that isn't code translation into an iPhone app. This plus library calls is what the majority of those game developers use. There are a few other capabilities which will need tweaking to line up with the new terms, but that's why stuff like this gets announced in the beta. It gives the devs a few months to tweak what's necessary, but still locks the system terms against what it is really aimed at.
The best programmers are already using the best software for the IPad. Sorry you backed the wrong horse.
Uhm.. I'm sorry, but you're going to have to open this up for me a little bit. Didn't understand at all, what best software?
Let me try to help you understand me.
Since 10 years I'm using a Mac. I check Windows and Linuxes (what's the correct plural?) from time to time in a virtual machine. I'm happy that I've changed to the Mac and I see nothing at the moment which would make me switch back.
....
For me, the Mac works. For me, my iPods worked. For me, my iPhone worked (sold it 1 month ago to buy an Android-Phone for the time until the next iPhone will be available contractless here in Europe). My Android-Phone doesn't work as it should.
Do I have to write more?
Cheers,
j.
Well, sorry to say, but the only thing you successfully communicated here is your blind religious Steve fanboyism.
You obviously don't realize that "engines and code interpreting" aren't outlawed by this latest license terms update.
Engines such as physics engines will already be written in C++ or C, it is the drastic oddity to find one written in something else. So that code is okey doke. Anyway engines as you are using the term are just libraries, not OS APIs so they weren't even part of the conversation to start with.
Alright, I chose my words wrong, with engines, I perhaps mean more "platforms", such as Unity3D.
Interpretation and Just In Time compilation have been verboten on iPhone since the first dev kit betas. Nothing new there, them's been the rules for two years now.
Yes, but as far as I understood, scripting languages are forbidden as well, which would make, for example Monkey Island forbidden. If you have written games, well, ever, you would know that scripting makes things easier and more practical.
Most of the rest of "translated or cross compiled" into iPhone Apps has a little bit of interpretation to it. If a developer uses code generation to create an Objective-C file, and repeats to generate a fully formed Xcode project which is then built within Xcode that isn't code translation into an iPhone app. This plus library calls is what the majority of those game developers use. There are a few other capabilities which will need tweaking to line up with the new terms, but that's why stuff like this gets announced in the beta. It gives the devs a few months to tweak what's necessary, but still locks the system terms against what it is really aimed at.
The agreement says that it has to be written originally in Objective-C, you can't make it java first and run it through a code converter. Apple would never know, but you've still broken the agreement.
Well, nobody knows if Unity is allowed until something official is given. But believe me, if you have almost finished a project on Unity, you cannot convert it to native code in a few months, especially most of these people work alone or in very small groups.
John Gruber lists the people affected by Apple's decision to change section 331 in his excellent "Daring Fireball": http://daringfireball.net/2010/04/wh...ed_section_331 - but there are other users affected by this decision not in his list...
As an app developer, we have government clients that want to commission a mobile app, but have to make any investment multi-platform in order to comply with rules requiring tax payers money to be spent on multiple-platform software. By using one of these "cross-platforms" (not the flash or silverlight 'meta-platforms'), we can deliver mobile iPhone, iPad, iPod Touch, Android, Desktop Mac, Desktop Windows and Desktop Linux compatible apps with much reduced development overheads. If we become required to use a different SDK for every platform, then the cost to our client will, at least, double - potentially making the project non viable.
Yes, this is an immense pain today as a result. On the other hand we're starting to see ObjC ports to Android (http://code.google.com/p/android-gcc-objc2-0/) and ObjC kinda sorta works on Linux and Windows and with gnuStep you even get some of the core libraries.
And of course, you can always use C++ or C. Write your core logic (model) in C/C++ and then your view/controller in the target platform language for Android and iPhone.
The issue is with managed langages like Java and C#. Looking at the Java to iPhone solutions it didn't look like a viable government solution given that the code is recompiled on foreign servers. Flexycore and the other one (that the big game devs use) do this.
MonoTouch looked good...until this. On the other hand it's Novell backed. Um, okay. And the future of Java in anything other than J2EE is suspect now that Oracle has it. While Android is Java it isn't J2ME.
I honestly don't see a bulletproof solution moving forward regardless of Apple's new rules. It's just a shame as I can't stand C/C++ anymore after a decade of Java and C#.
Maybe ObjC across all platforms is the lesser of the three evils. It'll depend on how usable the core language will be without libraries. I do like the message passing architecture even if I dislike the syntax. I REALLY am going to miss the Call Hierachy from eclipse though.
Very disappointing Apple.