Our project has a requirement to use user tracking from SOMO (somoglobal.com), and given this module doesn't exist in Trigger, we're trying to build our own bespoke module so we can load the tracking API and send Events from the trigger app using a custom forge.somo object.
I've followed the documentation on creating custom modules, and so far it's fairly straightforward. However, the SOMO plugin requires a couple of files to be part of the module and this is where I'm stumbling, getting errors in the ForgeInspector app when testing.
In the below screenshot, I've highlighted the 3rd party files added to the ForgeModule project; a xcdatamodeld file to the Compile Sources, a .pem to ForgeModule's bundle resources., and the .a added to the libraries. However, when I run ForgeInspector to test my module is working, I get errors that I have pinpointed to the xcdatamodeld & .pem files (with the PEM, ForgeInspector complains that it cannot find the file) If I manually edit the ForgeInspector project, adding these files to that skeleton, everything seems to work fine.
My understanding is I cannot/shouldn't edit ForgeInspector, given it represents the untouchable main Trigger project - is there a way around this? Feels like a scoping issue, but I would have thought anything in the sub-project would be visible to the parent, so I'm hoping I'm just displaying my relative inexperience with iOS / xcode development :-)
Related
I have an iOS project with common functionality (including FB Crashlytics logging) included in several other iOS projects each with their own GoogleService-Info.plist file.
Everything seemed to work fine until it came to adding the "Firebase/FirebaseCrashlytics/run" Run Script phase to the common project at which point I find I need to pass in the correct GoogleService-Info.plist file (via /FirebaseCrashlytics/upload-symbols).
Is there a way to do this, perhaps some way to detect the project containing the common project and set the correct path to the appropriate GS-I.plist file, or will I have to move all FB functionality into the separate projects?
In the end, I put the Run Script into my separate projects but referenced the FB path in the common project, e.g.
"../CommonProject/Firebase/FirebaseCrashlytics/run"
I assume this will work (there's no errors on compilation, obviously) but have yet to confirm FB logging, etc... occurs.
First I have did tons of researches on this issue. Non of existing solution similar to my issue.
I developed a framework. It is a pretty heavy framework which include a c++ static library and contains both objective-c and swift codes. I have created a sample app that imports my framework to mimic the behaviour of people can using my framework.
I put the framework under a libs folder of the project. I have make sure the framework is under Embedded Binaries and Linked frameworks and Libraries. I have also make sure that the path to libs folder exists under Framework Search Paths and Library Search Paths and User Header Search Paths.
Now When I run the sample app using my actual device and running on the computer that contain my framework project file, it works perfectly.
However If I run the sample app using simulator devices, it told me No such module x
Moreover If I run the sample app using my actual device and running another computer that I didn't use to develop my framework project, it shows error Cannot load underlying module for x.
Has anyone had this problem before? Any hint would be appreciated.
(I have also tried clean, clean build folder, clean Derived Data, restart Xcode, restart computer etc.)
Solved problem by setting Defines Module to No
I have code for a VST plugin and need to port some of it to an iOS app.
I have tried building the OSX version and using the lib.a and it doesnt work. When I open the iOS version of it, Xcode shows that it is missing the tagret.
If I copy the code directly into Xcode with all the JUCE modules, and I set the header search paths, I get compilation errors on things like no such type for String
After this latest JUCE update, Xcode would give the same errors until I updated the JUCE file itself, so I think the JUCE build settings or configuration of the new version is doing something differently. How can I get this code into a different Xcode project, so that I can use it?
Can I compile it as a library and use the objects through the header?
JUCE is designed to be included in projects generated by the Introjucer / Projucer (the JUCE project management tool). Without this, the correct preprocessor definitions will not be set up.
If you really needed to include JUCE source code inside your program, you could manually set up these preprocessor definitions (take a look at the AppConfig.h header from a generated project to get an idea of how much work this will be), but you'd really be going against the normal "JUCE way".
Simply including the headers and linking against the library will not work without considerable effort, as the include structure is ... odd ... and there isn't any library to link against directly anyway (the generated projects contain all the JUCE source normally, so there's no need).
Adding the JUCE source files (i.e. .cpp and .mm) to be compiled in a project directly will result in compilation errors, as they need to be compiled in a very specific order which is mandated by the header file (the header files #include certain implementation files after setting up their dependencies).
In short, if you can at all I would advise generating the project with the Projucer and adding other source files in as you need them, rather than the other way around.
First of all, my project builds fine initially.
Then I integrate VideoStream SDK for iOS into a standalone app, and it works.
Then I integrate VideoStream SDK into my actual project, and set up search paths for header files for the library, but then my project gets these issues:
I'd have a look if one of your source header files has the same name as a standard C++ or C header file. Quite possibly this prevents inclusion of the standard header file that defines struct tm. Look if there is a file "time.h" or "locale.h" or something like that has become part of your project.
I have not seen this solution posted ANYWHERE after so much time googling since the time I posted, but I disabled Always Search User Paths under Search Paths of Build Settings, and the project built.
I am currently building a library which should be used internally in a few iOS projects but should also be distributed to customers accessing our services with the library. The Library itself consists purely of C++ code and I am basically able to create Apps with it on iOS which work fine. My problem is creating a single, easily distributable file that can be given out to customers which can easily install them, use the provided headers and don't need to have the headaches that I am currently facing when it comes to linking.
Our code depends on two other projects, namely boost and websocketpp. For boost there is the script on github which I took to generate a framework. For websocketpp, I imported it into XCode and used the scripts from this github project to build a framework. I added both frameworks to my (potential) framework as dependencies and used the same script to build one.
I have an app using my library as a sub-project working fine. Even including the framework into the project and running it on a device works fine. So far so good.
However, trying to create an archive of the App project lead to several questions and headaches.
My library did not seem to contain the code for all architectures. So I tried to archive the Framework projects, which after small modifications in the build scripts to use different locations to search for headers worked fine.
It does not seem to contain all binary code or references to local files (i.e. my specific location of boost). I gathered that from Linker errors that I still get that tell me that some boost calls could not be satisfied.
The second issue made me think that I am must be doing something fundamentally wrong and my intuition tells me that it can't be that difficult and "hackish" to create frameworks or libraries for others for iOS development.
As you probably have found out by now, I am not very experienced when it comes to iOS and I am wondering if I am missing something fundamentally. So, I am sure that this question is rather broad, so some more concrete questsions:
Is there a(nother) way to generate some kind of distributable (preferably a framework) which contains: my public headers, my binary code compiled for all platforms supported for iOS development, the binary code of dependencies?
Is the only way to do that by adding some handwritten scripts to the build process?
I have the feeling that the information I found is quite outdated since it's older than a year and mostly refers to Xcode 4.2 or 4.3 -- so has there anything changed in this regard recently?
For example one error I get is:
File is universal (2 slices) but does not contain a(n) armv7s slice: <file>
The <file> slice is the path to the file in the framework in the Products folder of a different XCode workspace (the library was build in a different workspace then the app). I dropped the framework folder into the project for this test from a completely different location.
What is going on here?
Why does it keep referencing to some internal XCode directory?
How do I properly export it?
Since I guess my setup is probably skrewed up and weird from all the different things I tried up to now: How does this setup look like in a ideal situation?
Yes, there are some questions regarding this on SO already, however, either I don't see or don't understand in those replies:
...how to handle depencies of my code to other third-party code properly.
...how to generate a distributable file.
Have you checked your project build phase under Compile Sources and Copy Files to see if you are including your framework source files in your build?
You may also try the C/C++ Library template under OSX -> Framework & Library.
Finally, there's also kstenerud’s iOS Universal Framework, which I found very useful. I wrote a few articles in my blog on using it.