I began coding Objective C last night and i made my first basic Cocoa app for my Macbook Air.
I have built it and everything, but i can't find the executable app in the project folder?
I am using 5.1
A faster way would be:
In the Project Navigator (if it's not shown: cmd + 1 or View -> Navigators -> ...) expand the folder Products, then right-click on the ".app" and then "Show in Finder"
Look in ~/Library/Developer/Xcode/DerivedData. Then find the folder for your program.
Build data doesn't go in the project because (i) it's logically a separate thing; (ii) therefore you want to keep it in a separate place; and (iii) keeping it in the same place will usually confuse the issue of source control, either your repository or you.
Apple's preferred approach is that you Build -> Archive, which will (unless you've specified otherwise) always be a release build, then export as a .app or publish to the App Store from the Organiser.
That'll keep that version of the build with all symbolication data on your machine until you delete it. So you can send exactly the same build to someone else, definitely decide any crash logs that come back, etc.
Related
I have an Objective-C app I wrote roughly 12 months ago, with the iOS Deployment target set to 12.1 . I added the ResearchKit framework to it, and during the time of development the app was working fine. What I do remember is that it only worked on an actual device and not on the simulator.
A year later Im back to make changes, using Xcode 11, and am now getting a familiar error, solution to which I cannot figure out. This is both on real device and simulator.
I have done all that is required to add the library. See attached images below:
TARGETS -> General Tab
TARGETS -> Build Phases
ERROR
Attempting to run on an iOS 12 device fails too. Is there something I'm missing?
I ended up removing the pre-build Research.framework and adding the full Project instead:
Remove the Pre-built ResearchKit.framework file, select Move to Trash when prompted.
Make sure the ResearchKit project is closed (if it's open it wont be added as a project but as a file)
Drag and drop the ResearchKit.xcodeproj project file, into destination project. After this make sure the ResearchKit project has its files under it.
Go to Main project file of your project (not ResearchKit) and select your Target.
Make sure ResearchKit.framework is listed under Embed Frameworks. If not, then add it by selecting the + button and selecting it from the list. If it is not on that list then build the ResearchKit project to create the .framework file.
Under the same Target, go to Build Phases, and make sure ResearchKit.Framework is added under Link Binary with Libraries, and also under Embed Frameworks. If not then add it where absent.
Build and run.
There may be better ways to resolve the issue, but for now this works for me to run the App. App now runs on simulator. However, an initial build takes up-to a minute because the ResearchKit project it pretty big.
Update: I later figured out that the reason why I was encountering the 'Image not found' error is that I was trying to run on simulator while the ResearchKit framework had been build to target arm64 (real device). You will have the same issue the other way around (attempting to run on device-arm64 while app was build for simulator).
So how do the above steps fix this? That fixes the issue because by having the ResearchKit project files included you get to build everything for the currently selected architecture, whether device, or simulator. Happy coding.
I have built a Swift app. I added all libraries in Project -> Target -> Link binary with Libraries. I added external frameworks such as Parse to the project too.
I then selected all frameworks under the project and created a group folder called Frameworks.
I have observed/recorded three issues:
When I run ls -l in shell, the Frameworks folder is not actually there
Only frameworks such as Parse & Bolts are actually listed under the project. Other frameworks (e.g. QuartsCore, CoreGraphics etc.) are not listed anywhere with the ls -l command
If I try to archive the project, because the Frameworks folder is not 'there' as far as xcode is concerned, the SwiftFolder is not created (which would result in the app being rejected)
Surely it should be a straight forward process. What am I missing?
Apologies in advance for the fact that my code works yet I cannot solve such a simple problem!
1: A group in Xcode is not a file system folder, it's an in-app Xcode-specific construct. You can add file system folders to Xcode, but they are different and distinct from groups.
2: iOS frameworks will not be visible in your project folder as their location is managed by Xcode. They are added/linked to your app bundle at compile time.
3: Is your app failing validation/being rejected? Sounds like it could be a separate issue, everything else you're seeing sounds normal.
Only one thing worked - Shenzhen (failed on first attempt due to space issue). Here is what you need to do:
Go to Shenzhen on github, download, run and send apple the bill ;)
In case you are wondering, before I tried Shenzhen again, I actually tried the following:
Created a "Hello World" Single View Swift application in xcode. Added all the libraries and used the xcode archive facility to see if it generates the Payload and SwiftFolder. It failed on both.
I downloaded xcode 7.1 (beta) and tried again. This time I got the Payload folder but still no luck with SwiftFolder. So don't waste time on xcode 7.1 for this.
Called apple dev support (and yes, you are likely to be billed for this) - was transferred between three call centres (English spelling - sorry) and finally submitted the issue.
I'm writing a script to archive the iOS portion of a phonegap project. The script wipes the directory that the project is in and then repopulates it using the latest code from source control. I then run$ phonegap local build ios in order to build the project. However in order to archive the project I need its schemes to be defined. I have tried building the project from the command line but I get the message ** BUILD FAILED **. As of right now I have the code open the xcode project (the only way that I've found to get the schemes defined) and then sleep for 30 second while I wait for xcode to work its magic. My question is how can I either simulate opening xcode or otherwise define the scheme from the command line.
Thanks in advance for any help.
This is a completely fair question given that Xcode schemes are somewhat less than thoroughly documented and schemes have this feeling of being somewhat magical until you see how they hook into the build process as a whole.
Based on the workarounds you are seeking, it sounds as though you need to promote a scheme to being "Shared" so that automated tools (or other developers) do not have to first open your project and wait for Xcode to auto-generate the default scheme. This is an entirely normal 'ask' from developers trying to make their Xcode projects work with Continuous Integration systems or with other command line tools acting on an Xcode 4 or Xcode 5 project. The great news is that there are Xcode-native ways to configure your project without having to resort to messy or error prone workarounds.
TL;DR Version:
The default Xcode behavior for schemes is to treat them as a developer-specific setting and not share with other developers or tools. We need to promote your project's scheme to being 'Shared' and commit those changes to your version control system:
Start with a clean checkout of your project.
Navigate Xcode's Menus: Product > Scheme > Manage Schemes... menu option
Uncheck 'Autocreate Schemes' in the upper left corner of the scheme sheet,
Check the 'Shared' checkbox next to the scheme that should be made available to all developer users and build systems.
Finally commit all project changes back to your version control system.
This will make a single Scheme shared across all developer using this project, regardless of OS X username and make it such that unattended builds via xcodebuild or the build tool of choice will have a scheme to work with.
...And now, on to the the longer answer for the curious
First a bit of background before we dive into your direct questions:
Target: The app, static library, bundle, or more generally the 'product' constructed from the source code, assets, plists, build settings, and other files contained within the project. This 'product' is generated when a build operation is invoked either via Xcode's "Run" button or via the command line tool xcodebuild
Build Configuration: A named set of build settings that can be identified by a human-readable label. By default, all Xcode projects start with a "Debug" configuration that generates build targets with the greatest amount of transparency aiding developers in debugging their applications and a "Release" configuration that strips the resulting build of this diagnostic information and optimizes the build to reduce its size. Some developers elect to create additional configurations based on their team's needs: "Ad-Hoc" might be created so that the Signing Identity and Provisioning Profile settings can be changed for code signing the app for installation via an Ad-Hoc provisioning profile. "AppStore" or "Distribution" are other common custom Build Configurations one might see in other projects.
Action: A set of related activities supporting different phases involved in the development, diagnosis, and testing of a product. As of the time of writing there are six actions: "Build", "Run", "Test", "Profile", "Analyze", and "Archive". As a developer the two you will most frequently use are "Build" and "Run".
Build Scheme: An Xcode 4 invention for managing project build target dependencies, build parallelization options, for a specified Build Target. Each Scheme allows a developer to select exactly one Build Configuration (ex. "Debug" or "Release") for each Action ("Build", "Run", etc.) of a project's lifecycle as well as define other behaviors or options associated with that specific Action. For example, the "Profile" action in a scheme allows the developer to select which diagnostic instrument will be loaded by default when Profiling code in Instruments.app.
With these definitions in mind, lets get back to your questions:
How can I either simulate opening xcode or otherwise define the scheme from the command line?
Very simply: You don't need to do either, there is an Xcode-native mechanism for making schemes available and we just need to do some minor scheme reconfiguration to get you up and running then commit those changes to version control (I'm going to refer to this as 'SCM' for the rest of this answer).
The behavior you are facing is Xcode's default project behavior when it comes to persisting project settings. By default, many things are considered developer-specific settings and reside in a set of files mapping to the specific username of the account that opened the Xcode project itself (more on this in a moment). The policy governing these settings could be distilled down to the rule that Xcode settings were considered 'developer private until explicitly promoted to shared'. Although this was present in versions of Xcode prior to Xcode 4, it wasn't until the introduction of Schemes as the primary vehicle for invoking builds that this approach caused development teams and their Continuous Integration systems problems.
Schemes came along and consolidated a great number of settings screens from early versions of Xcode into a single editor window where a developer could take a look at the highest-level settings for each of the different Action phases of the app:
When running the "Build" action, one could define which targets need to get constructed, or if Xcode should try and identify build dependencies on its own.
For a "Run" action, select which Build Configuration should be used as well as which Debugger to use.
For a "Test" action, select which Build Configuration should be used as well as which Test Classes and Test Data Bundles should be used to test application behavior.
...etc...There are lots of other high-level settings but I'm going to leave exploring them as an exercise for the reader...or an opportunity to ask another SO question!
In each case, these settings cause something of a cascade effect -- Selecting a "Debug" configuration keeps as much diagnostic data in the app as possible to aid developers in tracing the source of problems, this in turn would invoke the "Debug" specific Build Settings as configured in the Build Target itself that may also run "Debug" specific scripts or enable "Debug" specific settings.
Naturally, these selections needed to live somewhere so that they could be persisted between Development sessions or on the rare occasion that Xcode decides to crash. The behavior of "Developer private until promoted" reigned supreme and these Scheme settings were persisted in the "xcuserdata" folder within the .xcodeproj file itself -- This still holds true for those projects that reside as a part of an .xcworkspace.
You can see this for yourself in your own project. First, ensure you are working with a clean version of your code, then open the Xcode project or workspace to ensure that your personal version of the default scheme is available when we walk through your project file:
Switch from Xcode to Finder, then navigate to your project's checkout directory.
Right-click on the .xcodeproj file for your project and select 'Show Package Contents'. If you use a workspace, still select the .xcodeproj that contains your project files, and not the .xcworkspace itself
Navigate into "xcuserdata".
Depending on the number of developers that have been involved with this project or the number of different machines with different usernames that have committed against this project, it is distinctly possible to have more than one .xcuserdatad folder.
Select the folder that matches your OS X username. For me, my OS X username is 'bmusial' so I would select the 'bmusial.xcuserdatad' folder.
Navigate into 'xcschemes' folder.
Observe that you have two files: "[TARGET NAME].xcscheme" and "xcschemenamagement.plist" that contains information about the order of schemes and if schemes should be auto-generated or not.
Ah ha! Schemes are treated as developer-private data and are auto-generated on the first launch of the project!
This realization starts to get at the core of what we need to do -- migrate this scheme out of the developer-specific xcuserdata folder into something shared among all developers, disable auto-scheme-generation to prevent others from falling into the trap in the future, and commit those changes back to your SCM. Switch back to Xcode, let's reconfigure a few things:
Navigate Xcode's Menus: Product > Scheme > Manage Schemes... menu option
Uncheck 'Autocreate Schemes' in the upper left corner of the scheme sheet,
Check the 'Shared' checkbox next to the scheme that should be made available to all developer users and build systems.
Switch back to your Finder window and go up a two levels to get back to the contents of the .xcodeproj folder (the one that contains a 'xcuserdata' folder). Notice that you now have a 'xcshareddata' folder. This folder contains a 'xcschemes' folder that contains the scheme we just shared and the .xcscheme in our own xcuserdata folder is now gone. We have just promoted your private Scheme as a shared, public scheme that will be available to all developers and tools, even those that have never launched the Xcode project directly.
Commit all of the changes we've made (there will be some new folders and files!) back to your SCM so that everyone receives the same configuration changes when the next time they update their source code!
The next time you run phonegap it will reset your checkout as your indicated but because you have a scheme committed it will have build actions it can work with.
Give this a shot and let us know how things go and if you run into any followup questions or problems along the way.
You may also find the ruby gem xcodeproj useful. It can create schemes without having to open xcode.
You can read more about it here.
For phonegap/cordova, save the share_schemes.rb script in a scripts directory in the cordova project.
#!/usr/bin/env ruby
# share_schemes.rb
require 'xcodeproj'
xcproj = Xcodeproj::Project.open("platforms/ios/MyProject.xcodeproj")
xcproj.recreate_user_schemes
xcproj.save
Then add a hook to run it in your config.xml.
<platform name="ios">
<hook type="after_platform_add" src="scripts/share_schemes.rb" />
</platform>
Now you don't have to open xcode to make changes, or check in any changes in your platforms folder. Every time you add the ios platform, your scheme will be created by this script.
I'm writing a modification for Arduino that turns an Arduino board into a game controller.
In order to add my board-specific files to the programming environment, right now, the user needs to open up the Arduino.app package, and then add a few different files into a various folders in the Arduino.app package. It is hardly user friendly. How can I make an installer which automatically moves my files into the appropriate locations within Arduino.app, or is that impossible?
You can download PackageMaker (available here, in the Auxiliary Tools for Xcode download).
You will then be able to make a .pkg that the user will be able to install simply by double clicking. You can also make a script that will check if Arduino is already installed and stop the installation if it's not. You get the idea.
Normally, especially in today's code-signed MacOS app approach (where any modifications to the app or its resources/files would break the app & make it not-launchable), I would say "you're out of luck".
But Arduino is one of the rare OPEN SOURCE apps.
You can fetch the source code from this page:
http://arduino.cc/en/Main/Software
And make your modifications to the project and then build a fresh, customized copy for yourself.
I figured out how to do it using the magic of scripting!
You can take a look at my solution here:
http://code.google.com/p/unojoy/source/browse/#hg%2FLeoJoy%2FLeoJoy%20Installer.app%2FContents%2FMacOS
The folder structure it's in makes it show up as an app on OSX, and the two scripts (LeoJoy Installer and LeoJoyInstaller.command) copy the files. There's two scripts there because I wanted to have a console window pop up to show the user progress, and that's the only way I could figure out how to do that. But, if you run this app in the same directory as the Arduino app, it copies files from the installer app into the Arduino.app package, updating the Arduino app so I don't have to distribute a whole separate version of Arduino.
I have a workspace that contains a project and a static library.
The library was called A originally and then I renamed it to B. However I changed my mind a little later and renamed it back to A.
The trouble is now that Xcode only lists liblB.a in Link Binary With Libraries and I simply cannot get this to go away and for liblA.a to reappear, even though I have renamed it back to A.
Within XCode the name of the target is A, also the name of the Product Name in the Build Settings is A. I don't have any references to anything named B anywhere anymore AFAIK or that I can find.
I've cleaned everything and cleaned again, deleted Derived Data in Organizer, closed and restarted XCode (which is an amazingly effective way to usually solve issues like this).
When I build the library it builds sucessfully and XCode say "Build A: Succeeded", it doesn't say "Build B: Succeeded".
I've seen this sort of problem before where XCode has problems shaking off references to things that no longer exist, and the usual solution is just to do a clean and a close of XCode. But that's not working this time. Any other suggestions on how to get XCode to forget about the name B and stack picking up A?
Thanks
Commit your code
Close Xcode
Open the xcodeproj file with your favorite text editor
Find all references to the undesired name and delete them or change them to the desired name
Open Xcode and test
If everything works, commit your code. Otherwise, revert and try again a little more carefully.
Generally, simple hand-editing the xcodeproj works fine, particularly to just rename or remove things. It's harder to add new stuff.