I am currently building out a test suite in an Xcode workspace that contains 3 existing projects. 2 App projects and a common framework project. Both apps are very similar in regards to UI with some minor differences.
I am trying to find a way to share the XCUITest framework I made for App A with App B.
Currently, App A has a test target set inside of its AppA.xcodeproj. All of App A's tests are doing great and easy to maintain. I need to extend this to App B and refactor App A's framework to only the App A exclusive bits so App A and App B can share the common XCUITest framework code base from a central base.
I have tried to create a new project, move over the UI test code and point the new UI Test target at App A's executable, but I could not figure out how to get the option to show.
I set the App A app as a Target Dependency in the New Project's test target > Build Phases tab, but no luck. I was able to set App A's target in the new test target's scheme but still landed on an error.
Assertion Failure: CommonBasePage.swift:21: failed: caught "NSInternalInconsistencyException",
"No target application path specified via test configuration: <XCTestConfiguration: 0x60400014e910>
testBundleURL:file:///Users/user.name/Library/Developer/Xcode/DerivedData/.../Debug-iphonesimulator/NewTestTarget-Runner.app/PlugIns/NewTestTarget.xctest/
testBundleRelativePath:(null)
productModuleName:NewTestTarget
testsToSkip:(null)
testsToRun:NewBasePage/testExample
reportResultsToIDE:YES
sessionIdentifier:<>
pathToXcodeReportingSocket:(null)
disablePerformanceMetrics:no
treatMissingBaselinesAsFailures:no
baselineFileURL:(null)
baselineFileRelativePath:(null)
targetApplicationPath:(null)
targetApplicationBundleID:(null)
testApplicationDependencies:
{...
I'm assuming targetApplicationPath:(null), targetApplicationBundleID:(null) should have legit target values but I'm unsure where else to look in order to set them.
I gave up on that and tried to create a new project & target as a Cocoa Touch Framework to shift the common code to a central point but was not able to import XCTest, which my framework depends on for XCUIApplication and XCUIElement fields.
import XCTest //Causes "Cannot load underlying module for 'XCTest'"I tried adding XCTest.framework to the targets "Link Binary with Libraries" section under build phases but no luck.
Is there a way to work with the XCTest framework outside of a test target?
OR
Is there a way to point one project's test target at another project's app target?
You can link XCTest and any other framework to anything. Make sure you have $(PLATFORM_DIR)/Developer/Library/Frameworks in both LD_RUNPATH_SEARCH_PATHS and FRAMEWORK_SEARCH_PATHS.
Making framework for shared code is a good idea.
Related
I have a Demo project and Framework which can be integrated with multiple ways(Cocoapods, SPM - using generated XCFramework, directly integrate with XCFramework)
For distributing Demo app to external users we integrate the Framework with SPM.
Problem with this approch is during development its makes really hard to regenerate XCFramework after each change, so I have decided to drag and drop the Framework's project to Demo app, but cant understand how to recompile XCFramework if there is a change.
Could you please help me with understading how to handle this scenario.
Create an .xcworkspace that contains the framework project and the demo app project side by side, then inside the demo app target General settings (see screenshot), add the .framework file from the framework project within the workspace instead of depending on the .xcframework binary file directly.
After that, add a "Copy File" build phase that embeds the framework file.
How do you test the shared portion of code when you have a multiplatform project? I see tests for iOS and tests for macOS, but nothing for the shared pieces. I want to add unit tests for the platform-independent portion of my app.
Required
The most important part is to import the module to the test target:
The #testable word means that this test can access the internal stuff of the imported module.
Also, note that the MultiplatformAPP is the name of my project. You should look for the name of your project, instead.
✅ Now you can access to the shared section and test it as you like. But there are some extra optional works you can do:
Optionally
You can build a custom bundle for your shared test:
Note that is doesn't matter what template group you are choosing this template from. It's a template! you can change it to anything else anytime. So we started with tvOS 🤷🏻♂️
Then you can nake it independent to any of the targets or depends on any of them you prefer to test with:
Note that I have named it Tests shared to match the pattern of the default tests naming convention of the multiplatform app.
Think we managed to figure this out.
If you go to File > New > Target ...
In the Multiplatform section there isn't many options, but in iOS there is a Testing bundle named "Unit Testing Bundle"
If you add that and name it "Tests Shared"
You can then unit test against files that are part of the Shared target
I'm working on an iOS app project, and add the json-framework project to the workspace. The project navigator on the left shows both projects, and the build scheme selector shows the schemes from both projects too. Now I want to add the libjson.a target from the json-framework project as a dependency on the iOS app target in the other project. The expected result is that whenever the app target is built, it builds (if necessary) the library target and links the app target against it. Here are the ways I've tried to do this:
Build both as part of the same scheme. The way I try this is to edit the scheme for my app, adding 'libjson.a' to the 'Build' portion of the scheme, and by the way "Find Implicit Dependencies" is checked. Then I go to the target editor for my app target, and in "Build Phases"->"Link Binary With Libraries", I choose 'libjson.a' from the list of workspace libraries.
When I subsequently try to build the scheme, I see it build the library target, but building the app target fails with linker error "Library not found for -ljson" - suggesting that it hasn't actually discovered that the library has been built. Indeed in the project navigator, the entry under the app project for the library is still red indicating that the file doesn't exist.
Add the json target as an explicit dependency. To try this, I don't modify the build scheme, but go to the target editor for my app target and click the add button under 'Target Dependencies'. No targets from other projects in the workspace show up, so this is a non-starter.
Drag the JSON project into the other project, then add the target as a dependency. This is what I would have done in Xcode 3. In the project navigator, I grab the library project and drag it over the app project. This brings up the usual 'add files' pane, which I just dismiss by clicking 'Finish'.
There are now two entries for the library project in the project navigator: one at the top level, and one under the app project. I can now add the library target as a dependency of the app target using the target editor, and can link against it without error in the link libraries phase. But it looks broken: there are multiple entries for the same project in the navigator. Is there a different way to do this?
What should be considered the "Xcode 4-ish" way of connecting these targets in different projects in the same workspace? It would seem lacking if multiple projects in the same workspace can't actually interact with each other.
Thanks,
Graham.
I’ve just set a test project up, pretty much as you describe in version 3, by creating a new workspace and dragging the two Xcode project into it, nested as shown.
You can delete the sibling project if you have it already.
Hitting build on this and it just works, as far as I can see.
I imagine there is internal path-confusion if you have two projects, and I’d be inclined to fiddle with location settings in "View"->"Utilities"->"File Inspector" and see what effect that has.
Another thing to try is to set your paths up in Xcode "Preferences…"->"Source Trees" and refer to them that way, as described here: Easy, Modular Code Sharing Across iPhone Apps: Static Libraries and Cross-Project References
HTH. Andy W.
I managed to get dependencies between projects in a workspace to work as I described here: http://blog.carbonfive.com/2011/04/04/using-open-source-static-libraries-in-xcode-4/.
Unfortunately I can't find a way to get Xcode to discover implicit dependencies or index everything in the build as advertised. I found workaround to both but I'm hoping that less manual configuration will be needed as Xcode 4 matures.
I was going to ask the same question, thinking that my own solution couldn't be right. But I don't see it mentioned here, and it does seem to work. Clearly XCode 4 is a work in progress. :)
I have a workspace with two projects: a static library and an app which uses the library. The projects are siblings. Each project has its own scheme, and each scheme is set to only build one target. In other words, I added two projects to the workspace and that's it.
To add the static library as a dependency of the app, I just drag the libsomething.a product from the library project (Project Navigator) into the "Link Binary with Libraries" list for the app target. That's it. Now when I build the app the library project is built first and then linked. Interestingly, when I modify the app's scheme to use a different configuration (eg, Release instead of Debug), the library is built using the same configuration.
So it works, and there is clearly some automatic dependency checking going on here. But it feels wrong. Then again, so does the modal scheme editor/manager and lack of a workspace object in the project navigator... I never thought I'd say it, but the Visual Studio UI (bleh) is a lot clearer.
My bullet-proof solution to do this :
Create "Per Debug-Release / Per Architecture" settings in Build Settings in the Main project (not the lib), to include either
../MyLibProject/build/Debug-iphoneos
or
../MyLibProject/build/Release-iphonesimulator
or
etc..
depending on the configuration (you can create those kind of configuration by clicking on the + next to Debug or Release and choose either "Any iOS Simulator SDK" or "any iOS SDK".
You need to do that for both "Header Search Path" (in case your library copy some headers files, which is more than likely) AND for "Library Search Paths". Which means that for each setting, you'll probably end-up with 4 different paths (debug sim , debug ios, release sim, release ios).
That would make sure the configuration of both projects match.
Now, to auto-compile the lib, that is to create the dependency, you can use the "Build Phase -> Link to Binary With Libraries -> + -> select the .a file" advice given above.
That's the only way I managed to have something that builds and link correctly for every environment on xcode 4.5
Note : I even added the -lmyLib flag in "other linker flags", but i'm not sure that's really necessary
I've had some success with creating framework-like static libraries, though it's not a perfect solution.
I see the next variants:
Explicit dependency in a project[About]
Implicit dependency in a workspace[About]
See the Xcode user guide: Xcode Concepts -> Xcode workspace under 'Projects in a Workspace Share a Build Directory'.
All projects in a single workspace share a build directory. Dependencies are discovered automatically and build if needed:
"Xcode examines the files in the build directory to discover implicit dependencies. For example, if one project included in a workspace builds a library that is linked against by another project in the same workspace, Xcode automatically builds the library before building the other project, even if the build configuration does not make this dependency explicit. You can override such implicit dependencies with explicit build settings if necessary. For explicit dependencies, you must create project references."
In my open-source Cocoa project, I have two Xcode projects -- one framework and one application. I want to link the framework in the application, and whenever I build the framework, I want the linked framework in the application to be updated automatically as well.
What is the correct way to set this up, especially so that someone else who clones my project can easily build both the framework and the application?
Drag the Framework project into the App project's source list (on the left). I make a "Projects" folder in the source list for that exact purpose.
Then, you can simply select your App Target, Get Info, and add the Framework as a Direct Dependency.
Now, whenever you build your App, your Framework will be built as well.
It's recommended to use a common Build Folder as well (Xcode->Preferences->Building) to help with linking.
I'm creating a static lib on Mac OS X for one of our customers, as well as a small cmd line app to test the static lib. The cmd line project has 2 extra library search paths, which meant I was linking to the Debug version in Release mode and just about went crazy, so I tried to get rid of these two paths, but I couldn't find where they were specified. I was looking in the project info, but it turns out they were specified in the target info.
I don't understand the distinction?! Why there are 2 sets of settings, which are essentially the same?! Can someone please enlighten me?
A project can contain multiple targets. For example, an app I write has four - the app itself, a Quick Look plugin, a framework and a bundle that contains Mac OS 10.6-specific functionality that can be dynamically loaded in.
Project settings apply to every single target in the project. Each target can then override individual settings if they need to - for instance, my project's Target SDK is set to 10.5, but the 10.6-specific bundle has it's Target SDK set to 10.6.
In some instances, some settings don't make sense to be in Project Settings - one of these, I guess, is search paths.
You often have multiple targets in a single project - for instance, you might have a framework project with a target for building as a dynamic .framework bundle, and a target for building a static lib. Or your app might have a target for building the app itself, and a target for building some helper command-line tool that it needs to install.
Wherever possible, I'd suggest changing settings at the highest level (in the project settings, and simultaneously changing debug & release configurations), and only customizing the target settings when necessary. Even better, move as many settings as possible into xcconfig files, which seem a much more explicit way of specifying your build setup.
Preface: you ship targets. Your end products are targets. Not projects. Think of a project as the umbrella above multiple targets.
For a more realistic example assume both Uber and Lyft were being developed by the your (umbrella) company.
The company has the following three environments:
Debug
QA
Release
The Debug and Release configs come out of the box with every new project you create. You can create as many additional configs as you want
This would require 3 configurations. To add a QA configuration follow the tutorial here
Did I apply this to the target or project?
I applied it to the project.
Ok so configs are only for projects and not for targets. Right?
Incorrect! It's confusing I know. You have to think of the project as a big container where you create your configs in there.
Then for each target (not project), for following tabs:
General, Resource Tags, Build rules, Info:
There is no difference between different configs
Signing and Capabilities tab:
You can switch between teams and sign it with a different team. This is useful if you want to sign your beta builds with your enterprise certificate but sign your Appstore build with app store certificate.
Build Settings tab:
For almost every variable in this section you can give a different value based on the config. Common Build Settings to customize are:
Architectures - 'Build Active Architecture only'
Build Options 'Debug Information Format'
Packaging
Set the plist you want per configuration.
Change the bundle identifier (Packaging >> Product Bundle Identifier). If you switch values for a field then in the plist you'll see as:
Signing
Code Signing identity
Code Signing Style (Manual or Automatic)
Development team
Provisioning Profile
Apple Clang - Optimization Level
If the values are different then the row's value would be
<Multiple values>
and you basically have to expand that value to see what value is given for debug and what value is given for Release or QA config.
If all the values are the same then you'll just see the value that is given to all of them. By default the values are the same.
Build Phases:
There's no out GUI way of switching based on configuration. However you can still do run certain commands based on the configuration. Example:
if [ "${CONFIGURATION}" = "Debug" ]; then
"${PODS_ROOT}/SwiftLint/swiftlint" autocorrect
"${PODS_ROOT}/SwiftLint/swiftlint"
fi
Summary
Long story short, this allows you to have 2 different apps (targets) with the same code (project), in 3 different environments (dev, QA, release). You create the different environments using configurations.
To learn more on this I highly recommend you to read more about this in depth and understand what configuration files (xcconfig) is. It's much more simpler than you think. It's mainly a key value pair:
AppCoda - Using Xcode Configuration (.xcconfig) to Manage Different Build Settings
NSHipster - Xcode Build Configuration Files