I use to bundle Macports libraries from /opt/local/lib into my application (with corrected load paths via install_name_tool).
With Xcode 10, this app gets rejected during upload to the Apple App Store, because the dylibs from Macports no longer contain the Mach-O LC_VERSION_MIN_MACOSX command. Older versions of Macports-delivered binaries contained it, as can be seen from
otool -l /opt/local/libHalf.dylib | grep LC_VERSION
How can I bring LC_VERSION_MIN_MACOSX back into Macports-delivered shared libraries?
Related
Getting Module compiled with Swift 5.0.1 can not be imported by swift 5.1 error while i have added PaymentSDK Swift5. Then i tried PaymentSDK 5.1 framework not getting this error while uploading app to AppStore. Working perfectly on development mode.
Applied this solution
https://github.com/Paytm-Payments/Paytm_iOS_App_Kit/issues/37#issuecomment-533982199
https://github.com/Paytm-Payments/Paytm_iOS_App_Kit/issues/40#issuecomment-538249618
The error clearly mentioned about you are uploading with simulator framework, during upload your framework should not contain simulator frameworks x86_64, i386. When you do uploading add shell script that removes that architecture from release builds. Use this script in the build phase script.remove simulator architectures
Copy PaymentsSDK.framework in your Mac’s Downloads folder.
// Open Terminal and move to the Downloads folder of your mac.
cd /Users/<Your Mac's User Name Here>/Downloads
//Run these commands to strip the x86_64 and i386 builds from your binary.
lipo -remove x86_64 PaymentSDK.framework/PaymentSDK -o
PaymentSDK.framework/PaymentSDK
lipo -remove i386 PaymentSDK.framework/PaymentSDK -o
PaymentSDK.framework/PaymentSDK
//That’s it. Now you have stripped out all the unnecessary builds from your //binary.
Now-Again. Copy Payments.sdk from your Downloads folder and replace it from the previous binary.
// Now, it will be validated successfully without any issues.
You can integrate the latest SDK for iOS. The Github link for the SDK is https://github.com/paytm/Paytm_iOS_All_in_One_SDK. Its integration information is available on developer docs of Paytm.
Without actually loading my .xcodeproj into Xcode, is it possible, from the Xcode app, to start an app install to my iPad using the .app file only, which was generated in an earlier build?
This is my last line of inquiry... I'm just looking at potential options because I don't have a paid developer account (yet) and might try to use Teamviewer to log into the remote client Mac to install via Xcode, but do not wish to reveal my project file/code on the remote machine. Installing from within Xcode purely using the .app file would solve my problem, if possible.
I managed to work out a way to do it using this, this, and this. You will need the XCode command line tools, which come as part of the App Store XCode install, or you can get the command line tools only from here.
First up, download and install npm. Then install ios-deploy from the terminal,
sudo npm install -g ios-deploy --unsafe-perm --allow-root
If you need to build from the command line, make sure you have a working XCode project which builds as you want, open a terminal and go to the directory with your .xcodeproj inside, then type:
xcodebuild -list -project <NAME>.xcodeproj/
xcodebuild -scheme <SCHEME NAME> build
Then, or if you've already built in XCode and just want to deploy your .app file to the iOS device, type:
ios-deploy debug --bundle <APP PATH>
You can change debug to release, or either way it will use whatever you set your XCode build configuration to be I think. The <APP PATH> location depends on your XCode install, but the most recent location (I think) is
~/Library/Developer/Xcode/DerivedData/{app name}/Build/Products/Deployment/
This will install your .app onto the iOS device from the command line, and you don't need to load XCode up, or expose your source files. Just requires the .app file. For me, this is a potentially useful way to install an app remotely on a client's device without the need for a paid developer account.
I followed the below process in order to install apps in IOS simulators
1.I have Test.app file with me go to Library->application support->iPhone simulator->6.1->Application->i created new folder and i placed my test.app file in that folder as of i knew after when we open the simulator we can able to see that particular app in the simulator it doesn't happened in my case
2.i followed the cd in terminal window xcrun simctl install booted (my test.app path ) it showing error that
Failed to install the requested application
An application bundle was not found at the provided path.
Provide a valid path to the desired application bundle.
and i tried with different methods which i had read in internet but nothing is working
so guide me how to install the app in IOS simulators and how to work with them.
I am trying to sign a kernel extension file "abc.kext".
I have a kext enabled certificate and tried to sign my "abc.kext" using:
codesign --sign "Developer ID Application: MyCompany (XXXXXXXX)" -a "x86_64" abc.kext
To verify that the signing is successful I run:
codesign --verify -vvvv abc.kext
and the output is:
abc.kext: code object is not signed at all
Also run:
spct -a -v --type install abc.kext
and the output is:
abc.kext:rejected
source: no usable signature
If I run:
kextutil -tn abc.kext
output is:
abc.kext appears to be loadable (including linkage for on-disk libraries).
Can somebody help me to find what I am doing wrong?
You don't explicitly say so, but from the outputs you're getting, it looks like you're trying to codesign a multi-architecture kext? If so, don't do that!
The command codesign --verify -vvvv abc.kext works for kexts I've built and signed, no explicit architecture required. kextutil -n is a very good indicator on any incompatibilities, including code signing, but it only applies to the running version of OS X, so you need to check it with all versions you plan to support.
If for some reason you need to create a signed version of a kext based on not source code but an existing universal binary, you will need to extract the 64-bit portion of the binary, create a kext bundle from that and sign that. Your installer can then place this signed 64-bit kext in /Library/Extensions, and if the installer detects it is installing on a volume containing OS X 10.8 or older, additionally place the existing universal kext in /System/Library/Extensions. (Additionally so that if/when an upgrade happens, the kext won't suddenly stop working or generate signing warnings.)
To extract the 64-bit binary, use:
lipo -thin x86_64 abc.kext/Contents/MacOS/abc -output ./abc-64.kext/Contents/MacOS/abc
where abc.kext is the original universal kext and abc-64.kext is the new kext that you'll be signing. You should give the signed kext the same bundle identifier, but a higher bundle version number than the universal one, even though they're functionally identical. The higher-versioned one will be chosen if it's loadable by the OS.
An overview of kext requirements in different OS X versions:
Signed kexts will only load on OS X 10.8 and newer, and those versions all ship with 64-bit only kernels. If you want to support older versions of OS X, you'll need a separate kext for those versions. OS X 10.6 and 10.7 kernels can be either 32 or 64-bit, so if you want to support those versions, use an unsigned universal kext. A kext where the 64-bit portion is signed might load in a 32-bit kernel, but definitely will not load on a 64-bit 10.6/10.7 kernel. 10.5 and earlier only have 32-bit kernels, although of course they exist as both PowerPC and i386 variants (the latter from 10.4 on only). I don't know if it's possible to create a 3-architecture kext, but I suspect it is. Just don't sign it.
Signing is only required on 10.9 and newer, so you have a little bit of flexibility on what versions each kext covers. (10.8 will also happily load the 64-bit portion of an unsigned universal kext)
By the way, when building kexts, use the OS X SDK corresponding to the oldest supported OS X version of that build. The deployment target mechanism doesn't work for kexts. (for the most part)
I get the above error message when trying to built a iOS7 project, I just cloned off BitBucket (sorry, it's private, thus can't link to it).
First off, I have tried all the solutions mentioned in linking against dylib built for MacOSX file '/usr/lib/libSystem.B.dylib' for architecture i386, Build Error - missing required architecture i386 in file, Building for MacOSX, but linking against dylib built for iOS Simulator file, and several more.
My system:
Mac OS X Mavericks; 10.9.3
XCode 5.1.1
Summary of what I've already tried:
reinstall XCode
reinstall Command Line Tools
remove entires in framework search path
remove several entries in Other Linker Flags
The error says its linking against dylib in /opt/local/lib/libsqlite3.dylib, which might indicate that it has something to do with my MacPorts installs, since only MacPort should install programs in /opt/local/, as far as I know.
Any ideas what I could've missed?
Xcode is more likely defaulting to OSX PATH environment variables to find that missing sqlite library.
Make sure to link it from your project in Xcode, pointing to iOS frameworks.