What is the technical reason for ARC to be supported by iOS 4.0 and above only?
It is my understanding that it is a compiler feature, which merely inserts memory management related code automatically instead of requiring the developer to do so. From what I read the calls themselves remain the same - at least that's what Apples Transitioning to ARC Guide implies.
As such, it should not involve features that have not been present in previous versions of iOS, and indeed ARC does work with iOS 4.0 despite having been introduced later.
I'm asking this question out of curiosity and don't actually need to make ARC work with iOS 3.x.
It is for the same reason that automatic reference counting only supports 64-bit Snow Leopard as a minimum deployment target: ARC support requires certain features present only in a new enough version of the modern runtime. That modern runtime was introduced with iOS 4.0, so older iOS versions lack the runtime capable of handling some of the things required technically by ARC. If it were just keyed to OS versions, 32-bit Snow Leopard applications would be supported as well, but only the 64-bit runtime is the modern one there.
If you watch Apple's presentations from WWDC 2011, particularly the "Objective-C Advancements In-Depth," you'll see that a number of under-the-hood improvements have been made to speed up the retain / release process, as well as things like the faster #autoreleasepool. There's an entire section on runtime support in the LLVM ARC specification. These improvements require more than just compiler support.
We already had to use the modern runtime for features like automatic synthesis of instance variables (as explained in Apple's documentation), so this isn't a terrible surprise.
Even iOS 4.0 as a target lacks support for weak references, so there are clearly technical issues at play here. This isn't just a marketing strategy to drive developers to the newer versions, as has been asserted by others.
The docs of Apple states that the dealloc chaining to super is handled in runtime in the case of ARC.
The kind of a same question would be:
Why is NSRegularExpression only supported by iOS 4.0+ and Mac OS X 10.7(Lion)+?
You have fully working simulators of iOS 5.0(and 4.0 obviously) in Mac OS X 10.6.7(Snow Leopard) where you can easily use NSRegularExpression, but it's not supported by Mac OS X 10.6.7 itself.
And concerning your question: ARC was introduced with iOS 5.0. At that time there were not many iOS 3.x users anymore, so my opinion is that Apple was a bit too lazy to make ARC compatible with iOS 3.x.
My guess would be that the clang tool chain (required for ARC) does not build binaries compatible with iOS 3.x.
Also, there are a couple of C functions used in place of sending -retain and -release that might not be available in iOS 3.x
http://www.informit.com/articles/article.aspx?p=1745876
Related
I am creating a project in maverics(using xcode 5.1.1) ,for 64 bit its running fine but for 34 bit it is giving error.
while running on 34 bit getting this error "-fobjc-arc is not supported on platforms using the legacy runtime"
to remove above error disabled ARC,but i need ARC also
so is there any way to create a project in Maverics using ARC on 32 bit
The 64-bit transition guide for OSX states quite clearly that ARC on OSX is only supported on 64bit.
Applications that target OS X v10.7 and later should take advantage of automatic reference counting (ARC). This technology frees you from having to manually retain and release objects, and in so doing, often fixes latent bugs in applications.
ARC is supported only in the new Objective-C runtime, which is supported only in 64-bit applications. For this reason, most new development should be 64-bit.
I'm aware that with Xcode now, it is recommended to use ARC, however I've read a bit about it not being compatible with iOS 4.x, at least when using __weak. When I create an IBOutlet it gives the choice of weak or strong as the storage type, does this mean my application is limited to iOS 5 or above, or will it still run on an older iOS?
Definitely just use ARC. As you point out, if you elect to provide iOS 4.3 compatibility, you don't enjoy that one little benefit feature of weak variables, where they'd be automatically nil-ed for you when they're deallocated (but you don't have that feature in non-ARC code, so it's not like you're losing anything). And, yes, when you control-drag from Interface Builder to the .h file, it says you have only the strong and weak options, but in the latest Xcode, at least, if you have iOS 4.3 as a target and you choose weak, it will automatically create it for you as a __unsafe_unretained, so all is good.
In short, use ARC, even if you're targetting support for iOS 4.3, and your coding life will be considerably better than if you didn't use ARC. Even in iOS 4.3, you get so many wonderful ARC benefits. And if you are willing to use iOS 5.0 as your target deployment, then you enjoy the full benefits of ARC.
If you use Xcode 4.5, you do, admittedly lose support for armv6, the processor for the iPhone 3G and earlier, so your app will only support the iPhone 3GS and later.
No, ARC is just compiler feature. It's per file, so it wouldn't impact your existing code at all.
iOS version support depends on your Xcode version.
With the last version of Xcode (4.5) you can create apps for iOS 4.3 and higher. If you need to create apps for earlier versions of iOS (prior that 4.3) you need to install Xcode 4.4.1.
I am using Xcode 4.2 and building a game for iphone (from iOS 3.0 - 5.0). Does cocos2d support ARC? What modifications needs to be made to convert code written in previous versions?
If I use the strong and weak keywords for variables and set compiler to LLVM GCC 4.2, what will be the results? Is it a necessity to change compiler to 3.0 to support ARC?
Cocos2d v1.1 and v2.0 are compatible with ARC. However, the cocos2d code itself does not use ARC and there are no templates provided by cocos2d that you can use to start programming with ARC. You are required to add a seperate static library target for the cocos2d files yourself.
As Ankit pointed out, Tiny Tim Games made the necessary changes to a forked version of cocos2d-iphone to make it ARC compatible. These changes have been integrated into the development version and should be available in the cocos2d v2.x branch. I've since written a tutorial to enable ARC in a cocos2d (2.0) project.
It was said that cocos2d itself will be converted to use ARC internally in v2.1 or v2.2.
It's important to note that there are no plans to officially support ARC in the cocos2d v1.x branch because the v1.x line is supposed to remain backwards compatible with 1st generation devices and iOS 3.x. But general ARC compatibility has been added to v1.1.
Kobold2D fully supports ARC and has it enabled in all 15 template projects for almost two months now. Kobold2D uses the latest stable versions of cocos2d-iphone 1.x and 2.x. Just start a new Kobold2D project and you're set to work with cocos2d and ARC.
Even though Cocos2d does not support arc but there is way in which you can use both of them together, and that is by cross project referencing. You can learn how to do it by refering this.. cocos2d and ARC
Even easier, just get my cocos2d-ARC template here: https://github.com/Elland/Cocos2d-iphone-ARC-template hassle free, just rename the project to your desired name and you're set :)
This may be subjective but, if I'm writing some code in Objective-C 2.0 and I'm writing about it on, for example, Twitter or in a blog, then should I refer to it as Objective-C 2.0 or just Objective-C?
The answer is actually not so subtle. Objective-C 2.0 was a sort of moniker used to identify the version of Objective-C that was released a couple of years ago at WWDC.
However, there are actually several different things that could be construed as Objective-C 2.0.
There is the API, the ABI, architecture, and platform.
Across all of the three, Objective-C 2.0 can refer to the specific set of syntactic features available and it is [almost] completely the same across all platforms and architectures. The one difference is synthesized ivars; only available on 64 bit Mac OS X and iPhone (but not in the simulator).
The ABI -- or Application Binary Interface -- refers to something slightly different; the way stuff is laid out in memory and how exceptions are handled. Exceptions are actually different between 32 bit Mac OS X, 64 bit Mac OS X, and iPhone. 32 bit Mac OS X has very expensive exception setup, but cheap throws. 64 bit Mac OS X has very cheap exception setup and slightly more expensive throws (and they are C++ compatible). iPhone has C++ compatible exceptions, but not quite as cheap setup.
Then there is the architecture; there are subtle differences between the variants of Intel, PPC, and arm CPUs.
Finally, platform; there are additional differences -- mostly subtle, the larger quantified by the above descriptions -- between the platforms.
So, Objective-C 2.0 doesn't really mean much. It is just Objective-C and the subtleties of the language are determined by the target platform, architecture, and operating system version. As well, the release of the Xcode toolchain can impact compilation in that certain bugs may be fixed that might allow additional features to be used in additional circumstances.
So, no, really.... just use Objective-C.
Unless what you are writing about is specific to the 2.0 version of the language, use just Objective-C.
With regards to stack overflow specifically, prefer objective-c to objective-c-2.0 because few people follow the objective-c-2.0 tag
Use Objective-C 2.0. Although you do not have to, its clearer. Its so people know you are talking about 2.0.
Objective-C 2.0 has some new enhancements:
garbage collection
fast enumeration: for..in
properties
thread synchronization: #synchronized(self)
#try/#catch/#finally/#throw exception
handling
I'm interested in using Objective-C 2.0 as a language to program portable code across multiple operating system platforms - while avoiding frameworks such as OpenStep or GNUStep.
However, though gcc 3.4.5 on Windows will parse the syntax of using #try/#catch/#finally/#throw exception handling when compiling with -fobjc-exceptions, it still generates this error:
error: storage size of '_stackExceptionData' isn't known
Is there any support of Objective-C 2.0 features on operating systems other than Mac OS X v10.3 and later?
Quote from Cocotron gets some Objective-C 2.0 support via gcc 4.3.0:
Recent Cocotron patches by Johannes
also completely enable #try/#catch
which had been present in the compiler
but needed runtime support.
www.cocotron.org about what Cocotron is:
The Cocotron is an open source project
which implements an Objective-C API
similar to that described by Apple
Inc.'s Cocoa documentation. This
includes the AppKit, Foundation,
Objective-C runtime and support APIs
such as CoreGraphics and
CoreFoundation
So if you are interested in cross-platform obj-c development Cocotron might be interesing for you ...
Apple uses a variant/fork of the standard GCC, in which Objective-C 2.0 support is built-in. As far as I know, none of the Objective-C 2.0 features exist in the standard GCC.
I'm not exactly sure about exception handling, but the other features you listed, unfortunately, are not available on other platforms.
P.S. GNUstep (and Cocoa) is an implementation of OpenStep, which is a specification.
The features in question require both compiler and runtime support and so, while it is certainly possible to build a compiler that supports the syntax (LLVM/Clang comes to mind) many of these features call out to the Objective-C runtime and, to my knowledge (and quick double checking on Google) the GNU runtime doesn't have the necessary support.
There's a cross-platform runtime as part of the Étoilé project which supports Objective-C exceptions (and #synchronized as a result) and, AFAIK, properties:
http://www.nabble.com/ANN:-New-Objective-C-Runtime-td13648692.html
By the way, Objective-C language exceptions aren't an Objective-C 2.0 feature. They've been in the NeXT runtime since Panther.
#try/#catch/#finally/#throw actually predates Objective-C 2.0. It was introduced with MacOSX 10.3 while Objective-C 2.0 was introduced with 10.5 (Leopard).