{"id":3406,"url":"https://github.com/jphong1111/awesome-ios-developer","name":"awesome-ios-developer","description":"List of awesome iOS \u0026 Swift stuff!!","projects_count":148,"last_synced_at":"2026-08-06T18:00:22.712Z","repository":{"id":38202550,"uuid":"356388461","full_name":"jphong1111/awesome-ios-developer","owner":"jphong1111","description":"List of awesome iOS \u0026 Swift stuff!!","archived":false,"fork":false,"pushed_at":"2025-07-27T04:43:00.000Z","size":10600,"stargazers_count":848,"open_issues_count":6,"forks_count":48,"subscribers_count":7,"default_branch":"main","last_synced_at":"2026-07-18T11:03:40.876Z","etag":null,"topics":["apple","awesome","awesome-list","awesome-readme","ios","ios-app","ios-swift","swift","swift5","useful-knowledge","usefull","usefull-materials"],"latest_commit_sha":null,"homepage":"","language":"Swift","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/jphong1111.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2021-04-09T20:16:11.000Z","updated_at":"2026-07-08T23:24:19.000Z","dependencies_parsed_at":"2025-12-14T19:00:49.649Z","dependency_job_id":null,"html_url":"https://github.com/jphong1111/awesome-ios-developer","commit_stats":null,"previous_names":[],"tags_count":1,"template":false,"template_full_name":null,"purl":"pkg:github/jphong1111/awesome-ios-developer","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jphong1111%2Fawesome-ios-developer","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jphong1111%2Fawesome-ios-developer/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jphong1111%2Fawesome-ios-developer/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jphong1111%2Fawesome-ios-developer/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/jphong1111","download_url":"https://codeload.github.com/jphong1111/awesome-ios-developer/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jphong1111%2Fawesome-ios-developer/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":36343627,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-08-06T04:43:03.162Z","status":"ssl_error","status_checked_at":"2026-08-06T04:43:02.660Z","response_time":54,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"created_at":"2024-01-05T21:53:24.999Z","updated_at":"2026-08-06T18:00:22.713Z","primary_language":null,"list_of_lists":false,"displayable":true,"categories":["Core Bluetooth","VIPER","Coding convention","📦 Dependencies and Modularization","Network Layer","JSONSerialization","Rxswift","Screen Layout Programmatically","Carthage","📚 Learning Resources","🔄 CI/CD and Team Workflow","TestFlight","iOS icon","Design Collaboration Tools","Vector Graphic Editors","🧑‍💻 Swift and Xcode","📱 Application and UI Fundamentals","Jenkins","UIdesign Inspiration","Useful Blogs for iOS Developers","HIG(Human Interface Guidelines)","CircleCI","🚀 Start Here","Three Steps(Iterative) in BDD","Jira","Fastlane","App Life Cycle","ViewController Life Cycle","Design Pattern","Adaptor","Delegation","Dependency Injection","Factory","Observer","Swift DocC","Clean Architecture","Reducer","Repository Pattern","Useful Cheat Sheet for SwiftUI","Design Tools","Useful Sites","xcframework","Email, Message, Call","Image Picker","Image Downloader","Location Manager","Various API Site","NotificationCenter","UserDefaults","Store Object","Core Data Stack","Relationships","Dependency/Package Manager","Localization","Useful for Localization","Accessibility","Thread Safety","DispatchGroup","DispatchWorkItem","Operation","OperationQueue","Five Factor Testing","2. Symbolic Breakpoint","Check build time in Xcode","Robot Testing","Xcode Cloud","Set Up","Local Notification","APNs Usage","Combine","RxCombine","Keychain","SSL Pinning","Using Alamofire 5","Cryptography","Biometric Access","Objective-C","Bridging Header","How to submit your app to the AppStore","iOS Version Adoption Tracker","Compare Changes in Swift Version","Managing Xcode Space","Use VIM in Xcode","Write README.md","🌟 GitHub Stargazers","🧩 System Capabilities","💾 Persistence","🔐 Security and Privacy","Show Preview in UIKit(Build UI with Code Base) 👍 👍 👍 👍 👍","Coordinator","Danger","Roadmap for iOS Developer","MVVM","🧭 State, Architecture, and Navigation","Online Swift Playground","JSON","🌐 Networking","⚡ Concurrency","🧪 Testing","🐛 Debugging, Performance, and Observability","♿ Accessibility and Localization","🚢 Distribution and Monetization","🧱 Legacy Code and Interoperability","Author"],"sub_categories":["Delete Rules","MVC vs MVVM","Swift Lint","Useful packages and tools","Usage","JSON Parser Library","Environment Variable","Modularization","Apple and Swift","Privacy","Swift Style Guide","Community","Swift","SwiftUI","Xcode","Pure Swift Application?","The default stack","2. Detach debugger in **Edit Scheme**","Design","Example","Type of Dependency Injection","KVO","KVC","When do we use UserDafaults","global()","Relative Stuff","Core Data","Keychain and cryptography","UIKit","Style and static analysis","Common patterns","JSON parser extension for Chrome","Navigation","Application lifecycle","File system","StoreKit testing","Performance","Logging and metrics","Accessibility","Localization","Transport security and pinning","Code signing","App Store","StoreKit and subscriptions","Objective-C","Discovery"],"readme":"# Awesome iOS Developer\n\n\u003cp align=\"center\"\u003e\n  \u003ca href=\"https://awesome.re\"\u003e\n    \u003cimg alt=\"Awesome\" src=\"https://awesome.re/badge.svg\"\u003e\n  \u003c/a\u003e\n\u003c/p\u003e\n\n\u003cp align=\"center\"\u003e\n  A practical, opinionated field guide for building high-quality iOS apps with Swift.\n\u003c/p\u003e\n\nThis repository is a map, not a checklist.\nStart with the fundamentals, build a small app end to end, and return to the deeper topics when a real problem gives them context.\n\nThe guide favors first-party frameworks, official documentation, measurable engineering practices, and dependencies that solve a demonstrated need.\nIt also keeps UIKit, Objective-C interoperability, Core Data, Combine, and older package managers visible because production iOS work often includes mature codebases.\n\n## 🔎 Contents\n\n- [Start Here](#-start-here)\n- [Swift and Xcode](#-swift-and-xcode)\n- [Application and UI Fundamentals](#-application-and-ui-fundamentals)\n- [State, Architecture, and Navigation](#-state-architecture-and-navigation)\n- [Concurrency](#-concurrency)\n- [Networking](#-networking)\n- [Persistence](#-persistence)\n- [System Capabilities](#-system-capabilities)\n- [Dependencies and Modularization](#-dependencies-and-modularization)\n- [Testing](#-testing)\n- [Debugging, Performance, and Observability](#-debugging-performance-and-observability)\n- [Accessibility and Localization](#-accessibility-and-localization)\n- [Security and Privacy](#-security-and-privacy)\n- [CI/CD and Team Workflow](#-cicd-and-team-workflow)\n- [Distribution and Monetization](#-distribution-and-monetization)\n- [Legacy Code and Interoperability](#-legacy-code-and-interoperability)\n- [Learning Resources](#-learning-resources)\n- [Contributing](#-contributing)\n- [Author](#author)\n\n## 🚀 Start Here\n\n### A sensible learning order\n\n| Stage | Learn | Build |\n| --- | --- | --- |\n| 1. Language | Swift syntax, value and reference semantics, protocols, generics, optionals, errors, and collections | A command-line or playground model |\n| 2. Tools | Xcode, Simulator, Git, breakpoints, schemes, build settings, and Swift Package Manager | A small app that builds from a clean checkout |\n| 3. Interface | SwiftUI, UIKit basics, layout, navigation, state, and the Human Interface Guidelines | A multi-screen app with loading, empty, error, and content states |\n| 4. Data | `Codable`, `URLSession`, persistence, caching, and dependency injection | An app that works with both remote and local data |\n| 5. Reliability | Swift concurrency, unit tests, UI tests, accessibility, localization, and observability | A tested feature that handles cancellation and failure |\n| 6. Delivery | Code signing, CI, TestFlight, privacy declarations, and App Store review | A beta build delivered to testers |\n\n### The default stack\n\nUse this as a starting point, not as a rule that every app must follow.\n\n| Need | Start with | Reach for something else when |\n| --- | --- | --- |\n| UI | [SwiftUI](https://developer.apple.com/documentation/swiftui) | UIKit offers required control, platform coverage, or integration |\n| Imperative UI and mature apps | [UIKit](https://developer.apple.com/documentation/uikit) | SwiftUI clearly reduces complexity for the feature |\n| Concurrency | Swift `async`/`await`, tasks, actors, and `Sendable` | A lower-level primitive is justified by measurement or interoperability |\n| Networking | `URLSession`, `Codable`, and HTTP caching | The app has a proven need for a networking abstraction |\n| Preferences | `UserDefaults` or SwiftUI app storage | The data is sensitive, relational, large, or user-created |\n| Secrets | [Keychain Services](https://developer.apple.com/documentation/security/keychain_services) | A server should own the secret instead of the app |\n| Structured persistence | [SwiftData](https://developer.apple.com/documentation/swiftdata) | Core Data better fits deployment targets, migrations, or an existing store |\n| Unit tests | [Swift Testing](https://developer.apple.com/documentation/testing) | Existing XCTest coverage or an XCTest-only capability makes migration unnecessary |\n| UI and performance tests | [XCTest and XCUITest](https://developer.apple.com/documentation/xctest) | A focused third-party tool provides measurable value |\n| Dependencies | [Swift Package Manager](https://docs.swift.org/swiftpm/documentation/packagemanagerdocs/) | A legacy dependency is only distributed another way |\n| Logging | [`Logger`](https://developer.apple.com/documentation/os/logging) and unified logging | A backend observability product is required |\n\n### What “production ready” means\n\n- The app handles loading, empty, offline, error, cancellation, and retry states deliberately.\n- The main thread stays responsive and shared mutable state has an explicit isolation strategy.\n- Tests protect important behavior, while analytics, logs, and crash reports make failures diagnosable.\n- Accessibility, localization, privacy, and security are part of feature design rather than release-week cleanup.\n- CI can reproduce the build from a clean checkout.\n- A human can explain every dependency, permission, entitlement, and piece of collected data.\n\n## 🧑‍💻 Swift and Xcode\n\n### Swift\n\n- [The Swift Programming Language](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/) is the canonical language guide.\n- [Swift API Design Guidelines](https://www.swift.org/documentation/api-design-guidelines/) explains how Swift APIs should read at the call site.\n- [Swift Evolution](https://www.swift.org/swift-evolution/) records accepted and proposed language changes.\n- [Swift Forums](https://forums.swift.org/) is the best place to understand language design and implementation discussions.\n\nFocus on these concepts before collecting framework recipes:\n\n- Value semantics, copy-on-write behavior, identity, and ownership.\n- Optionals and error propagation without force-unwrapping normal failure states.\n- Protocols and generics for real substitution, not abstraction for its own sake.\n- Access control and module boundaries.\n- Closures, capture semantics, and avoiding accidental retain cycles.\n- `async`/`await`, actor isolation, `Sendable`, cancellation, and task lifetime.\n- Memory ownership with strong, weak, and unowned references.\n\n### Style and static analysis\n\nConsistency matters more than allegiance to one style guide.\nAutomate rules that are objective and leave design judgment to review.\n\n- [Swift.org API Design Guidelines](https://www.swift.org/documentation/api-design-guidelines/)\n- [Google Swift Style Guide](https://google.github.io/swift/)\n- [SwiftLint](https://github.com/realm/SwiftLint)\n- [swift-format](https://github.com/swiftlang/swift-format)\n\nDo not make a build depend on a developer’s globally installed formatter or linter without documenting and pinning the expected version.\nSwift Package plugins, a repository tool installer, or CI-managed tooling make clean checkouts more reproducible.\n\n### Xcode\n\nLearn the tool instead of treating it as a Run button.\n\n- Targets describe products that Xcode builds.\n- Schemes describe actions such as Run, Test, Profile, Analyze, and Archive.\n- Build configurations describe groups of settings such as Debug and Release.\n- `.xcconfig` files keep build settings reviewable and reduce configuration drift.\n- Test plans organize test configurations, languages, locales, sanitizers, and execution policies.\n- The Organizer surfaces archives, crashes, hangs, energy use, and distributed performance data.\n\nUseful official references:\n\n- [Xcode documentation](https://developer.apple.com/documentation/xcode)\n- [Xcode release notes](https://developer.apple.com/documentation/xcode-release-notes)\n- [Sample code](https://developer.apple.com/documentation/samplecode)\n- [WWDC videos](https://developer.apple.com/videos/)\n\n### Git and repository hygiene\n\n- Commit one coherent change at a time.\n- Keep generated files, local user data, build products, and credentials out of source control.\n- Review `Package.resolved` changes as dependency changes, not noise.\n- Prefer small pull requests with a clear purpose, validation evidence, and rollback path.\n- Protect the default branch with required reviews and required CI checks.\n\n## 📱 Application and UI Fundamentals\n\n### Application lifecycle\n\nA modern app may use SwiftUI lifecycle APIs, UIKit lifecycle APIs, or both.\n\n- SwiftUI apps define an entry point with the [`App`](https://developer.apple.com/documentation/swiftui/app) protocol and organize UI through scenes.\n- UIKit apps use `UIApplicationDelegate`, `UISceneDelegate`, windows, and view controllers.\n- Background execution is constrained by the system, so save durable state when it changes instead of relying on termination callbacks.\n- Scene phase changes are signals to pause, resume, refresh, or persist work, not guarantees about future lifecycle events.\n\n### SwiftUI\n\nSwiftUI is Apple’s declarative UI framework across Apple platforms.\nIts core skill is not memorizing modifiers; it is understanding identity, data flow, layout proposals, navigation state, and update behavior.\n\nLearn:\n\n- View identity and the difference between view values and stored model state.\n- `@State`, bindings, environment values, and the Observation framework.\n- `NavigationStack`, sheets, popovers, alerts, and state-driven presentation.\n- Lists, grids, custom layouts, animation, gestures, focus, and keyboard behavior.\n- Previews as a fast feedback tool rather than a substitute for tests.\n- UIKit interoperability through representable types and hosting controllers.\n\nRecommended references:\n\n- [SwiftUI documentation](https://developer.apple.com/documentation/swiftui)\n- [SwiftUI tutorials](https://developer.apple.com/tutorials/swiftui)\n- [Managing model data in your app](https://developer.apple.com/documentation/swiftui/managing-model-data-in-your-app)\n- [SwiftUI performance](https://developer.apple.com/documentation/xcode/understanding-and-improving-swiftui-performance)\n\n### UIKit\n\nUIKit remains important for mature applications, specialized controls, established navigation stacks, and APIs that expose UIKit-first integration points.\n\nLearn:\n\n- View-controller containment and presentation.\n- Auto Layout, intrinsic content size, content hugging, and compression resistance.\n- Collection views and diffable data sources.\n- Trait collections, adaptive layout, Dynamic Type, and appearance changes.\n- Reuse, prefetching, cell configuration, and scrolling performance.\n- Responder-chain, event, focus, and keyboard behavior.\n\nRecommended references:\n\n- [UIKit documentation](https://developer.apple.com/documentation/uikit)\n- [View controller programming guide](https://developer.apple.com/library/archive/featuredarticles/ViewControllerPGforiPhoneOS/)\n- [Auto Layout guide](https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/AutolayoutPG/)\n\n### Design\n\nThe [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/) should be the first design reference.\nRespect platform behavior before creating custom interaction patterns.\n\nDesign and asset tools:\n\n- [SF Symbols](https://developer.apple.com/sf-symbols/)\n- [Figma](https://www.figma.com/)\n- [Sketch](https://www.sketch.com/)\n- [Mobbin](https://mobbin.com/) for product pattern research\n- [App Icon Generator](https://www.appicon.co/) for asset preparation\n\nCheck every important screen with:\n\n- Small and large devices.\n- Portrait and landscape when supported.\n- Light and dark appearances.\n- Larger accessibility text sizes.\n- Right-to-left layout.\n- Long translated strings.\n- Reduced motion and increased contrast.\n- Offline, empty, loading, and failure states.\n\n## 🧭 State, Architecture, and Navigation\n\nArchitecture should make change safer.\nIt should not exist to maximize the number of folders, protocols, or diagrams.\n\n### Start with boundaries\n\nFor a small feature, three responsibilities are often enough:\n\n1. Presentation renders state and forwards user intent.\n2. Domain logic decides what the feature means and how state changes.\n3. Data access talks to remote services, persistence, and system APIs.\n\nKeep dependencies pointing inward toward policy and domain behavior.\nCreate protocols at boundaries where substitution, testing, or multiple implementations are real requirements.\n\n### Dependency injection\n\nInitializer injection should be the default because it makes dependencies explicit and allows immutable storage.\nProperty and method injection are useful when lifecycle or framework integration requires them.\nA composition root should assemble the concrete dependency graph near the application entry point.\n\nAvoid using a service locator or global singleton as invisible dependency injection.\nShared stateless services can be reasonable, but shared mutable state needs explicit ownership and isolation.\n\n### Common patterns\n\n| Pattern | Useful when | Watch for |\n| --- | --- | --- |\n| MVC | The feature is small and framework conventions already provide the separation | Massive view controllers and business logic tied to UIKit |\n| MVVM | Presentation state and transformations deserve a testable model | View models that become an entire application layer |\n| Coordinator or Router | Navigation policy is complex or reused | Navigation abstractions that mirror UIKit without simplifying it |\n| Reducer or unidirectional flow | State transitions, effects, and replayable tests are valuable | Boilerplate for simple screens |\n| Repository | Multiple data sources need one domain-facing interface | Generic CRUD repositories that erase useful domain meaning |\n| Adapter | An external or legacy API does not match the interface the feature needs | Wrapping every dependency without a concrete mismatch |\n| Factory | Construction varies and callers should not know concrete types | A factory with one permanent branch |\n| Observer | One-to-many change propagation is inherent to the problem | Unbounded subscriptions, unclear ownership, and hidden control flow |\n\nArchitecture references:\n\n- [The Composable Architecture](https://github.com/pointfreeco/swift-composable-architecture)\n- [Swift Dependencies](https://github.com/pointfreeco/swift-dependencies)\n- [Refactoring.Guru Swift patterns](https://refactoring.guru/design-patterns/swift)\n- [Clean Architecture](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html)\n\nNo architecture is automatically “clean.”\nJudge it by dependency direction, testability, clarity, build performance, and how safely the team can change behavior.\n\n### Navigation\n\n- Model navigation as state when deep links, restoration, or tests need deterministic behavior.\n- Keep URL parsing and route authorization separate from view construction.\n- Validate external deep links and universal links as untrusted input.\n- Decide which feature owns dismissal, cancellation, and returned results.\n- Test cold-start and already-running deep-link flows.\n\n## ⚡ Concurrency\n\nSwift concurrency is the default model for new asynchronous Swift code.\n\nLearn:\n\n- `async` functions and `await` suspension points.\n- Structured child tasks and task groups.\n- Actor isolation and `@MainActor`.\n- `Sendable` and safe transfers between isolation domains.\n- Cancellation as a normal control-flow event.\n- `AsyncSequence` for streams of values.\n- Continuations for carefully bridging callback APIs.\n\nRules of thumb:\n\n- Keep UI state on the main actor.\n- Do not block the main actor with synchronous I/O, waiting, or expensive computation.\n- Prefer structured tasks whose lifetime follows the operation that created them.\n- Check cancellation before expensive or user-irrelevant work.\n- Avoid `Task.detached` unless the work truly should not inherit actor, priority, task-local values, or cancellation.\n- Treat `@unchecked Sendable` as a reviewed safety assertion, not a compiler escape hatch.\n- Use actors to protect shared mutable state when actor isolation fits the access pattern.\n- Measure before replacing clear actor-based code with locks or custom executors.\n\nGrand Central Dispatch, locks, operation queues, and semaphores remain relevant for legacy code, framework interoperability, and specialized synchronization.\nDo not mix concurrency models casually or assume a serial queue automatically makes an entire object safe.\n\nReferences:\n\n- [Concurrency in The Swift Programming Language](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/concurrency/)\n- [`Sendable`](https://developer.apple.com/documentation/swift/sendable)\n- [Migrating to Swift concurrency](https://developer.apple.com/documentation/swift/adoptingswift6)\n\n## 🌐 Networking\n\nStart with `URLSession`, `Codable`, `HTTPURLResponse`, and Swift concurrency.\nAdd an abstraction when the app needs consistent authentication, retries, caching, metrics, decoding, or endpoint construction.\n\n```swift\nenum APIError: Error {\n    case invalidResponse\n}\n\nlet (data, response) = try await URLSession.shared.data(for: request)\n\nguard let httpResponse = response as? HTTPURLResponse,\n      200..\u003c300 ~= httpResponse.statusCode else {\n    throw APIError.invalidResponse\n}\n\nlet model = try JSONDecoder().decode(Model.self, from: data)\n```\n\nProduction networking needs more than a successful JSON decode:\n\n- Define request and response contracts.\n- Map transport, HTTP, decoding, authentication, cancellation, and domain errors separately.\n- Set timeouts intentionally.\n- Respect HTTP caching and conditional requests.\n- Retry only operations that are safe to repeat, with limits, delay, and jitter.\n- Propagate cancellation when a screen or operation no longer needs the response.\n- Redact authorization headers, tokens, personal data, and request bodies from logs.\n- Monitor latency, status codes, payload size, and failure rate without collecting unnecessary user data.\n- Test malformed payloads, missing fields, server errors, offline behavior, slow responses, and cancellation.\n\nNever ship a privileged API secret in an iOS application.\nAnything in the app bundle or process should be treated as recoverable by an attacker.\nKeep privileged credentials and authorization decisions on a server you control.\n\nUseful references:\n\n- [`URLSession`](https://developer.apple.com/documentation/foundation/urlsession)\n- [`Codable`](https://developer.apple.com/documentation/swift/codable)\n- [Network framework](https://developer.apple.com/documentation/network)\n- [Alamofire](https://github.com/Alamofire/Alamofire) when its feature set justifies the dependency\n\n## 💾 Persistence\n\nChoose storage from data semantics, not familiarity.\n\n| Data | Appropriate starting point |\n| --- | --- |\n| Small preferences and feature flags | `UserDefaults` |\n| Credentials, tokens, and small secrets | Keychain Services |\n| User-created documents | Documents directory or a document-based API |\n| Re-creatable downloads and derived files | Caches directory |\n| Structured object graph for a modern deployment target | SwiftData |\n| Mature object graph, advanced migrations, or existing store | Core Data |\n| Cross-device Apple ecosystem sync | CloudKit, directly or through a supported persistence integration |\n\n### UserDefaults\n\n`UserDefaults` is for preferences and small property-list values.\nIt is not a database, secure storage, or a good home for large encoded object graphs.\nUse `UserDefaults.standard` unless an app group or a dedicated suite is required.\n\n### File system\n\nUse [`FileManager`](https://developer.apple.com/documentation/foundation/filemanager) URLs instead of hard-coded paths.\nChoose Documents, Application Support, Caches, or temporary storage according to ownership, backup behavior, and whether the data can be recreated.\nUse atomic writes where partial files would be harmful.\n\n### SwiftData\n\n[SwiftData](https://developer.apple.com/documentation/swiftdata) integrates a model layer with Swift and SwiftUI.\nEvaluate deployment targets, migration needs, CloudKit behavior, query complexity, and testability before choosing it.\n\n### Core Data\n\n[Core Data](https://developer.apple.com/documentation/coredata) is an object graph and persistence framework, not simply a SQLite wrapper.\nThe backing store is an implementation choice, and managed objects belong to their managed object context.\n\nImportant topics:\n\n- Persistent containers, contexts, and save propagation.\n- Queue confinement and concurrency.\n- Fetch requests, predicates, sorting, batching, and faulting.\n- Unique constraints, relationships, inverse relationships, and delete rules.\n- Lightweight and custom migration.\n- Persistent history and remote changes when multiple writers exist.\n- In-memory stores for focused tests.\n\nAvoid fetching a global context through `UIApplication.shared.delegate`.\nInject a persistence boundary or context appropriate to the feature and execution domain.\n\n## 🧩 System Capabilities\n\nAdd a capability because the product needs it, then study its lifecycle, permissions, background behavior, and failure modes.\n\n| Capability | Framework or starting point |\n| --- | --- |\n| Local and remote notifications | [UserNotifications](https://developer.apple.com/documentation/usernotifications) |\n| Push delivery | [Apple Push Notification service](https://developer.apple.com/documentation/usernotifications/setting-up-a-remote-notification-server) |\n| Location | [Core Location](https://developer.apple.com/documentation/corelocation) |\n| Bluetooth Low Energy | [Core Bluetooth](https://developer.apple.com/documentation/corebluetooth) |\n| Photos and limited-library access | [PhotoKit](https://developer.apple.com/documentation/photokit) |\n| Camera and media capture | [AVFoundation](https://developer.apple.com/av-foundation/) |\n| Biometrics and device-owner authentication | [LocalAuthentication](https://developer.apple.com/documentation/localauthentication) |\n| Background work | [BackgroundTasks](https://developer.apple.com/documentation/backgroundtasks) |\n| Widgets and controls | [WidgetKit](https://developer.apple.com/documentation/widgetkit) |\n| Live Activities | [ActivityKit](https://developer.apple.com/documentation/activitykit) |\n| Siri, Shortcuts, Spotlight, and system actions | [App Intents](https://developer.apple.com/documentation/appintents) |\n| Health data | [HealthKit](https://developer.apple.com/documentation/healthkit) |\n| Maps | [MapKit](https://developer.apple.com/documentation/mapkit) |\n| Purchases and subscriptions | [StoreKit](https://developer.apple.com/storekit/) |\n\nRequest permission in context, explain the benefit before the system prompt, and make denial a supported product state.\nInclude accurate usage-description strings for protected resources.\nDo not request capabilities “for later.”\n\n### Notifications\n\n- Ask for authorization at a moment when the user understands the value.\n- A local repeating notification must use a valid interval and system-supported trigger.\n- Remote notification delivery is not guaranteed and should not be the only source of durable state.\n- Keep device tokens associated with the correct environment, app, user, and installation.\n- Treat notification payloads and deep-link values as untrusted input.\n\n### Biometrics\n\nUse `LAContext` to evaluate a policy, and handle unavailable, unenrolled, locked-out, canceled, and fallback states.\nBiometrics authenticate device ownership or presence; they do not replace server-side authorization.\nStore protected secrets in the Keychain with an access-control policy appropriate to the product.\n\n## 📦 Dependencies and Modularization\n\n### Swift Package Manager first\n\n[Swift Package Manager](https://docs.swift.org/swiftpm/documentation/packagemanagerdocs/) is the default dependency manager for new Swift code.\nUse CocoaPods or Carthage when maintaining a project or integrating a dependency that still requires them.\n\nBefore adding a dependency, check:\n\n- Whether an Apple framework or a small amount of clear code already solves the problem.\n- Maintenance activity and response to security issues.\n- License compatibility.\n- Supported platforms and toolchains.\n- Transitive dependencies.\n- Binary size and build-time cost.\n- Concurrency annotations and strict-concurrency readiness.\n- Privacy manifest and required-reason API declarations.\n- Migration and removal cost.\n\nReview dependency updates like code changes.\nPin according to the project’s risk tolerance, keep the resolved graph in source control for applications, and automate update visibility.\n\n### Useful packages and tools\n\nThese are options to evaluate, not a default shopping list.\n\n| Project | Purpose |\n| --- | --- |\n| [SwiftLint](https://github.com/realm/SwiftLint) | Enforce selected Swift style and correctness rules |\n| [swift-format](https://github.com/swiftlang/swift-format) | Format Swift source |\n| [SwiftGen](https://github.com/SwiftGen/SwiftGen) | Generate type-safe resource access |\n| [Periphery](https://github.com/peripheryapp/periphery) | Detect unused Swift code |\n| [Alamofire](https://github.com/Alamofire/Alamofire) | Networking features and request abstraction |\n| [Kingfisher](https://github.com/onevcat/Kingfisher) | Image downloading and caching |\n| [SDWebImage](https://github.com/SDWebImage/SDWebImage) | Image loading and caching across Apple UI frameworks |\n| [The Composable Architecture](https://github.com/pointfreeco/swift-composable-architecture) | Reducer-based application architecture |\n| [swift-dependencies](https://github.com/pointfreeco/swift-dependencies) | Dependency management designed for testability |\n| [swift-snapshot-testing](https://github.com/pointfreeco/swift-snapshot-testing) | Snapshot tests for values and UI |\n| [Quick](https://github.com/Quick/Quick) and [Nimble](https://github.com/Quick/Nimble) | Behavior-style test organization and matchers |\n| [Swift Collections](https://github.com/apple/swift-collections) | Additional data structures |\n| [Swift Algorithms](https://github.com/apple/swift-algorithms) | Sequence and collection algorithms |\n\n### Modularization\n\nModules should express ownership and dependency boundaries.\nThey are not automatically an improvement.\n\nModularize when it provides one or more of these benefits:\n\n- Independent ownership or release.\n- Enforced access control.\n- Reuse across products.\n- Smaller test and build scopes.\n- Isolation of volatile infrastructure.\n- A stable feature or domain boundary.\n\nTrack build time before and after modularization.\nAn excessive module graph can increase configuration, dependency, and linking costs.\n\nUseful tools:\n\n- [Tuist](https://tuist.dev/) for generated projects, workspaces, caching, and project automation.\n- [XcodeGen](https://github.com/yonaskolb/XcodeGen) for generating Xcode projects from specifications.\n- [XCFrameworks](https://developer.apple.com/documentation/xcode/creating-a-multi-platform-binary-framework-bundle) for distributing multi-platform binary frameworks.\n- [DocC](https://www.swift.org/documentation/docc/) for API and conceptual documentation.\n\n## 🧪 Testing\n\nTests should protect behavior that matters and make refactoring safer.\nA large test count is not evidence of useful coverage.\n\n### Choose the right layer\n\n| Test | Best for | Avoid |\n| --- | --- | --- |\n| Unit | Pure logic, reducers, transformations, validation, and edge cases | Re-testing framework behavior |\n| Integration | Persistence, networking boundaries, decoding, migrations, and module contracts | Calling uncontrolled production services |\n| UI | Critical user journeys and system integration | Reproducing every unit-level branch through the UI |\n| Snapshot | Stable visual or structural output | Treating every pixel change as a regression |\n| Performance | Launch, scrolling, algorithms, persistence, and memory-sensitive behavior | Thresholds that are noisy on shared CI hardware |\n\n### Swift Testing and XCTest\n\nUse [Swift Testing](https://developer.apple.com/documentation/testing) for new Swift unit tests when it fits the project.\nIt supports parameterization, traits, tags, concurrency, and flexible suite organization.\n\nUse [XCTest](https://developer.apple.com/documentation/xctest) for UI tests, performance tests, Objective-C tests, and existing suites.\nSwift Testing and XCTest can coexist during incremental migration, but do not mix their APIs inside one test.\n\n### Test doubles\n\n- A dummy fills an unused parameter.\n- A stub returns controlled answers.\n- A spy records interactions for later verification.\n- A mock verifies expected interactions.\n- A fake provides a working but simplified implementation, such as an in-memory repository.\n\nPrefer a fake or stub that expresses behavior over a brittle mock of implementation details.\n\n### UI testing\n\n- Use accessibility identifiers only where semantic queries are insufficient.\n- Keep screen interaction behind small robot or page objects when it improves readability.\n- Reset state deterministically.\n- Disable uncontrolled animations or network dependencies through launch configuration.\n- Capture screenshots and logs on failure.\n- Test permissions, deep links, interruptions, and relaunch behavior where they affect critical journeys.\n\n### Accessibility testing\n\nRun Accessibility Inspector audits and automate appropriate checks with XCUITest.\nAutomated audits catch common issues but do not replace VoiceOver, Switch Control, keyboard, and real-device testing.\n\n### StoreKit testing\n\nUse a StoreKit configuration for local development and deterministic tests.\nUse the sandbox and TestFlight to validate App Store Connect products and server interactions.\nTest success, cancellation, pending approval, failed purchase, restore, refund, renewal, expiration, grace period, and interrupted transactions.\n\nReferences:\n\n- [Testing and performance overview](https://developer.apple.com/documentation/technologyoverviews/testing-and-performance)\n- [Organizing tests with test plans](https://developer.apple.com/documentation/xcode/organizing-tests-to-improve-feedback)\n- [StoreKit Test](https://developer.apple.com/documentation/storekittest)\n- [Testing in-app purchases in Xcode](https://developer.apple.com/documentation/storekit/testing-in-app-purchases-in-xcode)\n\n## 🐛 Debugging, Performance, and Observability\n\n### Debugging\n\nLearn these Xcode tools:\n\n- Source, symbolic, exception, and runtime-issue breakpoints.\n- LLDB commands such as `po`, `p`, `expression`, `bt`, and breakpoint commands.\n- View hierarchy debugger.\n- Memory graph debugger.\n- Address Sanitizer, Thread Sanitizer, and Undefined Behavior Sanitizer.\n- Main Thread Checker and Thread Performance Checker.\n- Network and file activity instruments.\n- Crash and hang reports in Organizer.\n\nNever “fix” a race by adding arbitrary delay.\nReproduce it, identify the ownership or isolation violation, and leave a test or diagnostic that would catch the regression.\n\n### Performance\n\nMeasure on a representative physical device with an optimized build.\nSimulator results are useful for iteration but do not represent device CPU, GPU, memory pressure, thermal behavior, or power use.\n\nWatch:\n\n- Launch and first-interaction latency.\n- Hangs, hitches, and main-thread work.\n- Scrolling and animation frame time.\n- Memory growth, leaks, retain cycles, and termination pressure.\n- Disk and network I/O.\n- Battery and thermal impact.\n- Download size, installed size, and on-demand resources.\n\nUse [Instruments and Xcode performance tools](https://developer.apple.com/documentation/xcode/performance-and-metrics) before guessing.\n\n### Logging and metrics\n\nUse unified logging through `Logger`.\nChoose subsystem, category, and level deliberately.\nMark sensitive interpolated values as private and avoid logging secrets or full payloads.\n\nUse signposts for important intervals that need Instruments correlation.\nUse [MetricKit](https://developer.apple.com/documentation/metrickit) and Xcode Organizer to understand behavior on distributed builds.\nUse crash reporting and product analytics only with clear privacy rules, retention, and consent where required.\n\n## ♿ Accessibility and Localization\n\n### Accessibility\n\nAccessibility is a product requirement.\nBuild with semantic system controls first, then add custom accessibility behavior where the UI needs it.\n\nVerify:\n\n- Useful labels, values, hints, traits, actions, and focus order.\n- Dynamic Type without clipping or hiding essential actions.\n- Sufficient contrast without relying on color alone.\n- VoiceOver reading order and rotor behavior.\n- Reduce Motion, Reduce Transparency, Bold Text, and Increased Contrast.\n- Switch Control, Voice Control, Full Keyboard Access, and external keyboards where relevant.\n- Captions, transcripts, and alternatives for meaningful audio or visual content.\n\nReferences:\n\n- [Accessibility](https://developer.apple.com/accessibility/)\n- [Accessibility for SwiftUI](https://developer.apple.com/documentation/swiftui/accessibility)\n- [Accessibility for UIKit](https://developer.apple.com/documentation/uikit/accessibility)\n- [Performing accessibility audits](https://developer.apple.com/documentation/accessibility/performing-accessibility-audits-for-your-app)\n\n### Localization\n\nLocalization includes language, pluralization, grammar, layout direction, calendars, dates, times, numbers, names, units, and culturally appropriate assets.\n\nUse [String Catalogs](https://developer.apple.com/documentation/xcode/localizing-and-varying-text-with-a-string-catalog) for new Xcode projects.\nProvide translator comments and avoid constructing user-facing sentences from fragments.\nUse `FormatStyle` and locale-aware Foundation formatters instead of hand-built date or number strings.\n\nTest:\n\n- Every supported language and a pseudolanguage.\n- Long strings and large text.\n- Right-to-left layout.\n- Singular, plural, and grammatical variants.\n- Non-Gregorian calendars and 12/24-hour time where product behavior depends on them.\n- Region-specific prices, decimal separators, measurement systems, and names.\n\nReferences:\n\n- [Localization](https://developer.apple.com/localization/)\n- [Preparing text for translation](https://developer.apple.com/documentation/xcode/preparing-your-apps-text-for-translation)\n- [Editing XLIFF and String Catalog files](https://developer.apple.com/documentation/xcode/editing-xliff-and-string-catalog-files)\n\n## 🔐 Security and Privacy\n\nSecurity is risk management, not a checklist of tricks.\nStart with a threat model: identify assets, trust boundaries, attackers, abuse cases, and the impact of failure.\n\n### Baseline\n\n- Minimize collected data and retention.\n- Keep authorization decisions and privileged credentials on the server.\n- Use TLS and App Transport Security without broad exceptions.\n- Store small secrets in the Keychain with appropriate accessibility and access-control settings.\n- Use CryptoKit or other reviewed platform cryptography instead of designing cryptographic algorithms.\n- Validate every server response, deep link, file, pasteboard value, notification payload, and imported document.\n- Redact secrets and personal data from logs, analytics, screenshots, and crash metadata.\n- Review third-party SDK behavior, privacy manifests, signatures, licenses, and transitive dependencies.\n- Keep development menus, debug endpoints, and verbose logging out of production builds.\n- Handle compromised credentials and server-side revocation.\n\n### Transport security and pinning\n\n[App Transport Security](https://developer.apple.com/documentation/security/preventing-insecure-network-connections) enforces secure connection requirements by default.\nUse narrowly scoped exceptions only when a documented compatibility requirement leaves no safer option.\n\nCertificate or public-key pinning adds operational risk.\nUse it only when the threat model justifies it and the team can support backup pins, certificate rotation, expiration, incident recovery, and remote failure.\nDo not copy deprecated `SecTrustEvaluate` examples or assume pinning replaces normal trust evaluation.\n\n### Keychain and cryptography\n\n- [Using the Keychain to manage user secrets](https://developer.apple.com/documentation/security/using-the-keychain-to-manage-user-secrets)\n- [CryptoKit](https://developer.apple.com/documentation/cryptokit)\n- [LocalAuthentication](https://developer.apple.com/documentation/localauthentication)\n\n### Privacy\n\nPrivacy work includes both product behavior and App Store declarations.\n\n- Maintain accurate App Privacy answers in App Store Connect.\n- Include valid privacy manifests and required-reason API declarations where applicable.\n- Audit included SDKs because their collection and required-reason APIs become part of the app.\n- Ask for protected-resource access only when the feature needs it.\n- Provide account and data deletion flows where policy or law requires them.\n- Make consent specific and avoid dark patterns.\n\nReferences:\n\n- [Privacy manifest files](https://developer.apple.com/documentation/bundleresources/privacy-manifest-files)\n- [Adding a privacy manifest](https://developer.apple.com/documentation/bundleresources/adding-a-privacy-manifest-to-your-app-or-third-party-sdk)\n- [User privacy and data use](https://developer.apple.com/app-store/user-privacy-and-data-use/)\n- [Apple Platform Security](https://support.apple.com/guide/security/welcome/web)\n- [OWASP Mobile Application Security](https://mas.owasp.org/)\n\nObfuscation and jailbreak detection can raise the cost of analysis, but neither establishes a trustworthy device.\nTreat them as optional defense-in-depth controls, not security boundaries.\n\n## 🔄 CI/CD and Team Workflow\n\nCI should make the repository reproducible and the default branch trustworthy.\n\nA useful pull-request pipeline:\n\n1. Resolve dependencies from a clean checkout.\n2. Build supported configurations.\n3. Run formatting and lint checks.\n4. Run unit and integration tests.\n5. Run selected UI, accessibility, and performance tests.\n6. Scan for secrets and vulnerable dependencies.\n7. Archive or export a build when distribution behavior matters.\n8. Publish concise logs, test results, and artifacts.\n\nKeep signing material and credentials in the CI provider’s protected secret store.\nUse short-lived credentials or workload identity when supported.\nDo not run secret-bearing workflows against untrusted pull-request code.\n\nTools:\n\n- [Xcode Cloud](https://developer.apple.com/xcode-cloud/)\n- [GitHub Actions](https://docs.github.com/actions)\n- [fastlane](https://fastlane.tools/)\n- [Tuist](https://tuist.dev/)\n- [Danger](https://danger.systems/) for deterministic review conventions\n- [Codemagic](https://codemagic.io/)\n- [CircleCI](https://circleci.com/)\n\n### Build performance\n\nTreat build time as a measured developer-experience metric.\n\n- Inspect Xcode build timing summaries and dependency graphs.\n- Keep run-script phases deterministic and declare their inputs and outputs.\n- Avoid unnecessary code generation and always-run scripts.\n- Measure type-checking and module-boundary changes.\n- Cache only artifacts that are safe and correctly keyed.\n- Use project-generation focus or selective-build features only after measuring the bottleneck.\n\n## 🚢 Distribution and Monetization\n\n### Code signing\n\nUnderstand:\n\n- Bundle identifiers, App IDs, certificates, provisioning profiles, entitlements, and capabilities.\n- Development, Ad Hoc, TestFlight, App Store, and enterprise distribution differences.\n- Automatic signing versus intentionally managed signing in CI.\n- Export compliance and privacy requirements.\n\nReferences:\n\n- [Code signing](https://developer.apple.com/support/code-signing/)\n- [App distribution](https://developer.apple.com/documentation/xcode/distributing-your-app-for-beta-testing-and-releases)\n- [App Store Connect Help](https://developer.apple.com/help/app-store-connect/)\n\n### TestFlight\n\n[TestFlight](https://developer.apple.com/testflight/) distributes beta builds and collects feedback before release.\nTest migration, account, notification, background, purchase, and server-compatibility behavior on TestFlight rather than assuming a development build is equivalent.\n\n### App Store\n\nRead the [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/) before implementation decisions become expensive.\nValidate metadata, screenshots, privacy answers, support URLs, account deletion, review notes, and demo credentials before submission.\n\n### StoreKit and subscriptions\n\nUse [StoreKit 2](https://developer.apple.com/storekit/) for modern Swift purchase flows.\nModel entitlement state independently from the paywall UI.\nVerify transactions, finish processed transactions, listen for updates, restore access, and design for purchases that occur on another device or outside the app.\n\nTesting does not require a physical device for every stage.\nStoreKit Testing in Xcode supports local purchase scenarios, while sandbox and TestFlight cover App Store-connected behavior.\n\nUseful references:\n\n- [Setting up StoreKit Testing in Xcode](https://developer.apple.com/documentation/xcode/setting-up-storekit-testing-in-xcode)\n- [Testing purchases with sandbox](https://developer.apple.com/documentation/storekit/testing-in-app-purchases-with-sandbox)\n- [App Store Server API](https://developer.apple.com/documentation/appstoreserverapi)\n- [App Store Server Notifications](https://developer.apple.com/documentation/appstoreservernotifications)\n- [Subscriptions and offers](https://developer.apple.com/app-store/subscriptions/)\n\nTest renewal, expiration, cancellation, refund, revocation, billing retry, grace period, upgrade, downgrade, restore, Ask to Buy, and interrupted transactions.\nDo not unlock durable server-owned value based only on an unverified client boolean.\n\n## 🧱 Legacy Code and Interoperability\n\nProduction iOS development often includes APIs and patterns that are no longer the first choice for a new app.\nLearn enough to maintain them safely before attempting a migration.\n\n### Objective-C\n\nUnderstand:\n\n- Header and implementation files.\n- Categories, protocols, delegates, blocks, and nullability.\n- Dynamic dispatch, selectors, KVC, and KVO.\n- ARC ownership and retain-cycle behavior.\n- Bridging headers and generated Swift interfaces.\n- Module maps and framework boundaries.\n\nReferences:\n\n- [Using imported C and Objective-C APIs in Swift](https://developer.apple.com/documentation/swift/using-imported-c-and-objective-c-apis-in-swift)\n- [Importing Objective-C into Swift](https://developer.apple.com/documentation/swift/importing-objective-c-into-swift)\n\nDo not describe a Swift app as free of Objective-C runtime or C-family foundations merely because the application target contains only `.swift` files.\nThat fact rarely affects product architecture, so investigate it only when interoperability, runtime behavior, or debugging makes it relevant.\n\n### Frameworks and patterns you may inherit\n\n- UIKit storyboards and nibs.\n- Core Data.\n- Objective-C modules.\n- CocoaPods and Carthage.\n- GCD and `OperationQueue`.\n- Combine and RxSwift.\n- MVC, MVVM, VIPER, coordinators, and custom routers.\n- Custom networking and persistence layers.\n\nMigration rule: preserve behavior first, add characterization tests, move one boundary at a time, and measure the result.\nA rewrite is not automatically simpler than the code it replaces.\n\n## 📚 Learning Resources\n\n### Apple and Swift\n\n- [Apple Developer Documentation](https://developer.apple.com/documentation/)\n- [Apple Developer Videos](https://developer.apple.com/videos/)\n- [Apple Sample Code](https://developer.apple.com/documentation/samplecode)\n- [Develop in Swift Tutorials](https://developer.apple.com/tutorials/develop-in-swift)\n- [Swift.org Documentation](https://www.swift.org/documentation/)\n- [Swift Forums](https://forums.swift.org/)\n- [Swift Evolution](https://www.swift.org/swift-evolution/)\n- [Swift Package Index](https://swiftpackageindex.com/)\n\n### Community\n\n- [Swift by Sundell](https://www.swiftbysundell.com/)\n- [SwiftLee](https://www.avanderlee.com/)\n- [Hacking with Swift](https://www.hackingwithswift.com/)\n- [Point-Free](https://www.pointfree.co/)\n- [objc.io](https://www.objc.io/)\n- [NSHipster](https://nshipster.com/)\n- [iOS Dev Weekly](https://iosdevweekly.com/)\n- [Use Your Loaf](https://useyourloaf.com/)\n- [Kodeco](https://www.kodeco.com/ios)\n- [Donny Wals](https://www.donnywals.com/)\n\n### Discovery\n\n- [awesome-ios](https://github.com/vsouza/awesome-ios)\n- [Swift package ecosystem](https://www.swift.org/packages/)\n- [WWDC Index](https://nonstrict.eu/wwdcindex/)\n- [iOS Developer Roadmap](https://github.com/BohdanOrlov/iOS-Developer-Roadmap)\n\nPrefer a recent official source when framework behavior, platform policy, security, privacy, or App Store requirements matter.\nCommunity material is most valuable for explanation, tradeoffs, and experience reports.\n\n## Contributing\n\nContributions are welcome.\n\nBefore adding a link or recommendation, check that:\n\n- It teaches a durable concept or solves a real iOS engineering problem.\n- The technical claim is current and can be verified.\n- The project is maintained or clearly labeled as legacy.\n- The description explains why the resource is useful.\n- A first-party framework does not already cover the need more simply.\n- The license, privacy, and security implications are acceptable.\n- The addition fits an existing section or justifies a new one.\n\nKeep pull requests focused.\nWhen correcting a technical claim, include the official source used to verify it.\n\nIf this guide helps you, star the repository or open an issue with a concrete improvement.\n\n## Author\n\nCreated and maintained by **Jungpyo Hong (Dennis)**.\n\n- GitHub: [@jphong1111](https://github.com/jphong1111)\n- Email: [ghdwjdvy96@gmail.com](mailto:ghdwjdvy96@gmail.com)\n","projects_url":"https://awesome.ecosyste.ms/api/v1/lists/jphong1111%2Fawesome-ios-developer/projects"}