When using the Everyplay SDK, Xcode properly recognizes the .framework and .bundle from the beginning, without me having to point to the directory manually, but the "Headers" file in the .framework doesn't seem to parse into anything.
It's plaintext-readable as Versions/Current/Headers, but that doesn't seem to actually let Xcode know how to get to the header files found in that directory. As a result, EveryplayUnity.h fails at #import , since it can't find that header.
How can I get Xcode to find this header?
This is usually the result from unzipping the SDK on Windows environment, which doesn't support typical symbolic links used by Mac OS X/Unix environments.
On multi-platform development environments, it's usually best to extract the SDK on a Mac and use the tools there (git, svn, ..) to add it to your version control system of choice.
Related
I must have read over a dozen posts on possible techniques to link a local library into my Swift Package. Specifically, my package depends on libturbojpeg.a, which most users won't have installed anywhere. Even if they did install it (there is a DMG), I'd have to go through hoops to make sure I was linking in the correct version. I finally found a post in the Swift Forums that basically says you can't do it now.
It appears that the only way to link it now is using .linkerSettings(LinkerSetting.unsafeFlags(..., but if you use that your package can't be managed by Xcode (see above link, and I even tried it and verified it cannot be used).
Is there some kind of workaround that allows me to distribute my Swift Package with the library?
In my Package, I created a directory "Libraries" and added my library there.
I discovered that Xcode 11 places included Swift Packages in a specific location in the Derived Folders directory. This means that it is possible to tell Xcode where to find it during the link phase.
My Package has these instructions in it for users:
1) Add the Package using Xcode->File->Packages with the URL of https://github.com/dhoerl/
2) Open the app's Project Build Phases, and from the Package shown in the left file pane, drag the Libraries/.a file into the link phase. It will appear just above the that should already be there
3) In Application Build settings, under library search paths, add:
"$(BUILD_DIR)/../../SourcePackages/checkouts//Libraries"
Build and run! Voíla - works like a charm!
Note: obviously this is somewhat fragile, Xcode 12 could change how packages are managed, but its possible by then that the Swift Package Manager will support linking of local libraries (its mentioned in the above link.)
I have a framework which is consumed by a DYLIB, and even though I have updated the framework XCode is still looking at an older version.
I have verified the framework being referred to by XCode is correct, and can use a hex editor to see the version string inside it is correct (.32). I have made a separate test app (that does not use a DYLIB) and I can consume the same framework (in the same location) without any issue.
I can even build my DYLIB fine w/o issue, and can see it is using the latest header files. However at run time I can see it is using an older version of the framework (.31) due to the logging used. I can also look inside the binary of the linked DYLIB and see this old string.
The funny thing is if I rename the framework binary, the DYLIB will still build (the test program will fail to link which is what expected), so it is used an older version somewhere.
I have tried regular Clean, "clean build folder", and also deleting the derived data directory (rm -rf ~/library/Developer/Xcode/DerivedData/*). I've also restarted XCode and my machine, and still getting this problem.
I've also tried deleting the library reference and re-adding it, which didn't help either. I've verified the directory is correct by looking at the build line used by clang.
I can't figure out where the heck XCode is reading the old version of the framework from.
If you check "frameworks search paths" under your target settings, do you see any paths you have not checked? Searching framework across OS returns only one possible reference?
I'm using this URL to implement the App authenticity for iOS.
https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-6-3/authentication-security/application-authenticity-protection/application-authenticity-protection-native-ios/
However, I need to know where to find the worklight.plist to make sure that the applicationId is matching what i'm putting in the application-descriptor.xml.
The worklight.plist file is available only after building the MobileFirst application using the MobileFirst Studio Eclipse plug-in (or CLI commandline tool).
For Hybrid applications,
You can then find the worklight.plist file in the your-project\apps\your-app\iphone\native folder.
For Native applications,
You need to only generate the NativeAPI for iOS and it'll be located in the generated folder, in your-project\apps\your-nativeapi\WorklightAPI folder. You then need to follow the native apps tutorial to copy over this (and more) files to the Xcode project.
Thank you,
I have found it after building the project inside the native folder.
I'm building an iOS app using unity3D. Everything goes ok until I try to build the solution. Unity builds the xCode project with 0 problems but then, when I try to build with xCode, I get several, all of them the same: "*.h not found".
The problem in this is that the headers don't exist in the project folder, but in the original-unity project folder they do exist.
I've seen a lot of similar problems around the web, but most of them relate to independent xCode projects, being the solution messing with the paths and so on... But with a project built by unity is it supposed to change that? When I go check them, they seem correct...
I've also seen that unity had a problem and by reinstalling it would fix the problem. Unfortunately it didn't...
Does anyone know what kind of problem is this? Should I change the build paths even though unity set them some way? Is it unity's fault?
Thank in advance
Native plugins need to be stored in special folder Plugins, for iOS it is Assets/Plugins/iOS. Citing from Unity - Building Plugins for iOS:
Automated plugin integration
Unity iOS supports automated plugin integration in a limited way. All files with extensions .a,.m,.mm,.c,.cpp located in the Assets/Plugins/iOS folder will be merged into the generated Xcode project automatically. However, merging is done by symlinking files from Assets/Plugins/iOS to the final destination, which might affect some workflows. The .h files are not included in the Xcode project tree, but they appear on the destination file system, thus allowing compilation of .m/.mm/.c/.cpp files.
Note: subfolders are currently not supported.
I marked the subfolders statement bold as I ran into trouble with this some time ago :)
I am working on a different iOS project in Unity and I have built it by exporting to Xcode (like I always have).
Whenever I try to open the "Unity-iPhone.xcodeproj" in Xcode, it gives me the following error:
Project cannot be opened because the project file cannot be parsed.
I have looked everywhere but cannot figure it out.
The project name does not have any spaces in it.
I have checked the .plist and everything looks fine.
The bundle identifier matches that in .plist.
This has worked in previous projects but now I am getting this error for some reason. What gives?
Today, I've been facing this problem (Unity Ver. 5.5 Windows Based system).
When I try to open my windows exported iOS project, i got "(..)the project file cannot be parsed". So, I decided to explore the project file, located in:
{Project path}/Unity-iPhone.xcodeproj/project.pbxproj
It is a plain text file, so you can use any text editor.
I found a line with a mismatched quotes. It was:
shellScript = "\"$PROJECT_DIR/MapFileParser.sh\""\nrm -rf \"$TARGET_BUILD_DIR/$PRODUCT_NAME.app/Data/Raw/QCAR\"";
To fix the problem, simply remove the quotation mark located at:
(...)MapFileParser.sh\" " \n(...)
It should be:
(...)MapFileparser.sh\" \n(...)
and it will be parsed correctly in xCode.
It's an automated typo error!
Good luck!
Well, after a couple days I have found the problem and it all has to do with the naming of the *.a files that the plugins import.
XCode does not allow for files to have spaces in their names (of course) but I had not caught that 3 of the *.a files from plugins had spaces in them.
After removing these plugins (I have different plugins that do the same thing anyways) xCode was able to parse the build and create a project for me!
Be careful of spaces!
Incompatable version of Xcode?
Are you using plugins? Most modify the project.
Try creating a new project and creating a build. If it works, it's a plugin, otherwise an Xcode version.
Faced the same issue today (Unity 2017.1.1).
Nothing related with the answers above. I just made a mistake in the Profile ID in the Player Settings of iOS : Edit > Project Settings > Player > iPhone, iPod Touch and iPad Settings > Other Settings > Identification.
I was getting this issue in Unity 2017.2 this week (building on Windows and then copying the build files over to the Mac for use in Xcode), and can confirm that the fix to the shell script line to remove the double quote as described by Anibal Itriago above worked in my case. Even an entirely blank iOS project with Vuforia disabled was failing to parse, but the line fix seems to resolve it.
My issue was related to dropbox.
I use a pc for development and a mac to build in xcode, so I store my project in dropbox. Sometimes dropbox can corrupt .pbxproj or even .plist files going from pc to mac, so when I attempt to open a project on my mac, xcode will throw the above parse error.
I had to zip the xcode project folder on the pc side, then on the mac side pull it out of the dropbox folder and unzip it. Then move it back to its original location. It's a pain but it worked.