Xcode: what is a good way to replace a resource file? - xcode

I have an iPhone application that is compiled under Xcode. I have a file which I shall call 'manual.pdf'. The app has a manual page that shows manual.pdf using WKWebView. The 'manual.pdf' file is generated from OfficeLibre.
When the UI has changed, I go through the original 'manual.odt' replacing the screen shots with new ones, and correcting the text. I then export a new 'manual.pdf'. I then have to...
delete the old 'manual.pdf' entry.
drag the new file to the Resources directory.
fill in the form to get it added.
I don't need a build-time copy script. Those look complicated, and this is not particularly labour intensive, and I don't necessarily want to do it every time the manual changes. But this feels wrong. I would be happy if Xcode just substituted the new file for the old file if it had the same name. But it doesn't.
I am running Xcode 14.1 building for an iPhone 12 running iOS 16.0 FWIW.

I found the answer. I had just edited the file, and I went to Xcode to update the reference. The new version was already there. I guess when I dragged the file, it created a link rather than copying the file.
Nice, once you know it is there.
PS:
I have made another discovery. Xcode used the latest 'manual.pdf' when building the application, but it did not save it when I committed the changes. I had to separately update the PDF file in the git archive to get it to update. However, the builds released to the TestFlight site all had the right PDF.
My minimal solution is to copy the file to the archive...
cp ~/Documents/manual.pdf ~/XcodeProjects/MyApp/MyApp/Resources/
This then gets committed with the next Xcode commit.

Related

How do I find why Xcode no longer notarizes my app?

