Home A - Z
Page Index

Blame

165205 Melisha Dsouza 2026-01-15 17:06:24 1 
# **iOS Coding Standard (Swift)**
2
3
### **1. Objective**
4
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.
5
6
### **2. Scope**
7
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.
8
9
### **3. Architecture & Project Structure**
10
Adopt **MVVM (Model-View-ViewModel)**, as it integrates seamlessly with both SwiftUI and UIKit (with Combine or async/await).
11
Maintain a consistent project folder structure, grouped by feature:
12
13
```
14
AppName/
15
├── Application/ // AppDelegate, SceneDelegate, Info.plist
16
├── Features/ // One folder per app feature (e.g.,
17
Profile, Home)
18
│ ├── Home/
19
│ │ ├── Model/ // HomeModels.swift
20
│ │ ├── View/ // HomeView.swift (SwiftUI) or
21
HomeViewController.swift (UIKit)
22
│ │ └── ViewModel/ // HomeViewModel.swift
23
│ ├── Profile/
24
│ │ ├── Model/
25
│ │ ├── View/
26
│ │ └── ViewModel/
27
├── Data/
28
│ ├── Network/ // APIService.swift, NetworkError.swift
29
│ ├── Persistence/ // CoreData, SwiftData,
30
KeychainService.swift
31
│ └── Models/ // Shared data models (e.g., User.swift)
32
├── Utilities/ // Helpers, Extensions, Constants.swift
33
├── Resources/ // Assets.xcassets, Localizable.strings
34
└── DI/ // Dependency Injection container (if used)
35
```
36
37
* **Key Principle**: Separate business logic from UI logic.
38
* **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`.
39
40
### **4. Naming Conventions**
41
Follow **Apple's API Design Guidelines** for clarity at the point of use.
42
43
| Element | Convention | Example |
44
| --------------------------- | -------------------------------- | -------------------------------------------------- |
45
| Types (Class, Struct, Enum) | `UpperCamelCase` | `UserProfileView`, `NetworkService` |
46
| Variables & Functions | `lowerCamelCase` | `var userName: String`<br>`func fetchUserData()` |
47
| Constants (Global) | `lowerCamelCase` | `let maxRetryCount = 3` |
48
| Booleans | Prefixed with `is`, `has`, `did` | `var isUserLoggedIn: Bool` |
49
| `@IBOutlet` (UIKit) | `lowerCamelCase` | `@IBOutlet var userNameLabel: UILabel` |
50
| `@IBAction` (UIKit) | `lowerCamelCase (verb first)` | `@IBAction func didTapSubmitButton(_ sender: Any)` |
51
52
**Reference**: [Apple's API Design Guidelines](https://www.swift.org/documentation/api-design-guidelines/)
53
54
### **5. Code Formatting & Style**
55
* **Indentation:** 4 spaces (or 2 if team agrees, but be consistent).
56
* **Maximum line length**: 120 characters (enforced by SwiftLint).
57
* Avoid unused imports, variables, or commented-out code.
58
* Add **Swift-DocC comments** `(///)` for all public classes, methods, and complex logic.
59
* Use `let` instead of `var` wherever possible for immutability.
60
* Use `final` on classes not intended for subclassing to improve performance.
61
**Learn more:** [Swift-DocC Documentation](https://developer.apple.com/documentation/docc)
62
63
### **6. UI/UX & Resource Management**
64
* Use **SwiftUI Stacks/Grid**s or **Auto Layout** (for UIKit) for flexible designs.
65
* No hardcoding.
66
* **Text**: Use `Localizable.strings` for all user-facing text.
67
* **Colors/Images:** Use the `Assets.xcassets catalog`.
68
* Use `private` for` @IBOutlet` and `@IBAction` to encapsulate view logic.
69
* Follow accessibility guidelines (e.g., `accessibilityLabel`, dynamic type support).
70
**Learn more:** [Using the Asset Catalog](https://developer.apple.com/documentation/xcode/managing-assets-with-asset-catalogs)
71
72
### **7. Networking & Data Handling**
73
* Use native `URLSession` with `async/await` for all REST APIs.
74
* `Combine` is acceptable for reactive streams.
75
* `Alamofire` is acceptable for complex networking needs if approved.
76
* Use SwiftData (preferred for new projects) or Core Data for local database storage.
77
* Parse JSON using the `Codable` protocol.
78
* Handle API responses using Swift's `Result` type or `async throws`.
79
* Avoid network calls on the main thread. Use `Task` or a`wait MainActor.run` to update UI.
80
**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)
81
82
### **8. Error Handling & Logging**
83
* Use Swift's error handling `(do-try-catch, throws)` for failable operations.
84
* Never use `print()` for logging.
85
* Use Apple's `OSLog (Logger)` framework for all logging.
86
* Swift
87
```
88
import OSLog
89
let logger = Logger(subsystem: "com.yourapp.feature", category:
90
"ViewModel")
91
logger.debug("Loading user profile...")
92
logger.error("Error loading user profile:
93
\(error.localizedDescription)")
94
```
95
* `OSLog logs` are automatically managed (not shown in release builds) and viewable in the Console app.
96
**Learn more:** [Logging in Swift with OSLog](https://developer.apple.com/documentation/os/logging)
97
98
### **9. Security & Performance**
99
* **Never store sensitive data** (tokens, passwords, PII) in `UserDefaults`. Use the **Keychain** services.
100
* Use `[weak self]` in closures to prevent **retain cycles** (memory leaks).
101
* Set "Optimization Level" to `-O` (Fastest, Smallest) in Release builds.
102
* Use Instruments (Leaks, Time Profiler) to find and fix performance issues.
103
Learn more: [Storing Data in the Keychain](https://developer.apple.com/documentation/security/keychain_services)
104
105
### **10. Testing**
106
* Write `XCTest` Unit Tests for ViewModels, business logic, and utility functions.
107
* Write `XCTest` UI Tests for critical user flows.
108
* Maintain at least 70% test coverage for core modules.
109
* Use **protocol-based mocking** and dependency injection to make code testable.
110
**Learn more:** [Testing with XCTest](https://developer.apple.com/documentation/xctest)
111
112
### **11. Automation & CI/CD Integration**
113
* Integrate static analysis tools:
114
* **SwiftLint**: Enforces formatting and style rules.
115
* **SwiftFormat**: (Optional) Automatically formats code.
116
* Use **Xcode's built-in "Analyze"** tool to find potential bugs and leaks.
117
* CI/CD (e.g.,** Xcode Cloud**, GitHub Actions) should run `XCTest` and `SwiftLint` and fail the build on violations.
118
**Learn more:** [Integrating SwiftLint with Xcode](https://github.com/realm/SwiftLint)
119
120
### **12. References**
121
* [The Swift Programming Language](https://docs.swift.org/swift-book/LanguageGuide/TheBasics.html) (Official Swift Book)
122
* [Apple API Design Guidelines](https://www.swift.org/documentation/api-design-guidelines/) (The most important reference)
123
* [Kodeco (formerly Ray Wenderlich) Style Guide](https://github.com/kodecocodes/swift-style-guide) (A popular community guide)