Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Managing multiple versions of an iOS App

Tags:

ios

swift

xcode6

Lets say I have an iOS App for let's say, Football news, now I want to create an other version for Basketball news that will be based mostly on the Football App but with a freedom to create a different behaviour in some aspects of each app + adding more apps in the future for other news subjects.

An other condition is that they will have a separate CoreData model, assets, icon etc.

As I understand I have few options:

  1. Manage the apps separately, place them in the same directory and point to the shared files in the first (Football app).
  2. Create a different target for each app in the same project
  3. Create a Workspace with one project that will hold the common code and a project for each project.

What are the pros / cons for each option and what are the best practices in this situation ?

Just to clarify - the apps I mention are an example, the App is not for news, and it must be a different app for each concept.

Thanks

like image 385
shannoga Avatar asked Jun 05 '15 08:06

shannoga


1 Answers

I work in an enterprise environment, and we have a mobile app that's a product of the company I work for. We sell licenses of that software to our costumers, which are always huge companies. Our app doesn't go through the App Store.

Each of our clients have some sort of customization on the app, either by simply changing their logos or even adding some specific features for one of them. What I mean by this is: we have to deal everyday with a situation very close to what you are describing, and here's my two cents.

In advance: sorry if I'm too honest sometimes, I don't mean to offend anyone.

1. Manage the apps separately, place them in the same directory and point to the shared files in the first (Football app).

Well... That's a weird solution, but it sure could work. It might be hard to maintain locally and even harder when using SVN/Git (specially when working on a team).

I had some issues before related to symbolic links before, but I'm not sure if that's what you are referring to in this option. If you explain a little bit better, I can edit this and try to give you a better opinion.

2. Create a different target for each app in the same project

That's a better start, in my opinion.

We use this approach mostly to handle various possible backend servers. For example, one of our targets uses our development backend server, while another target uses the production server. This helps us ensure that we can use the development-targetted app without risking serious costs to our team (due to a mistakenly placed order, for instance).

In your case, you could for example configure preprocessor macros on the targets to enable/disable some target-specific feature that's called by code. You could also use different storyboards for each target.

The downside of this option is that the code will be messy, because every piece of code will be on the same project. This is the main reason why I'd go with option #3.

3. Create a Workspace with one project that will hold the common code and a project for each project.

Again, I'd go for this. To be honest, we're not using this at our company YET, but that's due to internal reasons. I'm trying to get this going for our projects as soon as possible.

I wouldn't call it easy to set up, but if done properly it can help you save some time because of maintenance reasons. You'll be able to reuse any code that's possible to reuse, and still be able to keep your target-specific images, classes and views to their own "container"(project).

This way you'll get a default project (the app itself), multiple targets for it, and a "framework" to keep the code for each one of the targets. In other words, you'll be able to share code between the multiple targets/apps, and at the same time you'll be able to separate what belongs to each one of them. No messy project :)

I'm not sure about how CoreData is compiled by Xcode, as we're not using it. But check out the answer I just did for another question. It's not Swift, but that shouldn't make much difference as almost all of the answer is about configuring the workspace to achieve this solution. Unfortunately I think it too big, that's the reason why I'm linking the answer instead of pasting it here.

If you need any help setting that up, let me know and I'll do my best to help you.

like image 93
B.R.W. Avatar answered Sep 19 '22 01:09

B.R.W.