使用框架在app扩展中使用Cocoapods

Jon*_*ugg 14 ios cocoapods swift

我有一个用Swift编写的应用程序(我们称之为MyApp),其中包含以下目标:

  • MyApp :主要目标
  • MyAppKit :构建应用程序及其扩展之间共享的代码框架的目标,主要是API后端和数据库处理
  • MyAppWidget:一个使用MyAppKit框架的Today View Widget(或者现在叫做的任何东西).

MyAppKit框架被链接到使用它,即每个目标MyAppMyAppWidget.输入Cocoapods:我曾经有过以下的Podfile结构:

platform :ios, '8.0'
use_frameworks!

target 'MyApp' do
    # Mostly UI or convenience pods
    pod 'Eureka', '~> 2.0.0-beta'
    pod 'PKHUD', '~> 4.0'
    pod '1PasswordExtension', '~> 1.8'
end

target 'MyAppKit' do
    # Backend pods for networking, storage, etc.
    pod 'Alamofire', '~> 4.0'
    pod 'Fuzi', '~> 1.0'
    pod 'KeychainAccess', '~> 3.0'
    pod 'RealmSwift', '~> 2.0'
    pod 'Result', '~> 3.0'
end

target 'MyAppWidget' do
    # Added here event though the target only imports MyAppKit but it worked
    pod 'RealmSwift', '~> 2.0'
end
Run Code Online (Sandbox Code Playgroud)

这里的目的是仅将MyAppKit框架暴露给其他部分,而不是所有的部分(例如,我不希望能够import Alamofire在主应用程序内部).但是,从Cocoapods 1.2.0 RC开始,pod install失败并出现以下错误:[!] The 'Pods-MyApp' target has frameworks with conflicting names: realm and realmswift..它曾经工作,因为pods是为扩展名声明的,但只嵌入在主机应用程序中(有关详细信息,请参阅此问题).所以我从小部件的目标中删除了pod,只留下一个空target 'MyAppWidget'行.

使用此配置,pod install运行正常,但编译在MyAppWidget目标的链接阶段失败:ld: framework not found Realm for architecture x86_64.这可以通过显式添加Realm.frameworkRealmSwift.framework"链接二进制库"部分和目标中的以下构建设置来修复Pods-MyAppWidget.[debug/release].xcconfig:

FRAMEWORK_SEARCH_PATHS = $(inherited) "$PODS_CONFIGURATION_BUILD_DIR/Realm" "$PODS_CONFIGURATION_BUILD_DIR/RealmSwift"`
Run Code Online (Sandbox Code Playgroud)

但是,每当我运行时pod install,构建设置自然会被还原,我必须再次添加构建设置.

我看到以下解决方案:

  • 添加一个post_install钩子,每次添加这些设置,但它看起来像"hacky",经过一些错误的尝试,我没有找到API参考,也不知道如何MyAppWidget通过脚本将这些设置添加到目标.
  • 将Podfile更改为以下结构(甚至将其包装在抽象目标中):

    [...]
    target 'MyAppKit' do
        # Backend pods for networking, storage, etc.
        pod 'Alamofire', '~> 4.0'
        pod 'Fuzi', '~> 1.0'
        pod 'KeychainAccess', '~> 3.0'
        pod 'RealmSwift', '~> 2.0'
        pod 'Result', '~> 3.0'
    
        target 'MyAppWidget' do
            inherit! :search_paths # Because else we get the "conflicting names" error
        end
    end
    
    Run Code Online (Sandbox Code Playgroud)

    对于我而言,"小部件应该知道在链接期间要查看的位置,但不需要pod本身" ,这:search_paths似乎是合理的,但这并没有添加上述构建设置(我可能误解了继承)(编辑:它实际上有效,但不是抽象目标).这个想法来找我,因为在旧版本的CocoaPods中,解决方案显然是要添加的link_with,现在已经弃用了.

  • 将Realm暴露在MyApp目标中,但是这与我在主代码中无法访问"后端"代码的目标相冲突(它可能纯粹是美学的?).

所以,这是我的问题:在主要应用程序和扩展程序之间共享的框架中集成pod的最佳方式是什么,同时仍然能够编译,而无需调整并手动添加内容?

欢呼并提前致谢!


编辑

按照Prientus的评论,我探讨了抽象和继承的可能性.我现在发现的潜在问题实际上是多方面的:

  • 它曾经在Cocoapods 1.2.0之前工作,因为在小部件目标下声明的pod被嵌入到主机应用程序中但仍然链接到小部件.不,它只是拒绝在"主要与扩展"关系中为不同目标设置具有相同名称的pod
  • 使用抽象目标是不够的,因为目标不能仅从遗留目标继承搜索路径(inherit! :search_paths).
  • 搜索路径可以从真实目标继承MyAppKit,但是这会将所有这些pod暴露给MyApp代码(我想避免),并且仍然存在链接Realm框架的问题(因为实际上小部件使用了最微小的一点)一个吸气剂,因此需要它).

使用这最后一个选项并手动链接Realm.framework可以工作,但对于我的意图和以前的工作是不是最理想的.根据Cocoapods的GitHub上的各种 问题 ,其中一些问题似乎是一个错误.我添加了自己的问题,并在有新闻时更新.

Jon*_*ugg 12

那么,是什么给出了:

  • 我对"在目标之间分离豆荚"的关注是荒谬的,因为你仍然可以在任何地方导入它们.
  • "你必须手动链接"问题由一个简单的import RealmSwift声明修复.

因此,固定和工作的Podfile是:

platform :ios, '8.0'
use_frameworks!

target 'MyApp' do
    pod 'Eureka', '~> 2.0.0-beta'
    pod 'PKHUD', '~> 4.0'
    pod '1PasswordExtension', '~> 1.8'
end

target 'MyAppKit' do
    pod 'Fuzi', '~> 1.0'
    pod 'RealmSwift', '~> 2.0'
    pod 'Alamofire', '~> 4.0'
    pod 'KeychainAccess', '~> 3.0'
    pod 'Result', '~> 3.0'

    target 'MyAppWidget' do
        inherit! :search_paths
    end
end
Run Code Online (Sandbox Code Playgroud)

就是这样.我会说旧的行为更明显,并且不需要阅读"podfile目标继承".我确实学到了很多东西.干杯!


J.W*_*ang 6

我不认识你.但对我来说,扩展和主机应用程序包含框架定义的所有pod是完全合法和合理的.这就是我的意思:

def shared_pods
    pod 'Alamofire'
end

target 'Framework' do
    shared_pods
end

target 'Host' do
    shared_pods
    // Some other pods
end

target 'Extension' do
    shared_pods
end
Run Code Online (Sandbox Code Playgroud)

我知道你很担心,但如果你考虑一下,你使用的所有第三方框架都会有依赖关系.你不必担心它们,因为Cocoapods为你照顾它们.如果要使用它,则需要在列表中放置本地pod条目.

target 'Host' do
    pod Framework, :path => '../Framework'
end
Run Code Online (Sandbox Code Playgroud)

但是你必须维护podspec文件.