Bug 30052 - Submitting in store issues
Summary: Submitting in store issues
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Mac Add-in ()
Version: 5.9
Hardware: Macintosh Mac OS
: High normal
Target Milestone: 5.10 (C6)
Assignee: Chris Hamons
Depends on:
Reported: 2015-05-13 16:47 UTC by Radu
Modified: 2015-10-19 11:02 UTC (History)
10 users (show)

Is this bug a regression?: ---
Last known good build:

provisioning profile (7.28 KB, application/octet-stream)
2015-05-13 17:45 UTC, Radu

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Radu 2015-05-13 16:47:43 UTC
1) the autogenerated key in entitlements.plist is generated erroneously:


com.Housatonic appears twice - it should appear only once. This results in error when submitting to store.

ERROR ITMS-90286: "Invalid Code Signing Entitlements. Your application bundle's signature contains code signing entitlements that are not supported on Mac OS X. Specifically, value '3P26RN5ZVG.com.Housatonic.com.Housatonic.Project-Viewer' for key 'com.apple.application-identifier' in 'com.Housatonic.Project-Viewer.pkg/Payload/ProjectViewer365.app/Contents/MacOS/ProjectViewer365' is not supported. This value should be a string starting with your TEAMID, followed by a dot '.', followed by the bundle identifier ."

workaround: edit the Entitlements.plist, add the ke with the correct value and it doesn't get overwritten

After fixing this, next signing issue:

2) CFBundleExecutable key missing from info.plist. The build did upload but was instantly marked as invalid binary and an email was sent:
"Bad Bundle Executable - You must include a valid CFBundleExecutable key in your bundle's information property list file." This should normally be auto generated on build

workaround: add the CFBundleExecutable key manually in info.plist

3)using the Archive for Publishing option to sign the app and send to store results in many different weird signing errors reported by the store:

ERROR ITMS-90267: "The name of your application bundle must end with '.app' and not contain characters ':'."
ERROR ITMS-90270: "Unsupported toolchain. Packages submitted to the App Store must be created either through Xcode, or using the productbuild[1] tool, as described in "Submitting your Mac apps to the App Store." Packages created by other tools, including PackageMaker, are not acceptable. [SIS]"
ERROR ITMS-90236: "Missing required icons. The application bundle does not contain an icon in ICNS format, containing both a 512x512 and a 512x512@2x image. For further assistance, see the Apple Human Interface Guidelines."
ERROR ITMS-90296: "App sandbox not enabled. The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list: [( "com.Housatonic.Project-Viewer.pkg/Payload/mdTmpDir1927807944/Contents/MacOS/ProjectViewer365" )] Refer to App Sandbox page at https://developer.apple.com/devcenter/mac/app-sandbox/ for more information on sandboxing your app."

Submitting the package generated in /bin worked after working around 1) and 2). This is Xamarin.Mac Unified. We have submited a build using Xamarin.Mac classic last week and we encountered no such problems.
Comment 1 Jeffrey Stedfast 2015-05-13 17:13:18 UTC
1. can you attach your provisioning profile? The value gets expanded from that and the exact same code works fine for iOS (the code is shared).

2. legitimate bug, seems like this key is not being set by the CompileAppManifeest MSBuild task, I think because it was expected that the mmp tool would do that.

3a. well, the app name definitely ends with .app, so that means your app name probably has an illegal character? What is your app bundle name in the bin directory?

3b. pretty sure we use productbuild, so no clue.

3c. Did you specify a *.icns file in your Info.plist? Did you set the BuildAction of your *.icns file to "BundleResource"? Is it in your app bundle? Where?

3d. Did you enable the App Sandbox entitlement in your Entitlements.plist?
Comment 2 Chris Hamons 2015-05-13 17:18:55 UTC
@Radu - For us to make progress on this item, we might need a small example application (not you entire app) attached. 

Please note, that bugzilla is for reporting actual defects in our products and not requesting assistance. support.xamarin.com (requires a business license) or the forums are the primary channels for that. 

Here's two guides on how to write bug reports that have sufficient information to be answered:

Comment 3 Radu 2015-05-13 17:45:10 UTC
Created attachment 11193 [details]
provisioning profile
Comment 4 Radu 2015-05-13 18:14:36 UTC
Chris - I don't require assistance and I have not requested any. This is a bug report. Like I said, I already found workarounds for the issues presented and I managed to submit in store. I have just presented and detailed the difficulties which I have encountered which are actual defects in your products...

