Hi @benjohnde !

Thanks for this addition!

I tested by adding it in a fresh iOS project it works fine.
But I stil have trouble using it in a podspec as subspec (as there's no published version yet).

Having a published version on cocoapods will help a lot.

Hi @benjohnde !

Thanks for this addition!

I tested by adding it in a fresh iOS project it works fine. But I stil have trouble using it in a podspec as subspec (as there's no published version yet).

Having a published version on cocoapods will help a lot.

That's actually good news :) Then I have to find out if there exists a better way to lint the spec (lint does actually more than just linting, it validates the spec by compiling the Pod, creating a demo project and integrating the pod). I couldn't find a meaningful way to lint the spec (for some pre-release check) against my local host without replacing the source.

Done, CI should turn green in the end 🤞 !

@axxel it is still some decision whether you want to release the CocoaPod integration officially.

If so, after an official release one would need to adjust the s.version = '2.1.0' (according to the new version) and release the Pod by running pod trunk push, cf. https://guides.cocoapods.org/making/getting-setup-with-trunk.html. Then it gets published on CocoaPods.org and is officially available.

I am not super familiar with github-actions but there should be a way to automate that after a new version was tagged / published - somehow we should think about that for published android versions as well.

Nonetheless, this Pod is working and releasable.

Thanks for the continued effort. I will merge this but have a couple of open questions:

1. So the s.version string has to be kept in sync manually on every release?
2. I'm not sure I understood the validation situation: the file is 'valid' as is or we'll only know after the first release and if it is not, we'll then need to fix it and make another release (like 2.3)?
3. I'd like to bring up the naming subject again, now that a new namespace (cocoapods.org) is entered. I'm talking about the ZXingCpp vs zxingcpp vs zxing-cpp vs ZXingCppWrapper situation. For reference, please checkout point 7 here and the followup discussion as well as point 1 here. If it were not for the limitation of not allowing '-' in some contexts, I'd prefer if it was called zxing-cpp (most of the time). Bottom line: we have some rather incoherent naming mess right now and I'd like to not make that even more random. If I compare the cocoapods.org situation with pypi.org, then calling the entity zxing-cpp even though the thing you need to later include/add/link is called zxingcpp (Python) / ZXingCppWrapper (CocoaPods) has some consistency to it. I imagine on the Android side the same question will show up when looking for a name of the thing on MavenCentral, etc.? The Android module itself is called zxingcpp again.
   That also makes me wonder whether the term ZXingCppWrapper is actually still required, now that the core code and wrapper code ended up in one single framework? Why not simply call it ZXingCpp before potentially a lot more people start using it?

As the last part of the naming question is affecting all iOS users, let me ping the rest of the bunch again: @alexmanzer @parallaxe @ryantrem

Thanks for the continued effort. I will merge this but have a couple of open questions:
That also makes me wonder whether the term ZXingCppWrapper is actually still required, now that the core code and wrapper code ended up in one single framework? Why not simply call it ZXingCpp before potentially a lot more people start using it?

@axxel I'm right there with you. 👍🏻
This has always disturbed my inner Monk a bit, because as an end user of the lib I want just to use ZxingCpp and be able to write import ZxingCpp in my sources instead of caring about an "Wrapper".
It's not a big change, but in my opinion it's an important one in terms of consistency.

I have created a separate PR, which is independent of this CocoaPods topic here:
#638

3. I'd like to bring up the naming subject again

Absolutely d'accord with renaming it to ZXingCpp!!!

1. So the s.version string has to be kept in sync manually on every release?

Yes, sadly! Not sure if there exists another way of dealing with that honestly!

2. I'm not sure I understood the validation situation: the file is 'valid' as is or we'll only know after the first release and if it is not, we'll then need to fix it and make another release (like 2.3)?

No, or I did misunderstand the question.

• pod lib lint checks the podspec file, builds the podspec file, bootstraps a demo project and includes the Pod there, so basically a full-check (all locally)
• whereas pod spec lint does the same but checking against the provided repository including the tag version, basically after that works you can push the Pod up to CocoaPods in a chilled mood

I just merged the renaming, so the podspec needs a final update and we are good to go, right?

@axxel rename is pushed

Thanks for the continued effort. I will merge this but have a couple of open questions:

1. So the s.version string has to be kept in sync manually on every release?
2. I'm not sure I understood the validation situation: the file is 'valid' as is or we'll only know after the first release and if it is not, we'll then need to fix it and make another release (like 2.3)?
3. I'd like to bring up the naming subject again, now that a new namespace (cocoapods.org) is entered. I'm talking about the ZXingCpp vs zxingcpp vs zxing-cpp vs ZXingCppWrapper situation. For reference, please checkout point 7 here and the followup discussion as well as point 1 here. If it were not for the limitation of not allowing '-' in some contexts, I'd prefer if it was called zxing-cpp (most of the time). Bottom line: we have some rather incoherent naming mess right now and I'd like to not make that even more random. If I compare the cocoapods.org situation with pypi.org, then calling the entity zxing-cpp even though the thing you need to later include/add/link is called zxingcpp (Python) / ZXingCppWrapper (CocoaPods) has some consistency to it. I imagine on the Android side the same question will show up when looking for a name of the thing on MavenCentral, etc.? The Android module itself is called zxingcpp again.
   That also makes me wonder whether the term ZXingCppWrapper is actually still required, now that the core code and wrapper code ended up in one single framework? Why not simply call it ZXingCpp before potentially a lot more people start using it?

As the last part of the naming question is affecting all iOS users, let me ping the rest of the bunch again: @alexmanzer @parallaxe @ryantrem

I see this was already merged, but I'll add some thoughts regardless. One question for me is whether it is more ideal to have a single podspec, or one per "layer." For example, it's really important at a CMakeLists.txt level to have core separate from specific language bindings ("wrappers"). This makes it easy to use the core library in C++ code that is compiled for different platforms (e.g. Android, iOS, etc.) but doesn't use platform specific languages (e.g. Java, Objective-C, etc.). I wonder a little bit if we'd want the same thing here, where there is a podspec for language bindings that depends on a podspec for core. If a consumer can depend on a single podspec that has both core and language bindings, but can safely ignore the language bindings, then maybe the podspec situation is fundamentally different from the CMakeLists.txt situation, and a single podspec is ok.

I see this was already merged, but I'll add some thoughts regardless. One question for me is whether it is more ideal to have a single podspec, or one per "layer." For example, it's really important at a CMakeLists.txt level to have core separate from specific language bindings ("wrappers"). This makes it easy to use the core library in C++ code that is compiled for different platforms (e.g. Android, iOS, etc.) but doesn't use platform specific languages (e.g. Java, Objective-C, etc.). I wonder a little bit if we'd want the same thing here, where there is a podspec for language bindings that depends on a podspec for core. If a consumer can depend on a single podspec that has both core and language bindings, but can safely ignore the language bindings, then maybe the podspec situation is fundamentally different from the CMakeLists.txt situation, and a single podspec is ok.

Love these thoughts, I initially created two subspecs, Core & Wrapper. Then I skipped that approach as I weren't sure if one would want the Core without the Obj-C wrapper code. I can provide a recommendation @ryantrem if that's of interest for the react-native realm!

Preparing the 2.3.0 release, I came by the cocoapods.org page again and was surprised that searching for neither zxing nor zxing-cpp revealed anything about out project. Does anyone know what is going on? I would have hoped the project page would be discoverable via search.