When accessing the iCloud ubiquity container in my iOS app I get the following message:
Unknown platform linking against CloudDocs framework 7
It happens when I execute the following code:
FileManager.default.url(forUbiquityContainerIdentifier: nil)
My project is built with SwiftUI on Xcode 14.2.
It is running on an iOS Simulator.
It doesn't matter wether iCloud is set up correctly or not (Capabilities/iCloud container/enabled on device).
I get the same message whether that call returns a URL or nil.
Related
Our app has iOS 14.0 as the min. deployment target. We've been able to test perfectly well using the iOS 15.0 simulator, as well as an iOS 14.5 devices on release builds.
Yesterday, to address an iOS 14 visual bug, I tried building a debug build from Xcode on iOS 14 (both simulator and a real device) and it instantly crashed with the following error message:
Thread 1: signal SIGABRT
There was no line of our own app code executed - it crashed before hitting the breakpoint in func application(_ application: UIApplication, didFinishLaunchingWithOptions).
The console output was as follows:
dyld: Symbol not found: _$sSo22NSManagedObjectContextC8CoreDataE5fetchySayypGSo14NSFetchRequestCySo0gH6Result_pGKF
Referenced from: /Users/jacob/Library/Developer/CoreSimulator/Devices/F0DD4D51-D749-4A0D-B40D-1A70B2F0120B/data/Containers/Bundle/Application/0B1C5FF3-66F9-4046-807F-37A1C4773E70/Gener8.app/Gener8
Expected in: /usr/lib/swift/libswiftCoreData.dylib
dyld: launch, loading dependent libraries
DYLD_SHARED_CACHE_DIR=/Users/jacob/Library/Developer/CoreSimulator/Caches/dyld/21F2081/com.apple.CoreSimulator.SimRuntime.iOS-14-5.18E182
DYLD_ROOT_PATH=/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 14.5.simruntime/Contents/Resources/RuntimeRoot
DYLD_LIBRARY_PATH=/Users/jacob/Library/Developer/Xcode/DerivedData/Gener8-ayxdgejxdmjsncfcxxrqtyrsroer/Build/Products/Debug-iphonesimulator:/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 14.5.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/introspection
DYLD_INSERT_LIBRARIES=/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 14.5.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libBacktraceRecording.dylib:/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 14.5.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libMainThreadChecker.dylib:/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 14.5.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libMTLCapture.dylib:/Library/Developer/CoreSimul
Has anyone got an idea how I go about debugging this?
We are using core data in some parts of the app, hence the NSManagedObjectContext at the start of the error message.
We have an extension in our iOS project (Broadcast Upload Extension). The extension works well when doing local builds, however whenever we do a TestFlight build a distribute it we encounter following exception (found in device logs):
Error getting proxy for beta app with bundleID
com.foo.bar.screenshareextension: Error
Domain=ASDTestFlightFeedbackErrorDomain Code=5 "Failed to find a valid
app with bundleID com.foo.bar.screenshareextension"
UserInfo={NSDebugDescription=Failed to find a valid app with bundleID
com.foo.bar.screenshareextension}
one more error lists:
[com.foo.bar] Error was encountered trying to find service extension:
error=Error Domain=UNErrorDomain Code=1904 "Unknown application"
UserInfo={NSLocalizedDescription=Unknown application}
the bundle IDs are set correctly (meaning the container app has "com.foo.bar" bundle id while the extension has com.foo.bar.extensionname".
The extension is referenced through
var bundleUrl = NSBundle.MainBundle.GetUrlForResource("Foo.iOS.ScreenShareExtension", "appex", "PlugIns");
I can confirm actually that the extension appex file is physically in the archived file for distribution.
The only difference is that the min OS version is set differently in the container app & in the app extension. However when doing local builds this doesn't seem to matter.
What could be the reason for not being able to target the extension? (seems like it's missing?)
ps: we are using Xamarin.Forms
Not sure if this helps: I encountered a similar error today, the reason is that the default build target of the notification extension is 13.6(the latest OS), while my testing device is in 13.5. After I changed the build target, everything works fine.
I've got same error with native Swift code on iPhone 6 (12.4.8).
I'm still not sure what causes this bug, but for me it fixes only by changing device. On iPhone 8 (13.6) the absolutely same code works just fine, rebuilding for iPhone 6 and it's not even trying.
When a crash occur (using a test device connected to Xcode, in my case iPhone 4s with iOS 9), Xcode 7 fails to load debug data for some of the system classes, hence it displays the aforementioned error. I'm working with a Swift 2.1 project. Does any one know how to fix it and make it load such data? It has proven to be hellish trying to debug when this happen.
PS: It has nothing to do with the type of crash, it is just an Xcode problem.
I'm having a strange issue and wondering if anyone knows what is going on. In Xcode 6.2, if you follow these steps:
create a new workspace
create a new iOS > Application> Single View Application project in
the workspace
create a new iOS > Framework & Library > Cocoa Touch Framework
project in the workspace
add the framework as an embedded binary in the app
build and run the app on any 8.2 simulator and then stop it
launch the app from within the simulator
Every time you try to launch the app from within the simulator (not running it from Xcode, but actually clicking on the app icon inside the simulator) the app crashes on startup. The only thing I see in the system log is:
Apr 3 20:04:53 MacBook com.apple.CoreSimulator.SimDevice.6B002DFB-FE6C-4295-BA22-742E4CEE2B6D.launchd_sim[61494] (UIKitApplication:com.test.TestApp[0xcb1d][61787]): Service exited due to signal: Trace/BPT trap: 5
Apr 3 20:04:53 MacBook.local SpringBoard[61507]: Application 'UIKitApplication:com.test.TestApp[0xcb1d]' crashed.
Apr 3 20:04:53 MacBook assertiond[61511]: assertion failed: 14C1514 12D508: assertiond + 14743 [849F745E-3AAA-3638-91FF-892312A54F42]: 0x1
Does anyone know if this is by-design or if embedded binaries work correctly? I'm hesitant to add an embedded binary to my app if the app always crashes in the simulator.
Thanks!
- Tom B.
We have a iOS and Android Hybrid App Environment in which we have App Authenticity successfully running (drop down available to control the feature) using:
<mobileSecurityTest name="app">
<testAppAuthenticity/>
<testUser realm="wl_anonymousUserRealm"/>
<testDeviceId provisioningType="none" />
</mobileSecurityTest>
We added a "iOS Native API" project to our Worklight project that we use for our native iOS client development in XCode 5. We are successfully able to connect to the WL server and call all our existing adapter procedures in our different adapters.
For this native API project, we now would like to enable App Authenticity as well. When we use the same MobileSecurityTest as in the hybrid app in the application descriptor of the native API project we can deploy it to our WL server and the App Authenticity feature is enabled (drop down available to control the feature) at the iOS Native API entry in the console.
On the native iOS app/project we set:
bundle ID is exactly the same as in the hybrid project and the same as in the Apple Developer portal
Key Chain is enabled in the project and also set to worklight.group (as in the hybrid XCode project)
we are not able to get a successful authentication running when we want to connect to WL server. We see that the DeviceAuthManager tries to get the UUID from the device, but then the server returns an error response:
2013-09-24 08:58:35.530 App[32535:c07] DeviceAuthManager:getWorklightUniqueDeviceId --> returning UUID from the keychain
2013-09-24 08:58:35.564 App[32535:c07]
isCustomResponse
2013-09-24 08:58:35.564 App[32535:c07] this is it: Status: 403
InvocationResult: (null)
InvocationContext: {
delegate = "<MyConnectionListener: 0x7d73ec0>";
}
Response text: /*-secure-
{"WL-Authentication-Failure":{"wl_authenticityRealm":{"reason":"com.ibm.json.java.JSONObject cannot be cast to java.lang.String"}}}*/
2013-09-24 08:58:35.564 App[32535:c07] [ERROR] Worklight: -[WLRequest requestFailed:]:309::Status code='403' error='(null)'
2013-09-24 08:58:35.565 App[32535:c07] [ERROR] Worklight: -[WLClient onInitRequestFailure:userInfo:]:410::
We did try this with and without a registered ChallengeHandler that just prints the response. The same results, just that we can see the error response printed in the isCustomResponse method if we have the ChallengeHandler.
Also, a Worklight dialog is shown automatically that says "Error: An error was encountered while processing the request from the application (CLOSE)".
We can see that in 6.0 there is the worklight.plist value:
<key>wlUid</key>
<string>wY/mbnwKTDDYQUvuQCdSgg==</string>
is that also necessary in 5.0.6? Our plist file there does not have that.
When we change the environment value in the worklight.plist file from iOSnative to our app name (or something else) we get a response Response text:
{"errorCode":"UNEXPECTED_ERROR","errorMsg":null}
so I assume this value iOSnative is a fixed value that has to be there?
Sept 30th: WL 6.0.0.1 Update
In WL 6.0.0.1 it seems to not show the same bug when we used it with a Studio 6.0.0 generated iOSApi Environment deployed to a Consumer Server on Tomcat.
Now we are getting an:
Invocation Failure: Status: 403
InvocationResult: {
"WL-Authentication-Failure" = {
"wl_authenticityRealm" = {
reason = "forbidden state";
};
};
}
when we have Enabled, blocking and we can connect and call Adapters when we change to Enabled, servicing. (which was not possible with the 5.0.6 bug before)
Now we assume we need to somehow setup our iOS Certificates or Signatures that we use to sign the app for the iOS Simulator and for the iOS Devices (Developer and Distribution Certificates) on the Wl server, so that the WL Server allows a connection?
Could someone help us with the steps that we need to take to setup an iOS native App Authenticity in our XCode 5 project to successfully connect to the server and after that call our adapters with Enabled, blocking.
We did add worklight.group to the turned-on Keychain Sharing capability of the iOS app.
We copied all Wl iOSAPI files including the plist file with the wlUid into the iOS app xCode5 project?
As mentioned above, it works with Enabled-Servicing and with Disabled AppAuthenticity fine.
For App Authenticity to function in a native iOS application using the Worklight Native API for iOS, the steps are the same as in a Hybrid application on the Eclipse side:
Setup the securityTest in authenticationConfig.xml
Add the securityTest to the iPhone environment application-descriptor.xml
Add your bundleId to the iPhone environment in application-descriptor.xml
There is, however, 1 extra step to do - in Xcode.
Once you open the generated Xcode project:
Under Build Settings > Linking > Other Linker Flags
Add the flag -ObjC
Now you can Clean and/or Run the project on the iOS Simulator/device. Should work.