Unity and iOS 4.0, update III

Dear community, once again I’d like to start by offering my thanks to everyone for their patience through an unclear situation. We’re grateful for the dedication and commitment many of you have shown through all this and it once again serves as another reminder of just how awesome our community is.

Like everyone else who’s excited about mobile development, and in particular using Unity to create awesome games for the iPhone, we’ve been following the development of the iOS 4.0 Terms of Service closely. While we’ve had some reason to believe Unity using C# and JavaScript would be okay, Apple has not confirmed anything and in general very little information has been forthcoming. However, as of today Apple is still approving every game we know of and Apple has recently featured several excellent Unity games in the App Store. And all along we’ve continued to invest heavily in our Unity iPhone line, including a number of new features that will be coming soon in the Unity 3.0 release. But as soon as the new terms of service were revealed we also started working on a contingency plan, just in case Apple decides to stop approving Unity-based games. Allow me to explain that contingency plan so everyone out there knows what «plan B» looks like.

As you probably know, Unity is mostly written in optimized C++ with assembly optimizations and Objective-C wrappers thrown in for good measure. Game logic is written by the developer, using C# and JavaScript, both of which are running on top of .NET. The beauty of this scheme is that we’ve been able to sidestep the old scripting-versus-native question as .NET provides for very rapid development (and almost near-instant compilation), while at the same time generating highly optimized code. And on the iPhone we actually ahead-of-time compile .NET to completely static machine code for speed and conformance with the old iOS Terms of Service. Also, on the iPhone it’s easy to drop into Objective-C code to access fresh APIs like the Game Center, Core Motion, etc. This is truly a case of best of both worlds.

Since Unity’s .NET support may conflict with the new terms of service, we are working on a solution where entire games can be created without any .NET code. In this proposed scenario all the scripting APIs will be exposed to and can be manipulated from C++. This is of course not ideal as there are thousands of code examples, snippets, and extensions created by the community can no longer be copied into your project, .NET assemblies can’t simply be dropped in, and C++ is more complex than JavaScript or even C#.

But honestly, it’s not as bad as one might imagine. One still has the full benefit of the asset pipeline, the shader language, an array of tools and of course the engine and its optimizations. We are also working on maintaining the elegant workflows of the JavaScript and C# in Unity: «scripts» will still be able to be edited live, variables will still be shown in the inspector, and a number of other sweet features that one doesn’t usually associate with C++ development. Essentially we are creating a .NET based C++ compiler that will allow us to write purely managed C++ code in the Web Player and other Platforms. On iOS C++ code will be compiled by Apple’s Xcode tools. This indeed is a very powerful combination. In the Unity Editor, you have fast compilation times and a completely sandboxed environment. On the device you have native C++ performance and low memory overhead. This combines the key strength of scripting languages and C++ code.

When you combine those with the fact that when it comes to straightforward game logic, C++ really isn’t as complex as it’s often made out to be (and as it can be) hopefully you can see that life won’t be so bad after all. To help demonstrate my point, let’s look at a few different examples.

Here is a simple JavaScript function to rotate an object around the world origin:

And now here is that same bit of code written in C++:

As you can see the code required isn’t all that different in simple case scenarios, but what about a more complex example?

Here is a bit of JavaScript that peeks accelerometer and looks for user touch input on an iOS device, then uses that to fly a craft and fire a missile in the game:

And again, here is that same set of code in C++:

Again, the code doesn’t get that much more complicated just by writing it in C++ versus JavaScript, and the difference is even smaller compared to C#.

We continue to be excited about the iPhone, iPod touch and iPad as platform targets for Unity developers. While we don’t think C++ is the best language to write game code, using C++ as a scripting language has memory and performance advantages on low-end devices. This is a great feature to have for developers who want to squeeze the last ounce of memory & performance out of their games.

We still can’t believe Apple will force developers into choosing a specific language for development. And as mentioned, Apple is still approving every Unity-based game we know of. In case the situation changes, rest assured that we are working this Plan B.

We’ll be ready to talk more about this as well as share some time-line information with you soon, while of course waiting to find out if any of this will actually be necessary.

117 Комментарии

I’d love to see C++ as a language to interface with the engine. Albeit I do C#, Java and Python often, I always fall back to C++ and implement it there albeit harder. I just don’t like Garbage Collectors, although they are meant to make memory management cleaner; I’m very tidy with my memory, and it haven’t been a problem, even in old C.