Jeffrey - about point 3, everything is fine with app. If I submit to store the generated .pkg in the bin folder, it gets accepted (after applying the workarounds for 1 and 2). But if I send the .pkg built using Archive for Production I get all those weird errors. I attached the provisioning profile

I guess one could just make an empty app and try to submit build and see how that goes...
Comment 5 Chris Hamons 2015-05-13 18:46:11 UTC
@Jeff - This sounds like a bug in the new publishing workflow?
Comment 6 Jeffrey Stedfast 2015-05-13 19:17:21 UTC
Probably, yea... but why reassigning to me? I didn't write the publishing workflow code.

Reopening since the provisioning profile has been added.
Comment 7 Jeffrey Stedfast 2015-05-13 19:22:15 UTC


For iOS, the rule is that you replace * with the CFBundleIdentifier string from the Info.plist

Apparently for Mac it's different, hence the double com.Housatonic.
Comment 8 Jeffrey Stedfast 2015-05-13 19:23:57 UTC
Wait, no, this is odd. For all of my Mac provisioning profiles, they are in the format:

Comment 9 Jeffrey Stedfast 2015-05-13 19:54:47 UTC
Chris: parts 1 & 2 should be fixed in maccore master now.
Comment 10 Chris Hamons 2015-05-14 09:32:00 UTC
So it appears there is non-trivial problems with the publishing workflow. Assigning to David. Thanks Jeff!
Comment 11 Jeffrey Stedfast 2015-05-14 13:45:17 UTC
I've got a macios-cycle5-bug-30052 branch for the macios fixes and a monodevelop-5.9-bug-30052 branch for the XS fixes I've got so far
Comment 12 Jeffrey Stedfast 2015-05-15 15:25:59 UTC
I don't have AppStore publishing keys for Mac, so someone else will have to test this: http://storage.bos.internalx.com/monodevelop-lion-monodevelop-5.9-bug-30052/47/474bfdd07da4d0bf9a24e682d42455f4980005be/XamarinStudio-

No idea if it works, but it should be better.
Comment 13 Radu 2015-05-28 17:27:43 UTC
wow... you closed a bug without knowing if it is fixed.
Comment 14 Jeffrey Stedfast 2015-06-10 11:41:21 UTC
I'm just that good :-)

In the FIXED state, it just means QA will bang on it.
Comment 15 PJ 2015-06-23 14:18:28 UTC
This fix did not make it into C5SR2, and will now be slated for C5SR3.
Comment 17 Radu 2015-08-04 04:49:57 UTC
so this means that allowing your clients to publish mac apps in app store is not high priority? or what?
Comment 24 Jeffrey Stedfast 2015-09-02 11:31:47 UTC
Reassigning to the Mac team (I'm on the iOS team so I have no idea why this keeps getting assigned to me).
Comment 25 Chris Hamons 2015-09-02 13:38:12 UTC
We think we have this fixed now with:


Thanks @jeff

QA will do another pass to see if we got it nailed down.
Comment 26 PJ 2015-09-02 13:41:11 UTC
The final remaining issue discussed in comment 20 - 23 will be addressed in the Cycle 6 release.
Comment 27 Lluis Sanchez 2015-09-02 14:36:06 UTC
If it's for C6, it needs to be cherrypicked into the cycle6 branch.
Comment 28 Chris Hamons 2015-09-02 14:40:53 UTC
@lluis already done by @jeff
Comment 29 Jeffrey Stedfast 2015-09-02 16:02:18 UTC
No, that commit won't fix this problem. That commit only adds the .dSYM directory to the archive once mmp puts the .dSYM directory in the correct location.

The reason this still fails is because mmp is outputting the .dSYM directory inside of the .app bundle.

When the user uploads his .app bundle to itunes-connect, it reports the following errors:

1. App Sandbox is not enabled
2. The app could not be re-signed for submission
3. Invalid bundle: [project.pkg/Payload/project.app/Contents/MacOS/project.dSYM], with bundle identifier com.apple.xcode.dsym.com.companyname.project

All 3 of these errors are due to the fact that the .dSYM directory is dumped into the .app bundle.

Here's why:

1. itunes-connect assumes that the .dSYM directory within the .app bundle is yet another app bundle. Since the main app bundle is being codesigned with the "App Sandbox" entitlement, it expects ALL child app bundles to be code-signed with the sandboxing entitlement because it would make no sense for inner apps to not have that restriction when the parent app does.

2. it can't be re-signed because it doesn't have an executable in the .dSYM directory (because it's not a real app bundle)

3. notice that it is complaining about the dSYM directory with a bundle identifier of com.apple.* which it says is illegal.
Comment 30 Chris Hamons 2015-09-03 14:12:18 UTC
This does not appear to be fixed at all. Going to track down all of the use cases, fix them, and get some good manual test coverage if nothing else. We've bounced this around way too much......
Comment 31 Chris Hamons 2015-09-03 18:15:54 UTC
Alright, sorry for the confusion. There were 3 bugs here. 

1) The archive logic in XS was just broken. @Jeff fixed that up with two additional fixes.
2) The built in validate / publishing workflow is just broken fwict - https://bugzilla.xamarin.com/show_bug.cgi?id=33627
3) If you build as debug and try to submit, it will fail due to https://bugzilla.xamarin.com/show_bug.cgi?id=33628

