I've developed an iOS app that uses the url(forPublishingUbiquitousItemAt:expiration:) method of Apple's FileManager class. Starting with the first Beta of iOS 13 this function stopped working and now it throws an error, stating "This code has been removed. You should switch off of this SPI". But I can't find anything related to this function neither in the release notes of iOS nor in the documentation for this function, and it even states there that it would be supported on Mac Catalyst 13.0+.
This also has nothing to do with Xcode 10 and 11, as it occurs when the app is built using either one of those versions.
Does anyone of you know more about that? It would be great to get new information on that.
Thanks,
Fabian.
This is fixed in iOS 13 beta 6. Updated today and this error magically disappeared!
Had my mind blown when I saw this error message.
I was using this function to change the font size of a label in UIButton.
Like this(SWIFT) :-
Button!.titleLabel?.font = Button!.titleLabel?.font.fontWithSize(12)
I want to see the availability of this funtion for ios 7. So i see the quick help documentation of Xcode. There it was mentioned as iOS (8.0 and later)
Then i went on to search for the appropiate funtion on apple website but there it is wriiten that its available from Available in iOS 2.0 and later. See Here for ref.
Please do let me know which one to trust.
I saw answer but i am not that satisfied as i check the other class
Like NSMutableAttributedString for swift
here it is written as available from iOS (3.2 and later)
My strong guess is that since Swift came out together with iOS 8 Apple's documentation won't show anything being available before that. If you check the same method on Objective-C side, you'll see the same as on the web:
I also have a project targeting iOS 7 with calls to fontWithSize in Objective C and they work fine. So there should be no reason for it to not be available on Swift side of things.
Also found information from Apple's Radar system:
Engineering has the following feedback for you:
This is expected - Swift was not available until WWDC 2014 and the introduction of iOS 8, therefore the availability of these methods and contstants in Swift is correctly documented as iOS 8+.
Thank you for your feedback. Engineering has determined that this issue behaves as intended.
So clearly this is the Apple way of doing things, as usual.
in Objective C
it is still 2.0
I need to use beginAppearanceTransition:animated: in a UIViewController subclass that implements controller containment with custom animation transitions. I need to support iOS5 as a minimum.
The Apple docs say the method is:
Available in iOS 6.0 and later
Yet UIViewController.h has the method tagged with:
__OSX_AVAILABLE_STARTING(__MAC_NA,__IPHONE_5_0)
I'm hoping the docs are just wrong. Can anyone give me a definitive answer on whether I'm allowed to call this in iOS5?
I filed a bug report with Apple about this discrepancy and got the response that the methods are available in iOS 5.0. The headers are right and the documentation is wrong. I've filed another report to ask for the documentation to be updated...
The methods were added to the public headers in the iOS 6 SDK, but are available and can be used on devices running iOS 5.0.
Update (28-Aug-2013)
The documentation has been updated to show that beginAppearanceTransition:animated: and endAppearanceTransition are available on iOS 5.0.
In my experience when in doubt, the headers are more accurate. the docs are generated / written using the headers. So I assume at this point that iOS 5 is supported.
Now I tested it on the simulator. Once for 5.0 and once for iOS 6.1 and the moths are called on both versions whenever you push or pop a vc.
I am testing an app on an iPhone 4 with iOS 5.1 and an iPad 4 with iOS 6.0. I looked around and surprisingly did not find similar questions:
1- My app has some methods that have been deprecated in iOS 6.0 so I believe I have to build some if/then conditions to test for system version using: [[UIDevice currentDevice] systemVersion], and then use the version appropriate methods. Is that the most efficient way?
2- My understanding is, with only one target, the "project" Deployment Target and the "Targets" deployment target serve the same purpose. And I need to have one of them or both as iOS 5.1 since that is the minimum iOS supported. What is confusing is that if the target is built based on iOS 5.1, how would it run on the iPad4 with iOS 6.0:
Does the iPad OS checks for target versions before running or just tries to run the code and it happens that the iOS 5.1 target does not have any code that the 6.0 is incompatible with?
Even if that is the case though, how could a 5.1 target support 6.0 methods that I built to conditionally replace deprecated methods?
Many thanks!
Deprecated methods
Deprecated methods can be used if you are targetting iOS versions that were released before those methods were deprecated. But assuming your deployment target is set correctly, you won't get any compiler errors unless those deprecated methods were always deprecated for the versions you are targetting. In other words, if you are seeing deprecation warnings in your code you need to fix them or check that your deployment target setting is correct. Do not ignore them!
Xcode setting levels
You mention the fact that you can define the deployment target setting at both the target and project level. Xcode build settings at the target level will override project settings. So define the deployment target at one of these levels only, then go to the other and hit delete so you don't have duplicate values. If you only have one target then it doesn't really matter if you define it at the target or project level.
Backwards and forwards compatibility
Finally, there are many factors that come into play for backwards and forwards compatibility. Sometimes there will be new iOS 6 methods like supportedInterfaceOrientations which will simply be ignored on older iOS versions. Other times you need to add explicit checks:
If you are calling a method on an object and that method was only introducted with iOS 6, you will need to add a respondsToSelector: check like this:
// only available on iOS 6
if ([locationManager respondsToSelector:#selector(pausesLocationUpdatesAutomatically)]) {
locationManager.pausesLocationUpdatesAutomatically = YES;
}
If you want to check if a particular class exists on the current iOS version, you can check the return value of the +class method like this:
// Only available on iOS 6
if ([UICollectionView class]) {
// ...
} else {
// class doesn't exist in this iOS version
}
If you want to check if a particular function is available, do a simple if statement on it:
// Only available in iOS 6
if (ABAddressBookCreateWithOptions) {
ABAddressBookCreateWithOptions(...);
} else {
ABAddressBookCreate(...);
}
Finally, if you want to check if a constant is available, check it's address:
// Only available in iOS 4
if (&UIApplicationProtectedDataDidBecomeAvailable) {
// subscribe to notification
}
Your Base SDK setting should always be set to "latest".
If you follow all these guidelines you will be able to solve most of your problems without having to add explicit version checks. Checking the iOS version or device ID is very brittle and is likely to cause your app to break in future versions. You really want to avoid it.
You can use [[UIDevice currentDevice] systemVersion] to detect the OS version, that would work. Rather than detecting the OS version, you could use respondsToSelector: to see what methods are present, NSClassFromString() != nil to see if classes are present, and fallback if that method is not available.
iOS is backward compatible, so iOS 6 will run iOS 5 apps just fine. However, if you want to use iOS 6 specific feature but still support iOS 5.1, you have to :
Compile using the 6.0 SDK so that the compilers knows new APIs
Set your target version to the lowest supported, aka. 5.1. Any system higher than that number will run the code. Any lower will not try.
Use one of the method described in 1. to make sure that each device execute codes the OS support.
I hope that's clear, don't hesitate if you have more questions
What you must do is detect functionality, not iOS version, please check out this thread:
Conditional support of iOS 6 features in an iOS 5 app
You shouldn't check against the system version but rather check against the functionality you are trying to use. On that note remember that deprecated does not mean removed so whatever you are trying to do may very well be there for iOS6. To check against a specific functionality you would do something like:
if([TheClassInQuestion class] != nil)
{
//use it
}
iOS is backwards compatible. If you compile your app for iOS 5.1 it will be perfectly run on iOS 6 as well. No need to re-implement deprecated classes.
But if you change your deployment version from 5.0 to 6.0, Xcode will show you warnings if you use deprecated methods
If you want to use methods, which are available only in iOS 6, you can use this check:
if ([self respondsToSelector:#selector(doSomething:)]) {
[self doSomething];
}
Strange bug in iOS 6.0 sdk. Apple promised to deliver full reminder support via api, to allow thirdparty applications to read and write reminders on behalf of user. There is new methods in SDK to init storekit for use with reminders.
But seems like main method to make it possible - just not present. Both GM version of XCode 4.5 and simulator/ios-6 upgraded device shows that EKEventStore:initWithAccessToEntityTypes is not present in SDK and attempt to call it on device/simulator crashing application with
Error invoking method 'EKRemsIsGranted' on 'CEKtils' because
-[EKEventStore initWithAccessToEntityTypes:]: unrecognized selector sent to instance 0x13a59140
Interesting that this method is also mentioned and described in MacOs 10.8
but in iOS sdk it is mentioned but NOT described
Seems like apple devs forgot to "enable" it on iOS. is it possible at all or I missing something?
There's a description of the event (and some other useful information) here. You might also double-check that your UIEventKit framework is properly linked and up to date.