This question already has answers here:
To ARC or not to ARC? What are the pros and cons? [closed]
(6 answers)
Closed 9 years ago.
I am taking a class (computer based training on Lynda.com) and the instructor goes on and on about using "release" for your objects. This course was created in 2011 and clearly Apple has updated their product to do the release for you automatically. While I know I can go back to a manual mode and release items myself (eg turn off ARC), my question is this: what is the best practice? Should I leave ARC on or turn it off? Perhaps you have a good example as to when I should make this choice?
Also, if I am totally off base on this, your help is appreciated as well :-)
Thanks.
There is no reason to start a new project today that does not use ARC.
However, learning how to do memory management through retain/release may be useful if you are hoping to work as an iOS developer on existing projects, since in many older codebases memory management is still done manually.
What is the best practice? Should I leave ARC on or turn it off?
Best practice is using ARC for all new development, and selectively turning ARC off only for legacy libraries.
Perhaps you have a good example as to when I should make this choice?
The choice is very simple: if you are maintaining a large body of code with manual memory management, turn ARC off; otherwise, keep ARC on.
It is still very beneficial to get a working knowledge on how retain/release work: it would let you understand ARC at a deeper level.
As a side note, consider switching the course to something that has been updated in the last two years: ARC is easily the most important change in the language that has been introduced in the last few years; you definitely do not want to miss out on it.
Related
While trying to work older tutorials and material for learning iOS development, when I come across retain/release in a code, is it okay to just ignore it (and act is if ARC takes care of it)?
You can ignore it, however it is a good idea to understand what's going on. There's still a lot of older code out there you may need to read/use/modify. Also, a working knowledge of memory management is useful when debugging memory issues.
It should be fine but I would recommend reading up on converting from non ARC to ARC
Migrating to ARC
or
Migrating code to ARC
This question already has answers here:
Starting with Objective-C: To ARC or not to ARC?
(5 answers)
Closed 9 years ago.
when reading one of the iOS 5 book I've came across such information:
"While ARC makes it easier for you to write applications without
worrying about object management, lot of third-party libraries still
need to manually release objects. For this book, all the projects are
created with ARC turned off (...)" .
I am new to iOS Development, and I am not sure how to interpret it. Understanding Memory Management for iOS seems to be quite (very) important thing, but should I understood, that ARC is just a nice feature and I have to start without learning it, because it so new it can be not supported or possible to use in many situations?
Do yourself a favor, use ARC. This is by far the best addition to the language that has happened in the last five years. It lets you deal with memory management in a more declarative, rather than a procedural way, freeing you from writing a lot of "boilerplate code".
This is not to say that learning about manual memory management is unimportant: you should definitely know how it works, and be able to read the code written without ARC. But as far as your newly developed code is concerned, you should stay with ARC, because manual memory management wastes a lot of your development effort for nothing.
Better yet, get yourself another book: it appears that the authors did not have enough time to rework the examples for ARC, so they inserted a rather lame excuse about "other libraries out there".
It is a personal choice.
If you use ARC, you are not bothered about memory management.
But if you know how to make a full-fledged app with MRC (Manual Retain count) then using ARC is not bad.
Even in ARC at some specific time, you need to allocate and release memory, therefore MRC must to be learnt.
I still prefere to create non ARC projects.
But some weeks ago i have written this great article http://www.raywenderlich.com/5677/beginning-arc-in-ios-5-part-1 and sounds like this is great feature that Apple provides.
So, i want to try it. Lots of my college already use ARC and i see it works good.
But, one thing that i want to say - ARC isn't mean that you must write code and don't worry about memory management. ARC - this is something else, ARC also has own memory management rules/laws that you must keep in your mind while writing code.
Well, if you are new to objective C, the best thing you can do is to use ARC in your project. ARC is stable, and make memory management quite easier.
The books was right that there are some 3rd party libraries that still follows Manual memory management. But most of these libraries now provide ARC version also. If not you can still use them in your ARC project, by adding it as a static library project. Also you can disable ARC per specific files too.
I started iOS development in the pre ARC days, and to me manual memory management was difficult at first. So for starters, with ARC around, definitely ARC. Try to understand manual memory management when you have spare time.
Disclaimer : I still do not use ARC much, but for starters, ARC is the way to go.
ARC is nice to use, as a beginner it is very helpful. When we include third party libraries, you can have a option to disable ARC for that particular file (or) library.
For disabling ARC for a particular file:
add -fno-objc-arc to the compiler flags for the files you don't want ARC. In Xcode 4, you can do this under your target -> Build Phases -> Compile Sources.
If you want to understand Memory Management from the beginning, disable ARC and try yourself. That may help you alot
ARC is one of the best feature provided by Apple.
ARC takes care of overhead related to memory management issues
also Apple recommends use of ARC.
Rather than not using it better to make best use of it and stay free of memory overhead
I would suggest you to make use of ARC but do study how memory is
managed by ARC under the hood.
But when you need to develop applications with deployment target below
ios 4.0 You need to manually retain-release memory.
Few months back, when I started developing apps for iOS (I was experienced Java Developer), my colleagues who were experienced in iOS warned me to stay away from ARC (as they claim its kinda buggy). Now I'm pretty comfortable with MRR. But I want to move on to ARC if it really worths. While looking in Apple's documentation i.e. "About Memory Management". I found:
"If you plan on writing code for iOS, you must use explicit memory management"
So I'm still confused whether to go for ARC or not. I am only concered about iOS (not Mac development).
Thanks.
Your colleagues don't sound experienced with iOS. ARC isn't buggy. Every single experienced iOS developer I've heard mention ARC has done so in approving terms. I have over three year's experience with iOS and I would strongly recommend ARC, so long as you actually understand what's going on under the hood. Apple themselves, in the very guide you link to say:
You are strongly encouraged to use ARC for new projects.
When Apple say that you must use explicit memory management, they are grouping traditional manual memory management and ARC together as explicit memory management, in contrast to garbage collection.
Also, note that you linked to documentation in the Mac developer library, not the iOS developer library. If you need to develop for iOS, use the iOS developer library.
My personal opinion is that you should start learning to use ARC and implement them in your own projects (unless for some reason your client/boss doesn't want). More and more libraries are being created and converted to use ARC. Apple also advises you to use ARC in your own projects (see Jim's answer). Although I must insist that any person that starts learning objective-c and iOS should become familiarized with the traditional memory management and then go to ARC. Also, you could check this answer.
I'm a little experienced programmer, but from my point of view, ARC allows you to save a lot of time since you don't worry about retain/release objects and implement dealloc methods. In addition it lets you to think in terms of object graph. In this case you need to make attention to cycles within your application.
Out of there there a lot of tutorials on how to migrate to ARC. Here my favorites:
http://www.mikeash.com/pyblog/friday-qa-2011-09-30-automatic-reference-counting.html
http://blog.mugunthkumar.com/articles/migrating-your-code-to-objective-c-arc/
Hope it helps.
go for ARC as it in some cases give boost to application's performance read the blogs below
http://www.learn-cocos2d.com/2011/11/everything-know-about-arc/
http://longweekendmobile.com/2011/09/07/objc-automatic-reference-counting-in-xcode-explained/
http://www.raywenderlich.com/5677/beginning-arc-in-ios-5-part-1
and many more
If you have been experienced with MMR and probably aware of how tedious task memory management could become. When using ARC there is no need for retain and release calls, and not only that in many cases ARC can provide a significant performance increase.
Personally, I feel that if you're using a lot of C libraries in your code, ARC is a little bit harder to use right now (so if you're mostly using third-party C libraries and things like CoreFoundation, you might consider whether it makes sense or not), but even then, if these libraries are mostly isolated from your Objective-C controllers and such, ARC is still good.
Follow this guide: http://www.learn-cocos2d.com/2011/11/everything-know-about-arc/
When I moved to Objective C (iOS) from C++ (and little Java) I had hard time understanding memory management in iOS. But now all this seems natural and I know retain, autorelease, copy and release stuff. After reading about ARC, I am wondering is there more benefits of using ARC or it is just that you dont have to worry about memory management. Before moving to ARC I wanted to know how worth is moving to ARC.
XCode has "Convert to Objective C ARC" menu. Is the conversion is that simple (nothing to worry about)?
Does it help me in reducing my apps memory foot-print, memory leaks etc (somehow ?)
Does it has much testing impact on my apps ?
What are non-obvious advantages?
Any Disadvantage of moving to it?
Here's my specific take on ARC:
1) XCode has "Convert to Objective C ARC" menu. Is the conversion is that simple (nothing to worry about)?
It's simple. It works. Use it. As Kevin Low points out though, you will need to go through and fix up the bits where you use Core Foundation objects. That will just require a healthy lashing of __bridge or __bridge_transfer though.
2) Does it help me in reducing my apps memory foot-print, memory leaks etc (somehow ?)
Nope, not really. OK, sort of. It will help reduce memory leaks where you have coded incorrectly previously. It won't reduce memory footprint.
3) Does it has much testing impact on my apps ?
None whatsoever.
4) What are non-obvious advantages?
The future. There'll be more to come on the bonus that the compiler taking an intricate knowledge of how objects are reference counted gives. For example ARC provides the lovely objc_retainAutoreleasedReturnValue optimisation already, which is very nice.
5) Any Disadvantage os moving to it?
None whatsoever.
Please take my word for it and start using ARC. There's no reason (IMO) not to, thus the advantages definitely out-weigh the disadvantages!
For an in-depth look at how ARC works to perhaps help convince you that it's good, please take a look at my blog posts entitled "A look under ARC's hood" - here, here, here & here.
Here's what you really need to know about ARC:
The compiler understands Objective-C and Cocoa better than you. I don't mean this as an insult; it understands it better than me. I think you could safely say it understands the rules better than all but maybe a dozen people worldwide. And it knows tricks to use them to a degree that you and I can't repeat, even if we understood as well as it does.
The rest is just details:
You will write a lot less boring code. Code so boring it's easy to make mistakes.
As a blended compile time and run time process, it has access to tricks that you don't.
It will a better a job of writing memory management code than you can, even if you write the theoretical perfect memory management code.
It will reduce "high tide" memory usage (somewhat) without any effort on your part.
With zeroing weak references, it's much easier to avoid crashes caused by dangling pointers.
If you are starting a new application, stop thinking about it and just use it.
If you have an existing application:
You will need to re-test it. You need to make sure you have no circular references.
If you have an existing application that targets iOS before iOS 5, zeroing weak references are not supported. You should seriously consider requiring iOS 5.
If you have an existing application that targets iOS before iOS 4, you can't use it at all. What are you thinking, supporting crap that old?!?
In the last version of Xcode, it was not entirely bug free. It probably still isn't. But it's still worth using.
If you're using Core Foundation or non-Objective-C code, then it's not as simple as you will have to manually go through your code and make sure all the casts between Objective-C and Core Foundation are bridged (if you have any casts). You'll also still have to manage memory for non-Objective-C code.
It's supposed to essentially take care of all memory leaks for you, since it automates the retain, release, copy, etc. So far, I've never had an Objective-C leak since switching to ARC.
No. Building might take a tad bit longer since it has to go through all your code and insert all the retain and release code.
Not sure if there are any. In the end, all ARC is, is an automator.
You will have to learn about bridged casts as well as you cannot build for anything lower than iOS 4.
In the end, it's definitely worth it. I was skeptical at first, but after watching the WWDC video where they explain how it works, I liked it more and more.
Have you read Apple's documentation on ARC? It answers a lot of the questions you're asking.
Based on my experience, here's what I think:
Yes, it's simple. You definitely need to test your app after converting, though.
It can help reduce your app's memory usage and leaks, but it's not guaranteed to do that.
Yes. You'll want to test after converting to ARC.
You don't have to waste as much time thinking about and tracking down leaks. You can spend more time and energy on your app's actual code, rather than worrying about retain/release. Even if retain/release code is natural and easy for you, you're not infallible and you'll occasionally forget to release something. ARC doesn't forget.
If you're supporting iOS 4, you'll have to handle weak references, as ARC doesn't support those in iOS 4.
3) You should re-test your apps, but in my experience it will pretty much just work. Look at all the compiler warnings very carefully though!!!
4) Non obvious advantages: it's just really faster to code when you do not have to think about memory management. Perhaps that is obvious but the amount it helps still surprised me.
5) Disadvantages: Really the only disadvantage is having to turn off ARC for some third party libraries.
ARC has been so useful I simply will not code without it any longer. There's no reason to have to deal with all of that any more and it works well enough in practice.
Watch the WWDC video on ARC:
https://developer.apple.com/videos/wwdc/2011/?id=323
Apple's official stance in that video is that all apps that can use ARC should use ARC. The video goes into why, and is an excellent overview of the technology, so I'm not going to repeat it all here.
I discovered: ARC makes your code A LOT faster. In Apples WWDC video they say, that a couple of CPU cycles are saved for each NSObject's retain and release methods. This is because there is no need to check it on runtime anymore (It is outsourced to the compiler now). It's about 6 CPU cycles for each retain. If you use a loop which creates a lot of objects, then you can really feel the difference.
ARC not only makes the code faster, but YOU write less code, which accelerates your development process dramatically. And last but not least you must not search for memoryleaks by about 90% of your code. If you don't use a lot of low-level stuff, which must use "__bridge casts", you are COMPLETELY out of memory leaks.
Conclusion: If you can do it, DO IT!
I am a total beginner in iOS development. However, I've done Java, PHP and Javascript at work for severals years, so I am pretty experienced with OOP and design patterns.
Xcode 4.2 adds the new storyboarding capability for laying out interfaces in iOS 5.0. Is storyboarding simply a wizard for beginner developers or does it have advantages for more experienced developers as well?
My coworkers and I (both beginners in iOS development) are debating whether one should learn and program iOS using traditional NIBs vs storyboards. What are the advantages that storyboarding provides over previous ways of laying out iOS interfaces? Are there disadvantages to this approach?
Learn the old way in case you have to do both (or read some legacy code). This goes for Arc too; I shudder to think of new Cocoa/Cocoa Touch developers not understanding the old managed memory model.
I think the automated and convenience methods will always cover the "common" cases, and that story-boarding is an example of that. A convenience which greatly simplifies and accelerates the development process. However, there will always be cases where these methods do not provide you with all you need in a given, unusual situation. Just like using the UI elements does not stop developers from going under the hood with core graphics, core audio and so on when they need to. It is definitely, I think, a part of the future of iOS development, but only being aware of that part would be a handicap. So would not being aware of it.
I, personally, dislike automated tools. I have no idea what happens below, what sort of surplus code is inserted, the style of code is not mine and hence I need to work on another person's code. I'm the one that needs to support it for rest of time, not whatever automated tool I may have used.
It is all the tedious abstractions that will help you understand what is going on, especially when you are new to a field.
I'm personally like the traditional nib file approach, where I have more control over its behavior programatically and not having to hack the stroyboard backward to get things done. And of cause, if you have few developer working in a project, it's always good that you don't have to spend time merging changes (since you have several nib file compare to storyboard file)
storyboard files seem to be more readable than xibs.
both are xml files but the xibs seem to have unnecessary baggage and complexity.
I have compiled a list of about 15 reasons against using Storyboards: When to use Storyboard and when to use XIBs
Also, here's a tool that takes some of the pain away: http://github.com/jfahrenkrug/StoryboardLint