In my project i have added multiple projects for different environments like QA, Stage, Production, UAT. Will it has any impact on app size. Any drawbacks about having multiple targets in my project. Appreciate any help.
It shouldn't affect the app size, since when archiving the app you archive only one target. Unless, of course, the have dependencies between them, which shouldn't be the case if they are for different environments.
Related
If there are say 2 frameworks(framework-test,framework-live), one pointing to a test area and the other to live environment is there any way to keep both in the same xcode project and just change based on target or some flag?
I wanted to add a WatchKit Extension (with SwiftUI supported on iOS13+) to my existing app (target iOS12) while keeping both codebase separated (two repos).
How can I separate the WatchKit Extension code from the Mobile One?
Will my Watch App with SwiftUI only work for users with WatchOS 6 and iOS13 without affecting the existing users with iOS12?
How about the app binary size increase?
Thanks for reading!
I am not sure if there is a simpler solution, but this one should work:
Separation of both apps:
If you open in Xcode the Source Control navigator, you see that Branches, Tags and Remotes belong to a main entry in the Project navigator, i.e. to a Xcode project. So in order to have separate repos, you need separate Xcode projects to which you can assign separate repos.
You can however have multiple projects in one workspace, so that all files are available in this workspace.
To have one standalone app, and one app with a watch extension, just setup a workspace with your standalone app, and add another new project. This new project needs all files of the original app plus the watch extension.
Since you need files from one project also in the other, you could drag them from one project to the new one, but then they will be copied (a green + badge is shown during dragging). Usually this is not what you want, since you usually don’t want to maintain two copies separately. Instead, you can show such a file in the finder, and then drag it from the finder to the new project. In this case, you have the option only to copy the reference.
Independence of both apps:
Since you have two separate projects, you can set the deployment target in the target’s build settings as required.
Size:
Each project will get separate products, the standalone app only an xxx.app, and the new project xxx.app, Watch.app, and Watch Extension.appex. So there should be no overhead.
EDIT (due to the comment of Ouadie in his question):
I am not sure if I understand your problem:
With the procedure above, you get a single workspace with two separate projects that share part of the files.
The „mobile project“ is the same as you use right now. It has only a single target (despite of test targets) that is built exclusively with the sources required. It has thus the same size as now.
The „watch project“ is new. It has 3 targets, the „mobile“ target, the Watch target, and the Watch Extension target (despite of test targets). It is built with the shared sources, and the additional watch extension sources. Its size is thus larger, but the increase depends of course on your sources.
Since you have 2 repos, the projects are decoupled, but both repos share some files. If you want to decouple them completely, you could copy the files from your current project to your new project (instead of copying only references), but then you had to maintain 2 copies.
I hope this helps!
I have 3 targets in my iOS application namely Stage, Preprod and Prod. I added NotificationServiceExtension for the Stage target for the development purpose. Since the added NotificationServiceExtension is not available in other targets i.e pre-prod and prod, hence am not able to use the NotificationServiceExtension. Do i have to added 2 more NotificationServiceExtension for Preprod and prod targets? Or there is some different solution?
Thank you.
I'd recommend you to avoid using different targets for different environments. The better way is to use different build configurations, because:
.xcodeproj file will be much smaller
You will need single app extension
You will not need to add each new file to every target
You will not need to recompile the whole app for different environment
So in your case I'd create the following configs:
StageDebug
StageRelease
PreprodDebug
PreprodRelease
ProdDebug
ProdRelease
Here is a nice article about creating build configurations, have a look.
We have 3 apps that we maintain, that all use the same menu controller and Core Data model. In addition, one of the apps uses several views and controllers from one of the apps. It's getting to the point that we need to find some way to separate into different projects to prevent painful Xcode project merges. Right now all the code is mixed in together and each app has its own target in one Xcode project.
Is there any way we can separate the project easily into different projects that have AppA, AppB, and AppC where AppB and AppC depend on AppA?
Depending on how each app is different, you can create different targets in your Xcode.
Here's a docs on how you create Xcode targets.
If that does not suit your need, you can create multiple projects and reference files from other projects. I really can't tell what you'd need without more information.
Maybe use cocoapods.
You can make your own (private) pods for the various files that your projects rely on and then keep them updated in their own repository, and then the projects can include the pod and update it when needed. You can also point specific projects to specific branches of the pod repo etc.
(Not sure whether Core Data is supported in pods yet though, might be)
I have an iOS app with multiple targets: Prod, Beta, Alpha. Each target has different icons, a different bundle ID, and different preprocessor macros.
Unfortunately, there's also a lot of duplication across the targets (URL schemes, build settings, etc.). It's a pain to have to make changes to this configuration in every target, and always worry that I missed a target.
Am I doing it wrong?
I was indeed doing it wrong.
I ended up merging targets and creating a Beta configuration, in addition to the existing Debug and Release configurations.