When will Apple remove the methods/APIs marked as deprecated? After 2 or 3 releases after they were marked, or never?
In common usage deprecation merely means that the feature is no longer recommended to be used and MAY be removed entirely in a later release.
Wikipedia - Deprecation
It is good practice to stop using deprecated features as soon as it is reasonable to, as you have no guarantee how long they will continue to be supported. Sometimes it could be as little as the next release or many dozens of versions later.
A quick search for Apple and Deprecation brought up this API reference where a feature has been deprecated but has survived at least one major OS revision.
https://developer.apple.com/library/ios/documentation/uikit/reference/UIDevice_Class/DeprecationAppendix/AppendixADeprecatedAPI.html
So yeah, when will Apple remove them? Whenever they want to, so don't build stuff now that relies on them and move old code off of them as you can. The compiler will usually throw warnings when features that are being used have been deprecated.
Related
Xcode 13.2 Beta release notes features a promise for Swift Concurrency support for iOS 13.
You can now use Swift Concurrency in applications that deploy to macOS 10.15, iOS 13, tvOS 13, and watchOS 6 or newer. This support includes async/await, actors, global actors, structured concurrency, and the task APIs. (70738378)
However, back in Summer 2021 when it first appeared at WWDC it was hard constrained to be run on iOS 15+ only.
My question is: what changed? How did they achieve backwards compatibility? Does it run in any way that is drastically different from the way it would run in iOS 15?
Back-deploying concurrency to older OS versions bundles a concurrency runtime library along with your app with the support required for this feature, much like Swift used to do with the standard library prior to ABI stability in Swift 5, when Swift could be shipped with the OS.
This bundles parts of the Concurrency portions of the standard library (stable link) along with some additional support and stubs for functionality (stable link).
This bundling isn't necessary when deploying to OS versions new enough to contain these runtime features as part of the OS.
Since the feature on iOS 15+ (and associated OS releases) was stated to require kernel changes (for the new cooperative threading model) which themselves cannot be backported, the implementation of certain features includes shims based on existing functionality which does exist on those OSes, but which might perform a little bit differently, or less efficiently.
You can see this in a few places in Doug Gregor's PR for backporting concurrency — in a few places, checks for SWIFT_CONCURRENCY_BACK_DEPLOYMENT change the implementation where some assumptions no longer hold, or functionality isn't present. For example, the GlobalExecutor can't make assumptions about dispatch_get_global_queue being cooperative (because that threading model doesn't exist on older OSes), so when backporting, it has to create its own queue for use as the global cooperative queue. #objc-based actors also need to have their superclass swizzled, which doesn't need to happen on non-backdeployed runtimes. (Symbols also have to be injected in some places into the backdeploy libs, and certain behaviors have to be stubbed out, but that's a bit less interesting.)
Overall, there isn't comprehensive documentation on the exact differences between backdeploying and not (short of reading all of the code), but it should be safe to assume that the effective behavior of the backdeployed lib will be the same, though potentially at the cost of performance.
I have several iOS enterprise apps that had been developed years ago, and some of the earlier ones contain elements that Apple has deprecated, such as UIWebView.
My question is, after Apple has stopped supporting deprecated elements, will these elements continue to work in existing applications? Or will I need to go in and update the deprecated elements in all the apps in order to maintain functionality?
When Apple deprecates an API, it means that they intend to stop supporting that API in the future.
Sometimes this is because the API is no longer useful or is flawed (creates a security hole, for example), but it's typically because it has been superseded by a superior API and Apple is encouraging you to adopt the new API.
Existing applications running on existing operating systems will, naturally, continue to function.
When Apple is replacing one API with another they will typically maintain the legacy (deprecated) API for as long as practical. So your app is likely to run on at least the next few major versions of the operating system.
Apple also tries to avoid forcing you to choose a new API because that complicates development since you now have to support two APIs in your application if you want it to be compatible with earlier versions of the OS. (Of course, if you want the features of the new API today, you don't have many choices: either support both APIs or limit the OS versions your app can run on.)
How long is on a case-by-case basis. A security flawed API might be removed in the next OS. On the other end of the scale you have string encoding APIs that have been deprecated for almost a decade (because they can't properly handle all Unicode conversion cases), yet they are still included in the framework and still function as advertised.
On high-profile classes like UIWebView, I would expect it to continue to work for years to come, but it won't be improved or get any of the new features of WKWebView. So, over time, it will look and act more and more dated. How important that is to your app is a subjective decision for your development.
I believe it depends on the user's OS version on their device. If the OS no longer supports the deprecated elements, then you may notice an error similar to the one below:
"[Appname] needs to be updated"
I have just started using Angular dart and Im going through the online tutorial with examples, and DartEditor is currently striking out NgAttr and NgTwoWay saying they are deprecated, is this the case? and if so what are they being replaced with? the auto docs don't say.
NgAttr, NgOneWay, NgTwoWay, etc. were marked deprecated in preparation to the new bind-* syntax, which is not implemented, yet. So deprecation is arguably a bit premature, since there's no action for users to take, but I guess it is a first warning of the impending major breaking change.
As of AngularDart 0.13.0, these attributes are no longer marked as deprecated.
As Pavel pointed out, the deprecation was premature. We may re-deprecate them when we have a better way of doing things, but for now you can use them without that nagging feeling that you are doing something wrong.
There is a new milestone for bind-* syntax which has issues discussing these changes, it may not be actually removed until 1.0 is what I feel.
IPP <= 7.1 has special in-place functions.
In IPP 8 they are deprecated: deprecation-summary
It is not clear if the new out-of-place functions also support in-place operation.
My guess is that for some of the functions it is OK to pass the same pointers for src/dst, but for others it is not, but this is not documented.
Here is the documentation
I've had similar question and have posted it under Intel's developer zone. The following link will take you to my post and to the answer I got from Intel:
http://software.intel.com/en-us/forums/topic/498093
Here is a short quote from the above link:
in IPP 8.1 (will be available on the web on ww06 2014) deprecation message removed from all ipps in-place functionality (based on customers' feedback). The same is planned be done for ippi domain in the nearest future.
Hope you find this helpful (I did).
Here's a quote from Intel's comment on the deprecated functions:
In-place functionality will be removed: In-place functions accept only
one pointer for input and output. The out-of-place versions often
offer the same functionality but with the additional flexibility of
specifying a different output buffer.
In my experience, all out-of-place functions with deprecated in-place variants support in-place operation, pSrc and pDst may point to the same memory.
Therefore my answer is: Yes, IPP 8.0 still supports in-place operations, but it's not documented well.
Here is a list of functions deprecated in 7.1, with recommended substitutes. You should notice that the non in-place functions are typically recommended as substitutes for their in-place counterparts.
Here is a forum discussion where in an intel engineer affirms that non in-place functions can be used in place of their in-place counterparts, by setting src==dst.
There is a caveat, though. If you're using IPP 7.0, the compiler will issue deprecation warnings. However, for at least some of those functions, using the src==dst method produces corrupt output. This doesn't appear to be fully implemented until 7.1. I've experienced this issue personally with filter functions, and there's a question in the discussion about it, though Intel never responded to it.
It's frustrating that Intel hasn't been more forthcoming about clearly documenting this change. The resulting bugs are very difficult to diagnose, and could easily be overlooked entirely. The only way to catch them, is by comparing the output of both functions, and few people would bother to do that.
I just came to realize that my project is currently using methods that are "discouraged" in iOS 4.0+. I fear that deprecation is soon inevitable. However, in practical terms, I'm not sure what this would mean for my project. Does it mean that users who attempt to run the app on a future iOS version will experience runtime errors or does it simply mean that I'll have compile-time errors when maintaining it on future iOS SDK's? Or, am I missing the boat (and the river) entirely?
Thanks
It's unlikely that they'll remove the old method entirely, Apple just suggests (see "Animations") that you use the newer format.
As stated, if you want your projects to support iOS versions <4.0, continue using the old format. If not, it's recommended to update, but if you choose not to, don't be too worried about it. (at least not until the old format becomes officially deprecated)
EDIT: Just re-read the question, and to answer that specifically; no, not you nor any other users would experience errors in the future (provided you're using the functions correctly) - even if it does become deprecated.