I am having trouble uploading my app to the App Store Connect. I have uploaded the same app several times before but today its showing this error:
The app references non-public selectors in Payload/Runner.app/Frameworks/webview_flutter_wkwebview.framework/webview_flutter_wkwebview: initWithFrame:configuration:, isMainFrame, setNavigationDelegate:, userContentController With error code STATE_ERROR.VALIDATION_ERROR.50 for id
I have not change anything that has to do with the webview_flutter dependency since the last upload.
Xcode Version 13.4.1
Message from Apple: "The issue has been resolved on the app validation backend. Please try resubmitting. Sorry for the trouble."
When I run my app from xcode on my iPhone 12 Device, I get an error when trying to generate the Firebase AppCheck Token from below method. The error code is 0 and there is no description in the error object.
AppCheck.appCheck().token(forcingRefresh: false)
Just found out this might be cause by one of two issues below
Enable AppAttest in Capabilities
Set AppAttest environment to production even in testing since The App Check beta currently doesn't accept tokens generated in the App Attest sandbox environment.
https://firebase.google.com/docs/app-check/ios/app-attest-provider#install-sdk
When loading a certain url in UIWebView in IOS 10.1 it is failing on
Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made"
However the same webview loads fine in iOS 10.2
I can load the url in both 10.1 and 10.2 if I use NSAllowsArbitraryLoads = YES but only in 10.2 with NSAllowsArbitraryLoadsInWebContent = YES
I tested the URL with nscurl --ats-diagnostics and it passes all tests
I think that the issue may have something to do with an ip location validation within the webpage.
Are the differences between 10.1 and 10.2 in the handling of App Transport Security Settings? Are these documented?
---- Edit -----
I managed to resolve my issue by looking at the error in didFailLoadWithError. This told me exactly what the url was that was causing the failure. I added this url to my Exception Domains with NSExceptionRequiresForwardSecrecy=NO (determined using the ats diagnostics)
This fixed my problem but I still would like to understand the differences in the two versions 10.1 & 10.2.
Yes, earlier versions of iOS 10 did still enforce the forward secrecy requirement of app transport security in web views even with the NSAllowsArbitraryLoadsInWebContent key. That was a bug, that was fixed by Apple. The problem is that earlier versions of iOS shipped with the bug so you must be able to handle it, which isn't always possible if you don't know all the possible URLs that your Web you could navigate to. This may be part of the reason that Apple has extended their deadline for enabling app transport security and all apps submitted to the App Store.
We are facing issue with "iOS Push Notification" functionality with Mobile First 7.0.
We have downloaded push notification sample app from
Sample App. As MF 7.0 doesn't have any sample app. So we used sample app of MF 6.3.
After installation we have tried to "subscribe" through iOS device. Its throwing below error and app is crashing.
[ERROR ] FWLSE0020E: Ajax request exception: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. [project PushNotifications][ERROR ] FWLSE0117E: Error code: 1, error description: INTERNAL_ERROR, error message: FWLSE0069E: An internal error occurred during gadget request [project PushNotifications]The transaction has been rolled back. See the nested exceptions for details on the errors that occurred., User Identity {wl_directUpdateRealm=(name:null, loginModule:WLDirectUpdateNullLoginModule), SubscribeServlet=null, wl_authenticityRealm=null, wl_remoteDisableRealm=(name:null, loginModule:WLRemoteDisableNullLoginModule), SampleAppRealm=null, wl_antiXSRFRealm=(name:mibphsqb0hb1bfcko7t0nfstts, loginModule:WLAntiXSRFLoginModule), PushAppRealm=(name:Test1, loginModule:PushAppLoginModule), wl_deviceAutoProvisioningRealm=null, wl_deviceNoProvisioningRealm=(name:89E62244-B169-4C8E-BB83-BD7F6868310E, loginModule:WLDeviceNoProvisioningLoginModule), myserver=(name:b71e8870-df42-424a-bc38-924c645d621e, loginModule:WeakDummy), wl_anonymousUserRealm=(name:b71e8870-df42-424a-bc38-924c645d621e, loginModule:WeakDummy)}. [project PushNotifications]
com.worklight.common.log.filters.ErrorFilte
Why are you saying MFP 7.0 doesn't have any sample? it is linked to in the tutorials for MFP 7.0, here: https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-7-0/notifications/push-notifications-hybrid-applications/event-source-based-notifications/
So first try to the appropriate sample.
Additionally the error log does not reveal anything... provide logs from Xcode.
As for the crash - make sure you are using the latest MFPF 7.0 iFix from IBM Fix Central as an iOS push-related fix was delivered some time ago. You may be using a version affected by the bug.
I have an iOS application that stores some sensitive information in the keychain.
While writing values into the keychain, I am getting error code -34018.
I am currently using Apple's iOS KeyChainItemWrapper class.
Both of the following lines of code receive the same error code.
OSStatus res1 = SecItemCopyMatching((__bridge CFDictionaryRef)genericPasswordQuery, (CFTypeRef *)&attributes);
OSStatus res = SecItemUpdate((__bridge CFDictionaryRef)updateItem, (__bridge CFDictionaryRef)tempCheck);
This issue does not occur every time, but intermittently. Once I get this error, I am no longer able to write any values to the keychain.
I have printed the error description like so:
NSError *error = [NSError errorWithDomain:NSOSStatusErrorDomain code:res userInfo:nil];
and this is what the error prints out:
Error: Error Domain=NSOSStatusErrorDomain Code=-34018 "The operation couldn’t be completed. (OSStatus error -34018.)"
Seems like this is a bug in Keychain, which only appears when you launch your app from xcode. See here: https://github.com/soffes/sskeychain/issues/52
We debugged it a lot and it seems an issue accessing the keychain when
the app is launched from the background. This is only happening with
the debugger (i.e. when launched from Xcode). We think the issue
might be related in our case to the debugger keeping alive the app
even if it should be killed by the OS. We tried in fact to run the
app and then put it in background and launch many other app to occupy
RAM. With the debugger the bug came up when resuming the app from the
background, while without the debugger it didn't (we did run at least
10 tests each).
If someone will come here back with this error and XCode8 with iOS10, probably you have to enable KeyChain Share in the tab Capabilities:
As others have mentioned, this is a Keychain bug, one that Apple is aware of and has been aware of since at least mid-2015.
As of March 22, 2016, however, Apple has said:
We believe these problems were resolved in iOS 9.3.
iOS 9.3 was released on March 21, 2016.
See the thread: https://forums.developer.apple.com/thread/4743
To quote the response by an Apple employee:
Mar 22, 2016 3:28 AM
OK, here’s the latest. This is a complex problem with multiple possible causes:
Some instances of the problem are caused by incorrect app signing. You can easily distinguish this case because the problem is 100% reproducible.
Some instances of the problem are caused by a bug in how iOS supports app development (r. 23,991,853). Debugging this was complicated by the fact that another bug in the OS (r. 23,770,418) masked its effect, meaning the problem only cropped up when the device was under memory pressure.
We believe these problems were resolved in iOS 9.3.
We suspect that there may be yet more causes of this problem.
So, if you see this problem on a user device (one that hasn’t been talked to by Xcode) that’s running iOS 9.3 or later, please do file a bug report about it. Try to include the device system log in your bug report (I realise that can be tricky when dealing with customer devices; one option is to ask the customer to install Apple Configurator, which lets them view the system log). And if you do file a bug, please post your bug number, just for the record.
On behalf of Apple I’d like to thank everyone for their efforts in helping to track down this rather horrid issue.
Share and Enjoy
This held me up for 2 hours before I found a quick "fix" - reboot the iOS device
A quote from the discussion at http://forums.developer.apple.com/thread/4743,
From user littledetails
As others have reported, this mysterious keychain error is most easily observable when launching via Xcode with the debugger attached. Once the error starts occurring, the keychain doesn't seem to right itself regardless of memory pressure until one reboots the device.
When I rebooted my device the error went away, allowing me to continue testing. Not sure what else to do. In my situation, moving to NSUserDefaults or some other storage solution was not a possibility.
One way to get around this issue with the keychain is to use dispatch_async to allow the app to launch. This works when the app is opened from the background. Also make sure you have the kSecAttrAccessibleAfterFirstUnlock accessibility setting on the keychain.
dispatch_async(dispatch_get_main_queue(), ^{
// save/write to keychain
})
I am using GenericKeychain classes from apple:
https://developer.apple.com/library/content/samplecode/GenericKeychain/Introduction/Intro.html#//apple_ref/doc/uid/DTS40007797-Intro-DontLinkElementID_2
struct KeychainConfiguration {
static let serviceName = "MyAppService"
/*
Specifying an access group to use with `KeychainPasswordItem` instances will create items shared accross both apps.
For information on App ID prefixes, see:
https://developer.apple.com/library/ios/documentation/General/Conceptual/DevPedia-CocoaCore/AppID.html
and:
https://developer.apple.com/library/ios/technotes/tn2311/_index.html
*/
// static let accessGroup = "[YOUR APP ID PREFIX].com.example.apple-samplecode.GenericKeychainShared"
/*
Not specifying an access group to use with `KeychainPasswordItem` instances
will create items specific to each app.
*/
static let accessGroup: String? = nil
}
In this file I was specifying my custom accessGroup in this line static let accessGroup = "[YOUR APP ID PREFIX].com.example.apple-samplecode.GenericKeychainShared"
After returning to static let accessGroup: String? = nil the problem was gone. :)
Make sure keychain sharing must on under Capabilities in project Target.
In my case the App_Name.entitlements file has different bundle id than of my project bundle id. So, I change bundle id in the App_Name.entitlements file as of my project bundle id.
e.g., Suppose your project bundle id is com.Apple.testApp then got to
App_Name.entitlements file open key Keychain Access Groups key which is of Array type.
Under item0 set value of your project bundle id as eg:- $(AppIdentifierPrefix)com.Apple.testAp.
According to #iCaramba's answer. I've found a workaround:
Stop the task to kill the app (if you are already running the app)
Launch the app on your device manually. DO NOT use Xcode
Use Xcode to re-launch the app