Similar questions have been asked before, but I can't find the specific details I'm looking for. I have an Xcode project which has been completed and submitted and is on the App Store. I want to make a similar app for release in a different country. To avoid complications, I want to use a fresh project in which to make the changes. I intend to make a copy of the original project, tweak it, and then release it (this is not about language so localization is not the answer).
Because Xcode is doing so much complicated stuff under the hood, and because I'm unsure of exactly which details are being validated when submitting to the App Store, I don't know which details I need to change to ensure two separate projects on my Mac and two separate apps in iTunes Connect.
Obviously I will need new provisioning profiles for the new project. What else do I need to change once I've duplicated my project? The bundle identifier maybe? Anything else? Any advice much appreciated.
The thing that must change between projects is the application ID (or bundle identifier, as you called it).
And yes, when you change the application ID, you do need to create new provisioning profiles to go with it.
If you're feeling really ambitious, you can use the exact same project as your original one and merely create a new target (and application). That way any code changes you make to one can be picked up by the other and the differences would be the ID and maybe the localizations/resources used in each app. Here is a related question that talks about that.
Related
I started working at a company which developed an App for mobile payment. There is a "Terminal"-App, which receives payments of customers and then there's the "Wallet"-App, which users can download and use to pay (at those terminals).
The project consists out of 2 targets - one for the Wallet and one for the Terminal. The App is used only in 2 Countries. It's all quite sophisticated and has a huge code base.
Now I need to whitelabel the whole product for a client, who wants to use our App (both targets) with his own branding (and maybe some additional features or without some specific features) and I'm not sure what the best way would be to achieve that.
Currently I see 3 options:
Duplicate whole project
To copy the whole project to a new folder and make my changes in that new folder would probably be the most "dirty" approach. At some point, my first code base could differ from the duplicated one too much. Additionally, if any security-related issues would come up, I would have to fix it in both projects.
Create another 2 targets
I was actually thinking that this would be the best way to go. Creating a new target for the Wallet and the Terminal and then checking the current target in the source code to decide which features should be enabled or disabled sounded pretty good to me at the beginning. But then I created the new target and noticed that I will have to set that checkmark on EVERY single class for that new target. Besides that, I'm not sure any more if that's really the best way to go.
Use If-conditions
The third option would be to wrap every function, that will be available in only one of the apps, with an if loop. I see this as the "cheapest" option because it's easy to set up and I can still maintain my code base pretty well.
Is there any other option I have? Which way would yo go?
The most significant difference between the base App and the whitelabeled one will be its language. The whitelabeled version will be right to left, but iOS does a pretty good job on that without needing me to do all the mirroring.
You definitely want the extra targets. Having a new target means it's easy to use a separate bundle identifier, signing settings and more. It might seem like a pain to have to tick a bunch of boxes to add your files to the new target (perhaps quicker to use the target's Build Phase|Compile Sources list in Xcode) but it's worth it to create a real separation between the apps.
Instead of using a bunch of source code checks to determine which white label app you're in, consider making your app more data-driven. A plist file could be used to determine which capabilities your app has, and a different plist file can be used for each target.
For example, it might contain a top-level dictionary called features, with true/false values for a bunch of feature names. You have a FeatureManager that reads the file and is the single source of truth for all app components that want to know if something should be available or not.
We developed an app for our client and it is now available in the app store. Lets call it the MAIN APP here.
Now the client wants a separate version of that app, without changing anything but just the name of the MAIN APP. Let's call it the ALT APP here.
The MAIN APP has two Xcode projects, one is the older one, the other is the latest, which is the one what I am working on with new features.
I uploaded the first version of the ALT APP before by changing the app name and bundle ID of the older project of the MAIN APP. So you can think of it that the older project of the MAIN APP is now the project of the ALT APP
Now I need to update the features of the ALT APP to the same as the MAIN APP.
One way to do this is to copy paste the source files of the MAIN APP and overwrite it to the source files of the ALT APP but I think this takes time.
The other way I thought of is to just change the app name and bundle ID of the latest project of the MAIN APP, upload the ALT APP and then later on change it back when I need to upload the MAIN APP
But I am afraid that if I kept on changing the bundle ID there will be build problems(although I haven't encountered any yet).
Is there any better way to do this? Thanks in advance!
Make One Project.
Go to Project setting -> Build Setting
Change
Current Project Version
As you want.
Duplicate your 'base' target as you want
Go to Target -> General -> Version
and Write $(CURRENT_PROJECT_VERSION)
Change bundle identifier.
Go to Target -> Info and find 'Bundle name' and change it. That will be your app name.
I wish you can solve your problem.
This sounds a lot like you need to look into branching in your source code repository. Git in particular is suited to pulling individual commits between branches. Thus allowing you to select changes to copy. Providing you are careful about what you are committing.
Ultimately it sounds like your project is going to end up being an old code based with patches and a new code base with new features. Perhaps your client is not clear enough about what they want. Keeping two version of an app current in the app store would be a headache. Far better to retire one and move with the new.
well, I have my Xcode project done recently, which is a "promising" iOS app, and need to be evaluated by my boss in order to apply for a development group. But, no wonder, bosses are always, u know, lack of "professional" skills. I even cannot assume them to have an xcode compiler on his computer.
But, I need to present what I have done in a intuitive way. I have already finished a "project report", and I have to hand them in together with my project codes. well, that's the rule, and I cannot stay with my bosses to explain "how to open the file"..
So, I am wondering if there is a more simple way to show them the app. luckily, I can burn a CD to store the things they need. However, obviously, I rank "give them a Xcode install file" as the least choice.
Is there any better way that I can show my work? i.e. provide an iOS Simulator with that app pre installed? how could that happen? or any way else?
by the way, I have tried to upload it on App Store, but failed. Since it is just a raw beta version (too ugly to be listed on Store, as Apple explained). And I have heard that I can use "Enterprise Distribution" to skip App Store check. But, I cannot have an "Enterprise license".
Is it possible to have two projects in XCode using the same codebase?
I have an app which offers a demo version and a full version. They both share the same code and I just set a flag in my plist file, and somewhere in my code I do
if (demo_mode) {
// ...
} else {
// ...
}
This is easy for testing, but not suitable for the app store, since I want slightly different app icons and app names for them.
I could as well make a copy of the project, but then I'd have to apply changes in one project to the other (bugfixes, UI changes etc). That's why I want to use the same source folder for two projects.
All you need is one project with two target.
You can make different config or file with different target, also share the same code, but submit to App Store separately.
Let me know if you need more help.
You are probably going to use StoreKit to provide a non-consumable purchase for users to upgrade, and use this as your flag. StoreKit usually involves a good deal of boilerplate, so you might consider implementing something like MKStoreKit to handle some of that for you. You can use MKStoreKit to easily check if the user has purchased the upgrade or not. Restoring purchases is also relatively easy.
I have an existing iOS application that I need to be able to build and release multiple versions of for different clients.
This application interfaces with hardware that is available from a handful of different companies, the hardware is identical but each company sells the hardware under a different name
This is a free app, the goal is not to spam the appstore with multiple versions of the same app, the goal is to allow companies that sell rebranded hardware to have a mobile app that uses the brand name that they use for the hardware.
What I need to be able to do:
Build multiple versions of the same application that can be submitted to the Appstore, each version would be submitted under a different companies apple account. I would assume that means multiple projects so that each project can use a company specific provisioning profile
Each version has some different images (Icon, startup image, maybe a few others)
Each version has some different strings (Company name, Product Name, maybe a few others)
With Android I just create a library project and I can override strings and images with a trivial amount of effort.
With iOS I haven't found an obvious answer.
I looked into adding a new target to my existing project but I don't think that will work:
- I can't figure out how to replace images beyond the icon and starting screen
- I can't figure out how to replace strings
- Would I be able to use different provisioning profiles for the different apps that compile with the same project? I know the target settings allow different provisioning profiles, but doesn't the project settings have its own set of provisioning profiles?
Can I package the current application into a library that other projects can use and replace images/strings? So each version would have its own xCode project but use the same code.
Maybe I need to work more with the idea of multiple targets...
I am using xCode 4.2, but I am prepared to move to a newer version if necessary
Create multiple targets that use different Info.plist files. The biggest difference will be different bundle identifiers. You can also define different preprocessor macros that will control the conditional compilation of various chunks of code.
Alternatively/additionally, you can put your build configuration settings (including the changing location of the Info.plist file) into *.xcconfig files and reference those in your project, info, configurations area. Then, you can build a different version of your app by simply by changing your scheme. Putting build configration settings into files is a huge win for configuration control too.
Here's a link to setting up *.xcconfig files: http://itcoding.blogspot.com/2011/03/using-xcconfig-abandoning-build-panel.html. I've seen other articles like this as well -- but this one will get you started.
Good luck.
I did this differently at my last company, where we generated around 8 apps from one primary source repository.
We created one project that required one external class, call it Config. That class vended the unique info that makes each app unique.
Then to spin one app you create your App project, include the common "library", provide the Config.m file (Config.h is common), add the unique images etc.
This was very helpful for me. It is essentially the multi-target approach but you customize it for a company and you upload to their account.
https://developer.apple.com/videos/play/wwdc2019/304/ See from the 17 minute mark.
To summarize, you partner with the company you are developing for, from their Apple Connect account, they assign you as the developer and marketing role for the specific apps you are developing for them. You upload your builds to their account. They get ultimate decision of when they will release it and who will test it with TestFlight.