It's getting quite frustrating with Xcode 5 here. All I'm trying to achieve is embedding some custom Cocoa frameworks into my project and create two versions of the app, one for the Mac App Store and one for a custom Online Store (so that when building for the MAS there'll be a folder called Debug (MAS) so I can distinguish it from the other version).
I embedded three frameworks into the project (only god knows why only one project can have another one embedded at a time, to hell with this limitation) and added their products in the "Link binary with libraries" and "copy frameworks" build phase. The finished built products are at the default location in the Library.
Now here's the thing - every time I'm using custom build configuration files other than "Debug" and "Release", the frameworks are NOT copied to the custom build folders but instead just go into "Debug" and "Release" regardless of any build options of the main app. Also, the frameworks are always built using "Debug" and are no longer connected to the current build mode (test, archive, etc.). To cut a long story short, this is a huge mess with file paths and obviously a lot of bugs concerning custom frameworks and custom build configurations.
Now my question is - there has to be an official or working way of maintaining an Xcode project that is both distributed over the MAS and a custom online store (two versions) and has at least one custom framework embedded. How do all other developers have solved this problem, I feel like I'm doing something fundamentally wrong and if I do, sorry for putting the blame on Xcode but something's for sure: Xcode's path management with external components is a chaos and the cause for unlimited mailing list and forum posts...
The answer is to create separate targets for the MAS & non-MAS app. You can add additional targets to build the custom frameworks and make the different targets dependent on each other (as necessary). Once this is all setup (properly) then building any of the targets will build any dependent targets (with the same build flags). And AFAIK there's nothing preventing an Xcode project from including multiple sub-projects so I haven't a clue why you believe this to be the case.
Related
Is it possible to have a single Xcode project (and ideally a single target) that will conditionally include frameworks when built against a certain version of OS X / Xcode but not include those frameworks when built against another version?
I'd like to begin adding support for El Capitan to an application I'm working on but some of the support I have in mind requires linking against frameworks that are not present in Yosemite. Is there a way to configure an Xcode project so that the same project can be built under 10.11 / Xcode 7 with the frameworks but also built under 10.10 / Xcode 6 without the frameworks (and without throwing an error)?
I'm aware of how to check for the existence of a class or method at runtime, but it's not clear to me how I control the framework linking without creating a second Xcode project, a second source control branch or always building against Xcode 7 (none of which I want to do, yet).
The "other version" would essentially be another target — it's setup this way to do precisely what you're asking about. A basic example would be just a matter of right-clicking on your original target and selecting duplicate from the current targets; then make whatever changes to linking frameworks within the Build Phases section.
Targets
In Build Phases you'll notice I've linked three frameworks to my
original target:
After right-clicking on the original target and creating a duplicate
I'm able to link it differently:
The duplicate version of MyApp uses the same classes and headers as the original with the exception of those that require the excluded frameworks. It's also possible to import different frameworks, change things such as the Deployment Target (e.g. build for different versions of OS X), or perhaps which SDK each might use, etc.
Once you're more familiar with the standard build process you can then create custom build scripts to handle specialized tasks like keeping the target names the same or even creating installer packages — anything is possible.
OK, I know this question seems pretty easy to answer, or maybe documented, but I'm honestly 100% confused around the subject, with effects as... silly as submitting an application for review by Apple and then realizing (by the logs they sent me back), that the Framework wasn't there (actually, it was... but my Cocoa app was looking for it elsewhere).
Ok, so... let's say I have a framework with like 100 different classes I mostly use (which I do have), what settings should I use if I want to "bundle" my Framework with my apps (and copy it in the framework folder of the app bundle)?
Build Settings -> Installation Directory? (of the Framework)
Build Settings -> Header Search Paths? (of the App)
Build Settings -> Library Search Paths? (of the App)
Build Settings -> Framework Search Paths? (of the App)
use #rpath? and how?
anything else?
Given that I mostly have issues "linking" my frameworks to my apps (the framework compiles great, but there may be a runtime error occasionally when the app using it tries to run (which I... occasionally manage to solve - but without actually knowing how... lol)), what would you suggest?
Third party frameworks should be included with the app in a Frameworks directory of the app bundle.
Add a new copy files build phase and specify the Frameworks directory, then add your frameworks to this directory:
You may also need to tell Xcode where the frameworks are by adding a Framework Search Path like "$(SRCROOT)/MyFrameworks".
As far as I see every time I make a change, for example the value of a configuration variable, I have to
Make a copy of the change in each project (webapp, Android, IPhone, etc.)
Build each project
Distribute each project (besides the webapp)
I have found PhoneGap build which seems to be a great solution for the mobile part. But it's still beta and it doesn't solve everything. I still have webapp's code, which is not exactly the same.
Do you know techniques, tools or tricks, which help to improve this process?
Thanks in advance.
We are currently developing a web/Android app using PhoneGap and Sencha Touch (iOS is coming soon). So far our approach is as follows:
We have one project per platform plus several additional toolkit projects.
One platform is "primary", web in our case. This is what developers mainly use to develop and test the app. We're using jsTestDriver for testing.
During the build, the app is packaged for web in the first step. We're producing several artifacts here (.war file, tests in a .jar file).
"Secondary" platform projects do not include the source code. It gets unpackaged and copied to the right places when projects are built. This also includes tests from the primary platform.
Platform projects contain some additional code - normally only testing code, app code itself is currently cross-platform (not sure if it will stay this way).
So we're doing it mainly through advanced build scripts. We're using Maven for web and Android. iOS is coming soon (into our work, I mean), so we'll be looking for some sensible build tool there too.
We're building our projects using Hudson continuous integration.
What I have to admit is that this whole environment (multi-project Maven builds, JSTD, multi-node Hudson) is a hell of a setup, took quite an effort to figure it out.
I recently did some research on making a cocos2d app for iPhone/iPad AND Mac. I have done the iPhone/iPad route but have never done it with a Mac target. It appears that some people have added it as a target but mentioned that it is finicky and others have suggested making a separate Cocos2d Mac project that uses the same files. Any wisdom to impart here?
I believe it is absolutely crucial to have both iOS and Mac targets in the same project. Otherwise you'll spend too much time keeping one platform in synch with the other, until eventually you either manage to create a good (but still time-consuming) workflow - or end up neglecting one of the two platforms.
Ideally the code base should make as little use as possible of compiler macros. You'll want to compile both iOS and Mac code even if it's not being used for one platform. So having some classes or methods that are #ifdef'ed to Mac, others to iOS, will more often than not lead to compile errors when you switch targets. That means wrapper classes, so that you can write the same code regardless of the platform, are essential.
Right now, Cocos2D doesn't offer you to create iOS & Mac targets in the same Xcode project. The way to get there isn't immediately obvious either, because each target requires its own build settings for: Base SDK, SDK Root, Deployment Target, Architectures and possibly Compiler version. It gets worse if you also want to use 3rd party libraries (Box2D, Chipmunk, etc) because in some cases you'll be forced to create iOS and Mac specific targets for those libraries as well - if only to ensure that the library is built with the same compiler as the project's target, otherwise you can run into the strangest build or runtime issues.
I've had issues getting these platform specific targets to work within a single Xcode project without Xcode complaining or otherwise misbehaving. I haven't tried it with Xcode 4.1 and 4.2. By that time I had created .xcconfig files to host the build settings. The .xcconfig files may or may not be necessary with the more recent Xcode versions but they definitely make managing multiple platform-specific targets easier.
Long story short, the best and easiest way to do cross-platform development with cocos2d-iphone is by using Kobold2D.
Most of the 15 template projects have an iOS and Mac target in each project, you just need to select the corresponding scheme, then hit build & run. The most commonly needed platform-specific code (processing user input) is wrapped in a platform-agnostic, simple to use wrapper class KKInput.
Disclaimer: I'm the developer of Kobold2D. There's a slim chance that I may be biased. You should try Kobold2D anyway. :)
I have a more general question on working with libraries on with Xcode when building iPhone apps. I've created a framework from a project I've been working on to use some parts of it in other apps. That works pretty good, so far. But I have no idea how to debug into the files included in the included framework.
I hope to get some kind of 'best practice' on that.
Thanks a lot
–f
There have been a lot of discussions of how best to reuse code with static libraries. I've settled on the method described here by Clint Harris (which I think is what Shawn is suggesting as well). Creating a project dependency in this way automatically compiles the library for your project's target (simulator/device, debug/release) so you don't need four different copies of the compiled library sitting around. It also lets you step into the library source when debugging, as you want. Finally, updates to the library are included in any of the linked projects the next time those projects are compiled (so you don't have to recompile and redistribute the library binary to those projects yourself).
Generally, I'll include the Xcode project for the library as an external project dependency of the main application's project. The advantage of project dependencies, is that you can add a build phase that builds a fresh copy of your library along with the main project, and of course it will let you set breakpoints in the library's code.