I've run into a bit of a dilemma.
I'm considering making a lite version of my app that will be for free but will run on iAds. The Lite version will therefore have different .xib files because I have to make room for those iAds.
So what's better, should I just make some more .xib files in my project and then somehow programmatically load them. Or should I just create a completely new project (copy & paste
my old directory) and create the lite version?
Definitely don't fork it. You will regret it big time down the road as you'll have to merge virtually every commit across projects. (And XIB files can't be merged...)
I don't even know if you necessarily need to create additional XIB files. You could probably just conditionally resize/hide the necessary views in code. But even if you have to create additional XIB files, it doesn't compare to the pain you'll go through from forking.
Just create a different target within the same project. You can include different combinations of xib and source files within each target, and use some #ifdef's in your source code to limit features or functionality in the Lite version of the target by using a preprocessor define in the Lite target Build settings.
Related
Our team has made a big app. This app has been a success with previous client.
Now other clients will be using this app, but with added requirements and/or different needs.
I would like to focus on making the current app into a generic Engine so that we can maintain this engine up-to-date across those different client-apps.
How should I:
Tackle this?
Bearing in mind that some viewControllers will need to reflect for new client
Changing all the graphics across the app
Any hint of how I can achieve? Been googling since long, could not arrive at a decent solution.
I already did something similar in the past, here is how we did:
part 1A: create a template project using demo assets (images has to have a default names ex:background_home.png).
part 1B: make sure that "special texts" are loaded from a plist (example:[HOME_TITLE:"your title"]) in this way you will be able to load customizable texts from a plist in the app bundle programmatically.
part 2: ask your designer to make a special design for the client respecting the name used by the developers in the code (ex:part 1A => background_home.png) or ask your designer to generate more or less 20 themes.
part 3: make a MACOS app or a script which will copy the original project and replace demo assets and plist by the correct one in the original project. You want the script to generate an xcode project as you will need to double check with your developer team that the project is properly setted-up, build and deployment is much easier when you have an xcode project. In other words, the script just take the folder of the original project your team made and replace some file inside. So you won't struggle with xcode project architecture, you just replace defaults assets. Also remember that storyboard files or pbxproj are xml so you can parse and edit them, but you might have some headache doing this, that's why I recommand you to just modify the assets in the project folder.
Then you can compile that project, configure it with the provisioning you want and deploy it to your clients. Thats what we did when we needed and it worked like a charm. Basically we made a MACOS app that the sale's force could use directly with the client. They just had to send to the developer team the generated xcode project in a zip and we were in charge of the compilation and deployment. We "developed" more than 600 products using that trick.
PROBLEMS:
- The code was fully visible in the xcode project and anybody could read and/or steal it.
- The projects were very similar to each others as they came from the same source code, only the texts and assets were differents.
WORKAROUND-SOLUTIONS:
- You can imagine implementing crypto when saving the archive of a project, in this way only authorized personal can unzip the archive containing the source code.
- You can create multiple projects and do the same process with different types of project. In this way you can change the type of a generated project according to client wishes ...
Hope this help!
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 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'm in the process of creating an app. I'd like to have a pared down free version and a full paid version. Obviously, they will share a lot of code and some xib files. How to I share these without just duplicating them?
Create a second target (duplicate the main one) for the light version. You can then remove any files as necessary and define a preprocessor macro if necessary to distinguish between code for the lite vs paid version within a given code file.
How about making it one project with some sort of key or switch or something like that which will distinguish with version of the code to run.