What is the best approach to access project source files (.h/.m or Assets.xcassets) under podfile. I'm using a library and want to access my source files in my project. I don't want to hard code anything because I'm using some globally defined parameters.
- I guess podspec is one option (not sure), but I don't want to call pod update each time I made a change in podfile.
See attached image:
If you are using those classes in a single project, then there is no advantage in putting them in a separate pod. If they are used in multiple projects and are rarely modified, then you can consider creating a private Pod. In that case, however, you will need to call pod update every time you release a new build to your private pod.
Related
When I set path for my development pod, I cant commit podfile - it will break pod install for other devs. So I keep podfile in another change list and its really annoying. Is there a better way to develop pod?
I found this: link, it suggest to change to path every time I want to update something in my pod. But it's even worth than uncommited podfile.
You can use relative paths for development pods.
You can ask your co-developers to always use the same folder hierarchy between your current project (with the podfile) and the others developments projects/pods (with the podspec).
You can also use Repo to automatically do it for you (could be useful when a new guy comes, and/or if you have plenty of different development pods). It will install different projects/(development)pods according to the hierarchy set in its manifest. You can check this related answer if needed.
I have a app which historically has grown a lot and to be a bit cleaner and to have the option to give out code to third party developers in the future, I was thinking about splitting my project into multiple projects which I then could export as a framework.
Currently everything is in one big project. I have:
4 App targets
Shared view controllers
Shared web services
Shared model classes
Shared utility classes
Shared extensions
Shared protocols
The thing is that not every web service is used in every app. Not every protocoll is used in every app. Not every extension is used in every app and so on.
Now correct me if I'm wrong but can't I put, for example, the web services in their own framework and then use the framework in the project where I have my app targets?
Can I do the same for a "core" which contains all utilities, extension, protocolls and models?
Can I then use the "core" in the webs service framework as well as in the app targets?
What would such a structure look like? I already tried creating two framework projects and then use one framework inside the other but I cant build it. Is it because I would need to use Cocoapods inside each of the framework projects? Is that possible?
The web services for example would need "RxSwift" and "Moya" but the "Core" would also need "RxSwift".
Do I have a wrong thinking here? Shall I only use one Core framework and put everything in there which is shared? I'm confused and probably lack the deeper understanding of how the frameworks work.
I'm using CocoaPods and have separate from main app web service and core frameworks. This way it looks in the project:
Lets start with core because even web service depends on it. I call it Common instead of core and it is available on GitHub. It contains multiple subfolders which represent frameworks they extend. And there are two podspecs.
CommonExtended contains functions that are not available in app extensions (for example in Today Extension) and depends on Common. So, splitting core into two separate frameworks provide a way to use it in both main app and app extensions. Although Common is available on GitHub, I download and use it locally (but it can be downloaded from remote whenever you update your pods, you just need to specify remote address)
web service is a local folder which is called Api and its podspec looks this way:
As you can see, it has such dependencies as RxSwift, Moya and Common (the desired behavior from your question - framework contains framework).
So, whenever I need to use any of the frameworks in an app or its extensions - I just specify what kind of framework is required as dependency:
Then just import your frameworks and use them:
import Api
import Common
import CommonExtended
P.S. This is just an experiment, I'm not a CocoaPods professional. But it works for me.
Edit. Local pods are easy to update. You just make changes and see them in your project (as I remember Cmd+B on main project makes the changes to be visible). But this only works with files in local pod which already exist. If you need to add new file to a local pod - run pod install to make this file visible.
All the local pods are 100% local and they live in the same repository as main project. But Common is a remote repository which is downloaded locally. Why? Because it is used in different projects. So, on each machine you have to write its own path to Common in podfile. This link provides a way to define a path to Common on each machine and never change podfile again. Don't forget to commit Common changes to the remote. Other local pods will be committed with the project automatically.
I have my own private specs repository with internal pods. I used to add prefixes to the pods, however now I'm migrating to Swift I'd like to get rid of them.
However if I get rid of the prefixes (e.g. JAMNetworking to Networking) and I specify two sources in the Podfile, I'm getting conflicts as Networking is a existing public pod from the master repository. I know one possible solution is to specify the git repository url next to each pod, but it's annoying for me to add the url for each pod so I'm searching for an elegant solution. I have some ideas, but none of them seemed to work:
A) Add a name to the source and specify the source name for each pod, e.g.
source 'master', 'https://github.com/CocoaPods/Specs.git'
source 'internal', 'https://myurl.git'
pod 'samePodName', 'master'
pod 'samePodName', 'internal'
B) create two definitions with the source specified inside:
def publicPods
source 'master', 'https://github.com/CocoaPods/Specs.git'
pod 'samePodName'
end
def internalPods
source 'internal', 'https://myurl.git'
pod 'samePodName'
end
target 'MyProject' do
publicPods
internalPods
end
Unfortunately this only takes one of the def as valid and ignore the other one...so in this case it would install the public one. If I switch after installing then uninstall the public one and installs the internal one.
C) Create multiple targets. It's returning an error about multiple targets with the same name.
Do you think it's possible to find an elegant solution without adding the url for each pod or avoiding adding prefixes?
The elegant solution at the moment is to retain your prefixes. Consider
a) It's commonly agreed that best practice is for your pod to be named identically to its exposed Swift module
b) Swift modules may not link to another module with a duplicated name
... which renders moot the question of how to manage duplicate pod names.
Erica Sadun came to the same conclusion here. Until something like the reverse-DNS identifier proposed therein comes to pass,
Package names need to be clear and specific, yes, but they should avoid terms that will overlap because when you have a package called SwiftString and every Bob, Jane, and Harry also has a package called SwiftString, name collisions are inevitable...
And, until then, prefer SadunSwiftString to SwiftString and avoid the issue from the start.
stick with the prefixes since the real problem here is Swift's lack of namespacing above the module level. And by the time that's resolved we'll all be using SPM, no doubt!
I have an Xcode workspace that uses CocoaPods to include several third-party frameworks. I would like to edit a line of source code within one of these dependencies. However, when I do so, Xcode warns me that the file is locked and that any changes I make may not be saved. So my question is: will my changes to the source code be discarded when I run a pod install/update? If not, is there any other scenario, possibly unrelated to CocoaPods, that would discard my changes? And finally, is there any good way that I can edit the source code without running into such problems?
Thanks in advance.
You can not make changes in Original Pod file. If you want to add some more features then you have to fork that particular repo.
Follow steps to do so :
Find library you want to use on Git.
Fork library.
Update Podfile which refer to your forked version.
Suppose I want to fork GPUImage Library. Then point your fork in Podfile as given.
pod 'GPUImage', :git => 'https://github.com/UserName/GPUImage.git'
Make your changes.
Commit/push your changes to your forked repo.
Submit a pull request to the original author of Library.
If pull request is accepted and the pod is updated, revert back your Podfile to use the public pod.
You can create Category (Objective C) or Extension (Swift) to extend or add some features to existing class.
You can do this simple. Just modify the pods src code. Switch to another brach and switch back. Xcode would rebuild pods with your modified code.
If you want go back, you should remove the pod in Podfile, execute pod install.Then add pod back, execute pod install.
This solution is just for debug.
For permament, you should take #technerd 's answer
In fact there is another way in which you can modify the library as per your custom needs and get future updates from the library, all while still maintaining it via cocoapods
I have written article/tutorial explaining the same.
https://medium.com/#mihirpmehta/how-to-modify-cocoapods-library-within-pods-647d2bf7e1cb
I have a library that I'm using through Cocoapods, and I'm modifying it slightly. I have a class I've created in my normal project (outside of Cocoapods) that I want to use in the Cocoapod, but when I try to import the file it says that file doesn't exist.
As pods are seemingly achieved through a separate project within the same workspace, I assume that's the reason why I can't access it. How would I access it, however? Do I have to import the file separately into the Pods project and then maintain two separate versions? Or is there a better way?