It is certainly something we would consider (if it is possible
to have binary only library dependencies with Carthage).
You don't need to use Cocoapods to use Reveal. You can just
bring the binary framework into your project like you would with
any other binary .framework. So don't think that using
Reveal ties you to Cocoapods.
Have a look at the "Linking the Reveal Server framework into
your application" section of the Reveal Integration Guide in the
Reveal Help menu.
I agree with Michael and we are in the same situation where we are migrating away from CocoaPods to Carhage. Sure we could link to the framework manually but since we have a dependency manager it simplifies things greatly if we could use it.
Installing it on a breakpoint is an option but that also has the same complexity as adding it manually plus the burden of doing it on every developers machine.
We are almost at a point were we are thinking of not even using Reveal in our project. I would personally not like it if that happened, so please take a look at getting Carthage to work again.
I just wanted to chip in about possible Reveal Server support for Carthage, what it would and wouldn't allow you to do. The integration methods outlined in our Integration Guide have been carefully developed to ensure that users of Reveal don't accidentally link the Release version of their app with Reveal Server framework. As mentioned in the guide:
Never ship an app linked against the Reveal library. Reveal exposes your app to deep introspection and will likely cause your app to be rejected by the Apple review team. Reveal is intended for internal development and debugging purposes only.
This important requirement is reflected in each integration method:
When Using CocoaPods, Reveal Server pod can be included in such a way that guarantees it will only be linked in the Debug configuration, but not Release. CocoaPods itself handles the logic of using a different set of libraries for each configuration, and its user (the app developer) doesn't have to manage this manually.
When Loading the Reveal Server via an Xcode Breakpoint, this becomes trivial: the breakpoint obviously won't be triggered outside of a debugging session, and Reveal Server will not be loaded. If debugging on device, the build phase script we provide ensures that the app bundle will only contain Reveal Server as a resource in Debug builds.
When Linking the Reveal Server framework into your application, we use a combination of specific build flags and a build phase script to ensure that the framework is only linked in Debug configuration. It's not a very simple integration method, but that's because simply dropping a framework into your project will link and embed it for all configurations, which is not what we (and our users) want.
Now, back to Carthage. In contrast to CocoaPods, Carthage has been designed to provide a "lightweight" dependency resolving and building functionality, offloading the steps required to actually link them to Xcode. This means that if we were to ship Reveal Server as a binary framework for Carthage, correct integration would not be much easier than with the Linking the Reveal Server framework into your application method: you would still need to include a special build phase that ensures that Reveal Server is only linked in Debug configuration. Carthage does not provide such functionality out of the box, as far as I'm aware. This raises a question: is it really worth supporting an extra integration method, given the limited benefits it provides over existing ones? If you believe that the answer is "yes", please let us know. Just keep in mind that the integration steps required would not be as simple as with CocoaPods.
Now, regarding the integration complexity. I understand that this is a point of frustration: we all would love to be able to integrate Reveal easily and without extra steps or build phases required. Unfortunately, for the moment we don't see a way to go beyond the integration methods we provide in the Guide, for a simple reason: Apple has been and is constantly locking down the iOS ecosystem. Two main problems we have faced recently are:
Starting from iOS 10, it's not possible to load binaries (even signed correctly!) from a writeable sandbox of your app on device. This means that we cannot provide some sophisticated mechanism that automatically uploads Reveal Server framework into your app's sandbox, loads and starts it. It was an idea that we explored, but realised it's not possible anymore. Other apps/libraries, like Injection for Xcode, have faced the same challenges.
Xcode 8 does not support third-party plugins anymore. Originally, prior to shipping Reveal 2, we planned to provide an Xcode plugin for Reveal that would drastically simplify the integration, making it a single-click experience for any project on both Simulator and device. Alas, this was not meant to be: even though we implemented the plugin, and it worked great on Xcode 7, quick testing with early betas of Xcode 8 showed that we can't do this anymore.
So while we're always on a lookout for better ways to let our users integrate Reveal into their apps, the methods we provide seem like the best compromise that we have at the moment. I would also like to highlight the fact that integrating Reveal using a breakpoint (which is, in my opinion, the simplest and the least invasive method) actually consists of just two steps that enable Reveal debugging in all projects on the local machine/account in Simulator:
Create a breakpoint and move it to "User breakpoints".
Use Help → Install Debugger Commands menu in Reveal.
And you can enable/disable the breakpoint as a way to control whether Reveal is loaded into the app or not. For debugging on device, we provide a build phase script that works around the limitations I've described earlier. This script becomes a part of your project, but works on any developer's machine without stopping your app from building, even if that developer doesn't have Reveal installed.
I hope this clarifies things a bit. Please let me know what you think, and whether you still believe that Carthage support would be beneficial to you.
on 08 Apr, 2017 04:12 AM
We already have a "Copy Carthage Frameworks" build phase as outlined
here: https://github.com/Carthage/Carthage/#getting-started. I would
personally be fine having an additional "Copy Debug Carthage Frameworks"
phase that is the same thing wrapped in an `if [ "$DEBUG" ]`
Will look into the breakpoint option but it's not as preferred as the
above due to the issue Seb mentioned of added overhead for each