I had two target for my application. One free and other is for paid.
Now i need to add different icons for both target. Now the problem is that i can not used apple naming conventions like now i use icon_free.png and icon_paid.png.
My Problem when i add 512px icon then will iOS will automatically pick the correct image for each build
There are two ways.
First option: You can use apples naming conventions. Just store the icons in different sub directories. When creating the second target one suitable sub-dir was created. However, you can create a new one.
Place the files with default names in each of the directories.
Create separated groups for them in your navigtor tree in xcode. Upon creation of the second target that should have been done anyway. So you can have both versions of the icon with the same name at different branches within your navigation tree.
Then go to the copy build settings of each target and make sure that the appropriate version is included for each target.
Second option: Alternatively give the icon (and default etc.) files different names and name them explicitely in plist.info. And plist.info then exsist for each of the targets. For plist.info xcode should have created separate files anyway. You find it on the info tab of the projedct settings close to the build obtions tab.
In general I found it is good pactice beeing neat with separate folders. After hasseling around with difficult problems when having two targets with newer apps I always have one sub-dir with all the shared resources and one for each of the targets. It makes it easier to boundle the copy and compile settings for each of the targets accordingly.
Just one more: When ever you apply changes to the bundles in this way you should delete the apps thoroughly from the simulators and test devices. If you don't then you may run into situations where the root cause is difficult to find. That is that there are old versions of some of the resources on the device. They will not be updated along with new releases. You will then have as best missing resoures on 3rd party devices and in the worst case you will chase errors and all what you try does not have an effect on the device/simulator because the locally existing resource is not being updated. Difficult to figure out.
Related
I'm developing an iPhone app that can edit images. Ultimately, I want to have a small version that allows the user to simply edit their images, and a large version that allows social networking of the images. Then I'd like to develop a version of each for the iPad.
Being that this is my first foray into commercial mobile development, I'm confused about how to organize all these versions in Xcode. Obviously, there will be file reuse shared between each version. I guess my question is, how do I go about organizing these separate projects in the most efficient way so that they share files and so when I edit a particular file that is shared, the changes are made to each version of the application? Is there some kind of construct to follow in XCode?
Are there any links or literature on how to go about doing this? (was not sure the correct term to search for it).
Remember: If you find yourself repeating/duplicating something, suspect that you're doing it wrong.
Your Xcode project will have 4 targets in this scenario. The basic target layout for this setup looks like this:
A Static Library (for your shared source files)
A Resource Bundle (for your shared resources)
App-Full (Universal)
App-Lite (Universal)
The apps link to the shared static library, and copy the resource bundle.
Naturally, apps will have sources/libraries/dependencies which differ -- those go in the app target (or some other dependency).
Given your background: Plan on it taking a good amount of time (initially and as you go) and patience to figure out how these dependencies should be composed, used, and maintained.
I would suggest keeping the "lite" and "full" projects separate but within the same workspace. That way you can keep the shared files in one project and simply use a shared reference to them in the other. All changes made to the shared files from either project will affect both.
As far as iPhone/iPad versions, I would also suggest that you keep these apps completely separate but within the same workspace (so that they can share code) as well. If you look around about the suggestions for managing both apps in a single project (aka, universal app), the only real benefit is that customers can buy one app and can download it on either device and some may get upset if that isn't available to them. If your app is free, don't worry about it.
Lastly, a caveat about workspaces, you need to uniquely name your files across all projects. For example if you're working with a project that uses a MainViewController.h subclass and another project that uses a MainViewController.h subclass, you could assign or edit the wrong one by accident regardless of what project you're in, so be wary. If using unique file names is a problem, you can bypass using workspaces by simply creating an empty project to dump all of your shared code into and then add references to your standalone apps from there.
If you choose to keep various copies of your project for different functionality, it will be eventually confusing, as there are places when XCode offers you one thing instead of another. One such place is - when you open a project from location X, it will also show you your copy from location Y since you opened it last time. As a result, you are likely to commit more mistakes. Organizer is one more such place where you can make mistakes.
XCode is self-contained enough to maintain both iPhone and iPad versions. You will have two separate storyboards which can be made part of one project if you chose universal as the type of app.
As for various features, you shouldn't be maintaining separate copies of your project. Instead, recommended way is to keep all features within single project, and have app logic provide access to various features.
XCode keeps version of your build under Targets section when you click project. To maintain multiple versions through your dev cycle, use source code repository (git or svn).
I have my app with ID com.mydomain.AppName which is a paid version.
I decided to introduce free version as well, and through my code I easily add ads/remove some functionality with simple #defined/#ifdef business.
However, I do need my app ID to be different for free version. How do I do this conditionally (i.e. #ifdef FREE_VERSION ... etc.) for my app?
This question was answered in a previous post
The basic idea is that you create two targets and then either use #ifdefs or create separate files to control the content in the two targets. Creating another target is dead simple. Just right-click on your existing target and duplicate it. Give it the name that you want for the free app.
In your case, you'll probably want to have different icons for the Free and Paid game, so create two icon folders—one called Free-Icons and the other called Paid-Icons. Put them in the project folder and when importing attach them to one of the targets.
I duplicated the original Info.plist and Prefix.pch files and gave them different names but you could use the same names, just put them in different folders. You'll need to adjust the build settings for each target to reflect the new names.
You might also have less content in the free app. Just select the sounds and pictures that are only in the paid app and in the inspector mark the Target Membership as just the paid app.
You'll also need to edit your schemes as so that you can build two versions. I just finished doing this for a project that I'm working on and it took about two hours from start to finish to find everything that needed changed. I'm guessing I could add another version in about 15 minutes now that I know what I'm doing.
This way of doing things is way better than duplicating the code or swapping the content out in one code base because you can easily switch back and forth between targets to make sure everything works when you make changes.
You could achieve this by having different XCode projects - one for each type of app that rely on common code (aka library XCode project(s)). One XCode project would be for paid app, and would have different macros, setup functions. The other XCode project would be for free app. Both the apps's projects can include shared sources - which would be compiled based on macros (PAID or FREE) etc.
I've been asked to write scope the effort for rebranding a significant iPhone/iPad application for multiple customers, locale, languages, etc. Each incarnation of the rebrand might include different look and feel, possibly different behavior, or subsets of functionality.
My initial impression is it should be possible to use a single xCode project, and just include multiple .plist files targeted to specific project configurations. I'm unsure exactly how to accomplish this in xCode, thus I'm not sure how to accurately estimate the effort required.
I'm looking for pointers and developer references to find the most reasonable method to rebrand an existing app multiple times without forking new xCode project each time.
The feature I've been looking for is called "Targets" in xCode.
I'm going to use these as described here to deploy my single project into multiple binaries.
I'm not sure that's possible but with MVC, Cocoa makes it easy to localize apps.
I've used a client-server approach, where everything specific to one customer is downloaded or configured from a remote server. You still need customers with overlapping requirements, but you can switch on/off modules based on the needs of a particular customer.
Low-tech approach: grab the data, configuration files, and images from a different location in the file system. Or the same location, but drop the new customer data into the directory and archive the old. A plist, a text file, a series of #defines, etc, can switch a behavior on or off. Write your code so that it doesn't know how many images, which modules, what color the buttons are, etc, until it checks the configuration and gets the data and images it needs from your directory.
I have an iPhone/iPad app that I want to port to MacOSX. Most of my objective C classes should work just fine as long as they do not contain UIKit stuff. Obviously the interface will be different.
What is the best way to do this in Xcode? Start a completely new project? Add a new target? How can I keep the different platforms in sync? Should I just use git with multiple branches?
I've had difficulty setting up a unified project with different targets for the two OS types, so I generally split this into two projects that share source files.
For an application that will be targeted Mac and iOS, I tend to create one directory for the application. I place the two projects within this, and set up one directory for shared source files, one for iOS-specific stuff, and a third for Mac-specific stuff. This way, you might have different projects, but shared files will update between them as they are changed. The only time you manually have to sync the two is when a new shared file is added to the application and must be added to both projects independently.
You should be able to restructure your existing project to support this without much trouble.
You can also simply add the files from one project as references to the other one. Simply drag them from the source project (where the actual files reside) into the other project. The dialog will ask you whether you want to copy the files. Choose no. This will make the second project point to the files in the first project. Edits go into both projects.
Be careful with this, though, as there are a few differences between APIs in iOS and MacOS, even if they are called the same.
I was always wondering what's up with those Targets? What is it all about? What's the point of that? I never had to fiddle around with them, but obviously I can. Why should I want that, and what can I do with them? What's their purpose?
Each project can build multiple executables or libraries or call out to a makefile or shell script to build "stuff". Each one of these is a Target.
One iPhone project I have includes a separate target for each static library in my home grown SDK and a shell script target to build the Doxygen docs. Another project includes two targets, one for the app as used by general users, one for an administration & management edition.
In the first example, I need to build each library then link all the static libraries into an SDK test application, so my SDK Test App depends on all the library targets (but not the docs, since I don't need to constantly regen them.)
In the second example, the management and the general versions of the app share a considerable amount of code and resources. When I change one, I want to change them both.
The target is something like a "blueprint". It includes rules that tell the compiler what to do, which sources should be compiled, which files should be copied into the application bundle, which libraries should be linked.
If you want to make a Free-Version of your app one way to do so is to add a new target.
Of course you could just duplicate the whole project but then you had to keep those in sync if you change some code. Using a different targets makes this a lot easier.