How to make same iOS Swift App with only some differences in the code and assets with scalable and clean mode

Question

I have this needs.

I developed an app and I want to duplicate it. I can copy and paste the project but if I do this 10 times can be a problem. The problem is, if I f

Answer 1

Create a single project with multiple targets. Each target would have a different info.plist and whatever other changes you need, but shared source.

Answer 2

I would do this with Git:

In your origin repository, prepare your project with placeholders:

• Try to make a file where you define constants for the domain, the integers you mentioned etc. That file you could call Constants.swift.

• Put all assets you need to change in one .xcassets. (a different one than the assets that will stay the same) For example the Icon. You can already add the image-sets you want to have in your apps, but leave them empty (or alternatively add placeholder images)

• Write a placeholder for the app name and package name

• create a default splash screen (I guess you mean the launch screen). This could either be empty or if you want it to be similar in all apps, prepare it a bit so you don't have to change much for each app

When you have committed and pushed your main project, create forks for each of your apps. In the forks, you can change everything that you have prepared as placeholder.

If there is a but somewhere, fix it in the origin. Then you can merge the changes easily to each of your forks.

Answer 3

Here's my setup:

(1) Create a new project of type Framework.

Move all shared code - extensions, subclasses, image assets, even .xib files - into a this project. I created an App/Bundle ID ("com.company.framework") but I'm not sure if it is necessary for App Store submission. Also, checking off the "Allow app extension API only" will remove the warning you'll get.

For files like images or text files, create bundles and drag the bundles into the framework. I've found you can add new images/files through Xcode. To retrieve them, here's the code:

public func returnKernel(_ named:String) -> String {
    let myBundle = Bundle.init(identifier: "com.company.framework")
    let kernelPath = (myBundle?.path(forResource: "cikernels", ofType: "bundle"))! + "/" + named + ".cikernel"
    do {
        return try String(contentsOfFile: kernelPath)
    }
    catch let error as NSError {
        return error.description
    }
}

(2) Create a second project, this time for your specific app.

Let's say you called your framework "Kernel". All public declared code is available by adding:

import Kernel

Now, here's the best part (for me): you have two ways to work with this setup.

(3a) Drag your framework .xcodeproj into your app project.

PROS: You can (a) make changes to your framework source code and (b) build both at once.

CON: You can only have one app project open at once because Xcode detects that the framework project is open.

(3b) Drag the Kernel.framework project into your app project.

PRO: You can have all your apps open at once.

CONS: You will need to (a) make your framework source changes in it's project, and - I think - (b) manually update every app with the rebuilt framework.

I say "I think" because I use the former set up. It's a small price to pay to have one app open at a time. Typically if you are making a framework change it's for a single app.

FINAL NOTES:

• Changes made to the framework while working in "app #1" will be picked up when you open "app #2".

• I have separate Git repositories for (a) each app and (b) my framework, both locally and on GitHub. Works perfectly.

• I have separate Bundle/App IDs (and versions) set up for (a) each app and (b) my framework in the Developer Portal.

• Come App Store submission time, I archive the app and upload it. The framework comes along for the ride.