iPhone OS 4 license changes - How does it affect iTorque?
by Marc Dreamora Schaerer · in iTorque 2D · 04/08/2010 (4:00 pm) · 122 replies
By the changes of the iPhone SDK rules coming up, how is the standing of T2Di / T3Di even being even legal any longer?
The explicit change I've in mind is:
in combination with the fact that T2Di, like game salad and shiva (along most sega games and the C64 thingy), do not produce pure ARM code but have a VM.
An alternative interpretation / solution: Total cut of the scripting and moving all to a much better documented source only level (which I personally would prefer hehe)
PS: the iphone os 4 beta has been reported on various places to have happened so you might to check if thats true :)
The explicit change I've in mind is:
Quote:"Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited."
Source: http://twitter.com/gruber/status/11837642274
in combination with the fact that T2Di, like game salad and shiva (along most sega games and the C64 thingy), do not produce pure ARM code but have a VM.
An alternative interpretation / solution: Total cut of the scripting and moving all to a much better documented source only level (which I personally would prefer hehe)
PS: the iphone os 4 beta has been reported on various places to have happened so you might to check if thats true :)
About the author
#2
But by the past track of those things its a matter of days / weeks that you have to agree to send in anything at all and if the topic heats up further the way it explosively did, it will become more days than weeks.
Apple was a bit mean there anyway, cause Adobe has their CS5 event on monday and the broad assumption is that this new thing was primarily added to ensure that flash will never happen on the iphone (due to the wording and the explicit note of JavaScript in the webbrowser only)
04/08/2010 (5:54 pm)
As you currently only have to agree to it if you enter the beta, you won't be touched by it otherwise.But by the past track of those things its a matter of days / weeks that you have to agree to send in anything at all and if the topic heats up further the way it explosively did, it will become more days than weeks.
Apple was a bit mean there anyway, cause Adobe has their CS5 event on monday and the broad assumption is that this new thing was primarily added to ensure that flash will never happen on the iphone (due to the wording and the explicit note of JavaScript in the webbrowser only)
#3
"An updated version of the iPhone Developer Program Agreement is available. To maintain your ability to create new applications and upload binaries, the Agent of your developement team must log in to the iPhone Developer Program Portal to review and accept this agreement."
In this new agreement:
"3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited)."
To my best understanding, it's in effect right now.
04/08/2010 (7:13 pm)
Only if you enter the beta? Upon logging into iTunes Connect:"An updated version of the iPhone Developer Program Agreement is available. To maintain your ability to create new applications and upload binaries, the Agent of your developement team must log in to the iPhone Developer Program Portal to review and accept this agreement."
In this new agreement:
"3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited)."
To my best understanding, it's in effect right now.
#4
04/08/2010 (8:49 pm)
Does this mean T2Di is now worthless for selling a game through the iTunes App store?
#5
Question is how GG / LUMA is going to react.
All depends on apple if they keep that and to what degree they want to enforce it.
Fact is that the VM nature of TorqueScript was always gray area and every single game is only there because Apple was nicer than they needed to be really. the VM was never really legal it was just not explicitely forbidden, till today
04/08/2010 (8:55 pm)
If the above linked in change is really enforced, then yes they could just reject every single Torque for iPhone (2d and 3d) game completely.Question is how GG / LUMA is going to react.
All depends on apple if they keep that and to what degree they want to enforce it.
Fact is that the VM nature of TorqueScript was always gray area and every single game is only there because Apple was nicer than they needed to be really. the VM was never really legal it was just not explicitely forbidden, till today
#6
T2Di accesses OpenGL ES and CocoaTouch deep down at the core (with some Foundation stuff), so it's not using any undocumented features, and it's accessing them with an approved language.
Apple have modified their agreements several times before after receiving backlash, so I wouldn't rule out a clarification.
Let's wait and see before going all "RARGH! NEGATIVITY! BLERGH!" :)
04/08/2010 (10:23 pm)
I wouldn't worry about this. It's been discussed in various forums and IRC channels the past 11-12 hours this has been public. I see it like this: The engine is a C++ engine with some ObjC glue. All the API access happens there. The scripts tell the engine the game logic.T2Di accesses OpenGL ES and CocoaTouch deep down at the core (with some Foundation stuff), so it's not using any undocumented features, and it's accessing them with an approved language.
Apple have modified their agreements several times before after receiving backlash, so I wouldn't rule out a clarification.
Let's wait and see before going all "RARGH! NEGATIVITY! BLERGH!" :)
#7
In this post and his previous post, his comments are quite different to the opinions being sprouted here.
http://daringfireball.net/2010/04/why_apple_changed_section_331
I cant say anything "officially" but my personal opinion is to not speculate as if it were fact.
04/08/2010 (10:33 pm)
I agree with Ronny too. HIGHLY speculative misquotes from someone else blog post - is unhelpful all around.In this post and his previous post, his comments are quite different to the opinions being sprouted here.
http://daringfireball.net/2010/04/why_apple_changed_section_331
I cant say anything "officially" but my personal opinion is to not speculate as if it were fact.
#8
If Adobe is cut out so is Torque for iPhone, Shiva and Game Salad.
If they are not, Adobe will sue apple for unfair treatment and will do so badly.
If neither is cut, the point of the new formulation is questionable and so is its use.
04/09/2010 (12:26 am)
We will see.If Adobe is cut out so is Torque for iPhone, Shiva and Game Salad.
If they are not, Adobe will sue apple for unfair treatment and will do so badly.
If neither is cut, the point of the new formulation is questionable and so is its use.
#9
04/09/2010 (6:59 am)
It depends on how loose Apple will be on the wording. On one extreme they could be trying prohibit any middleware. On the other, they could be aiming at one particular company and the rest of us are caught in the crossfire. My gut instinct tells me you should not worry about Torque. Our engine will comply with the terms, and we look forward to continuing support for the platform, the tools, and you all. 
#10
I remember this very discussion happening a while back with an earlier iteration of the license and as expected everything turned out fine.
04/09/2010 (7:25 am)
I've changed the thread title something a little less speculative and reactionary, and I'll echo what Ronny, Sven and Mich have already said.I remember this very discussion happening a while back with an earlier iteration of the license and as expected everything turned out fine.
#11
My guess is that the more you can focus iTGB on iPhone OS development, and the more native-like you can make it, the safer you are. Ship a version that allows simultaneous deployment on Android and iPhone, and you'll be putting a huge target on yourselves. That's what Apple's trying to avoid.
But I do have to admit to some concern with continuing investment in my iTGB project. It would do a lot of good if you folks made contact with Apple and could assure me that you have a solution that's acceptable to Apple on both biz and tech sides.
04/09/2010 (9:04 am)
From a business perspective, Apple is trying to avoid being wedged by meta-platforms that make it easy for developers to deploy applications on Apple and competing platforms, reducing value-add and lock-in that Apple's large app base gives them.My guess is that the more you can focus iTGB on iPhone OS development, and the more native-like you can make it, the safer you are. Ship a version that allows simultaneous deployment on Android and iPhone, and you'll be putting a huge target on yourselves. That's what Apple's trying to avoid.
But I do have to admit to some concern with continuing investment in my iTGB project. It would do a lot of good if you folks made contact with Apple and could assure me that you have a solution that's acceptable to Apple on both biz and tech sides.
#12
For those of you who have used iT2D (aka iTGB), think about how the actual Xcode project is set up. Mostly C++ code, but the bindings to Objective C call native API functions. It's spot on with Apple's terms. I think TorqueScript is also in the clear, but if we have to make adjustments we will.
04/09/2010 (9:08 am)
@Brooks - Well, by your logic we are in the clear then. Our iPhone engines are more geared to iPhone development today than previous iterations. There has been some stripping of the original TGB code, plus desktop deployment has been removed. For those of you who have used iT2D (aka iTGB), think about how the actual Xcode project is set up. Mostly C++ code, but the bindings to Objective C call native API functions. It's spot on with Apple's terms. I think TorqueScript is also in the clear, but if we have to make adjustments we will.
Quote:It would do a lot of good if you folks made contact with Apple. When we hear back from them, we'll let you know.
#13
A) Their review process simply doesn't look closely enough technically to catch it as they're mostly concerned with boobies, "excessive" violence, political correctness, copyright infringement
B) These blanket clauses are in there to justify yanking apps on a case by case basis and so mostly go unenforced
What Brooks describes isn't that different than what Microsoft is doing on the Windows 7 Phone with C#/XNA/Silverlight, so from a business standpoint it does add up... A problem being C/C++/Obj-C aren't very good languages for lots of tasks (game logic being one of these) and Obj-C only runs on Apple platforms (whereas Mono currently runs pretty much everywhere).
If Apple does go forward with an iron fist on this, it will turn off a lot of developers and limit app developers to people with C/C++/Obj-C experience. It'll also squash some middleware solutions. C/C++/Obj-C requirements in a EULA seems really limiting and control freakish.
I've developed a fair amount of stuff on Apple OSX and been bitten many times by unannounced changes... and dramatic compatibility issues both technically and in EULAs. Come on Apple, can't you just be happy with 85,000,000 devices + whatever iPad is doing and billions of Apps sold? Seriously :)
04/09/2010 (9:33 am)
Sections 3.3.1 and 3.3.2 of the iPhone SDK Agreement are really difficult to swallow. There are a lot of apps that break 3.3.2 and Apple hasn't pulled them. I have a feeling this is either: A) Their review process simply doesn't look closely enough technically to catch it as they're mostly concerned with boobies, "excessive" violence, political correctness, copyright infringement
B) These blanket clauses are in there to justify yanking apps on a case by case basis and so mostly go unenforced
What Brooks describes isn't that different than what Microsoft is doing on the Windows 7 Phone with C#/XNA/Silverlight, so from a business standpoint it does add up... A problem being C/C++/Obj-C aren't very good languages for lots of tasks (game logic being one of these) and Obj-C only runs on Apple platforms (whereas Mono currently runs pretty much everywhere).
If Apple does go forward with an iron fist on this, it will turn off a lot of developers and limit app developers to people with C/C++/Obj-C experience. It'll also squash some middleware solutions. C/C++/Obj-C requirements in a EULA seems really limiting and control freakish.
I've developed a fair amount of stuff on Apple OSX and been bitten many times by unannounced changes... and dramatic compatibility issues both technically and in EULAs. Come on Apple, can't you just be happy with 85,000,000 devices + whatever iPad is doing and billions of Apps sold? Seriously :)
#14
Technically MonoTouch and UT are the ones that have the highest changes to get through it, as they compile to ARM, they have no interpreter or intermediate layer technically. But even there (on both ends) are doubts that it will end
@Josh: It will squash every single middleware aside of Cocos and the Oolong engine and potentially the blender trash. "every single" would include Unreal as well, which I doubt is in Apples interest to kick the two major middle ware engines used on the iDevices in the same go, just for the sake of locking out the major crap cannon (flash)
04/09/2010 (4:05 pm)
The problem of earlier iterations and this one is that apple has not the freedom to do the stuff on case to case base anymore if the intend is the one which most expect: Ensure that Flash will not deploy to the iphone, cause Apple otherwise has to defend itself massively in the clearly following court case because apple treats adobe different than UT, MonoTouch, the Shiva devs and Garage GamesTechnically MonoTouch and UT are the ones that have the highest changes to get through it, as they compile to ARM, they have no interpreter or intermediate layer technically. But even there (on both ends) are doubts that it will end
@Josh: It will squash every single middleware aside of Cocos and the Oolong engine and potentially the blender trash. "every single" would include Unreal as well, which I doubt is in Apples interest to kick the two major middle ware engines used on the iDevices in the same go, just for the sake of locking out the major crap cannon (flash)
#15
You can read the actual interview here: iGame Radio iTorque Interview
And while I have your attention, I can avoid posting or bringing this up elsewhere (the less the better). Most of you know I've been an unofficial point of contact for iTorque. I started off using my free time to work on docs, partial QA, and whatever support I could muster. The closer I got to the product and you all, the more frustrated I got with my own limited resources and time.
Eric has decided to put an official face on our iTorque engines. Give someone a budget, control of the milestones, cleared time for priorities and provide full guidance. He promoted me to Associate Producer of iTorque, giving me the reigns to drive iTorque to new heights. I'm looking forward to my increased involvement with iTorque and those who license it. I love the platform, love the engine, and really enjoy the community that has built up around it. I'm stepping up to the plate, so stay tuned.
04/09/2010 (7:50 pm)
Hey Everyone. I just responded to an e-mail from Omaha at iGame Radio. She wanted to get our take on the 4.0 features and the recent change to the license agreement. I answered her questions, but I figured you all would want to hear what I had to say. I don't think it is quite blog worthy, because frankly you all are working with this issue in a very level headed way. Always enjoy seeing intelligent discussion and supportive communication. So, here it is...copy and paste from e-mail:Quote:
Good questions. Let me start by addressing the easier one:
>Any other thoughts about the iPhone OS 4.0 SDK?
I tracked each announcement ("tent pole") from the presentation yesterday. As with every iPhone announcement, I was very pleased with the new features. It's great to see Apple address criticism with actions, and not just words. Multi-tasking, folders, and app pausing are long awaited and welcome features. The surprise of a game center and iAd were like icing on the cake. These are not subtle notations. Apple is really getting behind game developers and gamers with this update.
Of course, when you are a game engine developers and someone says "we have exposed 1500 new API", your first instinct is to panic about how much of that your licensees are going to demand from your next engine release. However, that was just a passing thought. I downloaded the preview SDK and as always I was very pleased with the new functionality and how well it's been exposed. I am really looking forward to working with our iPhone team to support the new features.
With that said, let's get into the gritty stuff...
> What are your thoughts about the decision that Apple made to include this in the agreement?
There is definitely some controversy and quite a bit of speculation, which is understandable. Whenever there are changes to a license agreement for software that is used by so many people, there is always going to be a huge interpretation battle. We have been licensing game engine technology for nine years, so we have been through our fair share of bumps in the road. Anytime we made changes to our EULA, we usually had a very sound reason for doing so. If a certain clause was widely unaccepted or irrational, we would listen to our community to see where we can best compromise. I have yet to get a direct communication line going with someone at Apple, but I do not see this change as being some tyrannical control scheme a lot of bloggers are accusing Apple of. Will it put some software out? Possibly. Will it put every middleware provider out? I don't see Apple making that kind of move. The addition of the Game Center shows their commitment to game developers, and game engines like iTorque allow people to work with the iPhone SDK at a higher level and get games to the app store faster. They can't be against that.
> Do you think that Torque for iPhone falls within this ban?
It depends on how loose Apple will be on the wording. My gut instinct tells me there should not be any concern over iTorque games being rejected. We have had various iterations of Torque on Windows, OS X, Linux, Xbox 360, Wii, PS3, embedded web browser, and of course iPhone OS. We know how to comply with both technical limitations and legal terms a company like Apple or Microsoft enforce. We have been doing it for nine years, and we will continue to do so. As an example, in 2008 just in time (JIT) compilation was restricted. We were able to comply since our TorqueScript language compiles scripts to a binary format, thus supporting ahead of time compilation.
From a technical perspective, iTorque is still compliant with the new clause introduced by 4.0. Our source engine, which is completely open to licensees, was written originally in C++. We have a platform layer dedicated to the iPhone, which is completely written in Objective C. Both parts of the engine are bound to each other, with no intermediate layer. At any time a programmer can directly access native API calls from the iPhone SDK. You can not get anymore direct than that.
If for any reason we have to change the way iTorque functions to comply with the current license agreements, or future changes, we are ready. Apple's iPhone SDK is very easy to work with, and modifying iTorque to work with any changes is easy for our team and for our licensees. I'm very proud of our iPhone engine team, and I know they are up to any task. I couldn't be more excited about the future of the iPhone and iPad, and our role in this.
I hope my answers are what you are looking for. If you have any followup questions, just let me know. Thanks for reaching out to us.
Regards,
Michael
You can read the actual interview here: iGame Radio iTorque Interview
And while I have your attention, I can avoid posting or bringing this up elsewhere (the less the better). Most of you know I've been an unofficial point of contact for iTorque. I started off using my free time to work on docs, partial QA, and whatever support I could muster. The closer I got to the product and you all, the more frustrated I got with my own limited resources and time.
Eric has decided to put an official face on our iTorque engines. Give someone a budget, control of the milestones, cleared time for priorities and provide full guidance. He promoted me to Associate Producer of iTorque, giving me the reigns to drive iTorque to new heights. I'm looking forward to my increased involvement with iTorque and those who license it. I love the platform, love the engine, and really enjoy the community that has built up around it. I'm stepping up to the plate, so stay tuned.
#16
Congrats on the promotion!
04/09/2010 (8:33 pm)
Excellent write up, very well thought out and reasoned.Congrats on the promotion!
#18
04/09/2010 (10:13 pm)
@eb - We are hiring, contracting, and upping the responsibility of our developers to fill the big shoes of Michael.
#19
@All - Thanks for the congrats! It's gonna be a good year for all.
04/10/2010 (12:32 am)
@eb - I still have a big role in the documentation effort for Torque. As Eric said, we are staffing up and budget has been allocated to increase the number of doc writers.@All - Thanks for the congrats! It's gonna be a good year for all.
#20
That said... how could they even tell you used C# if its AOT compiled anyway... the binary could just as easily been C or C++ generated.
04/10/2010 (11:08 am)
Quote:C/C++/Obj-C requirements in a EULA seems really limiting and control freakish.Yea... no reasonable platform would restrict the use of C# that was AOT compiled... but then again this is Apple we're talking about who has a clear track record for getting games wrong.
That said... how could they even tell you used C# if its AOT compiled anyway... the binary could just as easily been C or C++ generated.
Torque Owner Ricky Hopper