iPhone OS4 today

WISH SOMEONE WILL REPLY:

Is ALL THE SDK called WebKit - I dont thinks so!

So the words above mean only "iPhone OS WebKit engine" IE - Safari WebKit

I think they dont want Flash in thier iAd's



Oh yes:

"and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs"

That may not be Webkit....

 

I have to partially retract this comment as I've just discovered there are numerous ways to detect translated code. That assumes they (Apple) would have access to the code, however, so I'm not sure how efficiently they'd be able to detect it once it's compiled.

 

those were some of my thoughts on it too.

 

Microsoft tried to dictate its will to the desktop PC market. Apple is just controlling its mobile app platform. This is similar to Nintendo controlling its NES platform back in the 80s.

These three companies may have monopoly market positions in these different markets, but the latter two actually own the enchilada and AFAICT there is/was no antitrust illegalities involved.

Apple is free to license its stuff to whom it wants at what terms it wants. There is no issue of "tying" here since there are no third-party products involved.

Apple's only crime in the 80s was making the most amazing PCs of the decade and charging what the market would bear for them.

yeah, I'm a zillion times more productive in C#, and I've been coding it for months and Objective-C++ for years.

 

You or your engine? Please stop spreading silly rumors to the technologically clueless.

Unless Apple starts, rejecting aps or Unity gets a statement from Apple we will never know for sure. Os 4 is not even out. No one will know for sure for weeks.

 

And there's absolutely no reason you couldn't add Objective C code that calls the requisite functions to an app within your "compatibility layer."

It really couldn't be more clear: Apple has outlawed cross-platform toolkits with this new rule. You can't create a cross-platform toolkit without either doing code generation (which violates the "original language" clause) or a compatibility layer.

But they've also created a huge storm of protest and objection. At this point we need to see if Apple blinks, or blesses some of the available toolkits. Until then, it's all a risk.

[edit: clarity]

 

How so? Did Nintendo dictate the tools that developers could use to develop their games?

As far as I knew they just required a quality level to any title released for their console.

 

The new TOS needs to be accepted before the end of this month (maybe the 22nd?), if I remember correctly. So it's not about when OS 4 comes out.

But you're probably still right: We won't likely know for sure whether Apple will reject apps until Apple actually rejects apps. I'm betting they don't bother replying to Unity3d, in fact.

 

Here's a bit from this http://news.cnet.com/8301-30685_3-20002102-264.html?tag=mncol;posts piece on cnet.com:

That's somewhat reasuring, but I wish somebody from UT would say as much here to us. I mean, they may not know for certain how it'll pan out but Mr. Helgason has been quoted on at least two sites saying esentially what's above.

Meh, time will tell. I guess we can't expect to be coddled but it would be nice to get some sort of update today even if it's just "we're still looking into it."

 

@Troy Dawson, see my comment a few pages back about suing people for owning an iPod or iPhone that exploded.

Sounds about right. Every time I see ObjC code I have this sudden urge to swap my eyeballs with my testicles.

 

I meant from a legal standpoint (Nintendo played hardball with licensees wanting the privilege of shipping titles for the NES).

Morally, from what we know now, the apparent banning of C# and Lua blows 30" donkey parts.

As I said above, our only hope is that the engine -- the app if you will -- itself is a proper codebase. Game logic is not app logic, right?

 

I work in the games industry, full time. Have done for the last 15 years, and held positions such as Head of Game Design at SEGA, for my sins. If Job's reason for doing this is infact, as we expect, an effort to block Flash, then he's essentially using a boulder to crack a nut.

