Repository navigation
MacOS builds getting rejected by Apple #126705
Description
Activity
@borjandev Are you trying to re-sign already signed FlutterMacOS.framework?
@borjandev Are you trying to re-sign already signed FlutterMacOS.framework?
I am following the official Xcode MacOS app submission flows, same issue from the GUI and even from fastlane flows, the only variable is the commit change, once 3d25049 landed, every newer commit submission has resulted in the same rejection
Can you specify a commit hash that you want me to test specifically?
Let's try with
9c72f5a7e62e63c199739267f3feeee0559caf11@godofredoc same issue with 9c72f5a
• Flutter version 3.11.0-5.0.pre.57 on channel master at /Users/devdemo/fvm/versions/9c72f5a7e62e63c199739267f3feeee0559caf11
Umm my understanding is that we only sign binaries tied to a release, umm should we also sign artifacts associated with a random hash?
@borjandev are these files in your app tree:
entitlements.txtandwithout_entitlements.txt?If they are can you please delete them and try to sign again?
- Checking
find . | grep entitlements.txt./macos/Runner/DebugProfile.entitlements ./macos/Runner/Release.entitlements ./macos/example.app/Contents/Frameworks/FlutterMacOS.framework/entitlements.txt ./macos/example.app/Contents/Frameworks/FlutterMacOS.framework/without_entitlements.txt ./ios/Runner/Runner.entitlements ./build/macos/Build/Products/Release/FlutterMacOS.framework/entitlements.txt ./build/macos/Build/Products/Release/FlutterMacOS.framework/without_entitlements.txt ./build/macos/Build/Products/Release/example.app/Contents/Frameworks/FlutterMacOS.framework/entitlements.txt ./build/macos/Build/Products/Release/example.app/Contents/Frameworks/FlutterMacOS.framework/without_entitlements.txt-
Deleting
find . | grep entitlements.txt | xargs -I{} rm {} -
Checking again
find . | grep entitlements.txt(none found)
Used the Xcode GUI and default flows to upload, same issue, same email from Apple
thanks for explaining!
As a side note, the engine revision of 3d25049 points to 689eb6e as the hash of the engine binary. I visited google cloud buckets of the engine binary and it looks like the FlutterMacOS binary in FlutterMacOS.framework wasn't signed. Not sure if this is the expected behavior. entitlements.txt and without_entitlements.txt are present in the zip. the libswiftCoreImage.dylib files listed here are not on the list of files we would code sign.
umm if we are expecting 3d25049 to be signed, does this mean we published a release with unsigned binaries?
3d25049 was included in a release candidate branch which caused the binaries to be signed. My first thought was something related to signing but if 9c72f5a is failing in the same way then the error may be related to the file structure.
When I look at the first release branch AFTER 3d25049, it looks like it had a different engine hash: 55c988f
Thus I don't think flutter-team-archive/engine@689eb6e was ever included in a RC branch, and I don't think it was ever codesigned.
I'm not sure the issue, but I don't think it's related to the desktop release codesigning process.
@XilaiZhang @christopherfujino @godofredoc
The flutter master commit that started causing this MacOS rejection 3d25049 has the following PR linked to it #125598
This #125598 PR contains 2 commits :
reland "Migrate mac_host_engine to engine v2 builds." (flutter-team-archive/engine#41531) - acc49d3
Roll buildroot to 5708f2051772fd02c949e5dc9397e54f8c7a4478 (flutter-team-archive/engine#41540) - deef282
So one of these 2 commits above caused the issue (unless I am missing something?)
If it's not connected to the engine v2 builds, maybe it's related to the buildroot change? With the PR flutter-team-archive/engine#41540
deps = { - 'src': 'https://github.com/flutter/buildroot.git' + '@' + '37fa2f05f6b009a1a92879c03b0871d97100aa2d', + 'src': 'https://github.com/flutter/buildroot.git' + '@' + '5708f2051772fd02c949e5dc9397e54f8c7a4478',Which is linked to flutter-team-archive/buildroot#722 which has a ton of files removed as noted here https://github.com/flutter/buildroot/pull/722/files
Glancing through the removals, the obvious ones removed in reference to 'mac' are shown on the screenshot below, so I am not sure if they are relevant?

Here is the diff in a github view: https://github.com/flutter/engine/compare/19045bb99c..689eb6ee
I suspect the root cause is some subtle directory structure change (as speculated in #126705 (comment)). Note, a google search on the error message "unsealed contents present in root directory" results in https://developer.apple.com/forums/thread/93914, where a new QT release no longer had an accepted Mac framework directory structure.
44 remaining items
@vashworth it looks like I ALSO need my previous change, where I deleted it at the time we copied from the cache to the build dir
- added a commit that references this issue
on May 23, 2023 - added a commit that references this issue
on May 23, 2023 - added a commit that references this issue
on May 23, 2023 - addedr: fixedIssue is closed as already fixed in a newer versionIssue is closed as already fixed in a newer version
on May 24, 2023 - added a commit that references this issue
on May 31, 2023 This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.- locked as resolved and limited conversation to collaborators
on Jun 7, 2023 - addedP0Critical issues such as a build break or regressionCritical issues such as a build break or regressionand removed
on Jun 28, 2023

Is there an existing issue for this?
Steps to reproduce
masterbranch at commit 3d25049 or laterflutter create --org com.yourdomain example(change to a real bundle identifier)flutter build macos --releaseXcode Version 14.3 (14E222b)and click"Product --> Archive""Validate App"once the archive completes and perform the signing process which is a part of the same flow"Distribute App"and keep the"App Store Connect"selected, and perform the re-sign process for App Store Connect distribution which is part of the same flowExpected results
App appears in TestFlight without issues.
Last known good commit on master is 4fb146e where the app appears in TestFlight without issues.
Actual results
App doesn't appear in TestFlight on
masterbranch at commit 3d25049 or laterInstead, I get an email from Apple :
Code sample
Code sample
Screenshots or Video
Screenshots / Video demonstration
[Upload media here]
Logs
Logs
[Paste your logs here]Flutter Doctor output
Doctor output