But then again, I’m weird, and a control freak, and I don’t like no GC touching my allocations :| Not that I never make memory leaks. But you learn to look out for them.

if Google could go as big as it did on opensource then why cant THE INTERIM i-of-Apple take the middle ground and be known the i-Position. Unity u rock. U too Apple. Let everyone who knows C++ or C# or JavaScript or Java rock too. Let GREAT GAMES BE MADE. The «i» of Apple and the «U» of Unity makes the u-n-i. Lets build on the u-n-i architecture. Make growing in the hearts more than growing in the pockets a reality. the iReality.

People here are obviously indie/non-professional developers. Having working in the software industry for some 25 years as a software engineer on games, simulators, plc’s, robotics and many other platforms I have see how bad C++ exposure can go.

It is the wrong solution for high level abstraction. To those who think no great games use scripting, my god you are so wrong. WOW.. for a single massive example is almost entirely built with Lua. But almost _all_ AAA games titles have some form of HLL driving the game systems. From Naught Dog’s LISP.. to Unreals script, and Crysis’s script.

You think exposing C++ is a good idea, but in all my life I have NEVER seen it used wisely. There is a whole argument about C++ and OO that I really dont want to get into, but the facts are out there (google the C++ OO failures — there are some fantastic ones, from Netscape to IBM. And very little long term success).

For those that talk about compiling and building .. you are not talking about C++ but ANSI C. THAT is the true great cross platform toolset. C++ has a myriad of variants, and is a nightmare on many platforms to cross compile (unless you are lucky and have multiple gcc targets).

I would heavily recommend not going down this path. Choose _any_ other scripting system, any, there are hundred’s of great ones out there. Your product will suffer with this sort of change.

I’d just like to add to this what I imagine a lot of people have already said:

Regardless of whether or not the new TOS require it, I think allowing C++ Unity development should happen. Hell, I’d even like to see the Unity Engine in SDK form as well. Lets face it, a proper AAA game is fairly unlikely to be made using C# scripts, unless the game logic is fairly light.

I’m programming for +24 years and from my experience C/C++ is a programming language that will last forever, is owned by no corporate and thus is an EXCELLENT choice. Some code I have programed in the early 90’s are still compiling fine today (compression for example)

.NET is a Microsoft owned technology and who knows if they will drop it or not. Ask to anyone who worked with MFC, or Visual Basic how they feel now that Microsoft simply dropped these technology after millions of people learned and used them, or invested in expensive certificates… now these are not supported by Microsoft.

Better use C++ for everything, it is the most solid and lasting programming language ever.

Why is Apple being such a jerk about this? What possible advantage do they get forcing us to use C++? We are still dependent on Unity as a third party solution either way, it just means my games will be developed slower. Grr.

@Superwaugi: «we have to code a game only for the Iphoneplattform and code it again for other plattforms. One big advantage so far of Unity is, that you can use most of the code for different plattforms.»

We are planning to have a managed C++ compiler. This has two effects:
1. You can deploy the same code on all platforms Unity supports, including the web player
2. You have quick iteration times and a full sandbox

Wouldn’t it be great if Android phones were a bigger market than Apple… can only dream of that day. I love my Apple products but damn, I hate being held at gunpoint like this with their TOS. I love C# and I love Unity. I’m going to pray to the Gods that Apple sees the light in favor of Unity.