The big problem with everything iPhone is the issue with quality of applications. If they actually did this properly as with the other 1st parties (where your concept is reviewed, and they won't let low quality product through), then we wouldn't need any of this crap. What he's essentially doing is papering over the cracks in the approval process and his apparent inability to stop S*** getting through (see "iFart" as a good example) and as such, blocking proper developers who care about their games.

I've only put out one game so far, but I'm working on 2 MUCH bigger games which should have been up to the quality level of EA or Ubisoft titles (which is why I've been so quiet), so this is really bad news for me. I've been hoping that Apple would do something to sort out their approvals so we saw the end of Apps put out by rubbish outfits like "LOLriffic Games" (ew), and it'd be more about them trying to maintain the quality levels in the same way that SONY, MS and Nintendo do. Instead, what they've done is effectively move to force out developers who are perhaps looking for a more "efficient" way to get their games out rather than having to re-invent the wheel all the time, writing physics and graphics engines independently. Unity isn't all about "hobbyists", it's actually high end developers too. If this can't be sorted, I won't be making the effort to develop for apple products again.

Just hoping that Unity will sort us out with something alternative for the money we've spent - even if it's just a (sizable) credit toward something else...!

 

Actually you're wrong. As long as the code that hits the Xcode compiler is Obj-C, C, or C++ "it's originally in that language." The issue is a threaded environment and Apple, as well as a ton of other people, know that cross-compiled code often behaves differently in that environment. You can't hold historical preference in a EULA like that. So what...all my python math that I ported to Obj-C is off-limits too? Give me a break. It's an un-enforcable position if that's Apple's stance...which it isn't.

 

Part of it comes down to how big a stink is Adobe going to make. Are they going to demand to be treated like everyone else?

 

Apple is the No3 biggest company in US today. It will be soon the No1 tech company and No1 overall in US within 2-3 years (after buying facebook and enter the social/search market, I suppose).

20 Largest U.S. Companies By Market Capitalization
as of 02/09/10
(today Apple>210B)

Apple is doing its job right!


When we chose to go the unity way instead of developing on pure objC we knew that this had some serious cons and risks (we were just tempted to "cheat" with this rapid development toy).

It is unfair to blame Apple for this situation now...

 

I hope you're right, but I suspect you're not.

First, in that event they could have simply required that all code go through one of their compilers. None of this "original language" crap. That alone would have been enough to exclude Adobe/Flash.

Second, the "no compatibility layer" clause is entirely spurious if they only care that the code hits their compiler. The latter seems like it must be entirely about cross-platform toolkits. It doesn't make sense otherwise.

Presumably a compatibility layer would be written in C++/Objective C.

All of this speculation could be stopped in a heartbeat if Apple just publicly clarifies their position. Which they won't do.

And I hope I'm wrong.

 

Certainly reassuring, but still lacking info.

Here's what I think about what's going on. I'm an artist, not an experienced developer (but interested in it) so please bare with me.

IMO, Apple is taking quite a big risk with what they are doing. In one hand, they are trying to secure and protect their own market which has definitely proved to be both a great source of income for developers and Apple. If you where to put yourself in their shoes, meaning that you OWN Apple and OWN this super hot market (iPhone/iTouch apps), you'd want to protect it from, like someone earlier said, a tornado of flash games. As far as I can tell, Apple just want to not only OWN this but DOMINATE it.

However I say it's also risky for Apple because they are literally shutting doors on innumerable possibilities that can come with allowing Flash games/apps whatever to run on the iPhone etc. It can be risky because if they are shutting these doors on Adobe, Unity or whatever, they are also shutting the doors on the developers that are interested in developing iPhone apps. this is turn could lead to a majority of developers going to another platform to deliver their games, which could completely ruin the baby Apple's trying to protect.

Everyone knows this is being done to F*** Adobe up, however it's just sick to think that 3rd parties such as UT will be affected in the process. this is messed up. Only time will tell

 

How am I wrong? This is an exact quote.

It cannot be more clearer, Applications have to be originally written in Objective-C, C or C++. You can't in Unity's case write it in C# and "convert" it at build/run time to be valid.

 

Easy killer, easy. Silly rumors? We wouldn't have 900 scared developers reading this thread if there were silly.

I have OS 4 beta installed in my iphone and I've been reading the new docs since yesterday. The APIs are very clear and you can be sure the ones released in summer wont be very different to what is out in beta today.

If you want to be picky about my use of English then I'll rephrase myself. You as a developer, will have use the unity engine to write code that when run on the device will be able to access the multitasking APIs available in the OS.

So far in my experience I believe this will only possible by writing the application in a native language that can access those APIs

I might be wrong about that, but I am not sure, and that makes me scared. Do you have any idea how much money my company has invested in this in the last 6 months? Hell we preordered 20 licenses of CS5 last week just to be able to export our flash games to iPhone.

We all want to hear official statements from both Unity and Apple confirming or denying. Most of us in here have spent money in licenses that we are not sure we are going to be able to use and until we hear from them or we start seeing apps rejected on the app store panic is going to be around these forums.

In the end business is business and if Apple is only trying to make their profit then who knows what will happen before the release date.

We will see.

 

That is just because most US companies are crap and / or run by fools.

 

wut

 

Can I ask you a question what language do you think Unity is written in and secondly do you know what a wrapper class is?

 

Because you can't prove it. You can't PROVE that I didn't originally write the code in anything other than whatever I generated. Besides, if it was that clear...we wouldn't have 10 forums with 100's of pages of speculation would we?

There are a number of steps that can be taken on the Unity and Mono side...obfuscation of open-source being a common one.

If this was about Adobe, Apple wouldn't have put it in a beta release for an OS due out in June. they would have gone scorched earth already and amended all our current dev agreements. Do I think they are happy that this nukes Adobe? Yes. Do I think they have legitimate and maybe more important other reasons for doing this (again...a multi-threaded environ on an embedded device)? Yes...I do.

I think we will all be fine. There are a number of solutions for this problem.

 

Ok I correct myself, I just found out that it is possible and I bet Unity can be patched to allow the use of the new APIs. Still, I want those TOS changed or an official statement from Apple and UT giving us a little piece of mind..

My company is not exactly huge and my employment depends on profits.. this pretty much puts my job on the line.

 

http://www.appleinsider.com/article..._4_sdk_license_bans_flash_java_mono_apps.html

Most of you have read this, but I think that even to someone like me who isn't an experienced developer can clearly see that this invloves Unity as well.

 

Yeap!

The majority of developers bothered to learn an awkward language while we were clicking and dragging on a platform based on technologies of the biggest competitor of our market-maker (Apple). Why should we blame some other for this free choice we made ourselves?

Apple is free to do everything it believes to be good for its investors in long term.

 

Seriously what is all this hostility?

I have been coding in .NET since the beta of the 1.0 framework. I think I know what a wrapper class is. I started working on iPhone apps in October last year and we decided to go with Unity last month.

Yours is bigger!!!!!!!!
Does that make you feel better?

 

First it's not that black and white in regards to it converting the code, it doesn't just convert the code to the relevant language.

You are niaeve to just believe everything Apple says, remember they said MMS on the iPhone 2G wasn't possible due to hardware? They lied, it was simply a software lock. Again I will repeat, Apple lied in order to sell their newer 3G phone.

You also say their are a number of solutions to this problem, please share them I'm sure UT and Adobe could use your wisdom...

 

Unity is the application that actually runs, and was originally written in C++. Writing some C# scripts doesn't cause an application to be created; the people who wrote the Unity engine did that.

--Eric

 

Apple, if it so chooses, could deem Unity-based apps conformant since I assume Unity's code is the proper C/C+.

This is somewhat similar to the GLSL gap in the license.

But this is more wishful thinking at this point. My fears that Apple wants to lock out cross-development are greater than my hopes that Apple wants middleware here.

 

Are you people in denial or something? :?

"Applications" meaning iPhone applications and not the middleware (Unity) used to develop them.

 

Hopefully, Apple shares your interpretation.

 

I love your moderate and well-reasoned posts!

 

I agree, they could easily add a clause that allows Unity developed applications but they won't because then they would be seen to be basically endorsing Unity. Unfortunately unless Apple changes this EULA their isn't much hope left, this addition was designed to kill Adobe's upcoming Flash CS5 release but has instead ended up killing other middleware. Do Apple care? With an ego their size I'd imagine no.

 

Yes, denial seems rampant.

The language clause is only part of it. It also makes "compatibility layers" against the rules. That is part of just about any cross-platform toolkit, including Unity.

 

Best thing for Adobe is for Apple to buy them, make Flash VM run GREAT under Mac OSX/iPhone and turn Flash Pro CS5 into a 2.5D game dev tool.

 

No denial. But it's not as clear as you seem to think.

We knew no such thing. There was no indication that there was any "risk" in using Unity, or any indication that there ever would be. UT spent 6 extra months getting Unity to work with AOT instead of JIT, and as far as anyone knew, that solved every issue that existed. Apple has been happy to feature Unity games many times.

Of course it's fair...it's 100% their fault. Not admitting this is just as bad as the blinded muppets who think that MS is "not the bad guy".

--Eric

 

I may agree with that but I can still think this decision sucks for me as a developer.

Going with C# scripting meant I was developing codebase and skills that were directly transferable to XNA and xbox development.

Apple isn't making the tech world any better with this decision.

 

Unity would be crazy to sell a tool on the basis that the deception won't be found out. Hell, Apple would just sue them directly on the basis that they are enabling developers to violate the license.

 

It is that black and white. I've done it and have been paid well to do it.

You don't know me so don't pretend like you do. I don't believe anything any company tells me unless I can do the research and discern the information for myself. I've learned that during the 11+ years I've spent in the games industry dealing with console manufacturers. And the 5 years before that doing military grade engineering. So naive probably doesn't apply to me. .

As I mentioned in my previous post, that you must have missed or didn't understand. Here...I'll be nice an help you on your way. Google "obfuscated code" and understand that this has been done for decades in software and embedded devices to solve issues remarkably similar to this. Protect IP and give clients the ability to use or access system features. Unity could open-source a back-end under the same concepts giving us the ability to call functionality from whatever we like. The rest is left as an exercise for the reader. I'm sure Adobe and the Unity folks are already on this, and they don't need my help. Just because it's new to you doesn't mean it's new to everyone else.

Again, I think we will all be fine and this stuff will work itself out.

 

There's a slew of middleware that Apple would like to see go away, not just the Flash stuff.

I don't specifically think Unity 3D is in the cross-hair, but it could certainly be collateral damage.

 

If you look at binaries you can generally demonstrate* that, say, a given slab of assembler could not have been emitted from a given back end. E.g. every Objective-C method call is going to have a certain pattern of operands.

* "prove" has no fixed meaning. If I can demonstrate that you either compiled a piece of code using X or did some extremely unlikely and arduous other thing, a jury -- or some dude working in the App approval department in Cupertino -- will simply assume the former and not the latter.

Now, chances are if you use some toolchain -- such as C# -> Mono -> ??? or Flash AS3 -> Adobe LLVM -> ??? you will get binaries that can be demonstrated not to have been emitted by Apple's blessed toolchain. Obviously, you could write some kind of elaborate post-processing gizmo or modify your toolchain to create code that looks like it was emitted by Apple's blessed path, but this would be kind of a nutty way to do business (and it's nutty that Apple is putting folks in the position of figuring this crap out).

That said, it's perfectly possible that someone in the legal department tried to draft a clause that walked a tightrope between, say, banning people explicitly from writing Apps using anything other than XCode (which is something they could have just come out and said, right?) and allowing stuff like Flash SWFs passed through voodoo in -- and simply got it wrong. Even a pretty smart lawyer who works at Apple might not fully grok all the factors at work here.

 

IANAL, but it seems this situation (and many other past developer situations in regards to Apple's app store) may be covered under U.S. antitrust laws:

http://speirs.org/blog/2009/11/13/the-app-store-as-essential-facility.html

http://www.ftc.gov/os/comments/intelpropertycomments/pitofskyrobert.pdf

Hope we hear something back from Unity soon, it's been a full day now with no relief. Though given my current level of disgust with Apple, it may not matter: The current bruhaha simply reminded me of all of Apple's past slights toward developers, so I'm now reconsidering my plans for iPhone/iPad development regardless of the outcome of this particular situation. I can't really afford to risk an arbitrary and capricious App Store rejection.

 

Agreed

Sony or Nintendo can do stuff like this when they're dealing with 10s or possibly 100s of developers shipping 20 titles a month. This concept doesn't scale.

Again, see above.

Agreed. Indeed, virtually no serious game developers work without some form of middleware. If we're all forced to roll our own code for everything or wait for Apple to provide Cocoa libraries for everything then the iPhone will be dead as a games platform pretty darn quick.

 

Fear. Paranoia. Panic. Wild accusations. Lashing out. Good times.

So, Eric, I hope you're right. My interpretation so far is that Apple will be using a technique similar to android to package up a running app to bring back later: serialization. That Appleinsider article makes sense in this regard. Yes, the engine runs in C++ natively but I'm unclear on how the rest of the runtime data is handled and if it could be serialized via NScoder.
Here's a link for some background info:
http://blog.rlove.org/2010/04/iphone-os-4-and-multitasking.html

Someone could do a quick test and run a Unity game on iPhone OS 4 and switch to another app mid game. Come back to it. Does it work perfectly? If it does -- and you might have to do a lot of testing to be sure -- that explanation is pretty much bunk.

Philosophically, I hope that is the reasoning behind the change. Hopefully, that's not only the reason, but Unity is unaffected.

 

Yes it is as clear as I've wrote, legal documents have to be clear or else they won't hold up in a court of law. If you think that sentence can be misinterpreted multiple ways then you're wrong, its clear, concise and gets straight to the point.

 

Apple would never buy an overvalued and saturated technology (right before its death). It would be as irrational as for eBay to buy Craigs List.

 

http://daringfireball.net/2010/04/why_apple_changed_section_331

Just a little sidenote if no onw has read this. This'll give you a MUCH better perspective on why Apple would be doing this. If this is true, UT, MonoTouch etc are getting kicked in the ass by Apple. Even if someone from Unity said that they have good relationships with Apple.

Like Apple would care! they're not gonna throw away this chance to make this completely their own just for Unity (at least, I don't think they would). I dont think anyone in Apple's feet would do that. It's sad but it's true. I was just looking at the forums over at MonoTouch. They seem to be just as pessimistic, which is unfortunate.

let's hope it all goes well and Unity and others are left untouched

 

You are wrong here. If Unity worked like you think it works it would have already been banned from the App Store because Apple doesn't allow for apps that have built in scripting engines (and never has, no JIT/no scripting has ALWAYS been a part of the developer agreement).


The whole push for Mono/AOT for Unity was to work around that situation in the first place. And now Apple has banned the workaround as well.

 

Interesting...I'll bite since today is boring and there isn;t enough discussion going on . How could they show or assume a slab is different and not native if XCode is the final step in compilation? Everything is coming through their chain. So not only would they have to understand what happened before that last step but be able to untie what their own tool chain did to the binary. This from a company that hasn't even gotten automated app rejection correct yet. I'm not saying it's not possible. I'm actually interested in learning techniques on how they would go about achieving this.