iPhone OS 4 license changes - How does it affect iTorque?

#21

Quote:how could they even tell you used C# if its AOT compiled anyway... the binary could just as easily been C or C++ generated

In the general, "I made a custom solution case", they could check binary signatures vs their compiler. For middleware like iTorque/Shiva/Unity, they could just look at the development environment/deployment process. Would certainly make it difficult documenting/advertising your "shadow system" :)

Can you imagine needing to support C/C++ game dev with iTorque? Right off, your market is limited to C++ coders that know their way around XCode. Goodbye GUI/game scripting... Zoinks! Quite a retroactive change to absorb

3.3.2 already bans interpreted languages, that has been in for awhile. 3.3.1 takes it to the next level and dictates only C/C++/Obj-C, at least that is the most common interpretation.

This may simply be FUD aimed at Adobe as they prepare to launch CS5... and they could relax the EULA as still beta and easy at this point to make changes. I could see them sticking with it... and at that point, it comes down to whether they enforce or not and whether people try and ignore it or work under the new parameters.

#22

Quote:I could see them sticking with it... and at that point, it comes down to whether they enforce or not and whether people try and ignore it or work under the new parameters.

After all, the aproval process is already plagued by arbitrariness, the same than their politics of removing apps that had been aproved.

#23 The validity of this is not granted yet: www.engadget.com/2010/04/10/steve-jobs-responds-to-complaint-about-new-developme...

But if it is valid, then start to move all your code to ObjC / C++ code, cause TS either is gone or iTorque is.
That the engine is pure C++ / ObjC won't help in this case as TS is violating the part and the fact that there is an intermediate layer between TS and the API (iTorque)

#24 As Mich stated before, the current versions of iTorque meet the new license requirements. We're fairly certain TorqueScript passes muster with the new license as well. If we're forced to make a change though we're prepared to do it.

#25 Yeah, I just read that on Engadget and was thinking the same thing Marc... I am really hoping that we don't end up with worst case outcome of this change. It could be really bad for indie developers as a whole, regardless of their game engine of choice.

#26 Scott: I know what was stated before and it didn't make any sense already before because iTorque always violated it as far as I'm aware (no runtime generated code vs eval which clearly violates this point, so does the support for cs/gui/t2d files on the iPhone instead of only the compiled version).
Apple just let many violators pass in the past, thats how the C64 application got on the store, that how SEGAs mega drive emulator got onto the platform.

With this enforcement, Apple will no longer have the freedom to decide that on case to case base, cause any case where they let it pass means that a competitor that was rejected can sue them for unfair treatment.
Also independent of how you turn and bend it: Torque Script is neither C nor C++ nor Object C, that simple it is.
Neither is it Javascript and even if, JS is only tolerated for webapps

All given Apple does not find a healthy human thinking again instead of trying to rip of payed dev contracts by cutting the contractors used technologies.

#27 I'd put Steve Jobs saying that stuff in the probably going to happen slot... however, anything is still possible.

This being the case, what a cannon ball through the middle of iPhone/iPad/iPod development and middleware... really backwards too, there's a reason people qualify these kinds of (crazy) moves with "Well, they're Apple"

Hopefully, they clue in and revise 3.3.1 before OS4 is released.

#28 One thing that I just realized: In the light of this change, the recent change on the iTunes EULA makes a hell more sense: Apple knew they would soon cut tens of thousands of apps from the store and update ever again -> so no redownload

#29

Quote:It could be really bad for indie developers as a whole, regardless of their game engine of choice.

That is definitively true.

But indie game developers should also consider a serious self criticism process for having rushed in mass into a plataform that meant draconian conditions, blinded by the hype of marketing that also helped to create more hysteria around a technogadget.

Maybe if some of this guys that now suddenly are pumping out a game per month for this toy, had agreed on some basic terms and created a simple site with games priced around the $0.99, maybe today they would have the power to decide what language to use for development.

And even maybe the lucidity and prestige to recommend other open plataforms, like lets say, Android.

#30 @Marc
Only compiled versions of the scripts are deployed in the final app, which is not JIT code. TorqueScript has been perfectly legal under the license this whole time.

The best thing to do with this whole mess is to wait for the dust to settle and see exactly where Apple is going with it. Jumping to speculative conclusions based on a couple comments from Jobs and some bloggers only increases the panic factor when there's no reason to, at least for Torque users that is. ;)

#31 I'll assume TP has done due diligence on this but what I think Marc is referring to is:

Quote:3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple's Documented APIs and built-in interpreter(s).

TorqueScript is an interpreted language.

Many apps have been flying under the radar of this clause. If Apple is now clamping down on the App store, which limiting to C/C++ dev effectively does to much of the hobby market... enforcement could increase.

... and Scott is right, no need to hit the panic button, yet.

#32 One thing that Torque has going for it (if everyone's worst fears are realized) is it includes the source. Even if TS had to be cut from iTorque, GG could continue to sell it since developers would still be able to work with the C++ source. Sure it would make life harder for the folks reliant on script, but at least they wouldn't have to learn to code a whole engine from scratch.

#33 Yea... absolute worst case you can write C++ code instead of TorqueScript and still drive the engine... thats always been possible and some games with TGE have been done that way in the past.

