I have 2 frameworks created by me that use (both of them) a library also created by me.
The first framework initialize the library and makes all its workflow. After finishing the first framework, the second one must start.
But when the second one is going to start, after initializing the library, the app using both frameworks crashes with a exc_bad_access error.
Apparently the library is created correctly, but if i comment the line of code to initialize the library in the second framework, the workflow continues (it crashes later because it has no library initialization).
Is there anything I'm doing wrong? Should I use two separate libraries instead?
EDIT:
Imagine the situation:
Framework A has this methods: start, stop. And while it works it delegate to the methods: infoFromA,frameworkAFinished.
Framework B has this methods: start, stop. And while it works it delegate to the methods: infoFromB,frameworkBFinished.
Both start methods initialize the static library mentioned (lets call it problematicLibrary).
Both frameworks present some views to make its functionality. So lets make an example of the app workflow.
At the app view viewWillAppear method, I start the Framework A just using:
[FrameworkA start]; , this will initialize the library and present a view. With this view (using my problematicLibrary) some info will be delegated to the infoFromA delegated method. And after all the info is delegated, it will delegate to frameworkAFinished.
When the FrameworkA has delegated to the frameworkAFinished I start the next Framework: [FrameworkB start]. As the other Framework, it will initialize the library and present a view. While debugging, all the initialization of the library is done (create the instances of the needed objects and a new instance of the library is created) and while its presenting the view it goes through the viewDidLoad method and then it throws an exc_bad_access error at the problematicLibrary initialization line (which has been done before and continued to present the view!!) without going into any other method from the view.
I have checked if the initialization is doing well, and all the variables were at null value before the initialization, and a new memory address is given to the library object.
This sounds strongly like a symbol conflict to me. I'm just surprised the linker didn't catch it, but I assume that's because you're using a static library in both your frameworks instead of simply yet another framework.
Generally speaking, I'd warn that "this is a bad idea™". What you're trying to introduce into your design is basically dependency management. Like a lot of blog articles and specifically this SO answer suggest, you should avoid packaging frameworks (and by extension libraries) into frameworks.
What most likely happens in your scenario is this (I admit I'm guessing a bit here): You linked the library into Framework A. Thus, the library becomes a fixed part of it. Its symbols are in it, even if you did not expose them to the app in any header files or the like. As long as you use only that, everything works smoothly. Then comes Framework B, of which the library is also a fixed part. Even though you can't see it from your app, the very same symbols are inside it. This, however, clashes with the symbols that were already loaded by Framework A, hence a crash (as said, this would usually be caught by the linker, but I guess you "tricked" it by building the frameworks beforehand and packaged the library in them). Maybe somebody else can explain this in more detail, but that quickly becomes besides the point as to how you would go for a solution. From how I see it, it just won't work this way.
So here's a suggestion for how you can solve your problem:
If you really, really need to split like this (two frameworks used in your app using the same dependency), I'd suggest removing the library from the frameworks (i.e. make them depend on it, but not package the actual .a file in them) and documenting that properly. Then add the library to your app project, just like you added the frameworks.
If you want to make this fancy and easily installable into other apps, I'd recommend setting up a private CocoaPods repository and turn your frameworks into private pods. You can then easily define the library (or rather "new Framework C") as a dependency for Framework A and Framework B. When you then pod install in your app, cocoapods figures out the dependency and adds Framework C automatically to your project. This scenario is exactly what cocoapods (or any dependency manager for that matter) was designed for. It automates and helps in the project setup, so that the final build (the app) doesn't have to figure out dynamically what it can and can't use. The end result is the same.
Trying to duplicate that "in code" quickly becomes messy. Frameworks trying to figure out things of the surrounding app/project that uses them (like "is my dependency so-and-so already linked? if not, can I load my own version of the library?") can lead to a lot of pain.
Okay, in response to your comment I'll try my hand at a more detailed How-To for the non-cocoapods setup. As a preface, though, let me say that that's kinda hard to do on top of my head, as I have no ready sample project to toy around with. Since this is one of those "set it up once and then forget aout it for a long time" I have to admit my recollection of these things is a bit fuzzy, so consider this as a sort of "rough direction". There might be things you need to configure differently than how I recall them. Other SO user are thus hereby invited to edit and correct my answer here, too. :)
First, I have to say I am not exactly sure whether you need to convert your static library into a framework or not for this, I think you don't so I'll go from here (I have never used a static library in that way).
That means you can leave the project that builds your library as is. On second thought, you probably have to do this to be able to link against the library without making it a part of the framework that uses it. I will still refer to this code as "library" in the below points, but assume that you're able to turn it into a dynamic framework as well.
The projects building Framework A and Framework B should be changed. I don't know how you have this set up (as one project with various targets, whether you have a "development application" as part of it to test the frameworks on themselves, etc.), but the important thing is that in the target that builds a framework, the library should be linked (i.e. in the "Link Binary With Libraries" build phase), but not copied (i.e. it must not be in the "Copy Bundle Ressources" build phase). It might be tricky to set up any development/test target you use to run, depending on how you did that so far. For example you might have to manually edit Library Search paths in your build settings to be able to properly compile the framework.
Lastly, you need to change your final app's project settings, obviously. The library that was originally part of Framework A and B now needs to be linked to from its project directly, and, obviously, it needs to be copied into the bundle as well. Note that any projects that include either of your frameworks (A or B or both) in the future must do so, otherwise they won't work, because these frameworks expect the library to be present (but no longer "bring it with them").
In spite of this long-ish text wall, it shouldn't be that complicated, I think, but you may still want to check out how cocoapods can support you with something like this, perhaps it's helpful in the future. The linked article expects basic knowledge on how to use a pod and write one, but the other guides on the site explain that pretty well. I am just saying this because in the end, when using cocoapods in a project to add multiple libraries/frameworks that introduce dependencies, it basically sets up your project in the way I described above. It uses some fancy shell scripts that ensure everything is copied to the correct folders and such, but overall speaking that's how it works: A pod's podspec tells cocoapods what additional pods to include in your app for it to work (a dependecy the pod expects to be there, but doesn't "bring in" by itself).
Check if they are both compiling for the same target.
Check if they have access to the same target membership.
Check build phases to see that they are both there.
I think because the first library is not 'well' referencing the second one.
Also i think that you can't import a framework inside another one.
To make things easier, you can merge the two frameworks on a single one.
Also you can add a callback (using protocols or closures) that informs for the end of the first workflow, and you use this callback to initialize the second framework. This way the initialization will not be made automatically.
I have a library project (A) and a Metal library project (M). M is included into A in the "Copy files" phase. That introduces a build dependency, meaning that I can't build A for the simulator because it tries to build M first, and Metal is not supported on the simulator.
That's fine, but the problem is that A contains some unit tests, and when I try to test the project, I get this error message,
Logic Testing Unavailable. Logic testing on iOS devices is not supported. You can only run logic tests on the Simulator.
But I can't build for the Simulator because of the aforementioned dependency...
I read https://medium.com/the-sup-app/bare-metal-working-with-metal-and-the-simulator-70e085e3a45 -- perhaps this could help me removing the dependency of M in A for the simulator, but I'm trying to do this without Cocoapods, purely in Xcode.
Is there any workaround for this?
I ran into this exact same thing over the weekend. Tried to be a good citizen and include unit tests in my Metal project. ;-)
The only way out of this catch-22 is to not use XCTest for writing unit tests but create a separate target that runs as an app on its own. This new target then runs the unit tests.
In the old days I used GHUnit for this but I do not know if there is a suitable replacement for it these days.
Worst case scenario you can write your own little unit testing library that runs the XCTest macros.
So I am running into an issue where my Framework needs access to the KeyChain. That's fine, but it seems to fail when running in the simulator. Digging around it seems to be a known issue that xctest does the wrong thing here. Fair enough, bugs happen. In the Apple Developer forums it's discussed here:
Right.
This is a well-known issue with library tests (sometimes called logic tests by Xcode). Those tests are run by a tool (xctest) that does not have entitlements. Historically this caused problems for folks using custom entitlements (to access CloudKit, for example) but now it affects folks using the keychain as well.
AFAIK there’s no direct workaround. However, I believe you can avoid the problem by running this test code within your app (emphasis mine) (in the docs this is called an app test).
Because these run inside your app, they get the app’s entitlements.
If you don’t have an app handy, you can create a dummy one just to host the tests. (emphasis mine how do I do this?)
Please try this out and let us know if you hit any snags.
Oh, and don’t let the availability of a workaround prevent you from filing a bug about this. Xcode should be able to run library tests with entitlements, and this recent keychain change makes this even more important.
Share and Enjoy
https://forums.developer.apple.com/message/179846 (see: Eskimo's reply on Nov 4, 2016 2:12 AM)
He again goes on to say in another reply:
You can avoid the problem by running your tests within an app, creating a dummy app if you don’t have one handy. (emphasis mine)
Feel free to file your own bug about this limitation.
So again he references:
You can avoid the problem by running your tests within an app, creating a dummy app if you don’t have one handy.
I'm more than happy to do this, I just can't seem to figure out how.
The parts I have:
Framework Project
|
|- Unit Test Target
|- Framework Target
Dummy App Project
|
|- ??? How do I make this run the Framework's Unit Test Target?
Ah, this article helped:
https://medium.com/#ryuichi/setup-host-app-for-keychain-tests-in-xcode-8-97222611917e#.z3zpqwnzt
I was adding a totally new app project, I just needed to add a new Target in the Framework project for a Single View Application
That then allows me to select Host Application in the testing target.
Using my previous diagram, the final result that worked is:
Framework Project
|
|- Unit Test Target
|- Framework Target
|- Dummy App Target
I once asked a question related to XCTests. And in one of the answers I was told that it is a common practice to use a separate test target (other than the main app) when running unit tests (at least, in iOS development). I tried to find some sources about it, but I couldn't
I understand, that it is probably a best practice, so I would really like to understand it. Could someone explain to me why is it important, what benefits do I get from it and how should I go about doing it? Links to some articles explaining the issue will be much appreciated.
P.S. I understand that I need special environment for tests (fake in-memory database, mocked networking layer, etc.), but up until now I managed to achieve it without a separate test host. But I believe that there might be a better way.
To answer your points:
Why is using a separate test target important?
Separation of concerns. A unit test target does not have the same kind of structure as a regular app target - it contains a test bundle, which references the app target under test, as well as the test classes and any helper classes required. It is not a duplicate of the app target with test code added to it - in fact it should not even contain the code under test. This means that you don't have to make any special effort to keep the test target in sync with the main app target - the fact that the test bundle loads the main app handles all that for you. (You made a comment on Richard Ross's answer to your previous q suggesting you've run into the difficulties duplication causes already).
How should I go about doing this? (checked on Xcode 7).
Assuming you are wanting to add a target to an existing project that doesn't have any tests, select the main project, and then click on the '+' beneath the list of targets in the project. You can also use the File->New->Target menu option.
You'll see a menu asking you to choose a template for your new target. Select 'Test' and within test select 'iOS Unit Testing Bundle'.
Check the fields in the next screen - they should be correct by default - but you might want to double check the 'Target to be Tested' field value is correct if you have a lot of targets in the project/workspace. Click 'OK' and you should have a functioning unit test bundle, with an example test that you should be able to run using Apple-U or Product->Test You'll still need to #import the app classes if you're using ObjC.
If you are creating a new project, all you need to do is tick the 'Include Unit Test' box when creating the project - no other steps are required.
Apple Docs (with links to relevant WWDC presentations)
Tutorials. Most of the tutorials around are a bit out of date. But not that much has changed, so just look at the docs and figure it out. The two below might be useful, otherwise just google. From a quick glance, most of them seem to assume that the project had unit tests set up at the beginning
http://www.raywenderlich.com/22590/beginning-automated-testing-with-xcode-part-12 (2012/iOS 6, but the process is still broadly the same. Also deals with Jenkins, Git and running tests from the CLI).
Unit testing in OSX - most recent post - not iOS, I know, but more up to date than most of the iOS tutorials (Oct 2015), and gives step by step instructions (including setting the unit test target in the build schemes, which probably won't be necessary in your case). Probably worth a look anyway.
I'm making a swift .framework, but I'm running into what I believe is a build problem. So I've simplified everything to isolate my troubles. I've attached a screenshot of my newframework.framework project (top) and my example usage of the framework (bottom). The problem I'm having is that Whatever class is unavailable when I include newframework.framework. I can confirm that Whatever.swift is indeed included in target>>buildphases>>compile Sources
What could cause this not to work?
EDIT - Adding App Build phases screenshot
Your problem, as we figured out in comments, was that you were building your framework for "Generic iOS Device" and building your app for the simulator. Xcode can't make the app build without matching architectures, so you need to choose one over the other or produce a framework that includes every architecture.
(This was posted to help people who come here from the future find the answer quickly. Hello, future people!)