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.
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?
Our project are using different build configurations to separate server environments
(e.g: Production, Staging)
#if STAGE
public struct endpoint {
public static let api = URL(string: "https://stage.???.com/api")!
}
#else
public struct endpoint {
public static let api = URL(string: "https://prod.???.com/api")!
}
#endif
}
Chances are sometimes we need to switch between different configs to debug repeatedly,
however, Xcode will rebuild almost all files when switching configurations, even if we didn't change files.
Is it possible to optimize Xcode to prevent building almost every files when we change configurations, to let it build just like an incremental build?
Below is part of our configs in build settings
Environment:
Xcode 11
Swift & Objective-C mixed project
Cocoapods to install 3rd party libraries
Perhaps there is a different strategy you can use to avoid rebuilding.
I have a game which I wrote which is a server based game. I have a version of the server that runs on MacOS for easier debugging and is built with Xcode, and the game is an iOS game. Both client and server support building different environments, however I do not control them using the Build Configuration per se. Instead I use targets as the main way of controlling access to environments.
I use the following approaches:
Command line arguments to "control" environment
Using Config files to "control" environment
Using Build Target to "control" environment
All 3 are used in the case of the server (since it is a command line executable), and the last two are used in the case of the game.
The trick here is that my code allows for the dynamic switching of environments (and this is really the key element to this approach).
I use the Build Target to control the extent of switching allowed. For example, my Dev target allows switching between Dev, QA, Stage, and Prod. My QA target allows switching between QA, Stage, and Prod, and my AppStore target only supports Prod.
Of course, backing the targets are build configurations. For build configurations I use Debug, DevDebug, Release, DevRelease, and AppStore. So plain Debug configuration and Release configuration are used by the "QA Target". And DevDebug configuration and DevRelease configuration are used with the "Dev target". I use 3 targets in all.
When the app starts, if it can take a command line and an env is defined, it uses it (if it can). The next fallback is a config file (You can easily edit this if you are on the simulator or running a MacOS app). Then what's baked in.
This also implies I have an environment chooser. I have found that also allowing a chooser to be selected from network error popups is also handy (in case you are in the wrong env). Choosers are only available on non-AppStore builds.
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.
I have several apps that using the same core framework, Since each app have some small differences i'm searching for the best way to build the framework with relevant code and parameters.
The best solution (that is not so good) that i found is:
For different code compilation - using targets that include different classes
For different configuration using different Swift flags for each configuration (e.g. debug, release...)
The problems are:
I'm using several targets and each target duplicate the project configuration and i need to maintain all. this approach can lead to some bugs if i change configuration in one target but forget to change it on other target.
For debug/release & stagingA/stagingB/production I'm creating specific configurations instead combining them (This solution is problematic since for each staging i need to duplicate it for release and debug):
release production
debug production
release stagingA
debug stagingA
release stagingB
debug stagingB
Apps struct is:
App A include CoreFramework with code adjustments for A
App B include CoreFramework with code adjustments for B
Each app have debug, release, production... configuration. This configurations affect the framework (these configuration run also on the framework)
==> I'm looking for other/better way to configure my apps project's
Don't make "code adjustments" in the framework based on which client is calling it.
Construct your framework as if it were something provided as a binary release by an external supplier. Any behaviour that may be variable can then only be controlled by run-time configuration through a public API.
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.