I'm experimenting with SPM and, so far, adding dependencies to my main app target seems to work pretty well. However, the same isn't true when I try to add the same dependencies to a test target. Even though exactly the same libraries are listed in the 'Link Binary with Libraries' section, the dependencies are not recognised and/or seem to be missing their own (internal) dependencies.
I'm aware SPM is still something that many major frameworks only support on an experimental basis and this may be something that's not yet mature enough for production code but as I can't find anything to point me in the right direction, I thought I'd see if anyone could point out what I'm doing wrong (if anything) before I head back to Carthage.
Screenshots illustrating the difference between SPMs dependencies being recognised on the app target vs test target below. In the first image you can see that the compiler has access to all the Realm modules in the app target....
...but in the test target, most things (including some key dependencies required by RealmSwift) are missing despite adding the same package url.
Related
I'm currently working on a contract job where I've been asked to help integrate a 3rd party SDK with an existing React Native app. The SDK only comes in Android and iOS specific flavors, meaning that it has to be added on the platform-specific side of things (in my case, the iOS side with Xcode).
For the app, the client has created a react native module which gets built into a Library in Xcode, represented by a separate nested Xcode project in Libraries/MyLibrary.xcodeproj from the root of the base Xcode workspace project. This library has several method stubs defined in React Native which will need to be implemented in Swift (and likewise in Android), as this is in these methods that the 3rd party platform-specific SDK is utilized.
The issue I'm having has to do with accessing the 3rd party SDK framework in the library's existing bridging header file. I have followed every tutorial under the sun for how to integrate external frameworks with an existing Xcode project. This includes steps about adding the framework to the project, adding it under the Embedded Binaries and Linked Frameworks and Libraries sections of the project target, adding it under the Build Phases/Link Binary With Libraries section of both the project target and the library target, and adding the framework path under Project Settings/Framework Search Paths. From here, I add the appropriate import statement to my library's Library-Bridging-Header.h file with #import <MyFramework/MyFramework.h> so I can then access the framework in Swift. (This import statement is copied directly from the bridging header file of the sample project included with the SDK, so I know it is correct and should not be given in a different format such as quotes instead of angle brackets).
Regardless of following all of these steps multiple times over and in various combinations, I still get this error at build time: MyFramework/MyFramework.h file not found.
To clarify, MyFramework is just an alias for the actual 3rd party framework I'm attempting to integrate, and MyLibrary is an alias for the existing library with nothing but method stubs given to me by the client to implement in Swift.
Again, I have read every tutorial and forum under the sun, but none seem to address this very specific issue of integrating a 3rd party framework in a xcodeproj Library within the iOS version of a react native app. I would appreciate any new insights or suggestions anyone might have to offer! And please, please don't just post a link to or copy the steps from existing forum posts about a similar-sounding issue, as I've probably already read it 😉. Understand that I think that there is something subtly unique about my specific circumstances which are causing these same steps from the 10+ articles that come up on the first page of Google and StackOverflow NOT to work.
Figured it out! I'll post my solution here in case anybody out there ever runs into the same issue as me.
TLDR - You must add the 3rd party framework in the root of the xcodeproj Library (NOT the top level project) AND ensure that the files were actually copied into that directory, not just referenced from the directory you copied the framework from (be sure to double-check in Finder, since checking the 'Copy if needed' box doesn't always work for some reason). Then, you must add $(PROJECT_DIR) to your xcodeproj Library's Build Settings/Framework Search Paths, and also drag and drop the framework from the root of your xcodeproj Library into the Library's Build Phases/Link Binary With Libraries panel.
I'll address some of the issues with other tutorials/forums that I found, with hopes that it might help someone else that finds themselves as frustrated as I was in this position.
Most only address adding the framework to the base level project, not the obscure case of a project within a project. Therefore, when you start following the steps, it can be confusing to know whether you should be changing the settings of the top-level project or the sub-project. Again, as I discovered, all changes should ONLY be made to the sub-project.
There are a few tutorials that do seem to address this situation regarding a project within a project, but the steps describe adding the framework to the top-level project under Embedded Binaries and Linked Frameworks and Libraries, but I believe the situation described in these tutorials are somehow subtly different than this situation here. Again, only mess with the sub-project.
There's a lot of discussion out there about "umbrella frameworks", but that doesn't really apply to this situation, and again, the terminology similarities can make it seem like it's a similar issue. As I understand it, "umbrella frameworks" are discouraged by Apple, but again, this situation is not the same.
Sorry for the long-winded explanation, but I'm hoping to provide the kind of detail I would have liked to have found when I was searching for solutions for this weirdly obscure problem.
Cheers!
Our Xcode project contains a sub-project that builds first party frameworks which we use as our standard libraries. One is built for each platform (iPhone, iPad, watchOS,...) but there is significant overlap between them (extensions for example).
In our Objective-C code in the main project, I simply have a different prefix header for each target based on its platform, and I import the relevant framework header. This means in my entire project I can use all the symbols that are in our "standard library".
I want this to happen in our Swift code as well (for both Swift and Objective-C symbols). From what I'm aware, Swift doesn't have the concept of prefix headers, so I'm needing to import the framework/module manually in each file.
What's more annoying, my imports won't just need to be
import MyFrameworkForiPhone
But because of the platform specific frameworks, with the help of Swift compiler flags, they'll need to become
#if RD_IPHONE
import MyFrameworkForiPhone
#elseif RD_IPAD
import MyFrameworkForiPad
#endif
Does anyone have any suggestions about how to cleanly work around this problem, or am I stuck with this for the time being?
While it may not be advisable to have separate modules for different platforms, sometimes we find ourselves in this situation and have to deal with it. Fortunately, there is one way to shorten that boilerplate...
Solution
You could create a third module, perhaps called MyFramework that selectively includes the appropriate framework for the current platform. Such a module would only need one source file that looks just like your example above:
#if RD_IPHONE
import MyFrameworkForiPhone
#elseif RD_IPAD
import MyFrameworkForiPad
#endif
Then, every other source file would simply import MyFramework. This works because a module will re-expose anything public from other modules it imports.
Analysis
This approach also provides a sensible location for anything that the two platform-specific modules have in common. Shared code can move into this platform-agnostic module, helping you move closer to the ideal scenario.
Notes
If you're using Swift Package Manager, see the documentation on modules. It's as simple as making a new directory.
In Xcode, creating a module means creating a framework. See Ray Wenderlich's guide for an example. It references iOS, but the same process applies to other platforms.
I would strongly advise against creating frameworks designed only for iPhone or iPad. If there is any UI code It would likely make it impossible for an app to be resizable on iPad and there isn't any code that will compile for one and not the other.
Besides that, you're not compiling separate binaries for iPad and iPhone if it's the same app. Imports are done at compile time, so you cannot dynamically include different frameworks based on the device on which it's being installed.
If you have completely separate apps that only support iPhone or iPad (which should be avoided), you could add compiler flags to each of them to do different things with the same files.
[edit: oops, I answered the wrong question. This answer is for Frameworks that target multiple platforms]
The support for cross-platform frameworks is still pretty bad. In Xcode, I work as follows:
create a single source tree for my library
create subfolders for platform-specific stuff
if a class is implemented differently for different platforms, it appears in each platform subfolder (where it is supported at all)
Now create a "Target" in XCode of type "... Static Library" for each platform you want to support (I have WatchOS, iOS, and MacOS in mine). Name them differently, obviously. However, change the "Build Settings | Basic | Product Name" on every one of these static libraries to be the same, like "MyLibrary" for example.
for each source file in your library, tick the "Target Membership" in the file properties to select which the platform libraries that should include this file. Obviously, everything in the platform-specific folders should only be included in those platform targets.
for other platform-specific targets, add Library linking and Target Dependency for the platform-specific target, like "MyLibrary_MacOS" or whatever you called your library targets above.
Now you can have "import MyLibrary" in your source files and it will automagically find the one that is actually available on the platform that you are compiling. This way, you can have platform abstractions or platform-specific stuff in your library and it doesn't appear everywhere in the code, just like "Foundation."
I also add headers in there for MacOS to provide dummy implementations of WatchOS APIs that I need for testing, for example. That way, I can unit test code on MacOS.
No, this is not optimal, because a formal "Framework" compile would be better, but it is the only way I have found to do it locally with full debuggability.
If anyone else has actually used something that works better, please let me know. Please don't recommend something you haven't actually used :)
I know something like this is already asked many times on SO, but I've tried everything (been at this for three hours now) and I still didn't find a solution. I'm quite new to xCode and I'm starting to work on a project that was originally created by somebody else.
So, I have a library project in my xcode (XS2Library) and now I would like to reference to that library in my other project (WaarBenJij). Building the Library succeeds and I reference to it by adding the LibXS2Library.a to the Project target's "Link Binary With Libraries".
Xcode doesn't give me any errors, so it looks like the library project is referenced appropriately. However, when I try to build my project I get the error that a class that resides in my library project cannot be found ("'XS2URLLoader.h' file not found").
Can anybody steer me in the right direction, maybe?
There's a sensible difference between the .a file, which is needed for linkage and contains the library source, and the .h file, which is needed to compile (and preprocess) and which contains the functions and classes declarations.
Here you included the .a file, which is required for a later step, but to use the library you also need to import the required .h files into your project.
The easier way is to simply put them in your project.
Or you can add the whole library as a subproject and as a dependency.
I'm using the Unity 3D engine to build an iPhone app, and when I go to generate my Xcode project for compilation, it includes a few fairly large libraries: Mono.Security.dll.s, System.dll.s, System.Core.dll.s, etc.
I don't know if this question is really an Xcode question or a Unity question, but I'm trying to figure out why each of those libraries is being linked - which functions / classes are being referenced - ideally so that I can rewrite my code to remove as many of the dependencies as possible. Does anybody know a way to find this information out?
Are you using any external assemblies? If so you should get the source code for them and check what they are including. Sometimes it's possible to disable stuff in external assemblies to remove unneeded dependencies.
Go into the "project settings->player" menu in Unity and make sure that stripping level is set as high as possible. Stripping will attempt to swap System.Core with mscorlib, which doesn't include stuff like Linq.
A way to find out why a particular assembly is being included is to open up the references section of your MonoDevelop solution, and double-click on an assembly. This will open the assembly browser and you'll be able to get an idea of the namespaces that depend on a particular assembly.
This DLL stuff is added to project by Unity3D, Xcode has nothing to do with this. What version of Unity3D do you use? Try to tweak Optimization options in project settings (Inspector), especially 'Stripping'.
I'm trying to write an SSH client for the iPhone, and I'd like to use the libssh2 open source library to do so. It's written in C.
How should I include this C library for my iPhone app? Should I compile it into some binary that I include into the my app, or do I add all the source to my project and try to compile it along with the rest of my app?
I'm interpretting this question as:
"Should I compile the C library code once, and include the binary library in my project? Or should I include all the source and compile it every time I build my app?"
It depends. One of the projects I work one depends on several external libraries. Basically, we have a simple rule:
Do you think you will need to change code in the C library often?
If you will be changing the code, or updating versions often, include the source and build it with the rest of your project.
If you're not going to change the code often or at all, it might make sense to just include the pre-built binary in your project.
Depending on the size of the library, you may want to set it up as a distinct target in your project, or for even more flexibility, as a sub-project of your main project.
If I was in your place, I would build libssh2 ahead of time and just include the binary library in my iPhone project. I would still keep the libssh2 source around, of course, in case it does need to be re-built down the road.
I have an iPhone app that is 90% c. I have had no problem adding 3rd party sources to my project and compiling. I am using Lua, zLib, and libpng with no modifications. I've also included standard libraries like unistd and libgen and they just workâ„¢
The Three20 iPhone library has a great howto on adding their library to your xcode project. Give that a shot.
I think you will find in the long run you will be better off building it into a standalone library and linking it with your application. This makes it easier to integrate into future apps. Another benefit is that it encourages code separation. If you feel pretty confident with the library, you can link your debug exe to the release build of the library and get some extra performance.
I can't really think of any downsides to creating a library, after the initial cost of setting it up, and having an extra project to modify if you have some changes that need to be made to all your projects. Even if you don't know how to make a library for the iPhone, this is a good excuse to learn.
Just adding the source to you project should work fine as well.