I created an app using expo cli. I also created the build for the same using expo server and was trying to upload the app to the app store.
However, the previous version of the same app was written in Swift and I get this error.
As a result Apple is rejecting my app.
I have maintained the same bundle Id of the app.
Error :
Dear Developer,
We identified one or more issues with a recent submission for App Store review for your app, "My App Name". Please correct the following issues, then upload again.
ITMS-90433: Invalid Swift Support - The file libswiftAVFoundation.dylib doesn’t have the correct code signature. Make sure you’re using the correct signature, rebuild your app using the current public (GM) version of Xcode, and resubmit it. Don’t just modify the code signature of libswiftAVFoundation.dylib.
Best regards,
The App Store Team
I don't think that this solution works because when the application is built on Expo, using the command EAS, is the expo server who creates the IPA, and in one step copy the file libswiftCore.dylib (in my case) and is signing it using "codesign", then making changes in the local Xcode I don't expect solve this problem. ¿Maybe making some change that allows the project tell expo which signature must use in the swift support file?
thanks
solved by changing ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES to YES in my project configuration.
In XCode select your project -> Build Settings and look for "Always embed swift standard libraries". If NO is selected, switch to YES (for debug and release), and it's done.
It is recommended to clean your build in Xcode before building and submitting again, just to make sure you have no residues of your old build left!
Solution 2:
The other solution I came across is the version mix match. Make sure you are using correct version of expo. Otherwise just update it to the latest one.
Related
I tried updating a stand alone WatchOS app to the App Store and got this message from iTunes after uploading it:
ITMS-90492: Invalid WatchKit Support - The file WK doesn’t have the correct code signature. Make sure you’re using the correct signature, rebuild your app using the current public (GM) version of Xcode, and resubmit it. Don’t just modify the code signature of WK.
I have uploaded previous version without a problem, so I think it might have something to do with using WKInterfaceDevice().play(.click) in my code which is new to the version uploaded, but I am not entirely sure, has anyone ran into a similar problem and how did you fix it?
This appears if you have XCode beta installed on your Mac. It doesn't have to run just its simple presence results in this artefact.
I have been trying to submit my app multiple times to the app store and I keep seeing this error:
Invalid Swift Support - The files libswiftPassKit.dylib,
libswiftCoreAudio.dylib, libswiftContacts.dylib,
libswiftCoreLocation.dylib, libswiftCoreMedia.dylib,
libswiftCoreData.dylib, libswiftAVFoundation.dylib don’t match
/Payload/MyApp.app/Frameworks/libswiftPassKit.dylib,
/Payload/MyApp.app/Frameworks/libswiftCoreAudio.dylib,
/Payload/MyApp.app/Frameworks/libswiftContacts.dylib,
/Payload/MyApp.app/Frameworks/libswiftCoreLocation.dylib,
/Payload/MyApp.app/Frameworks/libswiftCoreMedia.dylib,
/Payload/MyApp.app/Frameworks/libswiftCoreData.dylib,
/Payload/MyApp.app/Frameworks/libswiftAVFoundation.dylib. Make sure
the files are correct, rebuild your app, and resubmit it. Don’t apply
post-processing to
/Payload/MyApp.app/Frameworks/libswiftPassKit.dylib,
/Payload/MyApp.app/Frameworks/libswiftCoreAudio.dylib,
/Payload/MyApp.app/Frameworks/libswiftContacts.dylib,
/Payload/MyApp.app/Frameworks/libswiftCoreLocation.dylib,
/Payload/MyApp.app/Frameworks/libswiftCoreMedia.dylib,
/Payload/MyApp.app/Frameworks/libswiftCoreData.dylib,
/Payload/MyApp.app/Frameworks/libswiftAVFoundation.dylib.
Is there something else i'm doing wrong? Or is it still not available? I'm not able to find any resources to help with the above
Seems like it's an issue with Cocoapods. As per below:
https://github.com/CocoaPods/CocoaPods/issues/4188
The current latest version of Cocoapods is 0.39 beta 4 which does NOT work.
You can check your
Build Settings -> Embedded Content Contains Swift Code.
If it's NO,you can set it to YES,and then have a try.If it's not working.You can update your Mac system to Mac OS X 10.10.5 and your Xcode to Xcode 7,just rebuild your project with iOS 9,and then Xcode will tell you which you must deal with.
For one of our clients, we have developed an OTA app store for distribution.
To enable testing if the apps are installed, in each of the apps I wrote, I added two custom URL schemes: one that's just the app id, and one with the app id and the version (both with . replaced by -); so for example com-mycompany-app and com-mycompany-app-1-2-0 for com.mycompany.app, version 1.2.0.
Then, in our "app store" I just use [[UIApplication sharedApplication] canOpenUrl:] to determine if an App is installed or the latest version, and if so, replace the "Install" button with an "Open" button.
When installing the app through XCode, it works great. However, when I install the same app OTA, through my "app store", the canOpenUrl: call always returns NO. To see if it was a caching thing, I have tried restarting the "app store" app after OTA install has finished, but I get the same results.
Is this an issue with my manifest plist file? In the Info.plist that belongs to the target, the custom URL Scheme stuff is obviously there, but it's not in the manifest's. However, I would imagine it only uses the manifest to launch initial install...shouldn't the Info.plist be used during actual install to register these sorts of things? Is there something else I'm missing?
Thanks!
Edit: I'm using a custom build script to actually create the .ipa and .plist files that are being used for OTA distribution. I tried using iPhone Configuration Utility to install the IPA directly, and my app store was able to recognize those URLs as being openable. The only possible things I can think of are either that the plist I'm using to download & install needs to have some sort of reference to these custom URL schemes, or it's actually a legitimate bug in Apple's OTA framework.
I got this working, in case anyone is watching this or stumbles upon a similar issue.
The only thing I changed -- and there's no documentation saying the old way wouldn't or shouldn't work -- was to use periods in my URL scheme, instead of hyphens. So com-company-app:// became com.company.app:// (same as the bundle ID), and likewise with the version-appended one.
I don't know if my old URL schemes were violating official URL spec, or if you're supposed to use reverse-DNS, but everything is working, now.
today my app update it has been released in the store, when updated or downloaded for the first time the app immediately crash on start.
I've tested the app on simulator and on device (the same where I've installed the update from the store) and I never experienced this problem.
My update it has been submitted with Organizer after the archiving, in the Distribute section.
Apple do not perform these types of controls before to release an app?
Anyone experienced a similar problem? I have no idea what could be the cause..
Thank you, Stefano.
Here's the best way to test a production build without deploying to the store:
Set your build Scheme to "iOS Device"
Do an Archive build
Select your archive and click Distribute
Choose "Save for Enterprise or Ad-Hoc Deployment"
Pick your code signing cert
After saving the ipa file, use Apple's iPhone Configuration Utility(*) to install it on your device
You should always perform two tests:
installing on a blank device after uninstalling your app *and any profiles in Settings -> General -> Profiles"
installing over the top of the previous version of your app, to make sure any files/preferences/etc are properly converted to the new format
(*) the iPhone Configuration Utility is mostly used for enterprise app deployment, but it's also useful for developers and is available as a free download for mac and windows at support.apple.com. You can also use iTunes instead, but it's convoluted.
As for why your app is crashing? No idea... it could be anything. Standard debugging advice applies.
The issue is related to the Framework. I had this exact error. It wasn't a case of logic as it was crashing before the AppDelegate was even called and my usage of NSMetadataQuery was much later in the life cycle than that.
It turns out that weak linking the Foundation framework was required.
Problem was solved by changing (under the Project Info in Xcode) the dependency option of the Foundation.framework from required to optional. Check for any such frameworks.
Try deleting any old versions of the app you have on your device, and reinstall. Also try on a different device, maybe with a different apple id to your developer account.
This happened to our app also, and apparently, other apps too.
Apple is aware of the problem and is currently working on a solution.
see this article:
http://techcrunch.com/2012/07/05/apple-responds-to-app-crashing-issues-has-a-dedicated-team-working-on-a-fix/
If you are using core data & you have updated database in your latest version without versioning core data in that case app crashes on launch after update.
I have an application already on the store and would like to release an update. Since my app deals with databases and I've had to change some parts of it, I would like to ensure that the update does not affect the existing functionality in any way once the user updates from the App Store.
What I did was this - install the first version of my app on my device. Changed the update's version in info.plist to 1.1 and run it via xcode (and install on my device). But what happens by doing this is some of the changes I made to the XIBs do not show up. It looks as if the app was only half-updated (if you know what I mean)
Is there any way to update an existing app programmatically without having to go through the app store and then find out it could lead to a disaster?!
Thanks for any help!
I would double check your build configuration. Between building the two versions of the app, I would recommend a "Clean All" just to be safe. The process you described works to verify updates. The only other alternative I can come up with is to create Ad-hoc distributions of both versions of your app, and install those.