Problems deploying to Apple's MAC appstore?

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..

 

http://developer.apple.com/library/...s.html#//apple_ref/doc/uid/TP40005929-CH4-SW2

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

 

I'm afraid it doesn't work.

 

Hello

It is possible to Archive the application using the "productbuild" command which signs the application and creates the installer.

However, if we don't want our games to get copied we need to validate the App Store Receipts at startup "immediately after the application is launched, before displaying any user interface or spawning any child processes".

As far as we understand, this is not possible with Unity 3.0.

So here we need Unity folks to assign this extra-feature the highest priority. This is a must have, and we need it as soon as possible in order to take advantage of early Store entrance.

 

Fresh in, you can do it! however it wants the latest xcode. Source: http://www.blitzmax.com/Community/posts.php?topic=92471

Quote:

 

Is there a launch date for the Mac software store yet?

 

scheduled to launch between November 2010 and mid January 2011 apparently.

 

There are six things required to create a valid package for submission, and two of them cannot be done via plugin or scripts...

Developer
- Edit the info.plist to add the application categories
- Sign the application
- Create and sign the installer package
- Validate the App Store Receipts at runtime

Unity Only
- Validate the App Store Receipts at startup before showing any user interface
- Change the Preferences file name and path to a valid one

Does anyone know if Unity is taking care of this?

 

There is no Mac AppStore Support at the time so the answer is no

 

I'm pretty sure someone did say that they were working on it or at least looking into it.

--Eric

 

We have a couple of games we think would run well on the Mac. If anyone wants to collaborate on getting this to work, please let us know.

 

News?

It seems we will see Mac App Store before than expected.

 

No news yet no

 

Mac App Store officially will open January 6:

http://www.apple.com/pr/library/2010/12/16macappstore.html

I hope Unity will support as soon as possible Mac App Store distribution.

 

1. Build in Unity for Mac Intel Only

2. Show Package Contents of the .app

2.a. Edit Info.plist
<key>CFBundleShortVersionString</key>
<string>1.0.0</string>
<key>LSApplicationCategoryType</key>
<string>public.app-category.puzzle-games</string>
<key>NSHumanReadableCopyright</key>
<string>(c) 2010 Iterations Software LLC. All rights reserved.</string>
<key>CFBundleIdentifier</key>
<string>com.oneiteration.zenofclover</string>
<key>CFBundleVersion</key>
<string>1.0.0</string>

2.b. Replace Resources/UnityPlayer.icns with one that is 512x512

2.c. Change permissions on /Data for "everyone" from "no access" to be "Read only"

3. In Terminal...

3.a. codesign -f -s "3rd Party Mac Developer Application: randy edmonds" ZenOfClover.app

3.b. productbuild --component ZenOfClover.app /Applications --sign "3rd Party Mac Developer Installer: randy edmonds" zenofclover.pkg

3.c. Delete the .app file after productbuild has created the .pkg (or the installer test will not work)

3.d. sudo installer -store -pkg ZenOfClover.pkg -target /

4. Verify that your app is installed in Applications

5. Ready to submit the .pkg to iTunes Connect!

 

I tried to follow your instructions but encoutered an problem i cant solve.

Everything went fine until i want to install the package. The installer runs to the end and says "installation successful" but when i look into my Applications folder there is no game installed. Even when i search my whole mac for a file i cant find one.
If i run the package manually with a double click i get the Error :

There was an error reading the package
JavaScriptError

Any clue what i am doing wrong?

 

Thanks for posting Randy - I'll give it a shot!

 

Unity should build their own app store.

 

Has your App been accepted, Randy? My game doesn't use PlayerPrefs so I should be ok on that score, but I'm wondering whether Apple are rejecting for not doing the DRM check. It would encourage me a bit if other Unity apps are being approved.

 

Im still Waiting For Review.

 

Receipt validation is optional.

 

My app was rejected! (bummer)
It seems that both of the problems are issues that are going to have to be fixed by Unity.
Please give me your opinion.

This is the message I received from Apple....


We've reviewed Zen Of Clover *and are unable to post this version to the App Store because it is using a private API. *The use of non-public APIs is not permissible, as documented in section 2.5 of the App Store Review Guidelines <https://developer.apple.com/appstore/mac/resources/approval/guidelines.html>. We have included additional details below to help explain the issue, and hope you’ll consider revising and resubmitting your application.

Using private APIs can lead to a poor user experience should these APIs change in the future. The non-public API, thread_stack_pcs, that is included in your application comes from the following private Apple frameworks - libSystem.B.dylib.

For discrete code-level questions, you may opt to consult with Apple Developer Technical Support at <http://developer.apple.com/support/resources/technicalsupport/>. To ensure that Developer Technical Support can best help you, please be sure to include any logs, screenshots, or steps to reproduce the issues you’ve encountered.


Furthermore, we cannot post this version to the App Store because your application is creating files in the incorrect directories. This is not in compliance with the App Store Review Guidelines <https://developer.apple.com/appstore/mac/resources/approval/guidelines.html>

* *2.30 Apps that do not comply with the Mac OS X File System documentation will be rejected

The application is creating files or writing to ~/.wapi. **Please review the section "File-System Usage Requirements for the App Store" on this page

 

Thats right! asap please that would be a good reason for me to by Unity 3.0 now!

 

Please see this post for the solution:
http://forum.unity3d.com/threads/64453-Mac-App-Store?p=461654&viewfull=1#post461654

 

Anyone who's Unity app, I can modify and then upload the store?
My god~~

 

"If i run the package manually with a double click i get the Error :
There was an error reading the package
JavaScriptError"

I am facing the same problem, Can you tell me how to fix this.

 

Has anybody found a solution to this javascript error yet?

Could it have anything to do with compiling the app on the latest version of Xcode?

 

Hi,

Issue resolved, the problem is wrong bundle identifier in info.plist
replacing the bundle identifier "unity.Twisted Games.Ice_Cube_Caveman"
with correct bundle identifier fixed the problem.

Thanks,
Vineel