WebResourceLoadDelegate in OSX 10.11 docs is "Available in OS X v10.2 through OS X v10.10.3" . What does it means ?
It means that WebResourceLoadDelegate informal protocol has been removed in OS X 10.11. Instead, the new WebResourceLoadDelegate formal protocol has been introduced at the same time (or maybe earlier, I'm not sure) to provide the same API. Though the new protocol has yet to be documented, you can use it freely.
Related
I'm trying to make an application that can share data between OS X and iOS using the multipeer connectivity framework. From what I understand I need two applications, one for OS X and one for iOS if I want them to communicate data both ways. Would they both have to be made with obj-c or can I make the iOS app using swift and the OS X with obj-c?
You can use either language on either platform. The multipeer framework can be called from Swift or Objective C and any combination will work.
In fact, it is possible to use the exact same code on both platforms by setting up a workspace with targets for iOS and OSX and common code included in both.
I have an app I've been developing under 10.9 using the 10.9 SDK, and I want to distribute it to my friends who are running 10.8. I know I can't guarantee it'll work there without finding an OS X 10.8 system (maybe in a virtual machine) and running it there, but is there any way I can check that I'm not using any 10.9-only APIs? Or even get a list of 10.9-only APIs that my application uses?
My understanding is that:
"Deployment Target" doesn't do this -- this just sets the LC_VERSION_MIN_MACOSX, so that if you tried to run it on an earlier version of OS X, it would refuse to even start.
"Base SDK" doesn't do this -- this is the version of the API it's compiled with. Some features added in newer versions of the SDK are available even on older versions of OS X at runtime (e.g., NSArray -firstObject).
Xcode's static analysis is pretty good at identifying the source of symbols (classes / methods) that I use, so it seems like this should be fairly easy to do, but I don't know how to do it.
"Base SDK" does what you want in a legalistic sense. Yes you may get some false negatives - for methods like firstObject - but better those than false positives. You can check any reported non-existant APIs and put in code to check dynamically (respondsToSelector:) and code defensively for those cases, or ignore them if you must and are really sure they are available.
Are the new Objective-C literal syntax additions (e.g. #3.14) only available when developing for OS X and not iOS? That's what the Xcode update 4.4 seems to suggest. If so, why?
No, they’re also available in the 4.5 preview and work on iOS.
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
What is the difference between carbon and cocoa ? For what type of applications we should use carbon and for what type of applications we should use cocoa ? Which is the best of both for developing applications in Mac OS ?
Short answer: For a new application, use Cocoa. Some legacy code may still use Carbon and if you don't need any new capabilities, it will continue to work.
Cocoa has an Objective-C API, and can be accessed from C and C++ code easily. Carbon is a pure-C API. There are both Cocoa and Carbon bindings for many other popular languages, but there are often some limitations.
Carbon is evolved from the original API for the original Apple Macintosh (and Apple Lisa) in the early 1980s. Specifically, when Mac OS X was released, Apple was unable to support some of the legacy Mac OS API functions, but provided a subset of legacy APIs called "Carbon", to ease the transition for developers who had pre-Mac OS X applications. They added thousands of new APIs and continued to fully support Carbon for several years, before finally deprecating it more recently. They have always said that Carbon is a dead-end and all developers should move to Cocoa.
Cocoa has evolved from the NextStep framework that Apple acquired and used as the basis to create Mac OS X. It's the "native" API for Mac OS X and the only way to access some of the newest capabilities.
Carbon was created to ease the movement to and from Mac OS 8 and 9. If your code needs to run under OS 8 or 9, then Carbon is the way to go. (Source)
However, if your software is designed for OS X, then you should emphasize Cocoa over Carbon.
Carbon is deprecated (it does not and will not exist in 64-bit).
For new application development, use Cocoa (I'm talking about native OS X application development the Apple-sactioned way. Obviously other alternative choices exist, such as Java, Python, Ruby, etc, which may be effective depending on your project type if a native UI is not required)
It depends on the scope and the functions of the application you're going to develop.
I'm going to be building an application that makes use of MacInTalk capabilities and the new OSX 10.7 international set of voices. The official documentation states that fine-tuning is provided only under Carbon APIs, while Cocoa APIs are more limited.
Specifically, these Speech channel settings are alterable via API in Carbon: rate, pitch, pitch modulation and volume attributes. This possibility seems to be unavailable via Cocoa.
On a side note, the most updated documentation of the Speech Synthesis Programming Guide dates back to 2006 and it might be the case that Cocoa access to the same functionality is out there, but it's not yet documented.