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.
Related
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"
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.
Though I am a programmer, I have never written for any Apple device. As such, my iOS-specific knowledge and familiarity with their API is nearly non-existent so please bear with me.
I would like to create an action from the lock screen (swipe, double tap clock, whatever) that would unlock and immediately open the App Switcher (I am not interested in extensions ala SwitcherPlus or the like). I guess this means writing a small script, and I could use some help concerning the API and other basics (the core features, shouldn't need any fringe stuff). While I am willing to get into the nitty gritty if need be, I am open to other solutions. Even something as high-level as chaining several Activator responses together would be fine.
I see Ruby under Cydia/Scripting (Telesphoreo). Though I'd slightly prefer Python or even Bash, being that my purposes are fairly minor Ruby would be just fine. I would rather not use Objective-C. While my original goal is the behavior described above, I can see myself wanting to do similar things in the future so some tips towards general know-how would be much appreciated.
If it is not clear, this a purely personal project. I am not at all concerned with packaging, sharing, backwards compatibility, commercial appeal, etc
PS - I have, until this point, set my Cydia viewing to "hacker" but not "dev". Does this endeavor indicate that I should up it to dev? The term seems a little generous, but if it opens up packages that I will need...
EDIT: I use an iPhone 4S, iOS 5.0.1
I don't think that this is possible in any scripting language. For one reason: You'll need to do code injection to achieve these goals (MobileSubstrate).
1) If you want to detect user interaction, you'll have to add ways to detect it or hook implementations which are already there. Even if you just wanna use Activator, you'll still have to develop a binary to register itself with Activator -> objC
2) There is no known way (at least to me) to interact with SpringBoard via scripts the way you want. So you'll have to make a binary which would execute the opening of the switcher.
I hope someone will have a better answer for you, but I'm very very sure that you won't get around using C/objC
There is a tool called http://www.cycript.org/ which is a bridge between JavaScript and objC, but I have never seen it being used for more than investigating.
I understand that iOS 5 is the latest (and the greatest) version of the Apple Mobile OS. I also know that it contains ARC, OpenGL ES Debugger yada yada yada...
I have already developed some in-house apps at my company and they all work perfectly fine. But as a developer, should I really bother upgrading all my apps to be iOS-5 compatible? If so, why?
"Upgrading" doesn't really apply to apps, only the OS. If your app already runs fine on iOS 5 (ie is "compatible"), which it might well be, there's no reason to change it.
If it's not currently "compatible", implying that you've tested it and something in the app is broken when run on iOS 5, then you would consider fixing or working around those issues so that your users on iOS 5 can use your app.
If these apps are ones that you're continuing to develop, you'd consider whether using the new technologies (ARC, new frameworks, etc) is worth the trouble of doing so and/or dropping support for older devices. That's a tradeoff only you can make relative to your apps and your business needs.
Considering that majority of crash related problems are due to memory allocation/deallocation/reference errors, it might be helpful to port the code over to use ARC. Of course the time/cost will need to be determined to see if it's worth it.
Do a cost benefit analysis.
Would an update building with the iOS 5 SDK benefit your customers by fixing existing or probable bugs, adding iOS 5 features, or providing other opportunities to just make a better product? Would an update provide you or your company with an additional marketing opportunity? At what cost in development, test and QA time?
Perhaps it would be a long term advantage in helping keep your development skills more up to date on the new APIs and tools (such as ARC).
But there's also an adage: If it ain't broken, don't "fix" it.
We are currently running rails 2.1.
My main motivation for the upgrade is the fear that gems/plugins will get rarer/unavailable/unsupported day by day for our version (,and the excitement of the latest technology).
I understand there are many-many improvements that come with rails3, but probably what my manager would want to listen is the advantages that he'd get, in terms of the business.
Ours is a Saas application, load on the app is not very high, but the demand for reliability is more.
Edit :
Looks like my inclination towards the upgrade needs rethinking, so answers to "should I upgrade" are welcome.
my original question also needs answers - how to describe the business advantages of an upgrade from rails2.1 -> rails3.
The app is under active development/enhancements.
The longer you go without upgrading, the harder it will be when the time comes. Sooner or later, any actively maintained project is going to have to move up to the more recent versions, and the more versions you have to skip along the way, the harder and more risky it will be. If you upgrade regularly, it becomes a fairly simple maintenance task.
I'm afraid that going from 2.1 -> 3.0 is going to be a fairly rough one unless your app is pretty simple. You might try going from 2.1 -> 2.3.9 as a first step. However, doing it now, instead of when it's 2.1 -> 3.1 will save you heartache. Right now, everyone is focused on helping people upgrade. A year from now, there will be fewer fresh resources available and fewer people going out of their way to help people upgrade.
If your application is under development and is likely to have more and more features over the months to come then you should migrate to the newer and actively supported version.
If your application only needs bug fixes occasionally then you should stick to the current version.
Upgrade!
I'd say that you should definitely upgrade, for the reasons you stated, but don't rush it. If you have a well defined test suite everything should be ok.
Most of core Rails 2.x code works with Rails 3, you can just read the deprecation warnings and fix things one by one. You can also use the official Rails Upgrade plugin to automate the bulk of the editing.
As for the gems and plugins you use, you can check their compatibility at railsplugins.org and decide if it's worth the trouble if any.
And the elevator pitch for the boss: You said the app is under development, so upgrading later when you absolutely have to means that you have to first deal with all the issues arising under 2.x and then deal with the upgrade issues plus 3.0 issues of a much bigger app. Upgrading now saves time by saving you the trouble of having to deal with 2.x issues. And you also avoid some of the upgrade issues since your app is probably much leaner now than the heavyweight it will be when you decide to upgrade later.
Since reliability is high on priority, you should probably not upgrade unless it's absolutely required. Some unforeseen issue is bound to come up.
To address the excitement of the latest technology, you can always try out new plugins and Rails 3 offline.
Businesses should not be sandboxes of developers. Nor should development be Resume Driven.
But that's just my opinion. :)
There are several reasons to upgrade, all of which are under the assumption that the app is and will continue to be under active development.
Integration with 3rd party software- for example, rails 1 did not have ActiveSupport. An app remaining on rails1 all through say rails 2 might want to integrate with a 3rd party API that primarily supports restful json. At that point, the sensibile path is to upgrade, but since you delayed it so long your risk of having lots of issues in the upgrade will be significantly greater than if you upgraded early.
Using plugins that will help with new features - if you want to add a new feature and someone has scratched your itch already, then if you are stuck on an older version of rails you will have to write that code yourself. The more code you have to write yourself, the greater the likelyhood of bugs and the more maintaince the code will likely require, depending on the function.
Fixing bugs in older verisons of the plugins/gems - if you encounter a bug in rails, or a plugin, or a gem, or some sort of other integration issue, it might be fixed in a later version, but what that depends on a newer version of rails. This will make your path to fixing said bug or implementing said enhancement greater the longer you wait to upgrade.