Apple Platforms Coding Conventions
| This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean. |
h1. OS X and and iOS Coding Conventions
Objective-C
ARC (Automated Reference Counting)
Qt uses manual reference counting, ARC usage is currently prohibited.
Rationale: ARC requires a 64-bit build. There is little benefit of using ARC for the 64-bit builds only since we still have to maintain the manual reference counting code paths. ARC can be used when Qt no longer support 32-bit builds.
Patching the Cocoa runtime
Qt does not patch or polyfill the Cocoa runtime using class_addMethod(). [There are some instances of this in Qt 5.3, but we do not want to expand the usage.]
Rationale: Using this technique to work around OS version differences would be convenient. However, as a library we want to be conservative and don't change the runtime. We also don't want to introduce another abstraction layer in addition to the version abstraction patterns already in Qt.
Use properties and dot notation
Use that instead of calling getters and setters. Cocoa and UIKit are doing the same. Use them in Qt's own Objective C classes as well. (We need to check which compiler versions, that we support, still need the synthesize directive + ivar declaration. Ideally, we should move away from that too).
Rationale: This is how Objective C works nowadays. It also adds the possibility of adding properties to classes through categories. Finally, it will ease the transition to ARC when 32-bit support is finally dropped.
OS Versions
We want Qt to work on new OS versions, including pre-releases. As platform developers we are not concerned about "official" support in the project, but would rather see Qt work right away. The main restriction is practical difficulties related to developing and testing on pre-release OS versions.
Dropping support for old versions is done on a semi-regular basis. Inputs are
- Market Share
- Is Apple still security-patching the version?
- Is it a maintenance burden?
There process of dropping support is gradual:
- Deploy-only (no binary package support). Compile-from-source is usually not a problem and a good way of testing compatibility.
- New features may not work on the old(est) platforms
- Deprecation in a minor release
- Removal in the next release.
Gradual loss of quality is not a goal.
QWebKit/WebEngine lives its own life depending on upstream support
We would like to move to a "the only version is the current version" world. (This is currently more true on iOS than OS X.)
Xcode version support
In general, if we support a given OS X version as a development platform then we support the most recent Xcode available for that version. Refer to the Xcode "wikipedia article":http://en.wikipedia.org/wiki/Xcode for a versions and requirements overview.
OS X and iOS code sharing
Both OS X and iOS set Q_OS_MAC. OS X sets Q_OS_OSX. iOS sets Q_OS_iOS. On the Qmake side this corresponds mac, osx, and ios.
Don't use Q_OS_MACX.
OS X and iOS share as much code as possible. This is done via the the static platformsupport library.
OS X / Cocoa
Use [NSApplication sharedApplication].
Rationale: While a little longer to type, [NSApplication sharedApplication] is type-safe an can save us from compiler errors.
Deployment
Qt binaries are forward compatible: Compile on 10.X and run on 10.X+.
Qt binaries are backwards compatible: Compile on 10.X and run on prior versions. How far back you can go depends on the Qt version in use. This is accomplished by compile-time and run-time version checks (weak linking). Grep for MAC_OS_X_VERSION_MAX_ALLOWED and QSysInfo::MacintoshVersion in the Qt source code to see the pattern in use.