Closed marcelvoss closed 4 years ago
For example, as the library is no longer being delivered as .zip, we can no longer use our CocoaPods spec.
What if you add a script_phase to CocoaPods to download the c library and add it to the sources afterwards?
We also use CocoaPods and I have been wondering from the beginning why the client library was not included in this repository. We actually have a private spec, too, which is just a combination of the client library and the code provided by this repository to make both available as a single pod. This however requires tedious manual work when having to update the client.
Having that said, is there any reason why you only support Carthage out of the box? Considering that CocoaPods is still very popular in the community I believe adding a .podspec
as well as the client library will make things easier for many teams integrating fiskaly into their apps.
Thanks for all your comments, we are listening to all of them.
Our team is working hard to make every SDK we are providing as bug-free and easy to use as possible. Our prioritization focuses more on bugs before we are addressing QoL changes and improvements. As we are receiving reports on Github as well as other platforms, the Issue count you are seeing on Github doesn't represent the actual number.
We can see that having Cocoapods available for this SDK is a much needed and wanted improvement. Therefore we increased the priority of this.
Thanks for your time and your reports.
Example Podfile can be found here for now:
https://github.com/fiskaly/fiskaly-sdk-swift/issues/24#issuecomment-665474624
Hi there, it's me again.
Today I tried updating our private podspec definition for this repo, and realized there is now a run script build phase included that downloads a fixed version client from a CDN. I honestly, don't understand the reasoning here. It has a fixed version identifier anyway and the repository needs to be updated once the client has been updated. Currently, this makes our setup that is required to make this work in our environment even more complicated. It currently feels like there is a dance around this and there is no clear answer for simplifying this (although the solution seems to be rather simple).
Can we go the simple (and straightforward way) of checking the client in into this repository? In addition to simplifying things, it would also make versioning easier for y'all. Then a version on GitHub, always also refers to the correct version of the SDK explicitly. @prempador