I have a MacOS app that I last notarized about a year ago with no issues. This time, however, when I created the initial Archive, the Organizer put it into a section called 'Other Items' instead of in the 'macOS Apps' section with all of the previous Archives. In addition, and more distressingly, when the Archive is selected, the button says 'Distribute Content' instead of the expected 'Distribute App', and pressing it simple exports the Archive or its contents, without running through the automatic notarizing process.
I suspect I have done something in the last year that somehow invalidates my app such that Xcode no longer recognizes that it is an app. I have followed the suggestions at https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues, but that did not provide any relevant clues.
I am using Xcode Version 13.4.1. How do I figure out what is preventing Xcode from offering to notarize the app?
To track this down, I created a new project, and then tried to notarize it. (I didn't actually notarize it, I just made sure that I could Archive it and it showed up in the correct section in the Organizer.) The new project archived as expected, so I knew that I could still notarize somethings; I was just having an issue with my app.
My plan was to copy items from my app into the new project in small chunks, and after each copy, attempt to Archive it. I figured that I would either find the item that was causing the failure (and fix it), or I would eventually copy the entire app without a failure. Either way, I would be able to notarize the app.
The first chunk I copied was all of the build settings. And right there, the new project would not notarize, so I removed and added build settings to binary search which setting was causing the failure. It came down to the RUN_DOCUMENTATION_COMPILER = YES build setting.
In the last year I have been more conscientious about documenting the code, and to actually see that documentation, I had added that build setting.
Comparing the archives created with and without running the documentation compiler, the MyApp.doccarchive file appears in the archive in the Application folder along side MyApp.app, so it appears that Xcode is confused by the "extra" file in the Application folder.

Adding a CoreData Data Model file to XCode 4.2 causes source control to stop working with a question mark

I've been trying in vain for hours now to add a CoreData Data Model file to my XCode project, which is under SVN source control. Whenever I do, I get the following display in XCode:
I've followed at least 5 or 6 different articles now on ways to make subversion play nicely with xcdatamodeld files/folders in XCode 4 without much success. I'm about to just give up and leave my data model file outside of source control, but I can't even get subversion/xcode to ignore it. Winning is not an option.
Things I've tried so far:
command line add/commit of the Data.xcdatamodeld - this causes XCode 4.2
to go into a tiz and crash repeatedly
ignoring the file in XCode Organizer - this causes XCode to report build warnings about a missing Data.xcdatamodeld file, which isn't there in xcode, on the file system or SVN
I've followed the suggestion here: http://www.tmro.net/2010/10/subversion-and-core-data-versioning/ only to have XCode then start crashing during any SVN operation at all (I had to delete my local version completely and reload from the repository)
I can replicate this in a controlled environment outside of my project
Has anyone seen this before and resolved this issue in XCode?
I can't be the first person to try to add a CoreData Data Model file to an SVN controlled project!
Thanks
I saw this also for an otf font bundle.
My datamodel file was stored oddly. In my project directory I had:
./Model.xcdatamodeld/Model.xcdatamodeld/contents
i.e. doubled-up directories
I did a commandline svn on the inner folder only, i.e.
cd ./Model.xcdatamodeld; svn ci Model.xcdatamodeld
It added the inner directory and the contents file, the ? disappeared in XCode and it committed fine. Don't see how the nested directories could be a problem, but this worked for me.

How to make Xcode refresh the editor content?

I am developing a project with Xcode 4.1 using Subversion through Xcode's built-in source control menu and command line. When reverting/updating the source through command line, I can't get the Xcode editor to show the current version of the source files (as they appear in the Finder or any external editor). I guess this is generally the case when editing a source file with an external editor.
Eclipse would immediately warn you that the editor content is outdated (Xcode does it when you try to save the file). Then you would simply right click on the project tree to refresh the corresponding files/directories. There must be a similar feature in Xcode.
svn revert MyFile.m
will copy the old back and therefore also the old timestamp, making XCode think it is using the most recent version of the file (which is true, except that in this particular situation you would want it to use the older version again).
As a workaround you can "touch" all the reverted files, giving them a new timestamp.
touch MyFile.m
That will make XCode display the content as it is in the file and also include it in the next build iteration. This works for .h/.m files but also any project or meta data files used by XCode.
Do you mean Menue:File >> Source Control >> Refresh Status ?

Xcode 4 code sense is not working

I am running a "old" Xcode 3 project in Xcode 4 and code sense is not working for my own classes. I have tried following:
Clean/rebuild
Remove Derived Data
Installing 4.3 documentation
Restart
Without any luck.
Sometimes the code sense works but mostly I just get "No Completions".
Try this:
Open Organizer then Project Tab.
Clear the "Derived Data". Xcode should re-index your project then and code sense should work. At least worked for me.
I know this is late, but for reference: http://sealedabstract.com/code/when-xcode-4s-code-completion-autocomplete-breaks/
Close the project, leaving XCode still running.
Open XCode’s Organizer window, go to the Projects Tab, select the correct project, and hit the Delete button next to “Derived Data”.
Quit XCode.
Navigate to your project’s .xcodeproject file in Finder. Right-click, choose “Show Package Contents.”
Leave the project.pbxproj file, but delete the project.xcworkspace file, any .pbxuser files, and the entire userdata folder.
Open the project in XCode. You will see XCode riding high on the CPU usage for around 10-60 seconds, depending on the size of your project. The activity window will say “Indexing”
When your CPU spike returns to earth, code completion will be working again.
There's a lot of deleting going on there so please be careful, but this definitely worked for me.
I've been doing this, and it's worked multiple times for me (after trying all of the above previously).
Edit: Now I just hit space, backspace (the mac version) and rebuild... works nice. Then, remember to scroll (sometimes the colors don't show up until you scroll somewhere)
Find your prefix file: "ProjectName_prefix.pch".
Comment out some line. (basically change it)
Build your project, doesn't matter if it fails or not.
Uncomment it.
Build again.
I'm betting only step 2 (modify the prefix) is what does it, but these essentially get you back to running. Suddenly everything magically recolors itself and completes functions.
Good luck if that doesn't fix it, perhaps try doing this to your dependency pch files (three20 or FB api's)
Clearing the "Derived Data" only works temporarily for me. I have to do it and then restart Xcode like 3-4 times each day to get code sense working again.
I found out the real cause is in the Target's Build Settings. I moved everything from Header Search Paths to User Header Search Paths and it is fixed. In my case, the framework I'm working with is RestKit.
BTW, I came up with this because I was adding another project (QuickDialog) into my project and I was curious that it is using User Header Search Paths, but not Header Search Paths. Here is the difference between them.
You can able to fix that issue by change build settings like this, PreCompile Prefix Headers :NO
FYI, if one file doesn't have code sense but the rest of your project does, check that its added to a target. Once I did that I got code sense back in that file.
It's been ages but the answer is just to move the code into a new folder and the code sense should be working now.
This happened when I added a new Objective-C Class and the code sense doesn't work only on the newly added .m and .h files (on XCode 4 latest update during this post).
Close all xcode windows
Delete all your projects from xcode>window>organizer and restart your project. It will now sense and index your project properly.
I wrote about it in detail here.
Basically my fix was that with localization. I upgraded from xcode 3.2.5 to xcode 4 and then screwed around with built in interface builder and turned on localization for a XIB file accidently which placed my source files in en.lproj directory. After moving them back to Classes folder it worked perfectly.
Again, for the sake of helping others with this issue which, in my case, happened upon upgrading to Xcode 4.3.
Of course I tried the solutions offered in this post, and none of them worked. But the suggestion to move the location of the project in Finder brought back some Code Sense, but the suggestions didn't make any sense.
I ended up deleting my project and re-cloned it from the git repository.That brougt back Code Sense for me...
I open a second project in the background whenever my Xcode's code sensing stops working (it usually works the first time i open the project but after a while code sense no longer works). So what i do is to open a second project in Xcode. Xcode will start indexing the second project and magically the code sense for my main project is back.
Running Xcode 4.3.1 on Lion
Hope this helps someone.
From this comment here I was able to debug the problem on my end, it seemed to be a bad -w flag that the clang preprocessor wasn't recognizing properly. Basically, running
defaults write com.apple.dt.Xcode IDEIndexingClangInvocationLogLevel 3
in Terminal increases the verbosity of the indexer, and should help you track down issues. Open Console.app and look for messages from Xcode, the search string IDEIndexingClangInvocation helped me find them.
For me it happened simply because the file had no target membership. If the first few answers did not work for you, go to your .m file (presumably it's this file that you're having trouble with), open the Utilities view (Edit -> Utilities -> Show File Inspector) and under "Target Membership" check the target to which you want this file to belong.

Image does not update when file name remains the same in XCode 3.1.2

I'm using XCode version 3.1.2 and am developing for iPhone using the Simulator with iOS 2.2.1 on Leopard. I had an image file named "img.jpg" in my project which I decided to switch for a different file. After adding the new file into the XCode Resources folder, I removed the first file and renamed the new file to the same name as the previous one, "img.jpg." When I run my program, however, the Simulator loads the old image instead of the new one, even though the old one has been deleted from disk (not just the reference). I tried changing the name of the file to "img2.jpg," and it worked like it should - loading the new image, but I want to keep the name "img.jpg." I ran a search with Spotlight for "img.jpg" to see if there was another copy stored somewhere that XCode was using, but it only returned my new image file. I have tried uninstalling the app from the Simulator and running the application again, but that also does not fix the problem.
What must I do for XCode to recognize that I want to use the new image file and not the old one?
Thanks for your help!!
You should clean build all your XCode Projects Targets by using "Build" -> "Clean all targets", and rebuild from scratch. This should fix your problem.
If you have a big project and don't want to wait that long, you can also remove and re-add the file reference from/to your project. That seems to always work.
You have to solve it by performing both routines:
Read the new images into Xcode
Product > Clean
Secondly update the simulator
You also have to force sending the updated images to the simulator.
You can do this by deleting the folders, or just removing the app from
the simulator (as you normally do on your phone).
I had this problem in Xcode 4. The problem was caused by a Default~iphone.png hanging around with the old image. I saved the screen shot over Default~iphone.png and chose that file as the launch image in the project summary page. You can tell if this is your problem when you select the Default~iphone.png file as the iphone launch image and xcode asks you if you want to overwrite Default.png.
An important addition - when working with Simulator, delete the folder in the Simulator
The folder must be named something like
/Users/username/Library/Application Support/iPhone Simulator/6.1/Applications/53630E9A-6E04-4D33-8600-AD29484C9FA8
and have YourAppName.app inside

Resources