I'm working on an app that has two targets for a lite and a pro version.
We are using Google's Sign In SDK for the authentication which requires a configuration file called "GoogleService-Info.plist".
PROBLEM:
Is there a way to have two different files with the same name and different targets, so each version uses the configuration file required?
Or there is a way to change the configuration file that the SDK uses? I haven't found a way to do this on Google's documentation.
The easiest approach to achieve this, is to create a separate directory in your project folder for each file. After that, you will be able to add both references and assign them to each target with no issues.
Source: BraveS - Copy file to root of XCode project when building
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've separated some functionality in an app I'm working on into a self-contained framework. Both the framework and the app are included in a workspace. How do I include this framework in my build in a machine-agnostic manner?
What I've been doing is adding the framework to the embedded binaries of my client app, as suggested on a number of posts here on SO. This works nicely until you start work on another machine, at which point the randomly generated 'DerivedData' directory the framework resides in can't be found, and you have to re-create the link. This will become a really tiresome process.
I was considering using CocoaPods for this purpose, but unless I'm reading it wrong, you can't just reference local projects with a podspec; the project needs to reside on a known source / repo.
So basically I'd like to know how people here have forged a multi-project build process that isn't linked to the directory structure of a particular development machine.
So I've found a solution that works. The issue was that my client app project referred to the framework file relative to the project itself.
The minimal steps I took to refer to (and embed) my framework were significantly fewer than some of the solutions I've seen.
In my client app's target (on the General tab), add the framework to the 'Embedded Libraries' section. This will also add a reference to the framework to the Project navigator.
Select the reference added to the Project navigator in step 1, and change it's location to be 'Relative to Built Products'. Optionally move the framework to the 'Frameworks' folder of the client app's project, where the rest of the frameworks live.
This second step ensures the build looks for the framework relative to the build products, rather than relative to something else, whose location may vary between machines / copies of the source.
Actually, you can indeed have private Pods. Most tutorials on how to do this usually keep these private Pods within private repos on GitHub, but you can also host them on another Git (non-GitHub) server.
As for the DerivedData directory issue, it sounds like you are including the framework via a build setting (i.e. something like "-framework ~/Library/Developer/Xcode/DerivedData/MyFramework-$$##$###$#/MyFramework.framework").
You should be able to simply click on the "Build Phases" section of your app's target settings and then the "add" (or "+") button and you'll see your (built via the same workspace) framework or library in that list that you can add. More information can be seen in this Apple documentation.
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 have an xcode ios repository which I share with another developer.
In this project we use a framework sdk which is not part of the system so it is referred froms some other directory on our hard disc.
The problem is that the path to this framework is different on each computer so I thought I can just add the path to the external framework to the gitignore file so we do not have to adjust the correct manually every time we pull from github?
Do you see another solution?
Thanks for your help!
Rather than depend on your external framework being present on a developer's computer tu could add it as a submodules to the repository. This has advantages:
the framework is added at a defined path relative to the project.
the version of the framework being used is specified so all developers are using the same version.
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.