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/
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:
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.
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.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
We want to develop an application for iOS and Android smartphones. We are mainly using Microsoft technologies for developing our applications. We thought that if we would use MonoTouch and Mono for Android we would only have to maintain one code base with only a different UI layer for each device.
Because currently nobody in our small team ever developed a smartphone application and we need it quickly we want to outsource it. We asked other companies whether they perfer MonoTouch or Objective C for iPhone development. Most of them said, that the would choose Objective C. They said that Objective C offers more functionality and possibilities, it's faster and for MonoTouch there is a chance that Apple will not support it anymore in the future. Is all of that true or are there other reasons to prefer Objective C? I know there are other threads like this around, but they did not answer my questions, especially the one regarding Apple's support for MonoTouch.
applications. We thought that if we would use MonoTouch and Mono for
Android we would only have to maintain one code base with only a
different UI layer for each device.
this is a possibility IF you structure your app right. If not: no.
If you use Java+ObjC+C# (for WP7 / Win8 metro etc) then this is not an option AT ALL
Because currently nobody in our
small team ever developed a smartphone application and we need it
quickly we want to outsource it. We asked other companies whether they
perfer MonoTouch or Objective C for iPhone development. Most of them
said, that the would choose Objective C.
If you are outsourcing it, you should dictate what you want it written in, surely? If you need to support it in-house, and you only have C# skills, then MonoTouch etc makes more sense for you, the people paying the bills!
They said that Objective C
offers more functionality and possibilities,
FUD, and also incorrect. Monotouch has the full API available. If it's not there, as Xamarin to bind it (which they have done often before)
it's faster
I'd love to see the benchmark. Yes, technically, it can be faster in some circumstances, but in general use, MonoTouch the same or quicker.
Programmer error is a more common cause of iOS app performance problems. eg not getting things off the UI thread (which is easier to do in MonoTouch than in ObjC, tho blocks have helped that a lot), or taking too long to get out of FinishedLaunching (the "main" method, if you will, tho it's not really...)
Garbage collection and things like linq, xml/json parsing, generics and collections are also hugely valuable, and very quick.
and for
MonoTouch there is a chance that Apple will not support it anymore in
the future.
yes, there is a chance. There is also a chance that Tim Cook will run off with Apple's billions and buy all of Hawaii (rather than Larry Ellison's "I'll just have this island" purchase). But the chances are now rather slim.
Is all of that true or are there other reasons to prefer
Objective C? I know there are other threads like this around, but they
did not answer my questions, especially the one regarding Apple's
support for MonoTouch.
Apple doesn't support MonoTouch. Xamarin does, and they do it exceptionally well. Apple doesn't support anything except XCode, which is their product.
Apple DOES allow MonoTouch apps (there are lots). Another way to look at it: usually, 95% of the top 100 games are written using Unity3D, which is based on the same techniques (ahead-of-time compilation of C# code and embedding a cutdown version of the Mono/.NET framework).
There ARE reasons to prefer ObjC which would be:
You already know ObjC and CocoaTouch and like it.
Your team already knows ObjC and CocoaTouch or you can easily hire people who do (note: currently, as far as I know, iOS developers are CRAZY expensive to hire, if you can get them)
You need to use the beta's the day they come out. Keep in mind that you can use the current MonoTouch and deploy to your iOS[REDACTED] device with the beta on it. You just can't use the new stuff in iOS6 YET (Xamarin said "around 2 weeks" which should be about now...). Also keep in mind that you can not deploy an app to the store which is built with the beta SDK, even if you don't use any of the stuff in it. You can't even mention iOS[REDACTED] in your product description (I've tried)
you love [squareBrackets andTheOccasional:#"strange syntax things"];
Now, will building a cross platform, shared code app be an easy undertaking? HELL NO. It's a very complex piece of development for a non-trivial application. But thats the fun part of software development: if it was easy, it'd be boring! Grab Greg Shackles book ( http://www.amazon.com/dp/1449320236 ) to get an idea of whats needed for iOS+WinPhone+Android style development.
My hunch is that the companies you talked to simply are used to using Objective-C. That's where their skills lie, and that's the biggest reason why they would prefer not to deviate from their path. The other reasons can be argued both ways.
It's true that no one can predict what Apple will do, but there's a very small likelihood that Apple will ban third-party toolkits & APIs like they did in the summer of 2010. That was only a short period of time, and they completely reversed that decision. Their current focus is on making app development easier, which means keeping the field open to alternative development methods. I think MonoTouch is safe.
As for speed, C# generally produces very fast executables. They may not be quite as fast as Objective-C, but I doubt you'd notice a difference. I remember seeing a website somewhere that showed C# outperforming C/C++ in some tests, but that was in the .NET environment, not Mono... and unfortunately I can't find the reference anymore. I'll keep looking. But the bottom line on speed is that C# speeds are very good. It's not like BASIC vs C. More like Java/JIT vs C.
C# gives you many, many(!) advantages over Objective-C, and they have been enumerated in other Stack Overflow answers, so I won't repeat them here. You can find them easily enough.
I'm an obvious fan of MonoTouch, but I do have to say one thing: I think it's a mistake for companies to think that because they are fluent in C#/.NET that they will easily be able to develop and/or maintain iOS apps using MonoTouch. It's just not true, because MonoTouch is basically a C# layer over the CocoaTouch API, meaning that you have to learn the Apple way of doing things. You have app delegates and view controllers and all the UIKit stuff. There's a real learning curve there. But if you're fluent in C#, MonoTouch will be a huge help.
UPDATE:
I found the article on C# speed: Head-to-head benchmark: C++ vs .NET
I have actually used MonoTouch for every app I've ever developed. Performance has never been an issue, and I can't imagine how bad for me it would have been using Objective-C. I've had 2 top 10 apps in the US app store: "Draw A Stickman" and "Draw A Stickman: Episode 2" (don't worry we are working on more).
If you know C# and .Net your gains in productivity are going to be massive compared to what would happen trying to learn Objective-C. I was a C# .Net developer (Windows only) prior to iOS development and the transition to MonoTouch is great.
If you like Linq, parsing XML in fewer than 100 lines, garbage collection, generics, simple multi-threading, and no weird square brackets, MonoTouch is for you.
I use both Objective-C and c# (MonoTouch & Droid), and I really like both. When I'm coding in c#, there are plenty of features such as Linq which I'd love in Obj-C, & when I'm coding in Obj-C there are plenty of things I'd love to have in c#, but I adapt to whatever I'm coding in quickly enough. Re performance, I've detected no difference at all, even for fairly graphic-intensive stuff, so I wouldn't use that as a reason not to use c#.
I think it's ultimately down to what you're comfortable coding in, though of course with a well designed cross-platform project, you CAN have fully cross-platform core code if you use Mono, and you'll only have to do the UI stuff in a platform-specific way - when it comes to this obviously you'll need to know the native stuff to get your UIs working in a way which is appropriate to the platform and familiar to its users.
We have a line of business app that uses MS SQL as a data store, and has WinForms and web UI's. It integrates with our windows mobile 6.5 and tablet apps with web services. All c#.
We've fully committed to MonoTouch after some experiments in Objective-C and HTML-5 (we had working prototypes): we get to re-use our business logic, and we're comfortable developing new code in c#.
Our business logic is constantly being enhanced, and these enhancements are immediately visible to the mobile app - without having to replicate the logic in Objective-C or C++.
Our main issue is finding a c# programmer who's comfortable with the iPhone and iPad UI's.
MonoTouch is stable and we've encountered no limitations (we're binding to the same iOS API that Objective-C binds to). During our learning curve, we've had question, bumped into bugs and have had some misunderstandings - but the support from Xamarin is superb.
Performance has been a non-issue - our app is snappy even though it's doing a lot behind the scenes.
No body can tell you for sure what will apple support and what it will not support in the future, however apple had some issues with mono in the past, and since history tends to repeat itself, then it may be a possibility of that to happen again
Having said that, always go with the native application development SDKS and environments, it will be more flexible, and it will be updated real time, and performance will always be better in the native
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!