{"id":20878901,"url":"https://github.com/codeandtheory/ynetwork-ios","last_synced_at":"2025-12-11T22:59:01.711Z","repository":{"id":63921259,"uuid":"514197775","full_name":"codeandtheory/ynetwork-ios","owner":"codeandtheory","description":"A networking layer for iOS and tvOS.","archived":false,"fork":false,"pushed_at":"2024-09-24T06:08:01.000Z","size":1033,"stargazers_count":3,"open_issues_count":2,"forks_count":3,"subscribers_count":7,"default_branch":"main","last_synced_at":"2025-04-15T15:44:37.963Z","etag":null,"topics":["ios","ios-swift","networking","swift"],"latest_commit_sha":null,"homepage":"","language":"Swift","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/codeandtheory.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}},"created_at":"2022-07-15T08:43:47.000Z","updated_at":"2024-09-24T06:06:25.000Z","dependencies_parsed_at":"2023-10-03T05:28:47.249Z","dependency_job_id":null,"html_url":"https://github.com/codeandtheory/ynetwork-ios","commit_stats":null,"previous_names":["codeandtheory/ynetwork-ios","yml-org/ynetwork-ios"],"tags_count":2,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/codeandtheory%2Fynetwork-ios","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/codeandtheory%2Fynetwork-ios/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/codeandtheory%2Fynetwork-ios/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/codeandtheory%2Fynetwork-ios/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/codeandtheory","download_url":"https://codeload.github.com/codeandtheory/ynetwork-ios/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253776780,"owners_count":21962554,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","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"}},"keywords":["ios","ios-swift","networking","swift"],"created_at":"2024-11-18T07:14:33.714Z","updated_at":"2025-12-11T22:59:01.684Z","avatar_url":"https://github.com/codeandtheory.png","language":"Swift","readme":"![Y—Network](https://user-images.githubusercontent.com/1037520/202389911-bd44883e-aa11-4584-9f78-3934ef1b4bf2.jpeg)\n[![](https://img.shields.io/endpoint?url=https%3A%2F%2Fswiftpackageindex.com%2Fapi%2Fpackages%2Fyml-org%2Fynetwork-ios%2Fbadge%3Ftype%3Dswift-versions)](https://swiftpackageindex.com/yml-org/ynetwork-ios) [![](https://img.shields.io/endpoint?url=https%3A%2F%2Fswiftpackageindex.com%2Fapi%2Fpackages%2Fyml-org%2Fynetwork-ios%2Fbadge%3Ftype%3Dplatforms)](https://swiftpackageindex.com/yml-org/ynetwork-ios)  \n_A networking layer for iOS and tvOS._\n\n🤖 Looking for the Android version? Check it out [here](https://github.com/yml-org/ynetwork-android).\n\nDocumentation\n----------\n\nDocumentation is automatically generated from source code comments and rendered as a static website hosted via GitHub Pages at:  https://yml-org.github.io/ynetwork-ios/\n\nUsage\n----------\n\n### NetworkManager\n\nYou will need to instantiate a `NetworkManager` either in your AppDelegate, SceneDelegate or other top-level application coordinator. You should then use Dependency Injection to pass it to the various service layers or view models that need it.\n\n`NetworkManager` can be extensively configured via a `NetworkManagerConfiguration` object and/or by subclassing, but for basic functionality neither is required.\n\n```swift\n// Declare an instance of the network manager, so that it can be injected where needed.\nprivate let networkManager = NetworkManager()\n```\n\n### NetworkRequest\n\nEach network request you issue will be its own object (class or struct) that conforms to the `NetworkRequest` protocol. This protocol allows you to configure many things about your request (path, method, query parameters, body, timeout, headers, etc.) but it has sensible defaults so that the only mandatory property is `path` (which endpoint to hit).\n\n```swift\nstruct GetUsersRequest { }\n\nextension GetUsersRequest: NetworkRequest {\n    // which endpoint to hit\n    var path: PathRepresentable { \"https://myendpoint.com/api/v1/users\" }\n}\n```\n\nThen you would issue a request like so (where the request will either return an array of `User` objects or else throw an `Error`). The following example shows how to use the modern `async` / `await` approach, but there’s also a completion handler based override of `submit`.\n\n```swift\nfunc fetchUsers() async {\n    let request = GetUsersRequest()\n\n    do {\n        let users = try await networkManager.submit(request)\n        // handle success\n    } catch {\n        // handle failure\n    }\n}\n```\n\n### Using relative paths\n\n`NetworkRequest` supports relative paths by having both `basePath` and `path` properties. `path` is treated as an absolute path when `basePath` is nil (the default), otherwise it is treated as a relative path when `basePath` has been specified. We recommend the use of `enum`'s to list your applications base paths and paths.\n\n```swift\nenum MyApiBasePath: String, PathRepresentable {\n    case prod = \"https://myendpoint.com/api/v1\"\n\n    // In a real app you'd probably have additional development endpoints\n    // such as dev, qa, uat, sandbox, etc.\n}\n\nextension MyApiBasePath {\n    // convenience property to point to the current environment\n    static var current: MyApiBasePath = .prod\n}\n\nenum MyApiEndpoints: String, PathRepresentable {\n    case users\n}\n```\n\nYou could then declare a new request protocol for each different api server that your app supports.\n\n```swift\n// You can declare a new protocol for each major endpoint your app supports\nprotocol MyApiRequest: NetworkRequest { }\n\nextension MyApiRequest {\n    // All requests sharing the same base path\n    var basePath: PathRepresentable? { MyApiBasePath.current }\n}\n```\n\nThen each request can derive from the protocol specific to their api server.\n\n```swift\nstruct GetUsersRequest { }\n\nextension GetUsersRequest: MyApiRequest {\n    // which endpoint to hit\n    var path: PathRepresentable { MyApiEndpoints.users }\n}\n```\n\n### Using associated values in paths\n\nMost api’s have some requests where the path contains a unique identifier. Adding associated values to your endpoints enum is a great way to handle these. It requires a slight reconfiguration in how our endpoint enum is declared.\n\n```swift\nenum MyApiEndpoints {\n    case users\n    case user(id: String)\n}\n\nextension MockApiEndpoints: PathRepresentable {\n    var pathValue: String {\n        switch self {\n        case .users:\n            return \"users\"\n        case .user(let id):\n            return \"users/\\(id)\"\n        }\n    }\n}\n```\n\nThen you could declare a request for a specific user like so:\n\n```swift\nstruct GetUserRequest {\n    /// Id of the user to fetch\n    let userId: String\n}\n\nextension GetUserRequest: MyApiRequest {\n    // which endpoint to hit\n    var path: PathRepresentable { MyApiEndpoints.user(id: userId) }\n}\n```\n\nInstallation\n----------\n\nYou can add Y-Network to an Xcode project by adding it as a package dependency.\n\n1. From the **File** menu, select **Add Packages...**\n2. Enter \"[https://github.com/yml-org/ynetwork-ios](https://github.com/yml-org/ynetwork-ios)\" into the package repository URL text field\n3. Click **Add Package**\n\nContributing to Y-Network\n----------\n\n### Requirements\n\n#### SwiftLint (linter)\n```\nbrew install swiftlint\n```\n\n#### Jazzy (documentation)\n```\nsudo gem install jazzy\n```\n\n### Setup\n\nClone the repo and open `Package.swift` in Xcode.\n\n### Versioning strategy\n\nWe utilize [semantic versioning](https://semver.org).\n\n```\n{major}.{minor}.{patch}\n```\n\ne.g.\n\n```\n1.0.5\n```\n\n### Branching strategy\n\nWe utilize a simplified branching strategy for our frameworks.\n\n* main (and development) branch is `main`\n* both feature (and bugfix) branches branch off of `main`\n* feature (and bugfix) branches are merged back into `main` as they are completed and approved.\n* `main` gets tagged with an updated version # for each release\n \n### Branch naming conventions:\n\n```\nfeature/{ticket-number}-{short-description}\nbugfix/{ticket-number}-{short-description}\n```\ne.g.\n```\nfeature/CM-44-button\nbugfix/CM-236-textview-color\n```\n\n### Pull Requests\n\nPrior to submitting a pull request you should:\n\n1. Compile and ensure there are no warnings and no errors.\n2. Run all unit tests and confirm that everything passes.\n3. Check unit test coverage and confirm that all new / modified code is fully covered.\n4. Run `swiftlint` from the command line and confirm that there are no violations.\n5. Run `jazzy` from the command line and confirm that you have 100% documentation coverage.\n6. Consider using `git rebase -i HEAD~{commit-count}` to squash your last {commit-count} commits together into functional chunks.\n7. If HEAD of the parent branch (typically `main`) has been updated since you created your branch, use `git rebase main` to rebase your branch.\n    * _Never_ merge the parent branch into your branch.\n    * _Always_ rebase your branch off of the parent branch.\n\nWhen submitting a pull request:\n\n* Use the [provided pull request template](.github/pull_request_template.md) and populate the Introduction, Purpose, and Scope fields at a minimum.\n* If you're submitting before and after screenshots, movies, or GIF's, enter them in a two-column table so that they can be viewed side-by-side.\n\nWhen merging a pull request:\n\n* Make sure the branch is rebased (not merged) off of the latest HEAD from the parent branch. This keeps our git history easy to read and understand.\n* Make sure the branch is deleted upon merge (should be automatic).\n\n### Releasing new versions\n* Tag the corresponding commit with the new version (e.g. `1.0.5`)\n* Push the local tag to remote\n\nGenerating Documentation (via Jazzy)\n----------\n\nYou can generate your own local set of documentation directly from the source code using the following command from Terminal:\n```\njazzy\n```\nThis generates a set of documentation under `/docs`. The default configuration is set in the default config file `.jazzy.yaml` file.\n\nTo view additional documentation options type:\n```\njazzy --help\n```\nA GitHub Action automatically runs each time a commit is pushed to `main` that runs Jazzy to generate the documentation for our GitHub page at: https://yml-org.github.io/ynetwork-ios/\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcodeandtheory%2Fynetwork-ios","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcodeandtheory%2Fynetwork-ios","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcodeandtheory%2Fynetwork-ios/lists"}