Hi,
I heard from a colleague at work that Unity cannot currently deploy to the new apple appstore. Is there a workaround for this at present, such as exporting to xcode, or a place where to edit the details for MAC export… not iphone 
Apparently a lot of people are having a problem with the new apple appstore for mac + unity?
There is no such way until Unity is updated to offer it.
Would it work to have an Xcode project that creates an app that just launches the Unity app?
–Eric
no, similar to iOS, you deploy a single signed application and upload it through the same build archive. You can not have such a setup from what I understood (where you have 2+ applications)
will be interesting when / if support for it will happen cause so far Unity does not build in such a way. Might be that Plan B for UT becomes more and more a “not plan b but lucky preplanning that now seriously helps us” cause with the mac app store, plan b can and should be applied to iOS and OSX (and on both real, not through the mentioned mono inbetween compilation)
We’re working this out, but no news yet. Stay tuned.
@dreamora: If by plan B you mean the backup plan we had in store for “oh crap, apple might shut us out of the iPhone app store” pre Apples announcement that they were only kiddin’ then how does this in any way relate to the issue described in this thread? I do not see how that idea helps solve the problem at hand.
Notice that planning for something like that doesn’t just wish it into existence real quick when we need it. Serious development time would have to be dedicated for such a task. Development time which would be diverted from expanding existing- and working on new features.
Or maybe I just completely misunderstood what you were getting at?
Plan B = Using Unity in a more SDK alike form from C++ cutting Mono
And I see very well how this solves it as this on osx would mean xcode project and compilation thus also xcode signing and packaging no problem
I really hope thats going to happen though as this “plan b” is the only reasonable explanation on why all iphone specific and focused features were postphoned and cut from 3.0 (multitouch UI, GK implementation, 2d system)
especially as U3 iOS got taken out of beta with major bugs still present like the texture2d.loadimage bug I reported with beta 3-5 somewhere, which makes the texture eat 7-12 times the memory it would have on the next pow2 size even with mipmaps included and stuff like this
I’m not sure I understand you very clear Dreamora.
How about Unity just builds a working xcode project and we compile it ourselves with tweaks where we need them to get it working for mac app store?
Or can we modify (hack around) the finished .app file to get it working properly?
unity already provides you with a full app, not the stuff to build one anymore actually.
no compile → no signing no packaging → no mac app store
I don’t know why you’d need “plan B” C++ when it’s not necessary for iPhone apps.
–Eric
@dreamora:
Short answer:
What Eric said.
Slightly longer answer:
As Neil points out, it is quite possible to have data built by Unity result in an Xcode project which you then build with the correct signing without needing to go through implementing a C++ API. It’s a matter of setting up a shell Xcode project which calls in on the right entry points of our binary. Quite a simpler operation than exposing the entire API to C++.
Regarding the seemingly unreasonable “postponing” of iPhone features:
If you find that prioritization of merging the iPhone branch into the regular editor import and build pipeline, upgrading PhysX, mono and general performance plus merging over quite a few bits of awesomeness from regular Unity to Unity iPhone to be wrong. And that we in stead should have given you a native UI system which you already can access via the Xcode setup (we brought the capability of doing this on both licenses in with 3.0) or written a new 2D system which is already well covered by third party plugins, then please send us an email with your development strategy advice.
Notice that I’m not saying we’re not doing those things which you request. We would love to. They were just not given priority during 3.0 development.
I fully agree on that.
Nobody said (I hope mine didn’t sound like it) that Plan B is a requirement to make this work.
But now that apple is going to bring an iOS alike environment to the desktop it becomes an even more viable option also as the amount of users who want to integrate Unity as rendering into windows application isn’t going to drop either.
The editor merge is very welcome and you know that
But thats not a new thing, thats a thing that was in development since Unity iOS 1.5 or so as that was the first time its development was hintend out, so its nothing that at least to me explains the postphoning.
PhysX, Mono: They are not iphone specific. They might have required iphone specific tuning, but neither of the two is something that was explicitely for the iPhone
And Unity GUI lacking multitouch even on U3 after Unity iPhone 1.0 through 1.7 is extremely hard to justify, I don’t think that even you can come up with a reasoning on why this has happened while no replacement for “cpu kill GUI” was priorized to replace it instead of leaving Unity in the state where the number 1 advice for optimization is “don’t touch ongui”
I’m not saying that you guys did a bad job, not even remotely
There were great enhancements
But the iPhone side is just rushed and incomplete, its not 3.0 to me.
Major memory bugs, bugs in the cleanup of unused assets, stripping thats more broken than working (I’ve not a single project to which I can apply it anymore at all), stripping still not capable working with 3rd party assemblies, stripping still not reporting WHERE it has a problem but just going nuts, reflection still not working on .NET 2 (ie no longer working at all), lack of multitouch capable gui, the still as broken if not even more broken bounding box “do I see the object or not” handling further worsened by Umbra, … I could continue this list for quite a while as I had to backport every single iphone project I did under contract since April this year to 1.7 as U3 killed them in one or more ways, with one of the major problems it being more cpu hungry and much worse on the memory handling basically killing pre 3GS completely.
The hint with the native UI is nice, unhappily totally useless as nobody is reasonably going to use UIKit to do ingame hud, input representations etc.
Sure we can use 3rd party plugins (I think I own all of them in this releation), but that does not compensate for the fact that 2 years were still not enough time to implement batching into Unitys own gui system and add multitouch support and that although you added another multitouch mobile platform? I don’t think you want to imply that it is “hard” or “unimportant” that one of the by far weakest aspects did not get touched although officials confirmed its weakness and problems in 2.1 already soon “an eternity” ago.
These are all points that to me weight heavy enough that I can not reasonably use 3.0 for production of anything that was taxing to 1.7, just cause U3 messes it up that badly that it requires a 3rd to 4th generation to run where it previously did on a 3G and for that I’m paying another 15mb+ build size due to the lacking ARMV7 only target.
I hope this explains a bit what I meant and whats behind my thoughts
I would also like to add that coming up with technology names as a reasoning for anything does not really help building trust. Many here in the past came across Torque and we all had our fair share of hot air hype trash. Its important to get the base working first and priorize the hype stuff after the core stuff is working, not the other way round. I’ve the hope that 3.1 will finally adress what 1.7, all the betas and 3.0 didn’t adress …
But I think we are getting off topic here, completely
I’m looking forward what you guys have up the sleeve for 3.x, for mac app store, the iphone and hopefully general Unity as SDK / library usage (anyone with a centralized server would love to hear about that)
Judging by what you seem to be wanting from it, 3.x should not be a disappointment for you.
Possibly with the exception of that C++ API. I still do not see how to justify it’s priority over other fixes and additions we have in the pipeline.
it’s not unity’s fault if they’re a few days behind the latest apple lets break things tantrum
Sounds like the code signing for Mac apps can be done via the “codesign” command-line tool. So that Unity doesn’t need to do anything special… just build the .app then sign it with the Apple tool. Right?
could you supply more details about the codesign tool since at work we have an apple mac game ready to go and to be able to fix this now would be amazing…
I haven’t paid the $99 Mac Dev fee yet so I don’t have access to the official Mac Store docs regarding how to sign for the Mac App Store, but I heard it uses the codesign tool. I’m hoping you (or someone reading this) will verify that.
I just found an AppleScript that signs an app with your signing identity / certificate using the codesign command-line tool. I haven’t tried it but I believe we should be able to build the .app with Unity, then use this Applescript to codesign it for the App Store. If I understand it, this AppleScript does the same thing that Xcode does during the post build phase.
http://www.gorbster.net/blog/archives/273
Let me know if it works!
If that is the case, then I would prefer Unity not spend too much time working this. As long as something usable is available, I’ll be content.
Indeed, when I get back to work I will try it! I haven’t subscribed to that yet, since at home I only have iphone. You have to pay another $99 for mac :]
He did say:
So we will see.
i don’t know if this workaround works but I hope we will have a Unity solution soon