I wonder if Swift supports MRC or only ARC.
I know that iOS use two memory management models: ARC and MRC. But can I create an app using manual reference counting or is it only available in Objective-C?
Swift only supports automatic reference counting. ARC is baked into the language.
As somebody who wrote Objective-C code using MRC for years, I can say with confidence: ARC is a big improvement on MRC.
MRC is fussy and error-prone.
Related
I am using Xcode's Instruments for first time and my app is based on ARC and built for iOS 6.1, but currently re-modified for iOS 7 and works well without crashing. I have run tests on a physical iPhone device also and have seen no problems at all.
Running Instruments keeps giving me the following details, but I have not seen any of my classes or objects apart from Libraries.
Is ARC not taking care of this? Do I need to manually release objects for all memory allocations?
Can someone please help me with what is going on here?
Any help would be much appreciated.
This post may help you: Does ARC work with Core Graphics objects?
Also, you need to be aware of retain loops. one object holds a reference (strong) to another object which also holds a reference to the first object (strong). This is most common in using delegation.
I'm using Objective-C/C++ and I have an Objective-C class that is a wrapper for a C++ class, are there any special concerns I need to be aware of in order to use fast app switching?
It is my understanding that the iPhone will auto-magically save state for Objective-C objects, but I'm not sure if I need to do any special work to enable support for C++ objects. My C++ class does not have any virtual functions.
By fast app switching you mean multitasking?
There's nothing additional you need to do - iOS 4 will handle the task suspension and resume transparently, unless you need to perform background tasks, regardless of whether you're using objective c++ or just plain objective c.
MonoTouch has automatic garbage collection on the iPhone. Couldn't someone prematurely implement garbage collection for Objective-C on iOS? I'm not the guy to do it, but I'm curious as to why or whether this is impossible.
I know that projects like this exist: what does it take to use them on iOS? Since they are in C/C++ anyway, and Objective-C contains those languages as subsets, but yet, those languages are actually aware of the system architecture... I'm out of my depths here...
While we're here, if anyone knows of any attempts to implement a GC on iOS, links would be helpful...
I don't think it's possible. The problem is that Objective-C is used inside the system library too. In OS X where garbage-collected Objective-C is supported, there are in fact three modes when you compile a code:
the function compiled can be only called from non-GC environment.
the function compiled can be only called from GC environment.
the function compiled can be called both from GC and non-GC environment.
See the discussion here, for example. The point is that the system library needs to be in the third mode in order for the OS to support both non-GC and GC apps. And in OS X, the libraries come in this hybrid mode. In iOS, I guess it comes in the mode 1. (I don't know for sure because I haven't jailbroken my phone, though.)
If you have complete control over both the system library and your app, it's possible to make them all garbage collected, but unfortunately we're not in that stage yet.
I'm sure we'll have GC in iOS in two years.
Nothing stops you from building your own garbage collector for your app. Or importing another project that will handle it. Again, for your app.
more discussion:
Is garbage collection supported for iPhone applications?
I keep running across references to MacRuby and was wondering if any of you have used it for iPhone/Objective C programming.
The MacRuby website says, "the goal of MacRuby to enable the creation of full-fledged Mac OS X applications which do not sacrifice performance in order to enjoy the benefits of using Ruby."
So, my question is: what are the benefits of Ruby?
And, more importantly, what are the limitations?
I've not used MacRuby, but I doubt if it could be used for iPhone development because it is built on top of the Mac OS X Objective-C runtime and uses the Objective-C 2.0 garbage collector (instead of using its own). Although iPhone OS has Objective-C 2.0, it lacks the garbage collector (you still have to use retain/release-style managed memory), so I expect MacRuby would not work out of the box.
Also, MacRuby would not be useful for developing for the App Store since using interpreters (other than those supplied by Apple) is verboten.
An iPhone port of Ruby might work on a jailbroken phone, but the device has very limited RAM and CPU resources, so I'm not sure how successful such a port would be. I expect MRI is too slow and memory hungry to be useful on the iPhone, but one of the alternative Ruby interpreters might work well - a MacRuby with its own GC perhaps.
I can certainly see MacRuby having many advantages for Mac OS X development. Here are some things off the top of my head:
As a language, Ruby it is a joy to use. Blocks are lovely. It's very dynamic and has great support for meta-programming, making it possible to quickly produce very compact but still readable code.
Objective-C can be quite high-level when it's being Objective, but can get annoyingly low-level when it's being C. Ruby has less of the C-ness.
IMHO, Objective-C has some really weird syntax. You get used to it after a while, but it scares newbies. Ruby has a much more mainstream syntax, especially if you use foo.bar('baz') instead of foo.bar 'baz'.
Objective-C uses header files. I get annoyed cutting'n'pasting method prototypes between .h and .m files. Ruby has none of that.
MacRuby is really cool, but it still not production ready (even on OS X), and it will not work on iPhone for several reasons:
It uses the Objective C garbage collector, which is not available on the iPhone
It depends on bridge support, which is not available on iPhone
It depends on the LLVM backend, which is awesome, but is not yet production quality for ARM
JITs don't work on the iPhone because of its security model (calls to mprotect() fail in most cases).
I expect over time some of these issues will be resolved, and at some point in the future things like MacRuby will be available on the iPhone, but that is probably several years away at a minimum. If you want to develop for the iPhone now, or foreseeable future, MacRuby is not a realistic option.
The benefits of Ruby are a less obnoxious messaging syntax that's far easier to read and type than tons of nested square brackets and far greater dynamism. The downside is generally execution speed and the way Ruby users tend to gravitate toward overusing its more obscure metaprogramming idioms thereby turning even simple projects into monkey-patched spaghetti.
You're never going to run it on an iPhone unless Apple decides to lift the no-background-processes limitations currently imposed, so if that's all you're interested in, don't bother.
I dabbled in some iPhone development and there seems to be two strategies:
use the iPhone specific libraries with ObjectiveC & XCode
use cross-platform libraries like OpenGL, OpenAL with C/C++ and an editor of your choice
Coming from the Windows/Linux C/C++ world, I took the second strategy and used Emacs and C/C++ for my app. I used a single ObjectiveC shim that passed messages into my application that was entirely C++. In theory, the main portion of it would run on other platforms if I replaced the outer wrapper that does iPhone specific stuff like allocation sound buffers, discovers file paths, etc.
So, what proportion of iPhone developers are embracing the XCode/ObjectiveC/iPhone-specific-libraries and what proportion are keeping that at a distance and writing more cross-platform-like code?
I think that when writing games you can get away with cross-platform libraries.
When writing anything other than games though, you will have to do a significant portion in Objective-C anyway. For that reason I personally think it is easier to do the entire app in Objective-C.