I'm going to call this bug the first one, which should now be fixed in master and C6. The other two are outstanding, and won't make C6. 

I'm going to work with QA to get better testing on this feature.
Comment 32 Rajneesh Kumar 2015-10-07 11:37:53 UTC
I have checked this issue with cycle 6 builds

and observed that I am able to submit "MacCoolApp" app to the App Store successfully. Please refer the screencast given below.

Screencast: http://www.screencast.com/t/FryJRxrPPm

This issue has been fixed and working fine with the Cycle 6 builds, so as of now I am closing this issue. If anyone face this issue again so feel free to Re-open it.


Environment Info:

=== Xamarin Studio ===

Version 5.10 (build 812)
Installation UUID: 3d25a767-a003-4a7d-9f5e-e57987cf6cf0
	Mono 4.2.1 (explicit/cc1cf60)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 402010062

=== Xamarin.Profiler ===

Not Installed

=== Xamarin.Android ===

Version: (Enterprise Edition)
Android SDK: /Users/mac360_xamarin/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		2.3    (API level 10)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.4    (API level 19)
		4.4.87 (API level 20)
		5.0    (API level 21)
		5.1    (API level 22)

SDK Tools Version: 24.3.4
SDK Platform Tools Version: 23
SDK Build Tools Version: 23

Java SDK: /usr
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)

=== Xamarin Android Player ===

Version: 0.6.1
Location: /Applications/Xamarin Android Player.app

=== Apple Developer Tools ===

Xcode 7.0 (8227)
Build 7A220

=== Xamarin.Mac ===

Version: (Enterprise Edition)

=== Xamarin.iOS ===

Version: (Enterprise Edition)
Hash: b5396c2
Branch: master
Build date: 2015-09-30 15:22:15-0400

=== Build Information ===

Release ID: 510000812
Git revision: feb7640e9c013af8bb30a6a72e5c3d2ebcefdcbd
Build date: 2015-10-02 19:15:27-04
Xamarin addins: f99ff0a7da6a31661870ef3567390a7e84e9a3c4
Build lane: monodevelop-lion-cycle6

=== Operating System ===

Mac OS X 10.10.5
Darwin mac360-xamarins-Mac-mini.local 14.5.0 Darwin Kernel Version 14.5.0
    Wed Jul 29 02:26:53 PDT 2015
    root:xnu-2782.40.9~1/RELEASE_X86_64 x86_64
Comment 33 Radu 2015-10-19 11:00:15 UTC
is this live yet?
I can't seem to be able to publish the pkg generated using the "Archive For Publishing" option. But it does work by choosing the generated pkg file in bin/AppStore.

In other words, 5 months later there's nothing new here. Point 3) behaves exactly the same
Comment 34 Chris Hamons 2015-10-19 11:02:03 UTC
"I'm going to call this bug the first one, which should now be fixed in master
and C6. 

The other two are outstanding, and won't make C6."

The first one should be fixed in C6, which is currently in Alpha. If it isn't, please let me know.