# # Be sure to run `pod spec lint CommonUse.podspec' to ensure this is a # valid spec and to remove all comments including this before submitting the spec. # # To learn more about Podspec attributes see http://docs.cocoapods.org/specification.html # To see working Podspecs in the CocoaPods repo see https://github.com/CocoaPods/Specs/ #
Pod::Spec.new do|s|
# ――― Spec Metadata ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――― # # # These will help people to find your library, and whilst it # can feel like a chore to fill in it's definitely to your advantage. The # summary should be tweet-length, and the description more in depth. #
s.name = "CommonUse" s.version = "0.0.3" s.summary = "I am now testing my first framwork"
# This description is used to generate tags and improve search results. # * Think: What does it do? Why did you write it? What is the focus? # * Try to keep it short, snappy and to the point. # * Write the description between the DESC delimiters below. # * Finally, don't worry about the indent, CocoaPods strips it! s.description = <<-DESC I am testing my framwork.Hope to create a perfect one soon . DESC
# ――― Spec License ――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― # # # Licensing your code is important. See http://choosealicense.com for more info. # CocoaPods will detect a license file if there is a named LICENSE* # Popular ones are 'MIT', 'BSD' and 'Apache License, Version 2.0'. #
# ――― Author Metadata ――――――――――――――――――――――――――――――――――――――――――――――――――――――――― # # # Specify the authors of the library, with email addresses. Email addresses # of the authors are extracted from the SCM log. E.g. $ git log. CocoaPods also # accepts just a name if you'd rather not provide an email address. # # Specify a social_media_url where others can refer to, for example a twitter # profile URL. #
# ――― Platform Specifics ――――――――――――――――――――――――――――――――――――――――――――――――――――――― # # # If this Pod runs only on iOS or OS X, then specify the platform and # the deployment target. You can optionally include the target after the platform. #
# s.platform = :ios s.platform = :ios, "8.0"
# When using multiple platforms s.ios.deployment_target = "8.0" # s.osx.deployment_target = "10.7" # s.watchos.deployment_target = "2.0" # s.tvos.deployment_target = "9.0"
# ――― Source Location ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――― # # # Specify the location from where the source should be retrieved. # Supports git, hg, bzr, svn and HTTP. #
# ――― Source Code ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― # # # CocoaPods is smart about how it includes source code. For source files # giving a folder will include any swift, h, m, mm, c & cpp files. # For header files it will include any header in the folder. # Not including the public_header_files will make all headers public. #
s.source_files = "*.{h,m,swift}"
# s.public_header_files = "Classes/**/*.h"
# ――― Resources ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― # # # A list of resources included with the Pod. These are copied into the # target bundle with a build phase script. Anything else will be cleaned. # You can preserve files from being cleaned, please don't preserve # non-essential files like tests, examples and documentation. #
# ――― Project Linking ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――― # # # Link your library with frameworks, or libraries. Libraries do not include # the lib prefix of their name. #
# ――― Project Settings ――――――――――――――――――――――――――――――――――――――――――――――――――――――――― # # # If your library depends on compiler flags you can set them in the xcconfig hash # where they will only apply to your library. If you depend on other Podspecs # you can include multiple dependencies to ensure it works.
Pod::Spec.new do|s| s.name = "InterfaceKit" s.version = "5.4.0" s.summary = "InterfaceKit helps you use interface of UIKit, AppKit and WatchKit in SwiftUI interface easily" s.description = <<-DESC This is supported by [Saidong Zhang](https://zsd.name)
its intention is to help people use interface of UIKit, AppKit and WatchKit in SwiftUI interface easily. /// You create custom views by declaring types that conform to the ``View`` /// protocol. Implement the required ``View/body-swift.property`` computed /// property to provide the content for your custom view. Then you can present your UIKit /// ViewController View by using `InterfaceView(MyView())` , as follows. ```swift /// /// struct MyView: View { /// var body: some View { /// InterfaceView(MyView()) /// } /// } /// ``` /// The ``View`` protocol provides a large set of modifiers, defined as protocol /// methods with default implementations, that you use to position and configure /// views in the layout of your app. Modifiers typically work by wrapping the /// view instance on which you call them in another view with the specified /// characteristics. For example, adding the ``View/opacity(_:)`` modifier to a /// interface view returns a new view with some amount of transparency: ```swift /// /// InterfaceView(MyView()) /// .opacity(0.5) // Display partially transparent interface view. /// ``` /// It is recommended to use `ZStack` with `InterfaceView` , as follows. ```swift /// /// ZStack { /// InterfaceView(MyView()) /// MySwiftUIView() /// } /// ``` DESC s.homepage = "https://github.com/adong666666/InterfaceKit" s.license = 'MIT' s.author = { "Saidong Zhang" => "3440217568@qq.com" } s.source = { :git => "https://github.com/adong666666/InterfaceKit.git", :tag => s.version.to_s }