Commit 165205
2026-01-15 17:06:24 Melisha Dsouza: iOS Coding Standard (Swift)| /dev/null .. CMMI/Guidelines/Coding Standard/iOS Coding Standard (Swift).md | |
| @@ 0,0 1,123 @@ | |
| + | # **iOS Coding Standard (Swift)** |
| + | |
| + | ### **1. Objective** |
| + | To ensure all iOS applications developed at [Your Company Name] follow a consistent, high-quality, and maintainable coding approach that aligns with organizational and industry best practices. |
| + | |
| + | ### **2. Scope** |
| + | This document applies to all iOS, iPadOS, and macOS development projects using **Swift** (and Objective-C for interoperability), developed in **Xcode**, and maintained under [Your Company Name]'s repositories. |
| + | |
| + | ### **3. Architecture & Project Structure** |
| + | Adopt **MVVM (Model-View-ViewModel)**, as it integrates seamlessly with both SwiftUI and UIKit (with Combine or async/await). |
| + | Maintain a consistent project folder structure, grouped by feature: |
| + | |
| + | ``` |
| + | AppName/ |
| + | ├── Application/ // AppDelegate, SceneDelegate, Info.plist |
| + | ├── Features/ // One folder per app feature (e.g., |
| + | Profile, Home) |
| + | │ ├── Home/ |
| + | │ │ ├── Model/ // HomeModels.swift |
| + | │ │ ├── View/ // HomeView.swift (SwiftUI) or |
| + | HomeViewController.swift (UIKit) |
| + | │ │ └── ViewModel/ // HomeViewModel.swift |
| + | │ ├── Profile/ |
| + | │ │ ├── Model/ |
| + | │ │ ├── View/ |
| + | │ │ └── ViewModel/ |
| + | ├── Data/ |
| + | │ ├── Network/ // APIService.swift, NetworkError.swift |
| + | │ ├── Persistence/ // CoreData, SwiftData, |
| + | KeychainService.swift |
| + | │ └── Models/ // Shared data models (e.g., User.swift) |
| + | ├── Utilities/ // Helpers, Extensions, Constants.swift |
| + | ├── Resources/ // Assets.xcassets, Localizable.strings |
| + | └── DI/ // Dependency Injection container (if used) |
| + | ``` |
| + | |
| + | * **Key Principle**: Separate business logic from UI logic. |
| + | * **Avoid "Massive View Controllers."** `ViewControllers (UIKit)` or `Views` (SwiftUI) should be "dumb" and only responsible for displaying data and forwarding user events to the `ViewModel`. |
| + | |
| + | ### **4. Naming Conventions** |
| + | Follow **Apple's API Design Guidelines** for clarity at the point of use. |
| + | |
| + | | Element | Convention | Example | |
| + | | --------------------------- | -------------------------------- | -------------------------------------------------- | |
| + | | Types (Class, Struct, Enum) | `UpperCamelCase` | `UserProfileView`, `NetworkService` | |
| + | | Variables & Functions | `lowerCamelCase` | `var userName: String`<br>`func fetchUserData()` | |
| + | | Constants (Global) | `lowerCamelCase` | `let maxRetryCount = 3` | |
| + | | Booleans | Prefixed with `is`, `has`, `did` | `var isUserLoggedIn: Bool` | |
| + | | `@IBOutlet` (UIKit) | `lowerCamelCase` | `@IBOutlet var userNameLabel: UILabel` | |
| + | | `@IBAction` (UIKit) | `lowerCamelCase (verb first)` | `@IBAction func didTapSubmitButton(_ sender: Any)` | |
| + | |
| + | **Reference**: [Apple's API Design Guidelines](https://www.swift.org/documentation/api-design-guidelines/) |
| + | |
| + | ### **5. Code Formatting & Style** |
| + | * **Indentation:** 4 spaces (or 2 if team agrees, but be consistent). |
| + | * **Maximum line length**: 120 characters (enforced by SwiftLint). |
| + | * Avoid unused imports, variables, or commented-out code. |
| + | * Add **Swift-DocC comments** `(///)` for all public classes, methods, and complex logic. |
| + | * Use `let` instead of `var` wherever possible for immutability. |
| + | * Use `final` on classes not intended for subclassing to improve performance. |
| + | **Learn more:** [Swift-DocC Documentation](https://developer.apple.com/documentation/docc) |
| + | |
| + | ### **6. UI/UX & Resource Management** |
| + | * Use **SwiftUI Stacks/Grid**s or **Auto Layout** (for UIKit) for flexible designs. |
| + | * No hardcoding. |
| + | * **Text**: Use `Localizable.strings` for all user-facing text. |
| + | * **Colors/Images:** Use the `Assets.xcassets catalog`. |
| + | * Use `private` for` @IBOutlet` and `@IBAction` to encapsulate view logic. |
| + | * Follow accessibility guidelines (e.g., `accessibilityLabel`, dynamic type support). |
| + | **Learn more:** [Using the Asset Catalog](https://developer.apple.com/documentation/xcode/managing-assets-with-asset-catalogs) |
| + | |
| + | ### **7. Networking & Data Handling** |
| + | * Use native `URLSession` with `async/await` for all REST APIs. |
| + | * `Combine` is acceptable for reactive streams. |
| + | * `Alamofire` is acceptable for complex networking needs if approved. |
| + | * Use SwiftData (preferred for new projects) or Core Data for local database storage. |
| + | * Parse JSON using the `Codable` protocol. |
| + | * Handle API responses using Swift's `Result` type or `async throws`. |
| + | * Avoid network calls on the main thread. Use `Task` or a`wait MainActor.run` to update UI. |
| + | **Learn more: **[Fetching data with URLSession and async/await](https://www.google.com/search?q=https://www.hackingwithswift.com/books/ios-swiftui/downloading-json-from-the-web-with-urlsession-and-swiftui) |
| + | |
| + | ### **8. Error Handling & Logging** |
| + | * Use Swift's error handling `(do-try-catch, throws)` for failable operations. |
| + | * Never use `print()` for logging. |
| + | * Use Apple's `OSLog (Logger)` framework for all logging. |
| + | * Swift |
| + | ``` |
| + | import OSLog |
| + | let logger = Logger(subsystem: "com.yourapp.feature", category: |
| + | "ViewModel") |
| + | logger.debug("Loading user profile...") |
| + | logger.error("Error loading user profile: |
| + | \(error.localizedDescription)") |
| + | ``` |
| + | * `OSLog logs` are automatically managed (not shown in release builds) and viewable in the Console app. |
| + | **Learn more:** [Logging in Swift with OSLog](https://developer.apple.com/documentation/os/logging) |
| + | |
| + | ### **9. Security & Performance** |
| + | * **Never store sensitive data** (tokens, passwords, PII) in `UserDefaults`. Use the **Keychain** services. |
| + | * Use `[weak self]` in closures to prevent **retain cycles** (memory leaks). |
| + | * Set "Optimization Level" to `-O` (Fastest, Smallest) in Release builds. |
| + | * Use Instruments (Leaks, Time Profiler) to find and fix performance issues. |
| + | Learn more: [Storing Data in the Keychain](https://developer.apple.com/documentation/security/keychain_services) |
| + | |
| + | ### **10. Testing** |
| + | * Write `XCTest` Unit Tests for ViewModels, business logic, and utility functions. |
| + | * Write `XCTest` UI Tests for critical user flows. |
| + | * Maintain at least 70% test coverage for core modules. |
| + | * Use **protocol-based mocking** and dependency injection to make code testable. |
| + | **Learn more:** [Testing with XCTest](https://developer.apple.com/documentation/xctest) |
| + | |
| + | ### **11. Automation & CI/CD Integration** |
| + | * Integrate static analysis tools: |
| + | * **SwiftLint**: Enforces formatting and style rules. |
| + | * **SwiftFormat**: (Optional) Automatically formats code. |
| + | * Use **Xcode's built-in "Analyze"** tool to find potential bugs and leaks. |
| + | * CI/CD (e.g.,** Xcode Cloud**, GitHub Actions) should run `XCTest` and `SwiftLint` and fail the build on violations. |
| + | **Learn more:** [Integrating SwiftLint with Xcode](https://github.com/realm/SwiftLint) |
| + | |
| + | ### **12. References** |
| + | * [The Swift Programming Language](https://docs.swift.org/swift-book/LanguageGuide/TheBasics.html) (Official Swift Book) |
| + | * [Apple API Design Guidelines](https://www.swift.org/documentation/api-design-guidelines/) (The most important reference) |
| + | * [Kodeco (formerly Ray Wenderlich) Style Guide](https://github.com/kodecocodes/swift-style-guide) (A popular community guide) |