Once you confirm these both things, you can go ahead and run next step, which is the Carthage dry run. If you don't see the badge there and it's a Swift framework that can be built with xcodebuild and have schemes supported by the iOS platform, then that should be OK as well. ![]() There should be a badge stating the Carthage support as well the platform support, as shown below (not that big, though) The way to check that is to visit the GitHub repo page of the framework and look at the README file. Check Carthage SupportĪlmost all the major third-party Swift frameworks support Carthage. Similarly, check how many other dependencies are being used and see if those can easily be replaced by native Apple technologies like Alamofire Or SwiftyJSON can be replaced by URLSession and Codable. An example would be SwiftLint think, why do we need to add SwiftLint as a dependency to an iOS app? It can be easily run on a GitHub pre-commit hook or from a command line script on the local machine or Continuous Integration server. Ditch Unwanted DependenciesĪt this stage, try to get rid of the dependencies that you no longer using or can be replaced with another approach if possible. In the analysis phase, you should do two major things. If you are using CocoaPods, then there must be a list of dependencies hanging there inside the Podfile of the iOS project. The first step to migrate the iOS project to Carthage is dependency analysis. One thing to note here: we are only talking about the Swift frameworks and dynamic libraries, not about the old Objective-C or static frameworks. It can be easily achieved by applying these five steps: In this post, we will assume that you have decided to go to Carthage and we will see how easy it is to migrate from CocoaPods to Carthage. ![]() I would strongly recommend reading that post to understand the basic difference. ![]() In my last blog post, I explained the difference between CocoaPods and Carthage and how to choose the right framework. Carthage is another dependency management solution which is written in Swift and maintained by GitHub engineers. As long as it works, everything is OK, but the pain starts if something breaks in CocoaPods or the magical settings that CocoaPods has done inside the Xcode project. It's written in Ruby and iOS developers need to know Ruby in order to use it. However, this is not the reality iOS developers want to share and distribute code for reusability, avoid duplication, and save time.ĬocoaPods has been serving as a dependency management solution for iOS apps for a long time. This might be the reason Apple didn't have any official package manager to manage dependencies for iOS apps yet. Apple's core technologies have provided enough frameworks and tools with healthy documentation that developers can use to build and distribute iOS apps. Apple may not like the fact that iOS developers are adding third-party dependencies to iOS projects.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |