I'm adding support for LiveActivities/Widgetkit for my iOS app.
I'm still supporting older versions for iOS 14+.
When checking if the user returned to the app through the LiveActivity in my SceneDelegate:
func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
if #available(iOS 16.2, *), isLiveActivity(activity: userActivity) {
...
} else {
let _ = handleDynamicLink(url: userActivity.webpageURL)
}
}
with
#available(iOS 16.2, *)
public func isLiveActivity(activity: NSUserActivity) -> Bool {
return activity.activityType == NSUserActivityTypeLiveActivity
}
Now the issue is no matter how I wrap it in #available(iOS 16.2, *) or even if I don't call isLiveActivity at all, just the presence of NSUserActivityTypeLiveActivity in the code anywhere will, on older iOS versions (tested on simulator only) throw the error:
dyld: Symbol not found: _NSUserActivityTypeLiveActivity
How am I supposed to include this check if I can't even include the symbol anywhere in my code ?
I would have assumed NSUserActivityTypeLiveActivity to be a compile time constant, but it seems like it's dynamically looked up and crashes, since it isn't available in older versions of WidgetKit.
I think it is a bug in the SDK and recommend you file a bug with Apple about it.
As a workaround you could do:
public func isLiveActivity(activity: NSUserActivity) -> Bool {
if #available(iOS 16.2, *){
// workaround; we know that the live activity type is a global
// variable containing the name of itself as a string via
// a debug session on iOS 16.2
return activity.activityType == "NSUserActivityTypeLiveActivity"
}
return false
}
The reason why I think it is a bug because looking at the documentation, NSUserActivityTypeLiveActivity we see it marked as iOS 14.0+ but if we were to launch the simulator with debugging (DYLD_PRINT_LIBRARIES environmental variable) as per iOS Crash Dump Analysis we see it complain:
dyld: Symbol not found: _NSUserActivityTypeLiveActivity
Referenced from: /Users/faisalm/Library/Developer/CoreSimulator/Devices/77B3F700-46F7-402C-91D5-11453CD73D23/data/Containers/Bundle/Application/73D71FF5-2E01-46E7-AEE9-C1BF94FC8846/useractivity-expt.app/useractivity-expt
Expected in: /System/Library/Frameworks/WidgetKit.framework/WidgetKit
.
.
DYLD_ROOT_PATH=/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 14.1.simruntime/Contents/Resources/RuntimeRoot
If we were to go into the above DYLD_ROOT_PATH we could check using nm that the global variable NSUserActivityTypeLiveActivity is not present because the following command yields no matches:
nm '/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 14.1.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/WidgetKit.framework/WidgetKit'| grep _NSUserActivityTypeLiveActivity
So the global variable NSUserActivityTypeLiveActivity needs to be marked properly in the WidgetKit source code as not being available until iOS 16.1.
Related
My App is using CoreLocation and CLLocationManager and is working fine in iOS 13 and iOS 12.
I have implemented new feature of Precise Location in iOS 14 using Xcode 12 and its working fine in iOS 14, iOS 13, iOS 12.
But When I execute ths Xcode 12 code in Xcode 11 version (Xcode 11.7) then I am getting error
Cannot infer contextual base in reference to member 'reducedAccuracy'
Value of type 'CLLocationManager' has no member 'accuracyAuthorization'
if #available(iOS 14.0, *) {
if authorizationStatus.accessLevel == .granted && locationManager.accuracyAuthorization == .reducedAccuracy {
return .locationAlwaysAllowPreciseLocationOff
}
if authorizationStatus.accessLevel == .denied && locationManager.accuracyAuthorization == .fullAccuracy {
return .locationDeniedPreciseLocationON
}
}
// MARK: iOS 14 location function.
#available(iOS 14.0, *)
func locationManagerDidChangeAuthorization(_ manager: CLLocationManager) {
// iOS 14 Location Delegate method, not available in iOS 13 version
}
and here the error is
Static member 'authorizationStatus' cannot be used on instance of type 'CLLocationManager'
As i Know Precise Location is feature of iOS 14 and its not available in below versions and "accuracyAuthorization", ".reducedAccuracy", ".fullAccuracy" is not available in iOS 13 versions.
My Question is how can i make my code run in Xcode 11 versions. I have already added the isAvailable check to check the device version.
Thanks in advance :)
No amount of #available or #available marking is going to help you in this situation.
Why not? Well, you're doing an unexpected thing: you are opening an Xcode 12 project in Xcode 11. Your code was compiled originally in Xcode 12, where iOS 14 is a thing. So it compiled successfully. But now you open the same project in Xcode 11, where iOS 14 is not a thing. Nothing about this environment has the slightest idea that it exists. Therefore, code that involves something unique to iOS 14 will not compile. If the compiler sees that code, you are toast.
So is all hope lost? Not quite! Suppose we were to hide the code from the compiler. If we do that — if we can arrange things so that, in Xcode 11, the compiler never sees this code at all — then we will be able to compile in Xcode 11.
Well, we can do that! We can use a compilation condition. All we need is some condition that we are allowed to check against, that will distinguish what version of Xcode this is. And there is such a condition — the Swift version.
So, we can write this, for example:
class ViewController: UIViewController {
let manager = CLLocationManager()
override func viewDidLoad() {
super.viewDidLoad()
#if swift(>=5.3)
let status = manager.authorizationStatus
print(status.rawValue)
#endif
}
}
That code compiles in both Xcode 12 and Xcode 11, because in Xcode 11 the compilation condition fails, and the compiler never even looks inside the #if block.
In fact, we can provide an alternative version of the code, to be used in Xcode 11. In order to make this work as we desire, we will also have to restore your #available check, because we have to make the project's deployment target iOS 13, and the Xcode 12 compiler will complain if we don't protect the iOS 14 code:
class ViewController: UIViewController {
let manager = CLLocationManager()
override func viewDidLoad() {
super.viewDidLoad()
#if swift(>=5.3)
if #available(iOS 14.0, *) {
let status = manager.authorizationStatus
print(status.rawValue)
}
#else
let status = CLLocationManager.authorizationStatus()
print(status.rawValue)
#endif
}
}
That code compiles and behaves correctly in either Xcode 11 or Xcode 12. Do you understand why? Let's review, because it's a bit tricky.
In Xcode 11, the whole #if section is never seen by the compiler. It sees only this:
let status = CLLocationManager.authorizationStatus()
print(status.rawValue)
That's good iOS 13 code, so all is well.
In Xcode 12, the whole #else section is never seen by the compiler. It sees only this:
if #available(iOS 14.0, *) {
let status = manager.authorizationStatus
print(status.rawValue)
}
That's good iOS 14 code, because, even though our project's deployment target is iOS 13, we have calmed the compiler's nerves by guaranteeing that this code won't execute in iOS 13 (where it would crash if it did execute).
Having said all that, the real answer is: don't. Everything I just did is way too much trouble! Once you've written code under Xcode 12, don't try to open that project in Xcode 11. That's not the way to test for backward compatibility.
I tried to build my project in Xcode 11 and it throws 26 identical errors
<unknown>:0: error: '==' is only available in iOS 13.0 or newer
The errors happen on Compile Swift source files stage upon calling CompileSwift normal arm64 /long/path/to/MyClass.swift .... There is no context help pointing to anything within the files. The files are quite different but look harmless and does not share anything in common.
After a lot of pain, I found the 4-month old app version compiles fine. So I did git bisect and found the offending commit, and then this code:
struct Config: Equatable {
let formatDescription: CMFormatDescription
let orientation: CGImagePropertyOrientation
}
Turns out CMFormatDescription did become Equatable only in iOS 13, while the app deployment target is iOS 11. It probably felt back to [NSObject isEqual:] in Xcode 10, but it became complicated in Xcode 11. Since Swift automatically generates Equatable conformance under the hood it had troubles in pointing the exact place of the error. The solution is to add your own Equatable implementation for CMFormatDescription:
extension CMFormatDescription: Equatable {
public static func == (lhs: CMFormatDescription, rhs: CMFormatDescription) -> Bool {
return CMFormatDescriptionEqual(lhs, otherFormatDescription: rhs)
}
}
While here Apple states that the Swift available flag should be applied also in objc, it's not working for me. What am I doing wrong?
I've got following declarations in Swift files:
#objc protocol Readable: AnyObject {...}
#available(iOS 10.3, *)
#objc class Reader: NSObject, Readable {...}
So let's check if it produces an error when I try to initialize it in pre-ios-10 project without version check. If I write following code in Swift:
let tmp = Reader()
it returns an error:
'Reader' is only available on iOS 10.3 or newer
What is expected.
However if I write following code in objc:
// if (#available(iOS 10.3, *)) { // commeted out to test if it succeeds without version check
Reader *tmp = [[Reader alloc] init];
// }
The build is finished without any error, while I'd expect the same error as in Swift.
I've tried to mark the class with:
#available(iOS 11, *)
#available(iOS, introduced: 10.3)
Neither of these works (produces an error) in objc. Any help, please?
Objective-C has had __attribute__((availability)) for longer than it has had #available. To make it work, the Objective-C compiler weakly links symbols that are not available on the deployment target. This means that compiling always succeeds, and starting your app succeeds, but the symbol will be NULL at runtime if it is not available.
Depending on what it is, you'll get more or less graceful degradation when you try to use it:
calling a weakly-linked function that is missing is going to crash
reading or writing to a global variable that is missing is going to crash
using a class that is missing will be a no-op and all methods are going to return zero
The old way of testing whether a symbol is found at runtime is just to compare it to NULL:
NS_AVAILABLE_MAC(...) #interface Foo #end
int bar NS_AVAILABLE_MAC(...);
int baz(int frob) NS_AVAILABLE_MAC(...);
if ([Foo class]) { /* Foo is available */ }
if (&bar) { /* bar is available */ }
if (&baz) { /* baz is available */ }
In your case:
Reader *tmp = [[Reader alloc] init];
tmp will be nil, because that would be the same as [[nil alloc] init].
The #available directive has only relatively recently been added to Objective-C. It's now possible to use #available in Objective-C in the same way that you use #available in Swift. However, to preserve backwards compatibility, it possibly never will be a compile-time error (at default error levels) to try to use a symbol that might not be available on the deployment target in Objective-C.
(This is based on an issue here: https://github.com/dokun1/Lumina/issues/44)
Consider the following function:
fileprivate var discoverySession: AVCaptureDevice.DiscoverySession? {
var deviceTypes = [AVCaptureDevice.DeviceType]()
deviceTypes.append(.builtInWideAngleCamera)
if #available(iOS 10.2, *) {
deviceTypes.append(.builtInDualCamera)
}
if #available(iOS 11.1, *), self.captureDepthData == true {
deviceTypes.append(.builtInTrueDepthCamera)
}
return AVCaptureDevice.DiscoverySession(deviceTypes: deviceTypes, mediaType: AVMediaType.video, position: AVCaptureDevice.Position.unspecified)
}
I am running Xcode 9.0. I want to run a framework that makes use of this feature in iOS 11.1, which is only available in Xcode 9.1. The code in this function that gives an error is:
if #available(iOS 11.1, *), self.captureDepthData == true {
deviceTypes.append(.builtInTrueDepthCamera)
}
When running on Xcode 9.1 on someone else's machine, this works fine, and the application developing with this framework can set a development target of 10.0, and it compiles fine. However, I can't even build the framework on my machine. The error I get reads Type 'AVCaptureDevice.DeviceType' has no member 'builtInTrueDepthCamera' in Xcode 9.0 I thought using the #available macro would fix this, but it doesn't work that well.
I've also tried to use this:
#if __IPHONE_OS_VERSION_MAX_ALLOWED >= 111000
if #available(iOS 11.1, *), self.captureDepthData == true {
deviceTypes.append(.builtInTrueDepthCamera)
}
#endif
But this causes an error reading: Expected '&&' or '||' expression
Anyone know what to do?
#available will raise the "SDK Level" so that the compiler will allow you to use API calls above your Deployment target, but it won't prevent the compiler from compiling the lines inside the #available scope.
You need to prevent the compiler from compiling those lines because the compiler doesn't have a definition for .builtInTrueDepthCamera. You can do that using the #if build configuration statement.
In this case you want to check for swift version 4.0.2. Xcode 9.1 shipped with Swift 4.0.2.
#if swift(>=4.0.2)
if #available(iOS 11.1, *), self.captureDepthData == true {
deviceTypes.append(.builtInTrueDepthCamera)
}
#endif
source: https://www.bignerdranch.com/blog/hi-im-available/#what-it-is-not
I have an iOS application that is providing Document Picker feature working perfectly on iOS 10 but that on iOS 11 always calls the documentPickerWasCancelled: with this message in logs:
[UIDocumentLog] UIDocumentPickerViewController : didPickDocumentURLs
called with nil or 0 URLS
I'm correctly calling dismissGrantingAccessToURL: with a valid NSURL on the provider extension but it never calls the documentPicker:didPickDocumentsAtURLs: on the other side.
I think I'm missing something, can you give me an explanation for this bad behaviour?
I'm having the same problems. Unfortunately I think the explanation is a bug or backwards-incompatibility in iOS 11. According to the documents it should be enough with a Document Picker extension:
"The Document Picker View Controller extension can perform import and export operations on its own. If you want to support open and move operations, you must pair it with a File Provider extension."
https://developer.apple.com/documentation/uikit/uidocumentpickerextensionviewcontroller?language=objc
And indeed this worked fine in iOS 10 and earlier. iOS 11 was probably meant to be backwards compatible with the existing FileProvider-less DocumentPickers, but seems it's not. Or perhaps they forgot to update the documents.
Instead, one can implement the new updated File Provider that gives access to your files via the standard document browser UI:
https://developer.apple.com/documentation/fileprovider
This does work with an iOS 11 FileProvider backing the iOS10 picker. You probably want to create a new FileProvider using the new Xcode template, then use :
#available(iOSApplicationExtension 11.0, *)
on the FileProviderItem and FileProviderEnumerator classes, then :
if #available(iOSApplicationExtension 11.0, *) {
in the methods on your FileProviderExtension
I find that my iOS 10 picker does correctly call this method, but note the completionHandler?(nil) was required to make it work. By default, the template for iOS11 inserts a completion that reports a failure. This code works for me:
override func startProvidingItem(at url: URL, completionHandler: ((_ error: Error?) -> Void)?) {
completionHandler?(nil)
// completionHandler?(NSError(domain: NSCocoaErrorDomain, code: NSFeatureUnsupportedError, userInfo:[:]))
}
However, that isn't the end to this iOS10/11 incompatibility. If you make an iOS10/11 compatible file provider, it won't run on some iOS10 devices as far as I can see. I can run or debug mine on a 32-bit iOS device, but the FileProvider crashes on a 64-bit iOS 10 device with this error:
dyld: Library not loaded: /System/Library/Frameworks/FileProvider.framework/FileProvider
Referenced from: /private/var/containers/Bundle/Application/61BBD1A7-EA1E-4C10-A208-CA1DFA433C8D/test.app/PlugIns/testFileProvider.appex/testFileProvider
Reason: image not found