I used to copy/paste my IOS plugin files inside Plugins/IOS folder on my Unity project, but it doesn't work for bundles (as it has directory structure).
I can't beleave there is no way to generate xcode project from unity with .bundle inside?
Any help appreciated
Unity3D will not contains folders in the Plugins/iOS to Xcode project. In fact Unity3D will only auto merge source file and .a library for you, as described by Unity3D's doc:
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.
But you can use the PostprocessBuildPlayer attribute to implement this yourself. I made a tool for this purpose called XUPorter, which can make exporting and libraries setting easier from Unity3D to Xcode. You may want to see it on GitHub. There is a demo in the package and you may set your bundle under the 'folders' tag.
Related
I'm trying to load a custom .dylib library via the dlopen() function (in a Swift iOS app). It requires a path to the library.
Where to put the library in the project structure?
What will be the library's path on the iOS device?
Also, a tangential question, it seems more usual to include the library's sources directly into the project and let Xcode build it. Is that a preferable approach for some reason?
1 )
If you include the .dylib library in with your list of files and resources in your project, you can use the "Copy Files" build phase to copy the dylib into your shipping app.
A tutorial can be seen here.
2 )
For dlopen, try using just the .dylib name before you try to use relative paths including the "#executable_path" or "#rpath" run time variables. An example can be seen here in this related question.
As for why some developers prefer to include the library source code in a project, I believe it's mostly just a preference by folks who aren't comfortable with the "Copy Files" build phase or in using dlopen.
I am manually adding the SQLite.swift subproject to my project. As the directions indicated, I copied the .xcodeproj file to my project. This allows me see all the source files (unlike this SO question).
Everything seemed like it was working fine. However, I discovered that the source files of that subproject were not copied to my project. They are still in original location where I downloaded them. Is this by design? What if I want to share my project source code with other people in the future? They won't have the subproject source that is necessary for my project to work.
If I do need to copy the subproject source to my project, then how do I do that?
Add it to your filesystem-structure first. For example by pressing "Show in Finder" on the "Chimee"-project which will lead you to the folder it's located in. Then copy the SQLite-project structure in there.
Afterwards you can then drag&drop the xcodeproj into your project which will then still link to its original path, but as it's now inside your project-structure isn't a problem anymore.
I guess that this is by design, because when you try it via Add files to "YourProject" you can select the Copy items if needed-option but it will still not get copied (only with .xcodeproj-files, it works with all other filetypes)
After doing more research, I now feel that using a dependency manager (like CocoaPods or Carthage) is a better option than manually adding the framework to the project.
This will allow easier updating in the future.
Github source code sharing and App Store submission issues have already been considered.
Using Carthage is not too difficult if you follow this excellent guide: Carthage Tutorial: Getting Started
Notes
Delete the framework files that you manually copied in before installing the framework with Carthage.
I will leave #TMob's answer as accepted for now, but I am no longer pursuing that route.
we want to create a MobFox-Plugin for our hybrid apps. It is already running well in CLI-Cordova Apps, but it does not work in our hybrid apps, because it seems that the directory structure of the framework (the symbolic links between headers and version directory) is destroyed by Windows, where the framework is inside the plugin in the mda project. If I start a build, the header directory of is not recognized as a symbolic link, but as an ordinary executable textfile on the Mac.
This is how I include the framework in the plugin xml:
<framework src="libs/ios/MobFox.framework" custom="true"/>
I also tried to copy the MobFox.framework to the SDK Frameworks Folder and reference it like the standard system libraries (which work well):
<framework src="MobFox.framework" />
But this also fails, though the Framework is now included correctly in Xcode. But the compiler now says that it cannot find the MobFox.h-class, this is how it's included:
#import <MobFox/MobFox.h>
So I really think that the problem is that Windows cannot handle the symbolic links inside the .framework File. Does anybody has a workaround or solution for this problem? Or an idea why my Workaround with placing the file in the Standard-Frameworks Folder does not work?
Any help would be highly appreciated.
Thanks
Same problem here - it appears that when the plugin is published to the cordova registry it loses the symbolic links inside the .Framework package that tell XCode where everything is.
They are maintained on git, so it is something in the plugman export/publish that is going wrong.
So for example
cordova plugin add https://github.com/uxcam/cordova-uxcam
will work for the plugin I am writing, but not
cordova plugin add com.uxcam.cordova.plugin
which is the published version.
If you delve down into the 'plugins' folder of the project you added it too and 'show package contents' on the com.uxcam.cordova.plugin file you can then get into 'src/ios'UXCam.framework' and see how it has messed up the symbolic links in the framework folder that should point at the Headers folder and a link the the library binary as well.
Reference: Cordova bug report here: https://issues.apache.org/jira/browse/CB-6092
Update: I've worked around the problem by manually putting files in the framework into the places they need to be. So now on the github project I reference above you can see that the framework library is directly in the UXCam.framework folder, and there is an explicit Headers folder that has the UXCam.h file in it. This works for a published plugin now.
Not an ideal solution and every time I update the framework I'll have to fix the layout again, but works for now until I can find the proper place to report the problem.
I am working on Worklight version 6.1.I have created a native ios environment.I added controller classes in the Xcode project and added native functionalities. I have added .js files in the eclipse project.Now I need build my iPhone environment.But I am afraid that native content (Xcode project) will get lost,after building the environment.What is the solution for this.
I should build at the same time native content shouldn't be lost.
How to do this...
Your explanation is VERY raw... it doesn't make much sense to me.
have created a native ios environment
What is that exactly? do you mean that you:
Created a Worklight project and added a Native API for iPhone, or
Created a Worklight project, added a Hybrid app and then added the iPhone environment to that application
Created a fully native project in Xcode?
The distinction between the 3 is important, and you need to mention this in your question in clear wording.
If what you mean is that you went with option 2 above, then your JS, CSS and HTML can be either in the common folder or in the environment folder.
If you then want to add native code, you need to first build your project and then open the generated Xcode project in Xcode, write native code and make sure to copy it back to your Worklight project in Eclipse.
I added controller classes in the Xcode project and added native
functionalities
Where did you add this? In which file? in the classes provided by Worklight in option 2 above, or in a new Class.
Either way, you need to bring these files back into Eclipse.
In Eclipse, you can create a iphone\nativeResources\Classes folder. During build-time in Eclipse, the files in this folder will be copied into the iphone\native\Classes folder, and when opened again in Xcode - your native code will be there...
Note: if you created your own class file, you will need to reference it in Xcode (right-click > add files...). Worklight cannot do this for you.
I believe your customizations should not be lost. Have you tried making the build already and your resources were overwritten?
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 :)