It`s good to know, that there is a Plan B. Beeing an artist myself it would not be easy to learn C++, because Java is much easier for someone coming from the modelling side. Anyway: If we have to code for Iphone in C++. we have to code a game only for the Iphoneplattform and code it again for other plattforms. One big advantage so far of Unity is, that you can use most of the code for different plattforms. Also it wouldn´t be great to recode our works in progress…. But again: thank you for having a Plan B. All the best to you!

@people who they don’t know UT
unity technologies is the most honest company that you can find in this industry. they did not and will not change it because this is their key to success so stop saying: i think unity … apple …
i can swear that if you don’t know so David don’t know too and when he know, you will know after few hours.
i think UT will improve AOT compiler and mono touch guys are working on it too so it will become better. as i said before C++ surely is a good option for many different reasons from academy to our hurts but there are many other important features to add. if UT was 1000 people then i would say that it’s a most have but now it’s just nice to have.

@Ryan: we will likely only do this if forced to, and we will only ever disable JavaScript if Apple absolutely forces us to. This isn’t sure (or even likely), but we are not in full control of this ourselves. We certainly won’t go and disable great features for fun.

@proponents of C++: no promises as this is a pretty big chunk of work, but we do hear that there’s more people than we thought who like C++ (but then this comment thread isn’t going to be representative, and we’re obviously not going to use it as some kind of public vote). Thus, no need to add «+1» comments.

@everyone: there’s been some speculation that we have some information that we’re not sharing. All I can say is that that’s far from the case, and we’ve promised to share any updates we get as soon as we possess them.

Wait wait wait… just to be clear, Javascript will be dropped? Think of the children!!! The reason I got Unity Pro/iPhone Pro is because of the ease of scripting. That was the selling point for me. I’m an artist who just started to taste a little of the programming world. C++ looks alien to me. :(

Is it just me or the lines written in C++ is more than the js example? How is that good when this easily increments quickly as you put in more codes?

I hope C++ is just an added option. Not a requirement.

Hate to see Unity to be only for 3l337 users.

I love the way the workflow is right now. Should it be C++ only, I guess artists will look elsewhere. I’d hate for that to happen.

Hopefully it doesn’t become like Apple. The «Hey, you can only use XCODE for this!» attitude.

Worst case: I’ll just drop Unity iPhone and just focus on making desktop games as long as I can make develop easily and faster with javascripts.

I’m happy for you C++ enthusiasts. Worried and concerned for fellow artists/js users like me though.

I dunno about y’all but I think this thread is quickly turning from «David: Oh Folks I’m sorry you may have to start using C++» to «Unity Users: Wow awesome we want to start using C++ roll it out!!» @David & @Joachim… are u surprised?? and that makes the 100th comment!!

Will you be open sourcing this .NET C++ compiler? I know many, MANY, people would be interested in this. There are some which are Windows only, C++/CLI, and some that are cross platform but incomplete, lcc.

Multi threading is a lot easier in C# then C++. Especially in the future once, we get simple syntax for delightful loops. Just spin your code off into a new thread and use C# it will end up faster. If you don’t like OOP then by all means continue to use C++.

mimiboss don’t know what kind of math your doing but C# does not support vectorization well. Although mono does add some extensions.

I think there is no question that C# and JavaScript are extremely efficient for doing the typical trigger and control scripts needed for respond to actions.

BUT, if you try to use Unity for more heavy-weight changes — like implementing a new terrain system. The current bitmap based terrain system is very good for plain vanilla shooters. But let’s say you wanted to have deformable terrain — maybe using voxels or something. Yes, IT IS possible to write code in C++ that you can call for generating the mesh … BUT … for these kind of changes, you really need keep and access custom C++ specific datatypes — and use them in all kinds of scripts. So, you really need your camera, your AI, your path-finding, your collision-system — basically EVERYTHING — to access data types only available in C++.

OR — if I look at my own railroad project (which has been written in C# — but I would have saved months writing it in C++, and the code would have been clearner), where I have a terrain system that covers the entire US. The basic terrain node is a hex and each hex define a terrain based upon curved surfaces (bezier-patches). (and yes, it runs great on an iPad/iPhone) This is a major system component that needs to be accessed by everything from the input-touch-tracking to cameras, to collision, etc. If you for instance look at a hex node — it has 6 directions — but instead of having an array of 6 directions and loop over them — in C# I need to handle each direction separately and duplicate code — because if I wanted to keep everything in arrays (points, control points, normals, directions, fdds, etc) it would cause each hex node to perform a dozen array allocations — whereas C++ can keep these as part of the type definition and be a part for the core hex node structure. And when you have millions of these hex node in memory, you really need to resort to extreme compression and custom datatypes.

Again, this is just one tiny example — but my point is that if you want to fundamentally change a «default» engine component in Unity — while keeping the excellent editor, the asset pipeline, the prefabs, the webplayer and lots of target platforms in addition to all the other cool stuff — the only language that really is capable of doing that, is C++. I can see that my case is not very typical, and you could even argue that Grome or some other low-level C++ engine/renderer would be a better fit for a project like mine — but I really LOVE Unity and environment, but Unity is so much more than just a renderer, and for me it was instant love the second I got Unity 1.6 a few years ago.

AND … I guess the fact that I have managed to complete a project with such fundamental components being fitted, and keeping everything C# is a testament to that we really don’t need C++ — but I would be completed the project many months ago in C++, the codebase would been 50% smaller, I would have been able to drop many layers of caching, I could have had even more trains and details in C++. So, please — don’t disregard the importance of C++ if you really want to extend Unity into ways your really never thought possible : )

That’s a curious result, but I believe you. It does make me wonder what the fundamental difference really is. When doing ahead-of-time compilation, mathematical expressions should result in roughly the same code. Perhaps GCC is just plain capable of optimizations that mono isn’t? I’d love to see someone do an in-depth analysis of what the issue is.

Having read the news and comments it gets clear to me that Apple granted Unity guys a period of grace to implement a solution based on C++ and once implemented, the period will be over and C++ will turn out to be the only way to make it for the Apple Store.

The more scripting languages you support, more difficult will be to mantain core code. Besides, imho, C# made Unity stand out in comparison to other solutions like Torque and Shiva3D.

Personally I would like to see the cost/benefit analysis that convinced so many of the above commenters that C++ game development > C# game development — given that the scenario is game logic and not core development.

While the idea of more choice seems like a good idea at first, I’m not so sure I would push for ubiquitous C++ scripting support.

While I applaud the company for providing a Plan B in case Apple brings the hammer down, I prefer this option only be a Plan B.

More choice brings complexity and confusion. There is a balance that must be struck and I would say Unity has already struck that balance. By introducing further scripting choices they will spread themselves thinner and either the quality will go down, competetivess will be reduced because time between updates will increase or the price will have to go up so they can hire more people, etc.

One of the biggest problems I forsee is the further dilution of scripting examples and documentation. While this would become a necessary evil if Apple forces their hand, I see it as a terrible blow to the ease-of-use of Unity in general. As an iOS developer I see the need to placate Apple (wish it weren’t so) but I don’t want to lose the speed of developtment and simplicity that Unity currently has achieved. If one needs C++, then use plugins. There is no need to script everything in C++ especially if it is managed.

The future will be managed code for the vast majority of programming anyway. Low level programming like the Unity engine itself makes sense in C++ but game mechanics and behavior scripting does not require a BS in computer science and we shouldn’t move in that direction. I want to be able to hire and use less skilled workers to do simple scripting, not require everyone feel comfortable with C++ if they don’t have to be. (And if lots of code examples become only available in C++… well then everyone needs to understand it.) As it is now, Unity is ahead of its time in allowing simple game programming tasks be done with high level scripting languages. C++, while a powerful and useful language in its own right, is not best suited for the future of simpler programming tasks.

I had to rewrite some math for «Crash Course» title. Typically c++ vs c# (using Unity Math) speed increase is 200% to 670%.
For example cross product is 2x faster, but lets try to use the same c++ code compiled in c#.

If C++ is not required, I’d rather see the Unity team put their efforts in other areas than spend the time and resources adding and supporting C++ as an option. Sure it might be nice to have it, but if it’s that big of a hassle, there’s a laundry list of other features I’d put before it. Just my $0.02.

@sven myhre
you can use C++ libraries to do your calculations in C++ and just call them and get the results in unity to display them.
@joachim
you can implement unity’s C++ support in a way that people jcan use unity as a library that can load scenes that made by unity editor and without editor support for things like public variables inside editor inspector and …
it’s ok for C++ programmers and their habits. i mean, most IDEs like unity are for scripting languages. engine’s that use C++ don’t have these kind of IDEs. take a look at source engine.
i think scripting languages like are the best option for game logic scripting but C++ is good for critical code wich is possible now in unity so let’s use currently available languages.
if it was possible to use .net with unity in windows, it might be possible to use managed C++ with unity and have it all work out of the box :)

Unity is training the next gen of game programmers by proxy. C++ has a million+ libraries on the web. Hex grid generators, University/guvmnt/miltary researched AI, graphics and rendering libraries, sound, the frakkin Universe mapping. the human genome, dynamics simulations, megasim frameworks blibbatty blabbitty blue.. I don’t know C++ but using Unity has given me confidence that I/you who use it and get these amazing ideas in our brains onto a computer screen that pull users down our tangents of thought using artworks and scripts can use the same logics they used deducing their first masked raycasts (goldanged bitshifting binary syntactical bltherfrest if ya ask me:)) to produce quality C++ code with the requisite guidance from the minds at Unity (documentation, documentation, documentation), who no doubt struggled and triumphed through the gates of learning to simulate via code and graphical representations of the results of that code just the same as everybody here writing comments to one degree or another. Beyond the extensive libraries and research presented as C++ code out there, this is a valuable «stay-employed» skillset alongside the knowledge of 3D meshing, rendering, rigging, dynamics and all the other disciplines that are necessary to compete effectively under the moniker of game developer/studio/team. And back to the original premise.Unity training the next gen of game programmers. All of these folks will not end up as a CEO/CTO of their own gaming studio but conversely will be working for others. To give them the best foot forward would be to add this to the «curriculum» for all. The pros at it will surely assist on the forums and soon the whole community will be kicking butt with a size 16 cowboy boot in that arena.

As I suspected, most people would actually like to use C++ regardless of Apple’s TOS issues. Many professional game developers are already writing their code in C/C++ so this is almost a welcome change regardless of the actual impact of Apple’s move.

Brilliant!
For simulations, like the train simulator I am working on now, I really miss the efficiency of C++. In such simulations with hundreds and potentially thousands of trains running in realtime across a nation, large datasets needs to be simulated even if not visible on screen. More than anything, in C#, I miss array definitions being part of the data type, like in C++ — so one can allocate arrays of structs in one single alloc, use dozens and even hundred of small temporary arrays in quick methods and even put them on stack with no memory alloc — or — being able bake them into larger structs. Being able to use C++ would also make it easier to reuse the same logic on game-servers, where C# and JavaScript is often not an option.

Even though 3.0 is a fantastic piece of work — I would trade everything new in 3.0 for being able to use C++ for scripting :)
I really hope this would make it into Unity — it is almost so that I hope for Apple to ban .Net, so this project can take first priority within Unity :)

@stew: I agree and I’d quite like to see unmanaged C++ available for advanced developers anyway, even if apple don’t require it.

@Sean: Surely the flash packager was written in C+ or objective C. Its the flash files that it plays that are not. This is similar to unity in that its core will be native and it plays the unity data files.

Personally i think Apple are nuts and should have simply come out and say «Flash is banned in iPhone». An alternative rule would have been for them to simply require that applications reach a set level of performance and responsiveness. Most flash apps would probably fail that anyway and if a unity app failed that then make it run faster!! Console games must pass a similar rule or Sony/MS will throw them out.

Thank you so much for sharing «Plan B»!
I think its an excellent plan!

I hope that Unity will proceed with implementing
«Plan B» regardless of Unity Apps currently
being approved because it would guarantee
compliance with the iPhone TOS, and also because
of the memory and performance advantages that
you noted. I strongly suspect that Apple will
get tougher with their TOS as time goes by,
and their «grace period» on the TOS has ended.

I’m really glad that i decided to dive into the world of unity last year. The current update about the Apple’s ToS and unity shows once more that UT won’t stop moving even if it means to break through heavy walls.

@David…thanks for the honesty and thinking about us. I use unity Free to design vehicle simulations (engine, transmission etc) for a driving school and some arcade games. I don’t have pro let alone the Iphone license so none of this really affects me. But I’m a huge fan of UT because and Personally I am glad you guys have already thought of plan B. However I think UT is too young to take on this Huge challenge and may loose focus of it’s vision of DEMOCRATIZING game development for the rest of us.

I see a number of the pple on this thread are thrilled about c++ and some even think it should be included across all platforms. Has any of you stopped to think about the implications for UT and it Business Model??

-Re engineering unity Iphone by a staff of only 60? (not all 60 of program)
-A possible increase in the price of the Iphone license to factor in new development costs.

…just to mention a few. Yes sure C++ comes with all the goodies, I just don’t think UT should be investing there yet. Like Dave said it is a back up plan (which I hope they never have to implement). I just Hope Sean’s theory flies

That may well be true Sean, but when David went for talks with Apple (check further down the company blog) over whether Unity was affected, did Apple just respond with ‘well its obvious’, the lack of a publicised result from that meeting suggests it was more like ‘yes’.

It’s quite possible that the reason Apple haven’t given a formal reply yet is because they consider the answer to be «obvious» in some way.

As far as I can see from the new ToS, Unity doesn’t actually break the rules. It uses XCode as a key part of its build process for iPhone apps and generates an XCode project file.

Also, Unity *was* «originally written in Objective-C, C, C++…» as specified in the agreement, and it is also true that «only code written in C, C++, and Objective-C» is being compiled and directly linked against the Documented APIs. Which is what the agreement requires.

What’s running on the iPhone is *always* Unity. It’s the database bundled with the app that changes, not Unity itself. Code is data.

But it’s that use of XCode in the Unity for iPhone tool-chain which is the clincher:

Adobe’s Flash is primarily a web browser plugin. How are users supposed to install such things on an iPhone? There’s no mechanism for installing plugins. Apple would have to build one, and add an irritating «Uninstall Plugins» app too, since plugins wouldn’t appear on any of the user’s home pages.

What if Apple bundled it into Safari? That would open the floodgates to all sorts of other web plugins. Flash doesn’t support WMV, for example. Would Apple also have to bundle Flip4Mac’s plugin too? Where do they draw the line? Whoever Apple slammed the door on would turn around and sue. Better to just ignore all third-party plugins and avoid all that expense. It’s not as if Flash makes Apple any money anyway; it’s just a nice-to-have, not an essential feature. (And, of course, the fact that there wasn’t a proper, full-fat version of Flash available for the iPhone-like devices until *very* recently also helps in that decision.)

Adobe’s cancelled Flash for iPhone app builder did NOT touch XCode or the iPhone SDK directly. It must, therefore, use a statically-linked set of libraries which would require updating whenever iOS itself was updated. This would be a support nightmare for Apple, as well as the developers using this technology. And an expensive one at that. Given that the various Stores are not major revenue streams for Apple, it’s not fair to expect them to shoulder this burden while *also* making the iDevice user experience notably worse for end users. Apple only loses if they support this development path. There is no benefit for them at all.

In summary: That Apple haven’t stopped accepting Unity apps seems to support my hypothesis that Unity isn’t actually affected by section 3.3.1 of the new agreement. (I’m not a lawyer, etc.)

Unity,
Should continue to implement this Plan B. Cause we can maybe be fine now, but what make you think that Apple will never add more ToS restrictions?
To be honest, even if Unity app are now being accepted on the App Store, theses apps are not ToS compliant. Unity should continue to implement C++ support, no matter what, there’s a lot of reasons why:
— Avoid any conflict with new ToS in the future. Or simply avoid any future rejection from Apple.
— More speed, less memory eat.
I think that plan B is not an option, it is a requirement and a very safe move made by Unity to stay on track! :P

While we are still waiting for an official yes/no regarding Apple’s ToS for Unity, this is the next most important piece of information we needed in order to plan for our product and to decide whether we would continue our investment in using Unity.

I’m still not entirely taken with this, I thought there was a meeting between yourself (David) and ‘Apple’ quite literally months ago, and yet this article still implies that you do not know if you may or may not conflict with Apples iOS4 TOS. Surely it’s a yes or no? I still don’t think we’ll be committing any time on IPhone projects in the near future with Unity now to be honest.

I know how to program C++ ( I read several books about it, including «Effective and more effective C++» ), just because of that I know several people using Unity will have several problems to create code to that language, you know, there are lots of developer that aren’t PROgrammers…

I hope it doesn’t mean a stop on Android support development, after Android support release I hope Apple will be afraid with all new boom of Android quality games, and, as consequence, loss of mobile market share, wich will made Apple review their ToS or continue with their philosophy of high quality and small market share….

@Robert Brackenridge: I have to agree, as well. I love the fact that UT have an excellent «Plan B» ready, but I still see it as a «Plan B». I can only imagine the amount of work it would be to fully implement this; work taken away from other, more important features. Plus, having to support four languages instead of three, and having to write all-new documentation for a new language.

We, already, have issues with trying to find a tutorial or example for something in the «right» language (i.e. «I found it in Js, but I need it in C#»). Adding yet another would just add a whole new layer of separation.

I look at everything being added in 3.0, and I am amazed. I, then, imagine taking any of that away just to add C++, and I just don’t think the trade-off would be worth it.

I’m with some of the other comments. I would hate to see a development requirement get in the way of future feature additions… I know how taxing this could be to a small company from a support perspective. There are many areas within the existing platform which are in need of attention and detail. But, I am quite happy that your team has taken the time to lay out a contingency.

This is poo.
Apple should be sued for monopoly and fascist behavior towards their developers.
All developer should be free to chose tools they want.
Will they in the future demand certain image manipulation software over another?
Will you update your tutorials and scripting reference manual from jscript to c++, for the new developers ?
And how can apple know what scripting language you use if you compile it ahead of time and run trough xcode ?

Actually C++ can be memory innefficient and slower than java and c# in some cases, because it has no garbage collector and are not optimized in some ways, you have to optimize it or your program will be slow and memory consuming, an example of bad C++ code, it doesn’t destroy unused objects instances:

1. Can this C++ implementation also support Objective-C++?
2. Can we also code/tweak in Xcode directly as an option or does it have to go through Unity’s editor to parse «C++ scripts» and generate raw C++ source for Xcode to compile?
3. Having said that coroutines are not supported at the moment, and as per question 2, is it possible to use Grand central dispatch now that iOS 4 supports it?

Just to clarify, would the C++ code be compiled for all platforms or are you planning to create some sort of interpreted C++ for windows, osx etc?

One method which would take less effort would be to provide a mechanism for native C++ components to be added which expose parameters and interact with other components. This would be less flexible but very powerful.

Formulating a «Plan B» is a great idea. I’m surprised Apple has left you hanging in the wind for so long now. I’m not a true programmer (more a hacker) who is a 3D / FX artist and game developer. I don’t know the nuances between programming languages. Thanks for providing code examples. I pray Apple will clarify it’s ToS immediately so we can all get to making games without worrying.

«On the iPhone version then XCode will compile the “scripts” to native code.
But what about the references set in the editor?»

In short: It will just work.

As you know C++ doesn’t support reflection natively, which makes automatic serialization of properties not a core feature of a GCC based compiler. The great thing about having a .NET based C++ compiler in the editor is that we can actually parse the C++ code while the user writes it. This means we can automatically generate additional boiler plate C++ code when making a build for the iPhone, essentially automatically generating all serialization code for the user.

In practice this means the workflow of exposing properties in scripts will work perfectly and effortless in C++ too. Awesome.

Is it UNMANAGED/NATIVE C++ or just a .NET implementation?
I’d love to have unmanaged C++ for performance reasons and to remove bloated .NET libraries from an iPhone/Android builds — probably will save up to 8Mb.

As someone who has been pondering using Unity instead of rolling out own engine in C++, but really does not like the restrictions and performance disadvantages of C#/etc, it would be great news to have C++ as an option. Please consider doing this, necessary or not!

I also am for the addition of C++ to the engine. My reasons for wanting this are:
— C# programming «dulls your senses», it is not really a games industry standard, so even if you work for 10 years on Unity and do great projects, you can’t really apply to work that requires C++ knowledge;
— Some times doing «simple stuff» in C# is a pain, ppl may not like working with pointers but they sure are very helpful;
— Mono is NOT really optimized… Although it is getting better, it is still REALLY slow! It doesn’t do a great job optimizing (ie inlining) that .NET does, and when you have intensive engine components believe me it will show its problems.

It would be great to work with C++, hopefully it would have a nice integration with a debugger! XD And it would be great if it had at least the same level of integration that you guys are adding to MonoDevelop to XCode (especially since the new version does seem much better).

I love it that you have a Plan B just in case and share it with us, it shows once again how much you guys care, thanks a lot for that.
I strongly disagree with those saying they´d love to have this option of using managed C++ no matter if its needed or not though.
Yeah, an additional language choice always sounds good in theory, even more so if it comes with in theory better performance as end result.
But i imagine how much work it would be to pull all of this off and i´d MUCH prefer UT working on improving existing functionality and adding new functionality other than support for another language instead.
I love unity but there are of course always things that could be improved and added (i have a long list of feature requests myself of which i post chunks on the various channels for that quite regularly), so yeah, i´d be really sad if instead of on a good chunk of those ressources instead get spent on managed C++ implementation.

So yeah, bottomline for me: Awesome UT thinks of a Plan B, but i hope it never has to be used.

@David
thank you so much for your honesty again! unity guys are always honest and it’s great! you are the only engine that don’t have a fake stupid comparison on your website that says unity is perfect! torque, shiva, gamestudio A7 and many others have them and show their own good features.
as a student i used C++ in university and love this powerful language. i use C# in unity and web development. having a C++ API is nice but UT can use the time to develop more great features.(if they don’t have to do this).
having C++ is nice because integration of some C++ class libraries like (physx softbodies) will be alot easier!
i love to have this feature just like many others but i think there are more important features for professional development. take a look at networking part of unity please! not that bug free!

If you decide to implement this even if Apple does not require it, would it be possible to mix C++ with C#/JS? That would solve some problems with the Mono memory management that have been reported before.

If the C++ path becomes unavoidable, if you could prepare plenty of Unity C++ code examples, documentation and tutorials available, that would really help those (me) who aren’t as comfortable with the language. :-)

@Big Pig: I mist admit that I got good help from Joachim Ante and others on this (but hey I used to be a coder, and there’s nothing foreign in these code example above). I can’t comment on the tricky bits like coroutines yet. Not because it’s secret, we just don’t know yet.

Thanks so much for this update. It’s rare to see a CEO dwelve into code examples :-)

Just one question, that has been already asked but not answered yet: will we have Coroutines in C++? I know of some Coroutine implementations in C++ and ObjectiveC, but it’d be nice to have Unity’s support on this.

@bronxbomber92 and others: there’s a lot of detail questions like these left to answer. We have been working on the technical bits, and iff this ever becomes a part of the product (which is not certain at this point), we’ll have to figure them all out :)

If Plan B did become necessary, how would that affect the C/C++/Objective-C Plugins Support available in Unity Pro and Unity iPhone Advance? Would that just «automatically» become a feature of both iPhone Basic and iPhone Advance and remain a Unity Pro feature? Or would you guys still try to restrict linking to static or dynamic libraries (or frameworks if you prefer) for the iPhone Advance?

Anyways, great to see you guys are fervently working on a backup plan! *Hopefully* the hard work is all for not (it’s rare one ever means to say, heh)!

While C++ might not be the best choice for scripting Logic, if all platforms supported it as an option I think it would strengthen Unity’s stance as a great engine to learn game development on. Computer Science students looking to get into the games industry like to get as much practice in C++ as possible (including myself), but working on projects around busy class schedules might not accommodate rolling their own engine in C++. So I know from that perspective, C++ support would be great.

@jackpoz: Lua doesn’t solve the problem with ToS 3.3.1. If anything it’s worse (not to mention a bunch of other reasons why it’s not optimal).

@MattCarr and others: C++ «scripting» is a somewhat compelling feature, but it’s a lot of work (and maintenance) so it’s not certain that we’d do it unless we have to. But we’ll see.

@ImaginaryHuman: translating C# / JavaScript to C++ is not trivial, and by the way doesn’t actually solve the ToS 3.3.1 problem, since it’s prescribed that an application has to be written «originally» in certain languages. But we’re considering that too.

@Daniel and drawcoder: you can already call into C/C++ libraries everywhere but in the browser. Yesterday I saw camera input and augmented reality on Unity Android, and that was based on an external library. It’s quite a straightforwards process.

Love this and the C++ option. Script could very well be auto generated into C++. This is great though because I would like to be able to use other C/C++ libs in my Unity projects especially on mobile. Keeping scripting as C# is also great and probably a bit better than Lua setups.

Why don’t you continue to let developers write code in UnityScript or C# and then convert the sourcecode itself to C++ automatically before compilation? This way we won’t even have to learn C++ at all, and to be honest, even though the examples seem *fairly* simple, there is still a learning curve and different/more complex syntax to get your head around. Why expose this to the developer at all when you could just translate existing code into C++?

Agreed, if it turns out that on iOS writing your game code in C++ is significantly faster than C#, I would switch. If this R&D reaches fruition, even if not necessary to ship games on the App Store, I’d be really interested to see some benchmarks on how it compares to C#/Javascript.

Will this C++ implementation be developed to completion if it’s discovered it’s not needed before it’s finished. Having C++ as an option would be a nice feature (even if the majority of the Unity user base never uses it) in any case.