CocoaPods does not build LaunchAtLoginHelper.app (and can't)

[Wes]

I could never get LaunchAtLogin to work when I consumed via CocoaPods so I had some time this weekend to dig in and here is what I found...

Short Version

The podspec is only producing the LaunchAtLogin.framework, not the Helper.app so consuming LaunchAtLogin via CocoaPods is busted... and also, the fix is not straightforward. I would recommend removing LaunchAtLogin from CocoaPods and updating the documentation to only support Carthage as the way to distribute your library.

Long Version

Your repo builds 2 targets (the LaunchAtLoginHelper.app and then the LaunchAtLogin.framework). The current podspec is just building 1 target (a framework), so there is no .app to copy when copyhelper.sh is called. You wouldn't know that from the build output because the script mistakenly returns a success exit code even though it can't find the LaunchAtLoginHelper.app.

I tried to update the podspec with 2 subspecs so that it would first build the .app and then the .framework but I don't think it's possible to get CocoaPods to build a .app. It always assume you are building a .framework. CocoaPods tries to figure out your build config, so it generates its own xcconfig and info.plist (there was discussion here about using the xcodeproj settings but that never materialized). After much searching online I failed to find any example or documentation about generating a .app from CocoaPods... it kind of always assumes you are distributing libraries. I tried copying the .app's info.plist and setting the INFOPLIST_FILE in the xcconfig to point to it but I never could get it working. Carthage works because it uses your actual build config and info.plist. I do believe there are ways to make CocoaPods work, but it's probably easier to just tell people to use Carthage. Which leads me to...

Options to fix this

1. Give up on CocoaPods and just recommend people use Carthage to consume LaunchAtLogin. I know some people (like me) only like to use CocoaPods for getting their dependencies and mixing podfiles with cartfiles sounds like it could cause issues, but in practice it should be fine for this library. LaunchAtLogin does not have any dependencies so it's not like consumers would run into dependency collisions between what CocoaPods and Carthage are pulling down. This is now how I'm consuming the library (mixing podfile and Cartfile) and I haven't run into any issues yet.

2. Make a build script to build the Helper.app that would run before executing copyhelper.sh. You could use xcodebuild in a script to make sure you build the Helper.app and maybe it wouldn't be too hard to do. Just have to make sure the script is building the correct version of the helper.app (debug or release - or maybe just always build release?). It would be one more script to write and debug if people have issues, but it's do-able.

3. Checkin the Helper.app binary and have CocoaPods pull it down with the source. I came across a blog post talking about distributing binaries with CocoaPods so it seems do-able.

Next Steps

@sindresorhus I'll leave you to decide which option to go with (or maybe there is another option I'm missing). If it were me maintaining this I would keep it simple and go with option 1. If you do want to go that route I can make a pull request to update the README and fix the copyhelper.sh script to set the exit code on error. All you would need to do (besides reviewing and merging that PR) is pod trunk deprecate LaunchAtLogin.

BTW, you can probably resolve #21 and #7 as dupes of this (and maybe #11? Although the original post was using Carthage so maybe it's not a dupe, just some of the comments are from people hitting the CocoaPods issue).

[Wes]

@sindresorhus Any thoughts on this? I'm sure you are busy, I would take care of making the pull request with updated readme (and reasoning) if you want to go with option 1.

Thanks!

[Wes]

@sindresorhus Have you had a chance to read this issue? Thanks!

[Sindre Sorhus]

@wes566 Sorry for dropping the ball on this and thanks for elaborating. I think the best way forward is to drop support for CocoaPods. I don't use it personally, so I'm not interested in maintaining difficult workarounds. And as you said, people can still use Carthage for this package, even if they mainly use CocoaPods.