I tried to upload my new app to App Store using Xcode 10, It's showing this error
Just use:
pod 'Alamofire'
pod 'Firebase/Core'
pod 'Firebase/Messaging'
pod 'HTHorizontalSelectionList', '~> 0.7.4'
pod 'Google-Mobile-Ads-SDK'
What is "Aspera transport"?
I don't know if it's too late or not, but I came across this issue this past weekend, it looks like Xcode 10 and application Loader version 3.7 are not working when trying to publish your app on itunes connect.
The solution: I found out that if you use application loader v3.6 the app will be successfully uploaded to itunes connect, that version of application loader belongs to the previous version of Xcode which is version 8. Application loader must be present in the application folder of that version of Xcode.
Related
I have seen serval questions regarding this same issue, i have gone through them all and tried them all.
I have tried :
pod deintegrate + pod install
setting Deployment Target 12.0
adding libGoogleSignIn.a to Link Binary With Libraries and to Frameworks, Libraries, and Embedded Content
Clean derivedData
Clean build folder, clean derivedData, exit Xcode , remove Pod and then install pod and then start Xcode and then build.
Checked pod folder and verified that GoogleSignIn folder exists
I have tried all of the stuff mentioned in the other answers and non of this fix my issue. I have several other pods installed and they are all working fine and has no issues.
I found a way to make it work.
Currently pod 'GoogleSignIn' installs google sign in 6.0.0 and unfortunately i was not able to do import GoogleSignIn with this version of the pod.
So i went back and changed pod 'GoogleSignIn' to pod 'GoogleSignIn' , '~> 5.0' and then i was successfully able to import GoogleSignIn
Answering back just incase someone else gets the same issue, try going back to previous versions !
If anybody has any other way to resolve this by using current version, please answer :)
I'm using Xcode 10.2 and swift 5. When I update my pods, facebook SDK pod giving me errors. please see attached image
is anyone facing this issue? How can I install pods with facebook-IOS-SDK?
This library is deprecated, seems like you need to replace the old pod with the 'FBSDKCoreKit', 'FBSDKLoginKit', and 'FBSDKShareKit' pods
Source
The old library's source
When I upload the build in App Store I get this message: ERROR ITMS-90081: "This bundle is invalid. Applications built for more than one architecture require an iOS Deployment Target of 3.0 or later."
In my project I am using Xcode 10 with swift 4.2. In my pods file I have put watchos plateform to 4.0 and I am using Alamofire version as pod 'Alamofire', '~> 4.0'.
Does Alamofire support watch os 4.0 ?
Please help..
Just answering a work around here so that build upload doesn't stop at App Store.
For this problem until Alamofire provide an update for watchOS 4 you can Manually update the target for pods that you are using your project.
For reference this is what I got when someone posted for a similar problem:
Can't upload App using Alamofire on watchOS when using Xcode 10
In case you have this error with Firebase.
I was using Swift PM and got the same error, and also other errors like:
ITMS-90635: "Invalid Mach-O Format..."
ITMS-90360: "Missing Info.plist value..."
ITMS-90124: "The binary is invalid..."
and other.
It was totally unobvious. I added many Firebase sublibraries (products) like FirebaseCrashlytics, which were actually not very necessary in my project. Removed them, keeping only the FirebaseAnalytics, and everything worked well.
So if you have this error and whatever package I would recommend removing/adding products.
I'm having a problem running my Realm-based Swift app on actual hardware. I keep getting "dyld: Library not loaded: #rpath/Realm.framework/Realm" when the app starts then leads to a SIGABRT dyld`__abort_with_payload. The app runs fine on the simulator. I've followed the steps on the Realm Swift website, dragged frameworks into embedded frameworks, added build phase script, added framework path to unit test target. I'm kind of at a loss here. I'm using xcode 9, iPhone 7 iOS 11.
Here's what fixed my problem:
Log out of xcode Preferences->Account
Open keychain app on mac and delete all iOS dev certificates.
Restart mac.
Open xcode and and log back in with Apple ID Preferences->Account
Go to app Target->General and make sure "Automatically manage signing" is checked and correct team is selected.
Run the app, and a message will pop up saying that cert not found in keychain (something like that). Just continue and when it warns you that cert needs to be revoked first, select to Revoke.
At this point, the problem is gone and the app is running.
For the issue I mentioned in the comments of op, the fix for that was to click on app target->Build Phases and drag the Run Script to the bottom of the list. It has to run after Embedded Frameworks! This was a side effect from me debugging original problem and removing/adding the realm framework. After doing that, the run script was now second last in the list with embedded frameworks following it.
I have resolved this issue through simple technique.
Steps for remove this realm error:
First step:
comment the line of pod //pod 'RealmSwift'
run the command in terminal "pod install"
Second step:
uncomment the line of pod //pod 'RealmSwift'
run the command in terminal
I had the same issue in Xcode 11.4 and I fixed it by editing my pod file
platform :ios, '13.0'
target 'MoneyLeft' do
#use_frameworks! -> !!! very important
pod 'Realm', :modular_headers => true
pod 'RealmSwift', :modular_headers => true
end
IF I set the deployment target for my app to iOS 4.2 when submitting to app store, will users with iOS 3.2 (or anything below 4.2) be able to download and install the app and the app won't run or will they not be able to download and install the app itself?
Thanks.
They won't be able to install and run the app (until they upgrade the OS on their device to that of the Deployment Target or above). But they might be able to buy and download the app using iTunes on their Mac or PC.
No, that's exactly what deployment version is about.
Best practice is to build against latest SDK version, with deployment version as low as possible. But that requires the discipline to do runtime checks and fallback implementations whenever using a API that wasn't there yet in the deployment version.