I'm gonna guess this is a combination of two factors...

1. There has been alot of crap in the iPhone app store... with the barrier to entry so low partially because of middleware... there is more junk than quality on the platform.

2. Windows Phone is coming and i guess Apple sees middleware products as an easy path to shipping the same app/game across both devices (and Xbox, PC, etc). They're probably concerned the iPhone just becomes a place for ports.

#34 1. I don't see how this can be blamed on professional middleware.
Most crap comes from the fact that apples examples + 3 lines give stuff like ifart.
The significant crap cannons have been banned already (that are these template + skinning app builders that recently got forbidden).
I also fully understand that apple does not want flash on the platform as its known to be a major crap cannon.
But I really can't see any reason in the blocking of commercial middleware as quality software also bases on quality middleware.
Its known that 1 team inhouse solutions are much more likely to be bugged pieces of shit than widely used techs.

2. That should really be the very last reason.
Win Mobile 7 has no native code support at all, just XNA. Thats a very specific target and I doubt that many middlewares will waste time on rewritting stuff totally just to please that platform with unknown future.
The android platform has shown how much a reason against it the lack of native support is.

#35 @Marc - I'm not saying those two reasons are my reasons... those are Apple's... and from what Jobs said that seems like its exactly what they are thinking.

For sure lots of bad apps were written in Obj-C and it won't keep you from making cross platform apps/games. All their doing is making it harder... which is gonna hurt the indies the most.

#36 I know that those are their reasons though saying their kind of implies that more than one god complex driven dictator (jobs) is responsible for it which I doubt that Apple has gotten to far that only people with a broken view on the reality can be working there especially in the dev departments.


And it will not only hurt indies, cause that clear sign of "get lost and shut up" towards any commercial development for their "god platform" in the end will make them lose all that can not afford to/ don't want to waste time to reprogram stuff for a single platform from ground up. Its not like banning the Unreal Engine before it even happened will help apple to raise the trust into their already before discussable / unfair / partially illegal practices.

Post edited by moderator - Try and keep it clean.

#37 Apple doesn't have technology partners, that much is clear. They have sprung breaking technical changes on their developers/middleware providers time and again. (Dropping NPAPI support from their browser with zero notice comes to mind)

There are some valid reasons for 3.3.1, probably the main one being that it forces developers to adopt their new tools/API stuff much faster and fully. Instead of developers waiting for middleware providers to maybe/maybe not support them.. and watering down the available apps with non-Apple specific ports. It isn't a perfect solution for them, but I can see the thinking.

This completely rubs my developer sensibilities the wrong way. Not looking to defend Apple on this... but it isn't purely megalomania.

#38 While I see the reasoning and understand that they want faster adoption, I don't see that these measures will help there in any way as people will focus even more on non-apple solutions to be not bound to draconian, non communicating world breaking changes all the time.
At least thats my point of view: who wants to rely on something where you can not even be sure that it will still be present by the time your current work is done?!

Realistically they also ensure that no real games will be developped for the iphone anymore as investing many months in creating a game if you don't know if you can even release it any longer is a major financial risk.

#39 I don't think anyone is trying to argue the point with ya Marc, actually agree. Just trying to understand the why's of the move from Apple's (many billions, high level) thinking.

EA will be fine and probably encourage this kind of herd culling change. There are a lot of developers who aren't EA... including us.

This is really a huge change for Apple to make retroactively... and I have a feeling there may be more yet to come. So, definitely has me looking even closer at Android and Windows Phone/Tablets.

#40 I'm not trying to argue as I know that we are in the same boat.
I'm just trying to understand the reasoning behind it including all points not just those Jobs might have in his "we are the best" mind.

Some things are not even remotely as easy to grasp that they play in too. Like the change in the iTunes EULA that in the light of the changed TOS suddenly started to get a whole different face and potentially much longer term consequences on how the AppStore works or no longer works and is intend to work.


And yeah I think EA will love it. It kicks out many that created quality software.
It will kick out even more that primarily caused price dumping, and for those I don't feel sorry as they flooded the store with low quality trash.
But I don't feel that it is the right way to punish all for Apples lack of guidelines on quality and min. performance for the "immersive application" class applications.
Such guidelines also would have ensured that Flash won't trashflood the Appstore.

What Apple at the time is also missing to get a base level for quality is an approval fee. That would ensure that people stop sending trash in just to have their name on the store.
It must not be high, its enough if it makes clear that most free / $1 trash will never make it back in.
$100 / approval request for example would be adequate, in trade for detailed information in case of rejection.

I think these two steps would be much more important to achieve the target of a good app quality and healthy platform.


I mentioned that in various places already but to me it seems that the driving force in this case potentially is not just a "keep out" reaction but more a behavior that Apple has shown several times in the past: They want to missuse their monopol control to force in their own solutions and basically "help" devs to adopt to their controlled solutions faster, especially on the advertising and social game platform end. That was at least one of my first reactions of the combination of the announcement of the new stuff in relation with the shut out of existing solutions (while not directly related, the nature of the solutions is that they have implementations for the competition and potentially won't get an Apple friendly implementation at least during the beta of OS4 and thats likely exactly what Apple wants independent of the notes on the game center page and alike which make it clear to me that I will not even consider to implement it during the beta)