My development environment is:
OSX Mavericks, Xcode 5 Cocoa mac application
I have been using FANN to train and run a ANN. It has worked so far and I have been able to train and run an ANN. I have even made a simple command line application to train ANNs using FANN. However I have run into a problem that may have to do with the way FANN is distributed.
I wanted to export and share the application I had made, so I archived the Xcode project. When I did this I made sure to copy libfann.2.2.0.dylib under Build phases, so the end user would have the library which is needed to use the FANN code in my app. However when I tried to save a developer ID sign application using Xcode it failed to code sign it. I can still save it without code signing it. The interesting thing is that if I remove libfann.2.2.0.dylib from the copying phase under Build phases, Xcode can successfully code sign the application and save it. However if I do this the resulting application is corrupt because it cannot find the FANN library.
I made libfann.2.2.0.dylib according to the instructions on http://leenissen.dk/fann/wp/help/installing-fann/.
I understand that this may not be a problem with FANN, but with Xcode. However I have other static libraries in the same project and FANN is the only one that is creating these issues, so I believe there is a high chance it has something to do with the FANN library. I am not an expert in code signing, but my guess is that there is a conflict between the way the FANN library is made using Cmake and code signing.
Thanks in advance.
I was able to find a solution after playing around with code signing.
I decided to try manually code signing my app with instructions from http://www.digicert.com/code-signing/mac-os-codesign-tool.htm. This did not work. However the code signing tool pointed me to a problem with libfann.2.2.0.dylib. So I checked if libfann.2.2.0.dylib was code signed and it was not. When I saw this I thought I would try code signing libfann.2.2.0.dylib with my developer ID and re-importing it into my project. This strategy worked and I was able to export a developer ID signed version of my application.
Related
I have been dealing with the same issue for a few days now. I'm unable to upload any app store connect files due to the libAgoraRTMWrapper file. To be clear, this entire app has been built through Unity using agora SDK. The reason for failure, according to XCode, is that the wrapper "doesn't have the correct file type for this location". Invalid Swift support.
This leads me to wonder if the libagoraRTMWrapper is even necessary. Yes, I would like to keep using RTM but not at the expense of several build failures.
As a sidenote, XCode does mention that the build is being made for iOS but the wrapper was built for iOS + iOS simulator. I don't remember ever specifying that but it could just be the way the SDK was initially imported.
this library is necessary for RTM to work. Do you have a custom build setting for the project? It is verified that the included SDK Demo works on iOS builds. Perhaps you can build that and compare the build setting to yours to find out what went wrong?
I have developed (on a Mac) a small Flutter app to learn the technology. Now, I would like to build it and use it on Mac, Linux and Android. The few packages I have used claim compatibility with all systems.
So the first thing I did was to run flutter build macos. I indeed obtain an application under build/macos/Build/Products/Release/nameofmyapp.app. It seems this runs correctly, but it fails, for instance, loading data from a DB, which is the first thing it should do.
I have a few questions:
are there any other steps that I should take? I see a long guide about the release process, but to be frank I don't need or want any of that: I only want to use the app myself. Is there something else to do other than flutter build macos?
am I looking for the built app in the right place?
if I did everything correctly, could it be that I need to authorize the app to access to the file in some way? Should I manage this workflow myself, or is there a standard way to perform this action in Flutter?
Sorry for asking more than one question, but I am not sure whether what I am doing wrong is
the build process
where to look for the built app, or
(not) handling the app permissions.
EDIT
Following a suggestion by Madhavam, I tried flutter run --release. The result is identical to running the built application: nothing is loaded from the database, and no errors appear in the console.
To be clear, these are the libraries that are not working:
sqflite should load data from a database (in my Documents folder) but does not show anything
file picker cross should allow me to load data from a JSON file, but when I try this interaction, I an not shown any dialog to load a file
shared preferences should read some settings, but they all appear as null
In short, anything that has to do with interacting with external files or storage does not seem to work
Yup, you have to manage it yourself. Take a look at this package
:https://pub.dev/packages/permission_handler
If you're using Firebase then you probably need to add the release keys.
One thing too, if you face an error only in the release build then I recommend running the app with flutter run --release so that you can see the errors that are being thrown.
So it seems that this is related to the default being an app that runs in sandbox. Since I do not want to distribute the app, it was fine for me to disable this setting. Details are in this answer
Maybe this tutorial is out of date( it was written in 2009),but I cannot find a better one. While following it step by step, I was stuck at Loading a Plugin section. Apple mail failed to load the plugin.
here is a screenshot of Console's information.
Has anybody else tried to follow this tutorial on OS X 10.9 recently?
////////////////////update/////////////////////////
It seems "~/Library/Mail/Bundles/MyPlugin.mailbundle/Contents/Frameworks/Python.framework/Versions/2.7/python" needs code signing.
Yes, this is a sandbox problem: Python Mail plug-ins (and I think all plug-ins) cannot read files outside of their container (the Plugin.mailbundle directory).
If you followed the instructions on the tutorial page you mention, you are probably building an alias build of the plug-in (using python setup.py py2app -A), which means that the plug-in will try and access files from the original source location, which is almost always outside of the sandbox (in your case, it's /Users/greedyint/Desktop).
Try running without -A to make a full build.
I have an OS X app that's distributed through the Mac App Store, and recently updated to Xcode 4.6.3.
When I run my regular build now, I receive:
Command /usr/bin/codesign failed with exit code 1:
/Users/Craig/Library/Developer/Xcode/DerivedData/Mac-dxcgahgplwpbjedqnembegifbowj/Build/Products/Debug/MyApp.app: code object is not signed at all
In subcomponent: /Users/Craig/Library/Developer/Xcode/DerivedData/Mac-dxcgahgplwpbjedqnembegifbowj/Build/Products/Debug/MyApp.app/Contents/Frameworks/DropboxOSX.framework
Command /usr/bin/codesign failed with exit code 1
I can't seem to discern any other changes in my project, so I can't tell if it's an issue related to the 4.6.3 update, or something else.
I have tried restarting Xcode, running a clean build, and cleaning the build folder.
I think I may have figured this one out. I've been running Xcode 4.6.3 on OS X Mavericks, under the impression that any build-specific tools were bundled in the Xcode application.
But, it seems codesign is in /usr/bin. Whether it's put there by one of the Xcode installers or comes with a vanilla system install, I'm not sure. But reading through the man page for codesign, I found this nifty option:
--deep When signing a bundle, specifies that nested code content such as helpers, frameworks, and plug-ins, should be recursively signed
in turn. Beware that all signing options you specify will apply, in turn, to such nested content.
When verifying a bundle, specifies that any nested code content will be recursively verified as to its full content. By default,
verification of nested content is limited to a shallow investigation that may not detect changes to the nested code.
When displaying a signature, specifies that a list of directly nested code should be written to the display output. This lists only
code directly nested within the subject; anything nested indirectly will require recursive application of the codesign command.
And then I found this post (https://alpha.app.net/isaiah/post/6774960) from two weeks ago (~June 2013), which mentions (albeit second-handedly):
#isaiah I asked a guy in the labs about it. He said codesign now
requires embedded frameworks to be signed separately before code
signing the app bundle as a whole.
Manually re-running the codesign command that Xcode normally runs, while adding the --deep flag to the end, signs the application properly.
I'm not yet sure exactly what ramifications this manual signing has, or whether I can tweak the Xcode build to add the --deep flag automatically, but this seems to be the underlying issue. (codesign no longer automatically deeply signs your app bundle.)
As highlighted in other answers, there is a change to the way code signing works. If you've installed any of the Xcode 5 DP's then the new tools will be being used even if you are using Xcode 4.6.X.
All you need to do at this stage (in Xcode 4.6.X) is take the --deep flag suggested above and add it into your code signing flags (Target, Build Settings) see image below.
For me, this problem was caused after dragging a folder named "resources" in my project. After changing its name into anything else(like "resourcessss" for example), the error disappeared.
I had the same problem, but the answer was simple: the code signing identity on my app was set to "-", so simply setting that to "Don't Code Sign" fixed me up.
"-" seems to be the default setting when you carry out some set of actions, although I can't tell you what those are.
This might help somone:
I finally figured out the solution by trial and error. In my case I had a folder name that matched the “Product Name” variable under build settings. This also matched the entire project name! So I simply changed one field. I changed the “Build Settings” -> “Product Name” . The value of MySpecialApp was changed to My-SpecialApp. That was simply it! I then logged back into the Apple developer portal and created a new App ID and mobile provisioning profiles for development and distribution and the rest is history. My releases now work when deployed via the Ad Hoc distribution.
A final note on this. This is definitely a bug that Apple should either alert the user that they have done something wrong and enable some sort of automated corrective action.
- See more at: http://www.chrisdanielson.com/2012/08/29/codesign-ipa-and-the-code-object-is-not-signed-at-all-problem/#sthash.F0nF3BbC.dpuf
For me it was a corrupted Framework PaddleMAs which:
1. I removed from my Cocoapods File
2. Ran pod install
3. Restarted my Xcode
and it solved the problem. For some reason a corrupted framework will prevent it being signed unfortunately XCode doesn't show this error really clearly and give you a good fix suggestion. Have raised a bug with Apple to fix.
I just created all new dev and deployment certs and I'm getting this weird error when I try to validate the application in the archive manager:
error: Codesign check fails : /var/folders/w_/dvqfkh916k12c5hn639qvvqw0000gn/T/oqhxIfU87c/Payload/TestUpload.app: valid on disk
/var/folders/w_/dvqfkh916k12c5hn639qvvqw0000gn/T/oqhxIfU87c/Payload/TestUpload.app: satisfies its Designated Requirement
test-requirement: code failed to satisfy specified code requirement(s)
I've looked all over to see how to fix this error but nothing seems to help for Xcode 4. I've followed the setup on the provisioning profile, however it doesn't seem to be updated for the newest Xcode 4 software (I've gotten this to work with previous versions of Xcode before archive manager was set in place)
Any help would be appreciated
I was testing using an old certificate cerated while ago and it did worked fine, but creating a new certificate using a new apple dev account wont work.
It seems like new certificates are created with issues from apple provisioning portal.
So, I guess there is not a problem on your app, and we just have to wait until they fix the bug.
If you're building dependent projects or libraries as part of the archive process, make sure that those targets are also being built with the App Store distribution certificate.
scoured this GUI looking for a "comment" but finding nothing - apologies if this gets posted as an answer.
I have spent the last 5 hours with that exact same error. Googling everything. Recreating certificates. Everything works when archiving, but then at the end I get the yellow triangle indicating the error. Using both wildcard and app specific distribution profiles that are recognized in Organizer as valid - I always get the error. You're not alone on this one and it is driving me insane - today was supposed to be the day we submit our app we've spent the last year on...
Will be watching this thread closely, can offer any further information from my end also if it will help any. If you find a solution Paradox, please post here as I am at my wits end and would be extremely grateful.
Are you sure you signed this with your Distribution profile and not your Developer profile? I think XCode 4.2 will give an error if you're trying to share an archive code signed with the wrong type of profile.
Some (old) information in this thread:
http://forums.macrumors.com/showthread.php?t=659607
I am having the same problem. Spent hours redoing certs, changing machines, changing versions of Xcode, making random changes that people have suggested, rebooting, changing icons you name it.
In Console there is a big dump of data related to the validation, if you're lucky it says something meaningful in there, it doesn't for me. Or at least nothing that I can understand :/
EDIT: The console outputs the command it runs but slightly butchered. It has a parameter R= but the output neglects the quotation marks around the argument. Running this command only outputs the just as helpful:
/var/folders/_x/XXXXXXXX/T/XXXXXXXX/Payload/XXXXXXXX.app: valid on disk
/var/folders/_x/XXXXXXXX/T/XXXXXXXX/Payload/XXXXXXXX.app: satisfies its Designated Requirement
test-requirement: code failed to satisfy specified code requirement(s)
Valid But Mismatched Certificates
This error can occur when submitting an application to the Mac App Store. The error occurs because one or more code signatures are valid but not signed by Mac App Store appropriate certificates:
Invalid Signature - The nested app bundle FRAMEWORK at path APPNAME.app/Contents/Frameworks/FRAMEWORK.framework has following signing error(s): valid on disk /Volumes/data01/app_data/dstr/mz_4939925606610311185dir/mz_6704668226144376567dir/eu.miln.beyond.mas.pkg/Payload/APPNAME.app/Contents/Frameworks/FRAMEWORK.framework/Versions/A: satisfies its Designated Requirement test-requirement: code failed to satisfy specified code requirement(s) . Refer to the Code Signing and Application Sandboxing Guide at http://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/AboutCS/AboutCS.html and Technical Note 2206 at https://developer.apple.com/library/mac/technotes/tn2206/_index.html for more information.
The solution is to re-codesign the application bundle making sure to use a Mac App Store application certificate.
Codesign
Use the codesign -d -vvvv <app.path> to check the signing certificate is correct.
If you have a complex signed application with mixed certificates or non-Mac App Store certificates, you can use the codesign flag deep to recursively resign the entire bundle:
codesign --force -o library -s '3rd Party Mac Developer Application: Your Organisation (000AAA000A)' --keychain '/absolute/path/to/mac-app-store.keychain' --preserve-metadata=identifier,entitlements,flags --deep '/absolute/path/to/APPLICATION.app'
Note the --preserve-metadata=identifier,entitlements,flags options. These are important to avoid overwriting or changing the associated entitlements and bundle identifiers.
Ideally, the deep flag should not be used but it can be useful to fix problems.