It has been awhile since I have used SpriteBuilder with Cocos2d. I am trying to create a new project from SpriteBuilder that I can modify in Xcode. From SpriteBuilder I go to 'File > Open Project in Xcode". This opens Xcode with the new project. When I build the project I get over 40 errors (e.g. 'UIAccelerometer' is deprecated: first deprecated in iOS 5.0 - UIAccelerometer has been replaced by the CoreMotion framework.). It looks like I need to update my Cocos2d. So I went to the repo here and found this statement in the README: "SpriteBuilder also allows you to update the Cocos2D version in your project, to newest version, making it trivial to always keep you project updated to latest Cocos2D version." So it looks like it should be easy to do it, but I can't figure it out. Any ideas?
Xcode Version: 7.1 (7B91b)
SpriteBuilder Version: 1.4.9
SpriteBuilder Revision: eea568a5c7
I'm not sure how you can update cocos2d directly from Spritebuilder, but rather than rely on SpriteBuilder to perform the update, you can do it manually.
You can get the most up to date version of cocos2d by downloading the project straight from its repository on Github. If you want to clone the repository from the command line, the command is:
git clone --recursive https://github.com/cocos2d/cocos2d-objc.git
This will download the latest version of Cocos2D (and its dependencies). Now to update the project. Navigate to the new version and copy three folders: cocos2d, cocos2d-ui and external. These three folders contain the changes that need to be moved into your project.
The next part is finding the location of Cocos2D in your project—it's located in the folder named cocos2d-iphone inside the project. Pasting the new folders will prompt a warning that you are trying to replace folders that exist already. For the current updated version of cocos2d, this shouldn't be a problem.
Then, you'll want to "Clean" your project and set your iOS Deployment Target to 8.0.
As a safety precaution, you should then clean the project build folder. You can find the "Clean Build Folder..." by holding the option key (⌥) while selecting the "Product" drop down. (Note that this is different from just using "Clean".)
Related
Here's a frustrating one. My project builds perfectly in 8.x versions of XCode, and yet in 9.x versions, it fails consistently in the linker phase, as the linker is unable to find the .o file for a seemingly random class.
For example, in one build it will be unable to find the intermediate object file for my UIWindow subclass:
In other builds, other files may be identified as the culprit, with the same "file not found" linker error.
So, clearly there is a disconnect in the linker phase. I can understand that. But I cannot make it work to save my life.
Here's what DIDN'T work:
• Deleting derived data
• Cleaning and option-cleaning
• In the .swift file inspector, removing the file from the target and re-adding to target
• Renaming the target
• Deleting the supposedly erroneous files from the project, and moving to trash, then re-adding the files to the project and target.
• Switching advanced workspace settings for Build Settings from "XCode default" to "Legacy"
• Updating XCode from 9.0 to 9.0.1
• Deintegrating Cocoapods and reinstalling them
Jeez.
So, none of the usual suspects are at play here.
Additional details :
• When I look in the folder specified in the linker error message, the .o files are NOT THERE. (Are they not being created? Is there a setting for that?)
• Using Mac OS High Sierra on a MacBook Pro Retina 15
So there's my conundrum.
Does anyone know why XCode 9 would either not be creating .o files, or would be unable to find those files, for a project that build perfectly in previous versions of XCode?
Thanks!
The only solution I found was admittedly pretty painful. I created a new project and then re-imported all the files and dependencies into the new project. Then setup all the build settings, etc. At that point the project was back to building and working fine.
If this happened again, I would try deleting the .xcworkspace file and re-generating it with pod install first before starting a new project.
May this not happen to you.
I have read about a possibility to add CocoaPods to an XcodeProject without getting the xcworkspace file, instead you get a xcodeproj file that you can integrate into your current project. How can I do that? Would love to use the xcodeproj file instead of xcworkspace.. I'm programming in swift (if that makes any difference).
Yes, its possible. But, we need to do few steps to proceed.
Check this Github thread.
The below line in pod.file will not let the client integration process.
install! 'cocoapods', :integrate_targets => false
We can drag and drop the Pods.xcodeproj to the main project
Link the target dependencies and Link Binary with Libraries in Build phases.
Thats it.
You can not do this.
The CocoaPods website guide to using CocoaPods found here directs you to using the .xcworkspace it creates. Several other guides found across the Internet all direct you to use this file indicating that using the .xcodeproj file will now result in build errors.
There is simply no evidence that this is a possibility at all.
From the CocoaPods website guide on using CocoaPods:
Save your Podfile.
Run $ pod install
Open the MyApp.xcworkspace that was created. This should be the file you use everyday to create your app.
More from their website:
Now you can install the dependencies in your project:
$ pod install
Make sure to always open the Xcode workspace instead of the project
file when building your project:
$ open App.xcworkspace
And from the Ray Wenderlich guide regarding using CocoaPods with Swift:
Open the project folder using Finder, and you’ll see that CocoaPods
created a new IceCreamShop.xcworkspace file and a Pods folder in which
to store all the project’s dependencies.
And from an NSHipster article on CocoaPods:
CocoaPods will create a new Xcode project that creates static library
targets for each dependency, and then links them all together into a
libPods.a target. This static library becomes a dependency for your
original application target. An xcworkspace file is created, and
should be used from that point onward. This allows the original
xcodeproj file to remain unchanged.
In older versions of cocoapods it was possible to install and update pods with the option '--no-integrate'. It allows you to create a library project, which could be imported into an existing project (read more). But this option is missing now. I've build a Xcode project for a maven-build with this option earlier. Today I've updated the pods of this project with the newest cocoapods version (1.0.0) but without the '--no-integrate' option and it still works. So eventually there is a way...
I have created a simple OSX Command Line App project with Xcode 6.3, called Foo, and set the location of Foo to ~/Desktop. Building and running the project is fine. To be clear, the project path is ~/Desktop/Foo/Foo.xcodeproj.
If I move the project's containing directory ~/Desktop/Foo to, say ~/Desktop/tmp/Foo, open ~/Desktop/tmp/Foo/Foo.xcodeproj, and then build the project, I see that Xcode creates ~/Desktop/Foo/build/ and so on. It seems that Xcode is still using the old build path rather than the build directory that is relative to the project (~/Desktop/tmp/Foo/build/).
Why is this? I am using a typical installation of Xcode and have not modified any configuration of Xcode nor the project or its build settings. Xcode 5 definitely did not behave this way.
Yes, the project has been cleaned.
I can only attribute this to accumulated cruft after installing, removing, and updating Xcode to various 6.x betas over the past year.
After deleting Xcode configuration via defaults delete com.apple.dt.Xcode, things are behaving as expected.
I'm attempting to move an AndroidStudio project from the default workspace location to another location (as part of moving this project to version control).
I'm new to AndroidStudio ( this is my first "real" project in it ) but when poking around the documentation I found that local.properties should be left out of version control, and so I got rid of that. That fixed my first errors when attempting to import.
However, now when I attempt to import the project from the new location, I get the following error:
The project is using an unsupported version of Gradle.
Please point to a supported Gradle version in the project's Gradle settings or in the project's Gradle wrapper (if applicable.)
This project was created just a few days ago in AndroidStudio, using AndroidStudio's default built-in gradle install. In fact, after selecting the project, but for importing it, I can see AndroidStudio is using it's built-in gradle:
/Applications/Android Studio.app/Contents/plugins/gradle
AndroidStudio has also disabled the "Use default gradle wrapper" setting.
I'm using AndroidStudio 1.0.2, on Mac OS X, 10.10.1
NOTE:
To explain why I'm moving my project, I started the project as an experiment, and it went well, so I made a new repo for it (private github for work), cloned it to where I do my real work, copied over my project to the local clone, and then attempted to import it to AndroidStudio.
So, it turns out I hadn't copied over .gradle or .idea when I copied the project to the new location.
Recently opened a project that I had compiled and submitted to Apple.
I haven't touched it for a couple of months but I'm getting this odd compile error at:
#import <Crashlytics/Crashlytics.h>
The error reads:
'Crashlytics/Crashlytics.h' file not found
Clearly the framework can't be found but I'm puzzled as to why, when the project was working a few months ago, it's suddenly stopped.
Any suggestions why?
Xcode: 4.6.3
Mac OS X: 10.8.4
Just add $(SRCROOT) to the Framework Search Paths in Project Build Settings (Search Paths).
Crashlytics installation process drops its Crashlytics.framework to your project folder (or creates the symlink).
If you moved Crashlytics.framework somewhere deeper in the project folder hierarchy - set 'recursive' to the right or just point directly to its parent folder in Header Search Paths:
$(SRCROOT)/Path/to/the/folder/containing/Crashlytics.framework
Delete frameworks from you project and disk. Check that you have the newest version of Fabric plugin.
Copy frameworks from plugin folder to desktop with this commands:
ditto -xk ~/Library/Caches/com.crashlytics.mac/5b91b14e832a7b1c29441ec5ba109810/sdks/ios/com.twitter.crashlytics.ios-default.zip ~/Desktop/
ditto -xk ~/Library/Caches/com.crashlytics.mac/5b91b14e832a7b1c29441ec5ba109810/sdks/ios/io.fabric.sdk.ios-default.zip ~/Desktop/
Add frameworks from desktop to your project.
Info from: https://twittercommunity.com/t/error-upgrading-from-crashlytics-on-ios/36196/2
I'd recommend just using CocoaPods to add the Crashlytics framework. No need to care about paths anymore.
Podfile:
pod 'Crashlytics', '~> 3.4.1'
Script Build Phase for dSYM Upload:
./Pods/Crashlytics/iOS/Crashlytics.framework/run <your_crashlytics_id>
Import:
#import <Crashlytics/Crashlytics.h>
For me, this worked:
Remove the fabric and crashlytics frameworks from your project, and delete the files from the disk for our project.
Comment the lines in your appdelegate.m file, if you added them for the following:
import Fabric/Fabric.h
import Crashlytics/Crashlytics.h
and
[Fabric with:#[CrashlyticsKit]];
In the fabric app, choose "New app", and select your Xcode project file
Recopy the build script and build as instructed. The build step is why you needed to comment the lines above-- it won't work if you leave those lines in.
After the build script runs, it will prompt you to drag the frameworks from the app window into your project navigator. This will copy the latest versions of he frameworks (which include the .h files) into your project
I have tried manually downloading, and copying from other projects, but this is the only way I could recover after losing the frameworks files for an app.
In my case, the Framework was in the project folder, but not in the Project Navigator. I dragged it to the project and everything worked fine.
I've had this issue working with distributed teams (through github) after checking in then checking out Crashlytics. The Crashlytics.framework will only have one folder inside it -- "Versions". You need to save a version of the contents inside Crashlytics.framework to another location, then copy-paste them into Crashlytics.framework later.
Remove Crashlytics.framework from the project and disk. Copy and add it again. It helped me.
In my case, I was migrating from an old Crashlytics install through the Mac app to Cocoapods. A lot of the answers to this question recommend completely removing everything and starting over. I started doing this and noticed a discrepancy between code found in Fabric's documentation and the code shown in the Fabric app during the step where it tells you what to copy into your Run Script Build Phase.
Fabric's documentation has double quotes surrounding the entire string: "${PODS_ROOT}/Fabric/Fabric.framework/run <Your_API_Key> <Your_Build_Secret>"
The Fabric App only had double quotes around the path to the run executable: "${PODS_ROOT}/Fabric/Fabric.framework/run" <Your_API_Key> <Your_Build_Secret>
So before you delete everything and start over, try updating your Run Script Build Phase to this:
"${PODS_ROOT}/Fabric/Fabric.framework/run" <Your_API_Key> <Your_Build_Secret>
I have changed the name of the working folder and Craslytics fails. Check this in Build Settings (Search Paths).
Good luck!
I have tried to play with the frameworks search path and relocating & reconnecting the framework file; checked the build settings (Link binary with libraries section) but the error persisted.
Finally, I have reinstalled the framework, which only takes 2-3 minutes. The problem might be caused by that you have relocated the Crashlytics.framework to another subfolder from the root directory, but I am not sure about the exact reason.
Delete everything regarding to the Crashlytics
Start crashlytics app, login and select your project
Add run script
Drag & drop the .framework file (I have kept it in the root folder)
Add the import and startWithAPIKey statements back
Completely Remove the Crashlytics Frameworks on your proj include the shell script in App Build Phases Run Script.
Reinstall the Fabric follow the guide,everything will be OK.
I had previously upgraded to Fabric and had no issues. A couple of days later, I reopened the same project and had the missing crashlytics.h file problem.
I couldn't simply reinstall from the plugin due to a non compiling project (I had so many CLS_LOG messages and references to the missing crashlytics.h file in my project, it would have taken a long time to remove them just to allow the build to work - refactor wouldn't work on CLS_LOG).
So instead, I deleted the crashlytics.framework from my project and did the following to reinstate it from the plug in directly:
Download the Fabric plugin again and double click the zip file to unpack the Fabric application.
Right click the Fabric icon and "Show Package Contents"
Copy the Crashlytics.framework folder to your Desktop and then re-add it to your project via File -> Add Files to ....
If step 3 doesn't work for you, you can also add crashlytics.framework to your project folder on your computer directly, and then also add it into your project list via Xcode same as in step 3 but uncheck "Copy Items if Needed" as you already put the files there yourself.
My project then compiled and worked fine again.
In terms of a guess as to why the file went missing? Part of the upgrade process got me to delete the old frameworks and then run the scripts etc. from the plugin. I think what happened is later when I emptied my trash, that some references were lost. I also had the problem where I'd put Crashlytics into my .gitignore file so it disappeared out of ALL my projects every committed which wasn't great.
Hope this helps someone!
I have same error.
Please try pod update
and fix it.
If FirebaseCrashlytics 9.0.0 installed , problem will be fixed.
stalling FirebaseCoreDiagnostics 9.0.0 (was 8.9.0)
Installing FirebaseCoreExtension (9.0.0)
Installing FirebaseCoreInternal (9.0.0)
//hrer
Installing FirebaseCrashlytics 9.0.0 (was 8.9.0)
Installing FirebaseFirestore 9.0.0 (was 8.9.1)
Installing FirebaseInstallations 9.0.0 (was 8.9.0)