Cocos2d file templates xcode 4

It is a good idea to always create a Distribution target for apps you intend to publish. Then in your build settings you can configure the code signing of the Distribution target to be the App Store distribution provisioning profile and the code signing for Release configuration can be set to the test provisioning profile or an ad hoc provisioning profile. It is important to ensure then that any settings you change for the release are also applied to the Distribution configuration so that the only difference between the Release and Distribution configurations are the code signing.

You could even wait to copy the release configuration until you have configured it for what you think will be a stable setting and then copy it and create the Distribution configuration with the correct code signing. One other important thing to note is that you can configure build settings for the project, but the target build settings can override the project build settings.

What is a Target? A target is basically a specific build of an app. Most of the time I have applied settings at the target level. For example, you might decide to create a free version and a paid version of your app.

A simple way to do this is to right click on your existing target and click duplicate. This will create a duplicate of the original target. You can then click slowly on the copied target name twice to highlight it and then rename it to something appropriate, such as SampleOpenGLApp-Free. What is a Configuration? Each target can have multiple configurations.

The two default configurations are Debug and Release. The primary purpose of these configurations is to enable making small changes when building a specific target, such as enabling or disabling the debugger. Code signing is another type of change that fits well into being defined at a configuration level. As mentioned above, for all of the apps that I create, after I have setup the Release configuration for a project I duplicate it and call the new copy Distribution.

I then change the code signing in the Distribution configuration so that it uses the provisioning profile for Apple App store distribution. It is also necessary to change the Archive scheme setting discussed below to use this configuration for the specific target more information about that is provided below in the Schemes section of this article.

General Tab The General tab is visible when you have a specific target selected. These settings are specific to each target. Here you can set the version number, app identifier, iOS version deployment target, app Icons, splash screens and other settings. Capabilities Tab The Capabilities tab is where you define specific capabilities, such as Game Center, that your app requires. Info Tab The Info tab displays the info. The info. Each configuration within each target can optionally have a different info.

Build Settings Tab The build settings for each target contain a lot of preprocessor and compiler settings.

The following are some that I think are important to understand. Code Signing Identity — You must set this to your iOS Team Provisioning Profile or some other valid provisioning profile in order to test your app on a physical device.

You also must assign a distribution profile to a release or distribution Scheme in order to publish an app either ad hoc or via the Apple App Store. User Defined Settings — User defined settings enable defining specific things for each target. Then in the app you can use the ifdef preprocessor commands in your app to add conditional build code to alter the build so that one target will build a normal version of your app and one target will build a paid version of your app.

So if you wanted to set this to 6. You should of course have to test on all major versions from 6. Base SDK — This is the software development kit that will be used to build and package your app. This is different from the iOS Deployment Target version. The default setting is Latest Version, so it should automatically set this to the most recent version you have installed. Build Phases Tab The Build Phases Tab is primary used to configure library linking and enables reviewing which resources will be added to a build.

The Link Binary with Libraries enables adding specific frameworks or libraries to your app. For example, if you wanted to add Game Center, you would go to this tab, expand the Link Binary with Libraries and then click the small plus sign in the bottom left corner and select the GameKit. It is important to note that this only adds it to the currently selected target.

It also strangely adds it to the top of your project navigator view. After adding a framework, drag it down to the Frameworks group folder and then check the target membership in the utility side view discussed in the changing view section above. If you have multiple target, you can choose which target binaries the framework should linked to. The Copy Bundle Resources allows reviewing all of the resources that will be added to your app bundle when it is packaged. This is a semi-useful way of reviewing your resource bundle before packaging your app.

Schemes are used to manage which target configurations to use in specific scenarios. The scenarios for each Scheme are run, test, profile, analyze and archive.

I am not sure if scenario is the official name for these, but calling them scenarios seems to make sense to me. Scheme names are auto created from the target names, so if you want to change their names you can change the target names, delete the schemes in the scheme manager and then auto create new schemes. In the scheme manager you can double-click on a scheme name to view the scheme details. It is here that you will want to set which build configuration is used in each scenario.

If you are not using unit tests and advanced diagnostics, then the Run and Archive scenarios are the most important to you. The Archive scenario should be set to the build configuration that has the desired distribution code signing. I set this to the Distribution configuration that I created in the Project Settings section above.

After the project becomes more mature, I change the Run scenario to use the Release build configuration and disable the debugger by selecting None from the drop-down list box to select the debugger.

Latest commit. Git stats 20 commits. Failed to load latest commit information. View code. Compiling installer from source Installing How to update? How to uninstall? I am a designer, can I redo the horrible UI an its animations? Requirements Mac OS X How to install? Compiling installer from source Follow this steps to compile and run the installer from the source code. Double click on the installer to open it if not already opened.

You should see information about your current installation on the first view. When ready press Continue. On the What to install? When ready press Install. Feel free to change the folder as you wish. Since the new release of Cocos2d-x v4. One for macOS and one for iOS. Considering that compiling and running for iOS needs the simulator, it might be easier and faster to do your test and development for macOS instead.

To compile for macOS:. Is there a reason you chose to use cocos2d instead of the SpriteKit? Hi, Reza, Can you, please, explane how can I make my folders structure in the folder of my source files? In Cocos 3. Can you please share the link on some project with complicated structure? If I put all file in the root of this folder — no problem, but it is not convenient.

On Android I should write path to each header file as workaround. The directories are the same in both v3 and v4 and it is called classes if you check in Finder. In the Xcode project on the other hand, you have Classes in v3 and Source Files in v4, but inside Source Files you can see there is still Classes and the files you write goes there. The Xcode folders are not the same as the actual file folders.

I am having trouble with the cmake step and, in general, having trouble getting a xcodeproj file in my iOS Cocos2d-4 project.